Modellazione di comportamenti adattivi per agenti

 degli Studi di Roma \La Sapienza"
Universita
di Ingegneria
Facolta
Corso di Laurea Triennale in
Ingegneria Informatica
relazione di stage
Modellazione di
comportamenti adattivi per
agenti robotici all'interno di
un ambiente dinamico
Laureando:
Fernando Risi
Relatore:
Luca Iocchi
Anno Accademico: 2006-2007
Ringraziamenti
Questa pagina contiene i miei ringraziamenti alle persone che mi hanno
aiutato, sostenuto, o che comunque reputo importante vengano menzionate.
Anzitutto desidero esprimere la mia gratitudine al Prof. Luca Iocchi, per
avermi introdotto al mondo dell'intelligenza articiale e per avermi concesso
l'opportunita di poter lavorare nel mondo della Robocup.
Vorrei inoltre ringraziare tutti i compagni del Team SPQR per l'aiuto, la
compagnia ed i preziosissimi consigli.
Un rigraziamento speciale va alla mia famiglia ed ai miei amici che mi
sono sempre stati vicini.
Indice
1 Introduzione
4
1.1 Traccia dell'esposizione . . . . . . . . . . . . . . . . . . . . . .
2 Agenti robotici in ambiente dinamico
6
7
2.1 Agenti robotici . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2 Scenario applicativo: la Robocup . . . . . . . . . . . . . . . .
9
2.3 Architettura del team S.P.Q.R. . . . . . . . . . . . . . . . . . 13
3 Modellazione di piani tramite Petri Net Plans
14
3.1 Generalita sulle Reti di Petri . . . . . . . . . . . . . . . . . . . 14
3.2 Descrizione del comportamento di un agente robotico tramite
Petri Net Plans . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Il simulatore 3D USARSim
21
4.1 Architettura di USARSim . . . . . . . . . . . . . . . . . . . . 22
4.2 Unreal Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Il protocollo di comunicazione . . . . . . . . . . . . . . . . . . 23
4.4 World Controller . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5 WorldControllerClient2007 . . . . . . . . . . . . . . . . . . . . 26
2
INDICE
5 Pianicazione del moto in ambiente dinamico
3
28
5.1 Il paradigma delle velocita relative . . . . . . . . . . . . . . . 29
5.2 Velocita determinata . . . . . . . . . . . . . . . . . . . . . . . 33
6 Conclusioni
36
6.1 Obiettivi raggiunti . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A Installazione ed utilizzo di USARSim
38
Capitolo 1
Introduzione
La seguente relazione descrive il lavoro svolto durante lo stage trimestrale
tenutosi presso il DIS (Dipartimento di Informatica e Sistemistica della Facolta di Ingegneria dell'Universita di Roma \La Sapienza") in collaborazione
con il gruppo SPQR Legged. Tale gruppo, composto da studenti e ricercatori, partecipa ogni anno alla Lega Sony Legged [WEB-4L] della competizione
internazionale RoboCup [WEB-RB].
Figura 1.1: Sony AIBO Ers7
4
CAPITOLO 1.
INTRODUZIONE
5
Il programma dell'edizione della Robocup di Atlanta 2007 prevede una
challenge di \obstacle avoidance" in cui due robot di una squadra devono
attraversare il campo evitando gli altri robot presenti sul percorso (per una
completa descrizione della challenge si rimanda a [WEB-CH07]).
Una prova di questo tipo interessa molti ambiti e potrebbe essere oggetto
di almeno tre stage di questo tipo. Si potrebbe suddividere il problema in:
1. riconoscimento degli ostacoli a partire dall'immagine acquisita dalla
telecamera del robot;
2. tracciamento degli ostacoli, in modo da avere informazioni precise sulla
posizione e sulla velocita, robusto ai rumori della percezione;
3. pianicazione di un percorso che eviti urti con i robot precedentemente
tracciati.
Nello stage cui riferisce questa relazione si e focalizzata l'attenzione sull'ultimo punto che puo essere cos riformulato: \pianicazione del moto di
un robot mobile da una congurazione iniziale ad una nale evitando gli urti
con gli ostacoli presenti nell'ambiente".
Nella problematica classica, ove il robot e vincolato al movimento su un
piano, per congurazione si intende posizione e rotazione del robot. Per ambiente dinamico si intende un ambiente in cui la congurazione degli ostacoli
non rimane ssa per tutto il tempo necessario al robot per espletare il suo
compito.
La mancanza dei primi due moduli, sviluppati in parallelo da altri membri
del team, non ha permesso il testing immediato sul robot possibile, almeno
CAPITOLO 1.
INTRODUZIONE
6
in parte, solo nell'ultima dell'attivita di stage. Si e quindi ricorso all'uso di
un simulatore di ambienti robotici USARSim, descritto nel capitolo 4, grazie
al quale e stata possibile un'accurata attivita di testing.
1.1
Traccia dell'esposizione
Nel capitolo 2 vengono introdotti il concetto di agente robotico ed ambiente dinamico. Successivamente si descrive l'architettura adottata
dal team S.P.Q.R.;
nel capitolo 3 viene denito il formalismo basato sulle Reti di Petri per
la denizione di piani;
nel capitolo 4 viene descritto il simulatore di ambienti robotici 3D
USARSim utilizzato durante lo sviluppo del modulo;
nel capitolo 5 viene presentato il paradigma delle velocita relative,
utilizzato per rilevare le collisioni previste;
nel capitolo 6 sono esposti gli obiettivi raggiunti e gli sviluppi proposti
per il futuro al ne di migliorare le prestazioni del robot in presenza di
ostacoli;
nell'appendice A viene descritta la procedura per la corretta installazione di USARSim
.
Capitolo 2
Agenti robotici in ambiente
dinamico
In questo capitolo viene data la denizione di agente razionale autonomo e di
agente robotico o robot (in [RN98] viene denito robot un agente articiale
attivo il cui ambiente e il mondo reale). Vengono illustrate le caratteristiche
hardware e software che lo deniscono, e le proprieta che lo rendono in grado
di operare in ambienti dinamici, incerti e imprevedibili.
2.1
Agenti robotici
Nell'ambito dell'intelligenza articiale un agente e un sistema che ha la capacita di percepire alcune caratteristiche dell'ambiente circostante tramite
sensori ed intervenire su di esso tramite attuatori (gura 2.1). In particolare ciascun agente e costituito da due componenti: il programma d'agente
(che realizza la corrispondenza tra percezioni e azioni) e l'architettura (che
7
CAPITOLO 2.
AGENTI ROBOTICI IN AMBIENTE DINAMICO
8
Figura 2.1: Struttura di un agente robotico
costituisce il meccanismo di calcolo tramite il quale viene eseguito il programma d'agente). Compito dell'architettura e fornire al programma d'agente i
dati provenienti dai sensori, eseguire il programma d'agente e trasmettere
agli attuatori le azioni scelte dal programma man mano che queste vengono
generate.
L'insieme delle percezioni no all'istante preso in considerazione e denito
\sequenza di percezione". Per ogni sequenza di percezione si puo denire un
agente razionale come l'entita in grado di compiere azioni che massimizzino
i valori attesi delle misure prestazionali, ovvero i criteri che determinano il
grado di successo dell'agente in riferimento ad un obiettivo pressato.
La progettazione di un agente e indissolubilmente legata all'ambiente in
cui l'agente opera. In [IOC99] e oerta la seguente classicazione dell'ambiente:
dinamicita (staticita): l'ambiente varia anche mentre l'agente e in fase
di elaborazione
imprevedibilita (prevedibilita): l'ambiente, data la sua complessita e la
CAPITOLO 2.
AGENTI ROBOTICI IN AMBIENTE DINAMICO
9
sua parziale accessibilita risulta essere, dal punto di vista dell'agente,
non deterministico
parziale osservabilita (completa osservabilita): l'ambiente non e interamente osservabile e l'agente non puo' venire a conoscenza di tutte le
sua caratteristiche
Altro aspetto fondamentale nella denizione di un agente razionale riguarda la sua autonomia: un sistema e autonomo quando il suo comportamento viene determinato dalla sua esperienza personale. Sarebbe inoltre
ragionevole dotare un agente di una conoscenza di base oltre alla capacita di
apprendimento; ma la denizione piu comune di autonomia e quella per cui
\un agente e autonomo se in grado di eseguire compiti complessi in ambienti
reali, senza l'assistenza o la supervisione umana". E' questa la strada che si
sta cercando di percorrere nell'ambito della RoboCup, ovvero rendere i robot
in grado di giocare una partita di calcio in maniera del tutto autonoma. (Per
una denizione piu esaustiva di agente robotico e di intelligenza articiale si
rimanda a [NAR06] e [RN98])
2.2
Scenario applicativo: la Robocup
La Robocup (Robot Soccer World Cup) e un campionato internazionale nato
nel 1993 con l'obiettivo di sviluppare automi per promuovere la ricerca e
l'istruzione nel campo dell'intelligenza articiale. La prima edizione, si svolse
nel 1997 a Nagoya (Giappone).
Ma il traguardo, forse troppo ambizioso e sicuramente molto lontano, del-
CAPITOLO 2.
AGENTI ROBOTICI IN AMBIENTE DINAMICO
10
la RoboCup e quello di creare entro il 2050 una squadra di robot in grado di
battere i vincitori dei mondiali di calcio, ripetendo il successo del supercomputer della IBM \Big Blue" che nel 1997 sconsse Garry Kasparov, grande
maestro di scacchi russo, campione del mondo dal 1985 al 2000.
L'idea di usare il calcio per fare sperimentazioni con i robot fu avanzata
per la prima volta nel 1992 nel saggio \On Seeing Robots" di Alan Mackworth [WEB-OSR], professore di informatica alla University of British Columbia
in Canada. Mackworth era convinto che il calcio ponesse una sda maggiore
degli scacchi, poiche i robot avrebbero dovuto vedere e interagire tra loro.
In parallelo, ma separatamente, nel 1992 un gruppo di ricercatori giapponesi
organizzo a Tokio un seminario su \Le Grandi Sde dell'Intelligenza Articiale": si discusse su come utilizzare il calcio per promuovere la scienza e la
tecnologia.
Figura 2.2: l'agente robotico Sony AIBO ERS7
L'elevata complessita ed eterogeneita delle problematiche arontate ha
portato gli organizzatori ad operare una suddivisione delle iniziative. Ne e
CAPITOLO 2.
AGENTI ROBOTICI IN AMBIENTE DINAMICO
11
nata una organizzazione del progetto in Leghe. Una delle leghe previste e la
4 Legged league, in cui e previsto l'utilizzo dell'agente robotico AIBO ERS-7
(g. 2.2).
Nelle gure 2.3. e 2.4 sono presentati i sensori e gli atturatori dell'ERS-7.
Figura 2.3: sensori ed attuatori di AIBO
Figura 2.4: sensori ed attuatori di AIBO (robot di schiena)
Le competizioni prevedono incontri di due tempi, della durata di 10 mi-
CAPITOLO 2.
AGENTI ROBOTICI IN AMBIENTE DINAMICO
12
nuti, tra due squadre composte da quattro robot Sony AIBO. L'ambiente in
cui i robot si trovano ad operare e una particolare ricostruzione di un campo
da calcio (Figura 2.5).
Figura 2.5: l'ambiente di gioco
Risulta evidente che la progettazione dell'architettura e del programma
d'agente dovranno tenere conto di un ambiente reale:
dinamico: varia piuttosto velocemente a causa della presenza di molti
agenti che interagiscono con la palla
imprevedibile: il programma d'agente degli avversari non e noto, sarebbe comunque molto costoso, da un punto di vista computazionale e
progettuale, modellare e prevedere l'evoluzione di uno stato iniziale
parzialmente osservabile: non sempre le percezioni (anche utilizzando
quelle comunicate dagli altri robot) forniscono dati attendibili dell'ambiente
CAPITOLO 2.
2.3
AGENTI ROBOTICI IN AMBIENTE DINAMICO
13
Architettura del team S.P.Q.R.
Dal 2005 il team S.P.Q.R. utilizza l'architettura GT2004 [WEB-GT04], presentata nella Robocup di Lisbona del 2004, caratterizzata da ottime scelte
progettuali ed una forte modularita che ha permesso la rapida integrazione
del codice sviluppato dai membri dell'SPQR.
Come si puo notare dalla Figura 2.6 l'architettura e di tipo deliberativo
(per una panoramica delle tipologie di architettura si rimanda a [ST-PP]):
il usso di informazioni passa interamente per il modulo gestore del comportamento. Cio comporta una parziale perdita di reattivita compensata da
opportuni accorgimenti in fase di pianicazione.
Figura 2.6: architettura utilizzata da SPQR dal 2005
Capitolo 3
Modellazione di piani tramite
Petri Net Plans
Questo capitolo presenta una rapida introduione al formalismo dei Petri Net
Plans con una descrizione delle caratteristiche principali e dei meccanismi
che regolano la loro evoluzione. Per una denizione puntuale si rimanda a
[ST-PP], [ST-FG] e [ZIP04].
3.1
Generalita sulle Reti di Petri
Una rete di Petri (conosciuta anche come rete posto/transizione o rete P/T)
e una delle rappresentazioni matematiche di un sistema distribuito discreto. Come un linguaggio di modellizzazione, esso descrive la struttura di un
sistema distribuito come un grafo bipartito con delle annotazioni. Ovvero,
una rete di Petri ha dei nodi posti, dei nodi transizioni e degli archi diretti che connettono posti e transizioni. Le Reti di Petri sono un linguaggio
14
CAPITOLO 3.
MODELLAZIONE DI PIANI TRAMITE PNP
15
formale graco con il quale e possibile modellare sistemi caratterizzati dall'essere concorrenti, asincroni, distribuiti, paralleli, non deterministici e/o
stocastici [MUR89].
Il primo ad introdurre questo formalismo e stato nel 1962 da Carl Adam
Petri in [PET62], e grazie del suo grande potere di modellamento (pari a
quello delle macchine di Turing) ha trovato numerosi campi di applicazione.
[MUR89] fornisce la seguente denizione formale:
Una Rete di Petri e una quintupla P N =< P; T ; F; W; M0 > dove:
P
T
F
W
= ft1 ; t2 ; :::; t
m
g e un insieme nito di places ;
g e un insieme nito di transitions ;
( ) [ ( ) e un insieme di archi (relazioni di usso);
: ! f1 2 3 g e una funzione di peso;
! f0 1 2 3 g e la marcatura iniziale;
0 :
[ =;e \ =;
M
P
= fp1 ; p2 ; :::; p
P
F
P
T
n
T
T
;
;
;
P
P
; :::
;
;
; :::
T
La struttura di una Rete di Petri (P,T,F,W) senza nessuna marcatura
iniziale specicata e denotata N.
Una Rete di Petri data una marcatura iniziale e denotata da (N,M0 ).
Una Rete di Petri e un grafo diretto, pesato e bipartito, con uno stato
M0
chiamato marcatura iniziale, in cui i nodi del grafo possono essere di tipo
Place (Figura 3.1) o Transition (Figura 3.2), collegati da archi direzionati e
pesati che possono congiungere solo nodi di diverso tipo.
La marcatura M consiste in un vettore di n interi positivi, dove n e il numero dei places della Rete. La p-esima componente del vettore di marcatura
( ) denota il numero di token associati al p-esimo place (in gura 3.3 un
M p
CAPITOLO 3.
16
MODELLAZIONE DI PIANI TRAMITE PNP
Figura 3.1: Place
Figura 3.2: Transition
esempio di place con tre token associati).
Figura 3.3: Place con 3 tokens
Se esiste un arco da un place
p
ad una transition t,
place per t, se viceversa esiste un arco che collega t a
p
p
viene detto input
si dice che
p
e un
output place per t. Una transition e detta pozzo (sink) se ha solo archi
entranti, sorgente (source) se ha solo archi uscenti. Se nella rete non sono
presenti places che fungono sia a input che da output per una determinata
transition (self loops) la rete viene detta pura, se ogni arco della rete ha peso
unitario la rete e detta ordinaria.
Da un punto di vista modellistico e possibile rappresentare condizioni
ed eventi tramite places e transitions. Le precondizioni (input places) e le
prostcondizioni (output places) di un evento sono rappresentate quindi da
insiemi di places, mentre l'evento stesso e rappresentato da una transition.
La presenza di un token in un determinato place puo essere interpretata come
il vericarsi della condizione associata al place.
CAPITOLO 3.
MODELLAZIONE DI PIANI TRAMITE PNP
17
Una Rete di Petri modica la sua marcatura nel tempo, cos come il
sistema dinamico che modellizza evolve nel tempo. La regola che determina
l'evoluzione di una Rete di Petri (regola di f iring ) e la seguente:
una transizione t e detta abilitata se ogni suo input place p e marcato
da almeno w(p; t) token, dove w(p; t) e il peso dell'arco che collega p e
.
t
La transition fa ring se e abilitata e l'evento ad essa associato si
verica
Quando una transition fa ring rimuove (consuma ) da ogni input place
(
) token, e produce in ogni output place p
pi w pi ; t
o
(
) token
w po ; t
Se una transition ha piu di un output place, i quali sono collegati ad altre
transition indipendenti, si verica quanto mostrato in gura 3.4, che modella
una situazione di parallelismo (concorrenza) tra gli eventi associati a t1 e t2.
Se consideriamo invece la situazione di gura 3.5, in cui sia t1 che t2 siano
Figura 3.4: t1 e t2 sono eventi concorrenti
abilitate, notiamo che e presente una situazione di conitto. Solo una tra
CAPITOLO 3.
MODELLAZIONE DI PIANI TRAMITE PNP
18
1 e t2 potra infatti fare ring rimuovendo il token in p. Questa situazione
t
modella il meccanismo di mutua escusione.
Figura 3.5: una situazione di conitto
Estendendo i concetti n qui esposti e possibile ottenere un potente strumento di modellazione procedurale, idoneo alla rappresentazione di piani
prodotti da un pianicatore condizionale del tipo proposto in [IOC99].
3.2
Descrizione del comportamento di un
agente robotico tramite Petri Net Plans
In questo paragrafo si vuole mostrare come sia possibile modellare il comportamento di un agente robotico con architettura deliberativa tramite i Petri
Net Plans (PNP), formalismo che permette la realizzazione di azioni non
istantanee e concorrenti.
Nell'architettura della SPQR Legged, un Petri Net Plans descrive una
sequenza di azioni attivate se vericate determinate condizioni descritte nel
piano.
CAPITOLO 3.
MODELLAZIONE DI PIANI TRAMITE PNP
19
Il concetto di azione viene modellato tramite un costrutto composto da
due transition, associate agli eventi di inizio e di ne dell'azione e da un
place, detto di esecuzione dell'azione, che e output place per la transition di
inizio e input place per la transition di ne.
Figura 3.6: costrutti di un'azione
Arrivato a start.action l'esecutore di piani non fara altro che richiamare la funzione initialization() della classe in cui l'azione e denita quindi
verra eseguito l'executeStep(), n quando non verra attivata la transation
di che determina la ne dell'azione, ed inne verra richiamata la funzione
termination().
E' ovviamente possibile creare piani piu complessi in cui azioni diverse
vengono eseguite in parallelo semplicemente combinando costrutti di azioni
e costrutti condizionali.
Un semplice esempio di Petri Net Plan in cui vengono eseguite piu azioni
in parallelo e mostrato in gura 3.7.
CAPITOLO 3.
MODELLAZIONE DI PIANI TRAMITE PNP
Figura 3.7: un Petri Net Plan
20
Capitolo 4
Il simulatore 3D USARSim
In questo capitolo viene fatta una introduzione ad USARSim, il simulatore
utilizzato nel testing del modulo sviluppato.
USARSim nasce alla National Science Foundation (NSF) nell'ambito del
progetto Urban Search And Rescue (USAR). In UsarSim viene fedelemente
riprodotto un ambiente robotico, includendo una serie di arene, di robot e
la sensoristica necessaria a simulare il comportamento di un robot reale in
azione.
Il simulatore si basa sull'Unreal Engine, motore graco di Unreal Tournament 2004, videogioco sviluppato dalla Epic Games, cui sono demandati il
rendering graco della scena tridimensionale e la simulazione delle interazioni
siche tra gli oggetti.
21
CAPITOLO 4.
IL SIMULATORE 3D USARSIM
22
Figura 4.1: un AIBO ERS-7 in USARSim
4.1
Architettura di USARSim
L'architettura di USARSim e assimilabile a quella di un classico sistema
client-server:
Lato Client: Della parte client fanno parte il Controller dell'utente e
l'Unreal Client, che fornisce il feedback video relativo ai punti di vista
disponibili (una camera per ogni robot ed una visuale esterna);
Strato di rete:
Tutti i client scambiano dati col server attraverso lo
strato di rete utilizzando il protocollo TCP/IP;
Lato server:
Come accennato, lato server la gestione della simulazio-
ne e demandata all'Unreal Engine che si avvale della mappa dell'arena
corrente, i dati dell'ambiente di simulazione ed i modelli utilizzati nella
simulazione.
CAPITOLO 4.
IL SIMULATORE 3D USARSIM
23
La comunicazione con il lato client e bipartita: i dati relativi al feedback
graco vengono inviati direttamente in rete ai client connessi, il dialogo con
i controlli e invece gestito tramite il controllo di comunicazione Gamebots.
4.2
Unreal Engine
Come accennato, il motore graco di USARSim e l'Unreal Engine rilasciato
dalla Epic Games con UT2004. L'Unreal Engine e un completo sistema di
sviluppo e simulazione di ambienti tridimensionali composto da:
un render graco 3D, Unreal Client, in grado di fornire visuali sia in
prima che in terza persona della simulazione, ideale per esigenze di
debug e sviluppo;
un motore per le iterazioni siche, Karma Engine che simula gravita
ed iterazioni tra oggetti;
un tool di authoring 3D, Unreal Editor, per la modellazione di mappe
ed agenti;
un linguaggio di scripting, Unreal Script, per modicare con relativa
facilita il comportamento del sistema.
4.3
Il protocollo di comunicazione
Il protocollo di comunicaione dell'unreal engine e proprietario; questo rende
dicile l'accesso ad Unreal Tournament da applicazioni esterne. I ricercatori
dell'ISI della University of Southern California hanno creato Gamebots allo
CAPITOLO 4.
IL SIMULATORE 3D USARSIM
Figura 4.2: Architettura di USARSim
24
CAPITOLO 4.
IL SIMULATORE 3D USARSIM
25
scopo di consentire la comunicazione tra l'unreal engine e le applicazioni di
terze parti. La comunicazione e basata sullo scambio di dati di testo semplice,
che seguono il formato
TIPO fSegmento1gfSegmento2g...
In cui:
TIPO e una sigla scritta in maiuscolo che specica la tipologia dei dati che
seguono
Segmento e una lista di coppie nome/valore in cui nome e valore sono
separati da uno spazio.
I messaggi vengono scambiati sulla porta 3000 e devono terminare con
[CR][LF].
4.4
World Controller
Durante la fase di testing di un modulo software e utile interagire con l'ambiente per aggiungere nuovi elementi o spostare il robot in nuove posizioni.
E' per questo che l'ing. Marco Zaratti ha pensato di introdurre il WorldController [WEB-MZ], un bot che permette, tramite semplici comandi, di
creare, muovere, animare e distruggere dinamicamente oggetti durante una
simulazione. Per creare il World Controller sull'arena va inviato il comando:
INIT fClassName USARBot.WorldControllerg fName WCg fLocation
x,y,zg
Quindi e possibile mandare comandi direttamente al World Controller
nella forma:
CAPITOLO 4.
IL SIMULATORE 3D USARSIM
26
CONTROL fType commandTypeg...
Qui sono elencati una serie di comandi frequentemente utilizzati:
CONTROL fType Createg fClassName USARModels.P2DXDummyg
fName P2DXg fLocation 0,0,-0.5g fRotation 0,0,0g
per creare un oggetto di tipo P2DXDummy, con nome P2DX e relative
posizione e rotazione;
CONTROL fType Killg fName P2DXg
per distruggere l'oggetto chiamato P2DX;
CONTROL fType SetWPg fName nameg fSpeed sg fWP x,y,z;x,y,z;...g
Per far muovere l'oggetto name, con velocita s e con un percorso che
attraversa i punti specicati nei WayPoints (WP).
Gli oggetti gestiti dal world controller devono avere uno script che estenda
la classe WCObject e devono riferire a StaticMesh con relative primitive di
collisione.
4.5
WorldControllerClient2007
Come spiegato nel capitolo 5 l'algoritmo utilizzato prevede l'approssimazione
degli ostacoli a circonferenze. Si e quindi pensato di rappresentare, nel mondo
del simulatore, questi ostacoli come cilindri (creati con 3D StudioMax).
Data la varieta e la complessita sintattica dei comandi si e pensato di creare una semplice interfaccia al WorldController: il WorldControllerClient2007.
CAPITOLO 4.
IL SIMULATORE 3D USARSIM
27
Figura 4.3: Il WorldControllerClient2007
Una prima versione del WorldControllerClient e stata implementata da Mauro Sbarigia [ST-MS] ed e evoluta nel WorldController2007 con l'introduzione
di comandi per la creazione, lo spostamento e la distruzione degli ostacoli.
Capitolo 5
Pianicazione del moto in
ambiente dinamico
La problematica della pianicazione di un moto in ambiente dinamico e estremamente vasta e nel corso degli anni le soluzioni proposte sono state numerosissime (per una trattazione completa si rimanda a [FAR01]). La soluzione
da me implementata prende spunto dalle pubblicazioni [FS93], [BIC95] e
[BAL01].
L'idea che c'e alla base e quella di considerare ciascun ostacolo come una
circonferenza avente per raggio quello della circonferenza cui e inscritto.
L'algoritmo calcola una velocita per cui, arrivato in prossimita dell'ostacolo, si trova esattamente sulla circonferenza descritta. A questo punto
ruotera attorno all'ostacolo seguendo la sua velocita no ad averlo superato.
In caso di ostacoli sucientemente vicini da impedire una traiettoria intermendia, questi vengono \aggregati" a formare una circonferenza tale che li
contenga.
28
CAPITOLO 5.
PIAN. DEL MOTO IN AMBIENTE DINAMICO
29
Il cammino in uscita dal pianicatore e facilmente rappresentabile ed e
costituito da sole tre curve:
segmenti rettilinei;
archi di circonferenza di raggio minimo a destra;
archi di circonferenza di raggio minimo a sinistra.
5.1
Il paradigma delle velocita relative
Il paradigma delle velocita1 relative riesce, grazie ad un algoritmo di semplice implementazione, a rilevare gli urti fra oggetti di uno stesso scenario
riducendo, di fatto, il problema della pianicazione del moto in ambiente
dinamico ad un problema equivalente in ambiente statico. Ipotizziamo di
avere un determinato numero di ostacoli mobili in un piano di cui sono a
priori note le velocita ed un oggetto mobile di cui possiamo controllare le
velocita. Si ipotizzi, inoltre, che gli oggetti in questione siano assimilabili ad
una circonferenza di raggio noto. Denendo le velocita di tutti gli oggetti
rispetto ad un comune sistema di riferimento si puo rappresentare lo Spazio
delle velocita2 (rappresentabile come in g. 5.1). Ogni oggetto viene quindi
rappresentato da posizione (x (t)) e velocita (v (t)) in funzione del tempo:
p
p
( ) = (x (t); v (t))
p t
p
p
Denotiamo con obj l'oggetto mobile controllabile, con obs ciascuno degli m
o
1 Descritto
2 Per
i
in [FIO93]
una denizione rigorosa dello Spazio delle velocita si rimanda a [BUR85]
CAPITOLO 5.
PIAN. DEL MOTO IN AMBIENTE DINAMICO
30
Figura 5.1: Spazio delle velocita
ostacoli mobili. Utilizzando il concetto di spazio delle congurazioni possiamo pensare l'oggetto
objo
accresciuto del raggio di
come un punto materiale e ciascun ostacolo
objo
. Per ciascuna coppia (obj
o;
obsi
obsi
) deniamo la
velocita relativa come:
_
xo;i
= x_
o
_ con i = 1:::m
xi
Considerando le velocita relative si puo trasformare il problema di pianicazione dinamica in m problemi di pianicazione statica. Infatti, dato l'oggetto
obsi
ed
objo
con relative posizioni e velocita il problema della pianicazione
di una traiettoria che eviti l'ostacolo si riduce ad un problema statico in cui
obsi
e immobile ed obj si muova con velocita assoluta x_ . Denendo ora la
o
traiettoria relativa trj
trjo;i
o:i
o;i
tra obj ed obs come:
o
i
= f(x; x_ ) : (x_ (t ) = x_
o
o;i ;
( ) = x )g
x to
o
(5.1)
CAPITOLO 5.
allora, se x_
31
PIAN. DEL MOTO IN AMBIENTE DINAMICO
o;i
non cambia, si avra una collisione tra obj e obs se:
o
\
trjo;i
L'insieme delle velocita x_
o;i
obsi
i
6= ;
(5.2)
per cui la 5.2 e vericata costituisce il cono di
collisione denito come:
C Co
= ftrj : trj
o;i
\
o;i
obsi
6= ;g
(5.3)
Osservando la gura 5.2 si nota immediatamente che il cono di collisione
Figura 5.2: Cono di collisione relativo per gli oggetti A e B
^ (posizione di obj , da ora per semplicita obj ), dalla
relativo e delimitato da A
o
A
^ (posizione di obs , da ora obs ) ed avente raggio
circonferenza centrata in B
i
pari alla somma dei raggi di
objA
e
obsB
B
, e dalle tangenti alla circonferenza
^ Denendo la velocita relativa di rispetto ad
passanti per A.
ad
obsB
come
!
velA;B
=
!
velA
!,
velB
se
! termina in
velA;B
objA
C Co
rispetto
=)
objA
CAPITOLO 5.
collidera con
32
PIAN. DEL MOTO IN AMBIENTE DINAMICO
obsB
. Si puo inoltre denire un insieme di velocita assolute
vo
Figura 5.3: Cono di collisione assoluto e relativo per gli oggetti A e B
che collidono con l'oggetto
obsB
introducendo il cono di collisione assoluto,
ottenuto traslando il cono di collisione relativo del vettore
!(g. 5.3).
velB
Il
cono di collisione assoluto puo essere pensato come un'estensione dello spazio
delle congurazioni nello spazio delle velocita, quindi il cono di collisione
assoluto riferito all'ostacolo
obsB
puo essere considerato come l'immagine
dell'ostacolo nello spazio delle velocita. e quindi essere rappresentato come
un'ostacolo nello spazio delle velocita V O . Per quanto detto, una traiettoria
i
e libera da urti se valgono contemporaneamente le due condizioni:
objo
non si trova all'interno di un ostacolo nello spazio delle congura-
zioni C O ;
i
il vettore v non termina all'interno del cono di collisione assoluto.
o
Per evitare collisioni fra l'oggetto
objo
ed un insieme di ostacoli
obsi
si de-
CAPITOLO 5.
PIAN. DEL MOTO IN AMBIENTE DINAMICO
33
ve considerare l'unione in senso insiemistico dei coni di collisione relativi a
ciascun ostacolo.
5.2
Velocita determinata
In questo paragravo viene formalizzata la velocita output del pianicatore tale
che eviti l'ostacolo preso in considerazione (safevel ). Tale velocita e ricavata
intersecando il cono di collisione assoluto con una circonferenza di raggio
Vm ax
centrata nella posizione del robot. Tale intersezione e possibile poiche,
come spiegato nel precedente paragrafo, il cono di collisione assoluto puo
essere considerato come l'immagine dell'ostacolo nello spazio delle velocita.
Figura 5.4: Velocita che eviti l'ostacolo
CAPITOLO 5.
PIAN. DEL MOTO IN AMBIENTE DINAMICO
34
Ora viene formalizzata la procedura che permette di ricavare la velocita
che eviti l'ostacolo.
! = ( ) la posizione del robot, = ( ) la velocita dell'o! = !+! = ( +
stacolo,
+ ) il vertice del cono di collisione
Sia
P
Vc
xr ; yr
Vo
P
Vo
xr
vx ; yr
vx ; vy
vy
assoluto.
!:
Si prenda in considerazione la circonferenza con raggio
2
Vmax
centrata in
P
(x
xr
)2 + (y
yr
)2 = V 2
max
e una delle due rette che delimitano il cono di collisione assoluto.
8
>
<
>
:
x
= x + kx
y
= y + ky
o
con k 0
d
o
con k 0
d
Si prenda in considerazione il sistema
8
>
>
(
>
<
=
>
>
>
: =
x
xr
)2 + (y
x
xo
+ kx
y
yo
+ ky
yr
)2 = V 2
max
con k 0
d
con k 0
d
Dal secondo e terzo vincolo ho:
x
2
y
Tenendo presente che
= x2 + 2kx
d xo
+ k 2 x2
= y 2 + 2ky
d yo
+ k2y2
o
2
o
!=(
Vc
xo ; yo
d
d
) = (x + v
secondo ed il terzo vincolo nel primo ho:
r
x;
yr
+ v ) , sostituendo il
T
y
CAPITOLO 5.
(x
PIAN. DEL MOTO IN AMBIENTE DINAMICO
xr )2 + (y
x2
35
yr ) 2 =
2xxr + x2r + y 2
2yyr + yr2 =
x2r + vo2 + 2xr vo + k 2 x2d + 2kxd xr + 2kxd vo + x2r
2x2r
yr2 + vo2 + 2yr vo + k 2 yd2 + 2kyd yr + 2kyd vo + yr2
2yr2
2vo xr
2vo yr
2kd xr +
2kd yr =
2
vx2 + 2kxd vx + k 2 x2d + vy2 + 2kyd vy + k 2 yd2 = vmax
da cui:
k
2
(x2 + y 2 ) + k(4v
d
x xd vy yd
d
) + (v 2 + v 2
x
y
2
vmax
)=0
le cui soluzioni sono:
k1;2
=
2(v
x xd vy yd
q
) 4v 2 (x2 + y 2 )
2(x2 + y 2 )
max
d
d
d
(2v
x yd
2v
y xd
)2
d
andando ora a sostituire nell'equazione in una delle due rette tangenti alla
circonferenza ho:
8
>
<
>
:
8
>
<
>
:
x
=x
y
=y
x
=x
y
=y
o
o
o
o
xrx
+ k1 x
xry
+ k1 y
xrx
+ k2 x
xry
+ k2 y
d
d
d
d
L'algoritmo calcola, ovviamente, anche i punti di intersezione con l'altra
tangente e restituisce la velocita che dierisce meno in angolo con il punto
obiettivo.
Capitolo 6
Conclusioni
6.1
Obiettivi raggiunti
Dagli esperimenti condotti sul simulatore risulta evidente che il robot riesce
a raggiungere la posizione desiderata evitando gli ostacoli anche se questi si
muovo in formazioni particolari per cui e necessaria l'introduzione di \ostacoli
virtuali" formati da aggregati degli ostacoli reali p.e. ostacoli vicini per cui
lo spazio intermedio non permette il passaggio del robot.
Ulteriori esperimenti hanno confermato che, con dovuti accorgimenti, l'algoritmo e robusto anche ad informazioni poco attendibili o addirittura mancanti sulla velocita degli ostacoli, come puo avvenire in ambienti reali. In
queste situazioni estreme, si considerano ostacoli con raggio piu grande di
quello reale, in modo che vengano create traiettorie che passino a distanze
maggiori dall'ostacolo e si attuano azioni correttive che allontanino il robot
dall'ostacolo, compensando l'inadabilita del tracking.
Nell'ultima parte dello stage si e portato il codice sul robot; tuttavia
36
CAPITOLO 6.
CONCLUSIONI
37
la mancanza di un ltro adatto a discriminare la posizione dell'ostacolo ha
limitato il testing ad ostacoli ssi con posizione conosciuta.
6.2
Sviluppi futuri
In vista della challenge di \Obstacle Avoidance" di Atlanta 2007, dovra essere
implementato un ltro che riconosca la posizione dell'ostacolo in modo da
poter applicare quest'algoritmo durante la challenge.
In futuro il ltro dovra essere anato per fare un tracking ecace capace di avere informazioni complete della velocita dell'ostacolo, in modo da
sfruttare appieno l'algoritmo che generera traiettorie piu ecaci.
Appendice A
Installazione ed utilizzo di
USARSim
In questo paragrafo desidero descrivere il processo di installazione di USARSim che, per quanto semplice, e soggetto di numerosi problemi.
Nel server del laboratorio e conservata una copia del necessario per la
corretta installazione del simulatore.
Processo di installazione:
1. Installare UT2004. Da questo punto si indichera la cartella in cui e
installato UT2004 con %UT2004%;
2. Installare la patch ut2004winpatch3369.exe;
3. Copiare la cartella UT2004 della copia di USARSim presente nel server
sovrascrivendo la cartella %UT2004%.
Il passo 3 non fa altro che aggiungere a %UT2004% i le necessari per la
compilazione degli script e l'esecuzione di USARSim.
38
APPENDICE A.
INSTALLAZIONE ED UTILIZZO DI USARSIM
39
Spostarsi nella cartella %UT2004%nSystem e compilare gli script di
USARSim con il comando:
ucc.exe make -ini=USARSim.ini
A questo punto e possibile eseguire USARSim con il comando:
ut2004 USAR-Soccer2007?spectatoronly=1?quickstart=true -ini=usarsim.ini
dove USAR-Soccer2007 e il nome della mappa caricata. Ovviamente e
possibile caricare una qualsiasi delle mappe presenti nella cartella maps.
Si consiglia di abbassare al minimo la priorita del processo e tutti gli
indicatori dei dettagli del videogioco ed alzare al massimo la simulazione
delle leggi siche.
E' possibile creare il seguente collegamento in modo da far partire USARSim in bassa piorita e con mappa USAR-Soccer2007
%windir%nsystem32ncmd.exe /c \start /low C:nUT2004nSystemnUT2004.exe
USAR-Soccer2007?spectatoronly=1?quickstart=true -ini=usarsim.ini"
Bibliograa
[BAL01] J.Baltes, Adaptive Path Planner for Highly Dynamic Environments,
2001
[BIC95] A.Bicchi Planning Shortest Bounded-Curvature Paths for a Class of
Nonholonomic Vehicles among Obstacls, 1995
[BUR85] W. Burke. Applied Dierential Geometry Cambridge University
Press, 1993
[FAR01] A.Farinelli Tecniche di pianicazione delle traiettorie in ambiente
dinamico
[FIO93] P.Fiorini Motion Planning in Dynamic Environments Using the
Relative Velocity Paradigm, 1993
[FS93] P. Fiorini, Z. Shiller. Motion planning in dynamic environments using
the relative velocity paradigm. 1993
[IOC99] L.Iocchi Design and Development of Cognitive Robots
Phd.Thesis
[MUR89] T.Murata Petri Nets: properties, analysis and applications, 1989
40
BIBLIOGRAFIA
41
[NAR06] D.Nardi, Dispense del corso di intelligenza articiale
[PET62] C.A.Petri Kommunikation mit Automaten
Phd.Thesis
[RN98] S.J.Russel, P.Norving. Intelligenza Articiale- un approccio moder-
no, 1998
[ZAR06] M.Zaratti A 3D Simulator of Multiple Legged Robots based on
USARSim, 2006
[ZIP04] V.A.Ziparo Rappresentazione ed Esecuzione di Piani Tramite Reti
di Petri, 2004.
[ST-FG] F.Giannone Rappresentazione e traduzione di piani
Relazione di stage
[ST-MS] M. Sbarigia Valutazione delle prestazioni di Sistemi Multi-Robot
Relazione di stage
[ST-PP] P.F.Palamara Deliberazione in ambiente multirobot
Relazione di stage
[WEB-4L] http://www.tzi.de/4legged/bin/view/Website/WebHome
[WEB-AI] http://www.aibo.com
[WEB-CH07] http://www.robocup.org/regulations/4.html
[WEB-GT04] http://www.germanteam.org/GT2004.pdf
[WEB-MZ] http://digilander.libero.it/window/
BIBLIOGRAFIA
42
[WEB-OSR] http://www.cs.ubc.ca/spider/mack/links/papers/osr/osr.html
[WEB-RB] http://www.robucup.org