Università degli studi di Roma "La Sapienza" Facoltà

Transcript

Università degli studi di Roma "La Sapienza"
Facoltà di Ingegneria
Relazione di Stage
Corso di Laurea Triennale in
Ingegneria Informatica
Valutazione delle prestazioni di
Sistemi Multi-Robot
Relatore
Laureando
Prof. Luca Iocchi
Mauro Sbarigia
Anno Accademico 2005/2006
Sessione Autunnale - Dicembre 2006
A chi ha sempre creduto in me.
A chi mi ha voluto bene davvero.
Alla mia famiglia.
A me.
In ogni cosa ho voglia di arrivare
no alla sostanza.
Nel lavoro, cercando la mia strada,
nel tumulo del cuore.
Sino all'essenza dei giorni passati,
sino alla loro ragione,
sino ai motivi, sino alle radici,
sino al midollo.
Eternamente aggrappandomi al lo
dei destini, degli avvenimenti,
sentire, amare, vivere, pensare,
eettuare scoperte.
Boris Pasternak
Indice
1 Intelligenza Articiale e Robocup
1.1 Articial Intelligence . . . . . . . . . . . . . . . . . .
1.1.1 Introduzione . . . . . . . . . . . . . . . . . .
1.1.2 Signicato del termine e approccio utilizzato .
1.1.3 Breve storia dell'AI . . . . . . . . . . . . . . .
1.2 La RoboCup . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Panoramica sull'evento . . . . . . . . . . . . .
1.2.2 La Four-Legged League . . . . . . . . . . . .
1.2.3 La Rescue League . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
8
8
8
9
10
10
12
12
2 USARSim
2.1 Il simulatore 3D USARSim . . . . . . . . . . . .
2.1.1 Introduzione . . . . . . . . . . . . . . . .
2.1.2 Architettura di UsarSim . . . . . . . . . .
2.1.3 Unreal Engine . . . . . . . . . . . . . . . .
2.1.4 Gamebots, il protocollo di comunicazione
2.1.5 Controller . . . . . . . . . . . . . . . . . .
2.2 L'ambiente di simulazione . . . . . . . . . . . . .
2.2.1 Le Arene . . . . . . . . . . . . . . . . . .
2.2.2 I Robot . . . . . . . . . . . . . . . . . . .
2.2.3 I Sensori . . . . . . . . . . . . . . . . . . .
2.3 Limiti nell'utilizzo di USARSim . . . . . . . . . .
2.4 Unreal Editor . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
16
16
17
18
19
19
20
20
21
22
22
24
3 Sony Aibo e SPQR Four-Legged Team
3.1 Sony Aibo ERS 7 . . . . . . . . . . . . .
3.2 Il codice della SPQR Legged Team . . .
3.2.1 Architettura software del SPQR .
3.2.2 Il coordinamento . . . . . . . . .
3.2.3 I piani . . . . . . . . . . . . . . .
3.3 USARBot.ERS . . . . . . . . . . . . . .
3.3.1 I sensori virtuali . . . . . . . . .
3.3.2 La telecamera . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
27
27
27
29
31
31
31
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.3.3
3.3.4
3.3.5
3.3.6
Ball Helper Sensor . . . . . . . . . .
IR Sensors . . . . . . . . . . . . . . .
Acceleration Sensor . . . . . . . . . .
Il comando di movimento MultiDrive
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
32
32
32
4 Lavoro e Tools nella Four-Legged Team
4.1 Introduzione al lavoro svolto . . . . . . .
4.2 Strumenti utilizzati . . . . . . . . . . . .
4.3 Tools sviluppati . . . . . . . . . . . . . .
4.3.1 SIMMotion . . . . . . . . . . . .
4.3.2 WorldControllerClient . . . . . .
4.3.3 LogExaminator . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
36
36
36
38
40
5 Four-Legged Test e Risultati
5.1 Piano di Test . . . . . . . . . . .
5.1.1 Considerazioni iniziali . .
5.1.2 Piano di test preliminare .
5.1.3 Problemi riscontrati . . .
5.1.4 Piano di test nale . . . .
5.2 Risultati dei Test . . . . . . . . .
5.2.1 Output della fase di test .
5.2.2 Analisi valutativa . . . . .
5.2.3 Ulteriori considerazioni . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
44
44
45
46
46
47
47
51
52
6 P2AT,P2DX e SPQR Rescue Robots Team
6.1 P2AT e P2DX . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 SPQR-RDK . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Presentazione della piattaforma di sviluppo Spqr-Rdk
6.2.2 Zeus . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3 Il coordinamento . . . . . . . . . . . . . . . . . . . . .
53
54
55
55
56
56
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Lavoro e Tools nella Rescue Team
57
7.1 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . . 58
7.2 La mappa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8 Rescue Test e Risultati
8.1 Piano di test . . . . . . . . . .
8.1.1 Scelta del piano di Test
8.1.2 Problemi riscontrati . .
8.2 Risultati dei Test . . . . . . . .
8.2.1 Output della fase di test
8.2.2 Analisi valutativa . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
62
62
62
63
63
63
9 Conclusioni
65
9.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.2 Conclusioni personali . . . . . . . . . . . . . . . . . . . . . . . 66
9.3 Ringraziamenti . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A Utilizzare SIMMotion
69
B Utilizzare WorldControllerClient
71
C Utilizzare LogExaminator
73
5
6
Introduzione
La relazione che segue descrive gli obiettivi, gli strumenti utilizzati, il lavoro
svolto ed i risultati ottenuti nel periodo di stage trimestrale sostenuto presso
il Dipartimento di Informatica e Sistemistica dell'Università "La Sapienza" di
Roma. Gli scenari di applicazione sono tratti dalla Robocup, competizione
internazionale tenuta ogni anno con lo scopo di promuovere e incentivare
l'attività di ricerca nell'ambito dell'intelligenza articiale e della robotica.
In particolare il lavoro è stato realizzato collaborando con la SPQR FourLegged Team per quanto riguarda i robot calciatori e con la SPQR Virtual
Rescue Robots Team e SPQR Rescue Robots Team per quanto riguarda i
robot per il salvataggio.
Obiettivo fondamentale dello stage era testare e valutare il funzionamento
e l'ecacia dei moduli software di coordinamento prodotti dalle due squadre
tramite una metodologia tale che la valutazione sia successivamente replicabile. Per raggiungere tale obiettivo, si è scelto di utilizzare il simulatore 3D
USARSim, lo stesso utilizzato nell'ambito delle competizioni Virtual Rescue
della Robocup, così da poter progettare, osservare e ripetere i test senza
rischiare di danneggiare i robot e soprattutto avendo una visione assoluta e
privilegiata di cosa succede nel robot, al robot e intorno al robot durante
il test, eliminando (o comunque riducendo drasticamente) in questo modo
anche il rischio di "inquinamento" dei risultati dovuto a percezioni errate,
disturbi o malfunzionamenti dell'hardware reale.
Se tale simulatore ben si adatta alla simulazione per i Rescue Robots,
essendo questi dotati del sistema operativo Linux ed avendo la possibilità
di collaborare con la SPQR Virtual Rescue Robots Team che ha un background di conoscenza, tools e framework suciente a rendere immediato ed
agevole l'utilizzo di USARSim per eettuare test, il discorso è dierente per
quanto riguarda la SPQR Four-Legged Team. I Four-Legged Robots sono i
robot commerciali Sony Aibo che utilizzano il sistema operativo proprietario
Aperios. Questo sistema deve essere necessariamente mascherato per poter
far funzionare il codice prodotto per il robot sui tradizionali pc, limitandone
alcune parti e sostituendone completamente altre. Essendo questo il primo
anno che il team ha deciso di utilizzare il simulatore, durante lo stage è stato necessario sviluppare un tool che facesse sia da ponte tra USARSim e il
7
codice del robot sia da integratore delle parti dipendenti da Aperios che non
possono quindi essere eseguite.
Per i motivi appena accennati, il lavoro di stage si è concentrato principalmente sui Four-Legged Robots con il risultato di aver sviluppato 3 tool,
il primo in collaborazione con gli altri compenenti della squadra per poter
simulare i robot su USARSim, gli altri due più specicatamente per la valutazione semi-automatica delle loro prestazioni. Per la valutazione dei Rescue
Robots si è preferito una valutazione non automatizzata, sia perché le strategie di valutazione prevedevano comunque una componente umana attiva, sia
perché spendere molto tempo nel modicare i tool esistenti o nel crearne di
nuovi non avrebbe comunque dato vantaggi sucienti a giusticare lo sforzo
eettuato.
I risultati ottenuti dai test mostrano come variano le prestazioni di entrambe le squadre al variare delle loro strategie, restituendo valori abbastanza chiari da essere valutabili e abbastanza generici da essere comparabili
anche con quelli ottenuti da strategie completamente diverse, evidenziando
che la metodologia applicata permette la replicazione dei test e la valutazione
e comparazione di qualunque strategia senza avere la presunzione di eleggere
un improbabile "univocamente migliore", ma mostrando tabelle di valori che
lasciano all'utente la possibilità di valutare egli stesso senza dicoltà quale
sia l'alternativa preferibile in una determinata circostanza.
La prima parte della relazione (Capitoli 1 e 2) si concentra sull'intelligenza articiale e la Robocup. Viene poi presentato lo strumento fondamentale
per la simulazione e l'eettuazione di test: il simulatore USARSim.
La seconda parte (Capitoli 3 4 e 5) illustra una panoramica sulla squadra
SPQR Four-Legged Team, sulle caratteristiche dei robot reali utilizzati e
le dierenze con quelli simulati, e sull'architettura software che permette
il funzionamento dei robot. Vengono presentati gli strumenti utilizzati e
quelli sviluppati o migliorati per adattarsi alle necessità, presentati il piano
e le strategie di test, elencate le limitazioni imposte ed inne commentati i
risultati ottenuti.
Nella terza parte (Capitoli 6 7 e 8) si avrà un'analoga presentazione delle
squadre SPQR Rescue Robots Team e SPQR Virtual Rescue Robots Team
e della loro attività, dei robot utilizzati e dei test eettuati, con i relativi
risultati ottenuti.
La quarta ed ultima parte (Capitolo 9) sarà dedicata ai personali commenti nali sull'attività di stage, alle prospettive di sviluppi futuri e ai dovuti
rigraziamenti.
8
Capitolo 1
Intelligenza Articiale e
Robocup
"Io penso, Sebastian, quindi sono..."
(Pris, dal lm "Blade Runner")
Questo capitolo fornisce una breve e generica panoramica sull'Intelligenza
Articiale, dalla sua nascita ai tempi moderni, illustrando sinteticamente
qual è l'approccio attuale utilizzato nella ricerca. Viene poi presentata la
Robocup, uno degli eventi più importanti a livello mondiale per promuovere
l'Intelligenza Articiale, la Robotica, l'Automazione e i vari campi di ricerca
ad essi correlati. Di questa manifestazione verranno evidenziate soprattutto
le leghe a cui l'Università La Sapienza di Roma partecipa con i suoi Team di
sviluppatori e da cui sono tratti gli scenari di utilizzo del lavoro di stage.
9
1.1 Articial Intelligence
1.1.1 Introduzione
Nel 1956 in occasione dell'ormai celebre incontro tenutosi al Dartmouth College con lo scopo di riunire ricercatori appartenenti a diverse Università allora
interessati alla teoria degli automi, delle reti neurali e allo studio dell'intelligenza, viene coniato il termine attualmente utilizzato per una delle più
stimolanti aree di ricerca dell'informatica moderna: nasce l'AI, l'Intelligenza
Articiale. Da allora losoa, cinema, letteratura, scienza, tutto ha contribuito a far parlare dell'intelligenza articiale, senza però arrivare ad una
formalizzazione e ad una idea comune del signicato del termine stesso.
Nel 1997 il famoso supercalcolatore Deep Blue riesce a vincere in una sda regolamentare il campione del mondo di scacchi Gary Kasparov. Sempre
nello stesso anno, il robot esploratore autonomo Pathnder costruito dalla
Nasa atterra su Marte. Sembrerebbe che questa famosa "intelligenza articiale" abbia raggiunto il livello di quella umana. Ma sono in molti a non
pensarla in questo modo, a ritenere altresì che sia assurda anche solo l'idea
che possa esistere un "pensare" costruito dall'uomo.
La locuzione "Cogito ergo sum" (lett. "Penso quindi esisto") è l'espressione con cui Cartesio (Principia philosophiae 1, 7 e 10) esprime la certezza
indubitabile che l'uomo ha di sé stesso in quanto soggetto pensante. Ci si
chiede: Può una macchina "pensare"? Può una macchina avere coscienza di
sé? Cosa signicano parole come "pensare" o "intelligente?"
1.1.2 Signicato del termine e approccio utilizzato
Nonostante siano passati più di cinquant'anni, ancora oggi per tale termine
non esiste un'unica denizione che consenta di descrivere gli obiettivi che
essa si pone e circoscrivere nettamente l'insieme delle discipline che vi sono
direttamente aerenti.
Al di là delle disquisizioni losoche che possono a volte risultare tediose,
non è semplice denire il signicato del termine "sistema intelligente". Nel
corso della breve ma intensa storia di questa disciplina molti sono stati gli
approcci seguiti e benché ciascuno di questi avesse per obiettivo lo studio
e la progettazione di "sistemi intelligenti", essi si dierenziamo tra di loro
anche profondamente in funzione del signicato di volta in volta associato
alla parola "intelligente".
Storicamente, diverse strade sono state seguite. Uno dei primi approcci
indicato da Turing nel famoso test è stata considerare intelligente un sistema in grado di comportarsi come un essere umano. Eettivamente un
programma come il famoso Eliza che è in grado di ingannare una persona
poco esperta che si ritrova a chattare con una macchina credendo di parlare
con un essere umano potrebbe sembrare "intelligente". Ma allora un programma che esegue calcoli in un microsecondo è meno intelligente di uno che
10
Fig. 1.1: Quattro possibili categorie di denizioni per sistema intelligente.
impiega qualche secondo, ovvero un intervallo più simile ai tempi di reazione
di un essere umano? O una macchina che calcola l'inversa di una matrice 5x5
in un microsecondo è più intelligente di un uomo che impiegherebbe milioni
di volte tanto?
La denizione che maggiormente ispira i recenti studi condotti sull'Intelligenza Articiale è quella che identica come
sistema intelligente un sistema in grado di agire in modo razionale, ovvero
in grado di operare nel modo più vantaggioso possibile rispetto a un insieme
di obiettivi pressati e in funzione delle informazioni accessibili dall'ambiente
con cui interagisce [?].
Questo è un approccio decisamente più moderno di quello proposto da
Turing, è un approccio che si allontana da questioni legate all'emulazione
cerebrale o alle disquisizioni sul signicato del termine "pensare". Comportamento razionale signica fare la cosa giusta, e la cosa giusta è quella che
ci si aspetta massimizzi il risultato, a fronte della informazione disponibile.
Questo non necessariamente coinvolge il pensare, ma il pensare deve essere
a disposizione dell'agire razionalmente [?].
1.1.3 Breve storia dell'AI
Come detto, questo non è l'unico approccio, anzi. Storicamente c'è stato un
alternarsi di periodi di splendore e momenti dicili di ogni approccio. Vieni
qui proposta una breve e schematica storia dell'Intelligenza Articiale, da
prima della sua nascita uciale al giorno d'oggi. Non ha la pretesa di essere
una storiograa completa, ma permette di capire com'è stato l'evolversi nel
tempo di questa disciplina.
Le origini dell'AI
11
1943
1950
1952-69
1950
1956
1965
1966-74
1969-79
1980-88
1988-93
McCulloch Pitts: modello del cervello a circuiti booleani
Turing "Computing Machinery and Intelligence"
Look, Ma, no hands!
Primi programmi di AI, la dama, Logic Theorist, Geometry Engine
Scuola di Dartmouth: il nome "Articial Intelligence"
Robinson introduce il metodo di risoluzione
L'AI scopre la complessità computazionale. La ricerca sulle reti neurali sparisce
Primi sviluppi dei sistemi basati sulla conoscenza
Esplode l'industria dei Sistemi Esperti
Crolla l'industria dei Sistemi Esperti: "Inverno dell'AI"
La storia recente
1985
1988
1988
1991
1993
1995
1997
Le reti neurali tornano in voga
Risorgono Metodi probabilistici e Teoria delle decisioni
"Nouvelle AI": ALife, GA, soft computing
Ritorna la Robotica e la visione
AAAI Robotics Context
Agenti e Multi agenti
RoboCup
Dopo il cosiddetto inverno dell'AI e il crollo dell'industria dei Sistemi
Esperti, negli anni novanta torna alla ribalta nelle università e nei laboratori
di ricerca di tutto il mondo lo studio dei sistemi intelligenti, specialmente nel
campo della cooperazione di agenti, stimolata anche da eventi e iniziative a
livello mondiale quali la RoboCup.
1.2 La RoboCup
1.2.1 Panoramica sull'evento
La Robot World Cup Initiative [?] (più conosciuta come RoboCup) è un
campionato mondiale che si disputa fra robot autonomi. Nata nel 1993 da
un'idea di un gruppo di ricercatori giapponesi, essa è un tentativo di promuovere l'intelligenza articiale, la robotica e altri campi di ricerca correlati
ponendosi un obiettivo ambizioso: sviluppare entro il 2050 una squadra di
robot umanoidi completamente automi che sia in grado di battere in una
partita di calcio la squadra campione del mondo secondo le regole approvate
dalla FIFA (l'organismo che governa il calcio mondiale). Ciò implica che una
squadra di robot bipedi che camminano, corrono e calciano un pallone sia
in grado di percepire le situazioni di gioco, e che ogni singolo robot prenda
decisioni sul movimento da compiere e sulla strategia di gioco.
La tecnologia attuale è lontanissima da questo obiettivo; la maggior parte
dei robot si muove su ruote anziché su gambe, e ha spesso seri problemi solo
a scorgere la palla e gli altri robot. Le tecnologie coinvolte in questa sda
12
abbracciano tutta una gamma che va dalla ricerca sui robot intelligenti, alla
scienza dei materiali, all'elettronica.
Fig. 1.2: Una simpatica immagine tratta dalla RoboCup.
La RoboCup è uno sforzo di collaborazione internazionale per promuovere la scienza, la tecnologia e l'educazione attraverso un tema di richiamo
come il calcio dei robot. E' pensata per poter arontare complessità pratiche
del mondo reale sebbene in un ambiente limitato, orendo un obiettivo di
ricerca integrata che copre ampie aree della robotica intelligente, tra cui: la
realizzazione di sensori capaci di acquisire in tempo reale, il comportamento
reattivo, l'acquisizione di una strategia, l'apprendimento, la pianicazione
in tempo reale, sistemi multi-agente, la ricognizione di un contesto, la visione, la capacità di prendere decisioni strategiche, il controllo dei motori,
il controllo di robot intelligenti, e altro ancora. Le competizioni non sono
quindi ni a se stesse, ma permettono di portare avanti un discorso di ricerca che possa essere applicato in svariati ambiti del mondo reale, favorendo e
incoraggiando lo sviluppo di agenti autonomi che possano esplorare mappe
sconosciute, riconoscere oggetti, apprendere automaticamente, coordinarsi
per raggiungere obbiettivi comuni.
Il coordinamento nei sistemi multi-robot è una delle più interessanti aree
di ricerca e di sviluppo nell'ambito della RoboCup. L'università "La Sapienza" di Roma partecipa ogni anno con la squadra SPQR Four-Legged, SPQR
Rescue Robots e SPQR Virtual Rescue Robots nelle rispettive leghe riportando buoni risultati. In uno scenario come il calcio tra robots o l'esplorazione
di mappe è fondamentale che i robots cooperino per il raggiungimento degli
obbiettivi, soprattutto considerando che l'hardware dei robots è uguale per
tutte le squadre, che dieriscono tra loro solo per il software sviluppato.
Risulta evidente che la vittoria o la scontta dipendono principalmente dalla qualità delle scelte eettuate e dal software prodotto, solo marginalmente
da fattori quali disponibilità economica, presenza di sponsor o casualità e
fortuna. Fornire una valutazione delle prestazioni di tali sistemi multirobot
è proprio l'obbiettivo del lavoro di stage di cui è oggetto questa relazione.
13
1.2.2 La Four-Legged League
La RoboCup Four-Legged League [?] è una categoria che prevede l'utilizzo di
uno specico agente robotico nell'ambito del gioco del calcio. L'adozione di
una specica piattaforma hardware fa si che il confronto fra le varie squadre
avvenga esclusivamente in termini di capacità di sfruttarla, tramite la progettazione di un opportuno software, nel modo migliore possibile. L'agente
robotico scelto per tale categoria di competizioni è l'agente robotico AIBO
prodotto dalla Sony.
Nell'ambito della categoria Legged League della RoboCup, il modello
AIBO ERS 7 [?] fornisce la piattaforma hardware comune su cui ciascun
team implementa un proprio codice al ne di ottenere un squadra di quattro
agenti calciatori. Durante ciascuna partita gli agenti possono utilizzare la
rete wireless per comunicare tra di loro, ricevere da un'opportuna postazione
arbitrale informazioni sullo stato dell'incontro (inizio o ne partita, goal
segnati o subiti) e su eventuali penalità initte loro a seguito di violazioni
delle regole, ma naturalmente non possono comunicare con l'esterno.
Fig. 1.3: La disposizione iniziale dei robot in una partita della RoboCup
Legged League.
In gura vengono mostrate, tramite un'immagine dello schieramento di
inizio match tra due squadre di AIBO ERS 7, alcune delle principali proprietà degli oggetti che costituiscono l'ambiente con cui ciascun agente AIBO
interagisce nelle competizioni della categoria legged: colore della palla, colore delle porte, posizione e colore dei quattro marker posti ai quattro vertici
del rettangolo che delimita l'area di gioco, posizione delle linee di campo e
inne colore e forma della divisa da gara di ciascun agente. Benché ciascuna
di queste proprietà (come anche molte altre) sia regolata da opportuni standard ssati dalla Legged League stessa, l'ambiente risultante è comunque un
ambiente non solo dinamico ma anche non deterministico e inaccessibile.
1.2.3 La Rescue League
La RoboCup Rescue League [?] è la lega il cui scopo è quello di incoraggiare lo sviluppo e la ricerca in quei campi della tecnologia utilizzati nella
14
rintracciamento e nel salvataggio di esseri umani in strutture che hanno subìto gli eetti di un terremoto, edici in amme, incidenti sotterranei e via
discorrendo.
Attualmente, durante le competizioni, vengono preparate delle arene che
riproducono l'interno di edici colpiti da terremoti o incendi, secondo gli
standard NIST Usar Test Facility. All'interno delle arene sono posizionati
manichini, che costituiscono le vittime da individuare. Ogni squadra in gara
presenta uno o più robot che dovranno esplorare l'ambiente in modalità autonoma o teleoperata. Lo sviluppo, in questo ambito, di agenti in grado di
agire in maniera autonoma ed esplorare tali ambienti, individuando le eventuali vittime, è una sda interessante, in quanto coinvolge aspetti quali la
mappatura dell'ambiente, la localizzazione del robot, l'individuazione degli
ostacoli e delle vittime e la necessità di predisporre una modalità di esplorazione completamente autonoma in caso di impossibilità di comunicare col
robot.
Fig. 1.4: Una immagine di un robot per il soccorso in gara nella RoboCup
Rescue.
A partire da quest'anno (Brema 2006) è stata introdotta la Rescue Simulation League della disciplina "3D Simulation", basata sull'utilizzo del simulatore UsarSim. Gli obiettivi sono gli stessi della Rescue League, ma in
questo caso i robot e le arene sono simulate.
15
16
Capitolo 2
USARSim
"Hai mai fatto un sogno tanto realistico da sembrarti vero?
E se da un sogno così non dovessi più svegliarti?
Come potresti distinguere il sogno dalla realtà?"
(Morpheus, dal Film "Matrix")
In questo capitolo verrà oerta una panoramica sugli strumenti principali
utilizzati durante l'attività di stage. Particolare attenzione verrà dedicata a
USARSim, il simulatore 3D utilizzato in tutte le sperimentazioni eseguite.
Verrà data una introduzione generale e una panoramica sulle motivazioni che
spingono i ricercatori ad usarlo, le modalità di utilizzo, verranno evidenziate
le parti che è stato necessario sviluppare per favorirne lo sfruttamento da
parte delle SPQR Teams, analizzati i suoi punti di forza, i suoi limiti e gli
auspicabili sviluppi futuri. Inne verrà data una brevissima presentazione
dell' Unreal Editor, strumento utilizzato per la generazione e la modica
delle mappe utilizzabili da USARSim.
17
2.1 Il simulatore 3D USARSim
2.1.1 Introduzione
Sviluppato come strumento di ricerca all'interno di un progetto riguardante
lo studio di Robot, Agenti e Team di operatori nel contesto di Urban Search
And Rescue (USAR) della National Science Foundation (NSF), USARSim
[?] è il simulatore 3D orientato al soccorso robotico che ha conquistato rapidamente il ruolo di standard de facto per quanto riguarda la simulazione nei
laboratori di ricerca di tutto il mondo. In UsarSim viene riprodotto fedelmente un ambiente di soccorso robotico, includendo una serie di arene, di
robot e la sensoristica necessaria a simulare il comportamento di un robot
reale in azione.
Fig. 2.1: Alcuni dei robot presenti in USARSim.
Il simulatore è stato progettato partendo dal famoso videogioco UT2004
come un'estensione del motore di gioco Unreal Engine, un software commerciale multipiattaforma orientato al gaming FPS (First Person Shooting)
multigiocatore, sviluppato dalla Epic Games. UsarSim demanda completamente all'Unreal Engine il rendering graco della scena tridimensionale
e la simulazione delle interazioni siche tra gli oggetti. In questo modo,
lasciando gli aspetti più dicili della simulazione ad una piattaforma commerciale in grado di orire un rendering visuale superiore ed una buona
modellazione sica, tutti gli sforzi nello sviluppo di UsarSim sono concentrati sui compiti specici della robotica, quali la modellazione di ambienti,
sensori, sistemi di controllo e strumenti d'interfaccia. Inoltre lo sviluppo è
facilitato dall'utilizzo dei software di editing avanzato integrati nel motore di
gioco, quali l'editor graco Unreal Editor ed il linguaggio di scripting interno
Unreal Script. Questi strumenti permettono una notevole congurabilità e
personalizzazione del software, attraverso modalità relativamente semplici e
immediate [?].
Di contro, l'assenza di documentazione e il funzionamento interno sconosci18
uto purtroppo non permettono di eettuare modiche e ottimizzazioni a basso livello. Questo costringe gli sviluppatori ad utilizzare scorciatoie e trucchi
per inserire features altrimenti non aggiungibili. Inoltre, la simulazione della
sica è plausibile, ma non realistica, e l'illuminazione degli oggetti non è dinamica e non sfrutta il pixel shading che i maggiori . Queste limitazioni non
possono essere superate dagli sviluppatori di USARSim essendo dipendenti
dall'Unreal Engine. Auspicabilmente entrambe dovrebbero essere superate
con il rilascio della nuova versione del Game Engine contenuta nel gioco
UT2007, la cui commercializzazione è prevista per il prossimo anno.
2.1.2 Architettura di UsarSim
Fig. 2.2: L'architettura di USARSim.
Dal punto di vista architetturale UsarSim è strutturato come sistema
19
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 (solitamente, una camera su ogni robot robot più una
visuale esterna).
• Strato di rete : Tutti i client scambiano dati col server attraverso lo
strato di rete, basato sul protocollo TCP/IP, in particolare i Controller
tramite un semplice protocollo di stringhe di testo (di cui di parlerà in
seguito).
• Lato Server : Dalla parte server la gestione della simulazione è basa-
ta sull'Unreal Engine, il motore di gioco vero e proprio, che si avvale
della mappa dell'arena corrente, contentente tutti i dati dell'ambiente
di simulazione, e dei modelli utilizzati nella simulazione, tra cui i robot,
i sensori e le vittime.
La comunicazione con il lato client è bipartita: i dati relativi al feedback
graco vengono inviati direttamente in rete agli Unreal Client connessi; il
dialogo con i Controller è invece gestito tramite il protocollo di comunicazione
Gamebots.
Verrà approfondita solo la descrizione del lato server, con particolare
riferimento all'Unreal Engine, al protocollo Gamebots ed ai Controller utilizzabili.
2.1.3 Unreal Engine
Il motore di gioco alla base di UsarSim, l'Unreal Engine, è rilasciato dalla
Epic Games all'interno del gioco Unreal Tournament 2004 [?].
L'Unreal Engine è un sistema completo di sviluppo e simulazione di
ambienti tridimensionali, composto da:
• un renderer graco 3D, Unreal Client, in grado di fornire visuali ego-
centriche (poste sul robot) ed exocentriche (in terza persona) della simulazione, che può essere utilizzato per esigenze di debug e di
sviluppo;
• un motore per le interazioni siche, Karma Engine, che simula la
gravità e le interazioni tra gli oggetti;
• un tool di authoring 3D, Unreal Editor, per la modellazione di mappe
ed attori;
• un linguaggio di scripting, Unreal Script, per modicare agevolmente
il comportamento del sistema.
Al momento è considerato lo standard di fatto tra i game engine adattati
alla ricerca scientica.
20
2.1.4 Gamebots, il protocollo di comunicazione
Il protocollo di comunicazione utilizzato dall'Unreal Engine è proprietario:
questo rende dicile l'accesso ad Unreal Tournament da parte di applicazioni
esterne. Gamebots è un software sviluppato dai ricercatori dell'ISI della University of Southern California allo scopo di consentire la comunicazione con
l'Unreal Engine, in un contesto di rete, tramite l'apertura di una connessione
(socket) di tipo TCP/IP, utilizzabile da applicazioni di terze parti.
UsarSim utilizza Gamebots come protocollo di comunicazione tra l'Unreal Engine ed i Controller esterni, e vi applica alcune modiche per supportare
le proprie classi di dati. La comunicazione è basata sullo scambio di dati di
testo semplice, che seguono il formato
TIPO {Segmento1} {Segmento2} ...
I dati scambiati in USARSim vengono suddivisi in base alla sorgente: i
messaggi inviati tramite USARSim dal robot e dai sensori verso il Controller,
ed i comandi inviati dal Controller remoto al robot. Attualmente esistono
vari tipi di messaggi e comandi, ne verranno forniti esempi più avanti nella
relazione.
2.1.5 Controller
UsarSim si presta ad essere utilizzato per testare sistemi di controllo e coordinamento robotici; di conseguenza lo sviluppo dell'interfaccia col simulatore è
giustamente demandato all'utente. In questo contesto, vengono denominate
Controller tutte le applicazioni esterne che utilizzano il simulatore.
Le operazioni usuali all'interno di un Controller sono le seguenti:
• il Controller apre un socket tramite il quale si connette all'Unreal
Engine;
• il Controller invia il comando per inserire un robot in UsarSim tramite
il comando INIT;
• il Controller entra in un ciclo innito in cui ad ogni passo riceve i dati
dai sensori ed invia comandi per controllare il robot.
Tipici comandi sono DRIVE [?] per ordinare al robot di fare detrminati
movimenti e SET per attivare o disattivare sensori.
L'architettura client/server di Unreal permette di aggiungere molteplici robot nella simulazione. Considerato che ogni robot utilizza un proprio
socket per comunicare, ogni controller deve creare una diversa connessione
per ognuno dei robot impiegati.
21
Fig. 2.3: Un esempio di Controller completo di interfaccia graca per il Sony
Aibo ERS 7.
2.2 L'ambiente di simulazione
2.2.1 Le Arene
Nella terminologia di Unreal tutti gli oggetti che, come un robot, un sensore
o una vittima, possiedono comportamenti individuali, sono deniti Attori,
mentre i luoghi in cui gli Attori si muovono ed interagiscono sono chiamati
Arene.
La ricostruzione dell'ambiente gioca un ruolo molto importante nella simulazione: l'Arena è il necessario contesto senza il quale la simulazione non
avrebbe senso. In UsarSim vengono fornite tre Arene (Gialla, Arancione e
Rossa), che riproducono ambienti disastrati a dicoltà progressiva, secondo gli standard NIST Usar Test Facility. Nel caso ve ne fosse bisogno (ed
il lavoro di stage è questi casi), è sempre possibile creare nuove mappe ed
utilizzarle per eettuare i test.
Fig. 2.4: (a) Un'arena reale. (b) La corrispondente arena simulata
Le mappe vengono modellate all'interno del tool Unreal Editor, in grado
22
di importare modelli dai più diusi programmi di authoring 3D (Autocad,
3D Studio, Maya, ProEngineer). Per modellare macerie ed ostacoli possono
essere utilizzati materiali diversi, tra cui vetri, specchi, nastri arancioni di
sicurezza.
Durante l'attività di stage sono state sviluppate e migliorate una mappa
che riproduce il campo regolamentare della Four-Legged League e una mappa
per eettuare i test della Rescue Team.
2.2.2 I Robot
I robot sono gli Attori più importanti delle scene modellate in UsarSim. Durante lo stage sono stati utilizzati tre modelli di robot che verranno descritti
in seguito: i modelli P2-AT e P2-DX della ActivMedia Robotics e il modello
Aibo ERS 7 della Sony.
Fig. 2.5: Alcun dei robot virtuali per il soccorso e i corrispettivi reali.
I comandi relativi al controllo dei giunti sono impartiti al robot attraverso
messaggi nell'interfaccia Gamebots. Utilizzando il modello astratto KRobot
come base di partenza, è possibile costruire una riproduzione del proprio
robot, programmando in codice Unreal Script. Durante lo stage è stato
introdotto uno speciale robot, il WorldController. Merita attenzione questa
particolare novità perché è stata utilizzata durante lo stage in vari modi
sia dalla Legged che dalla Rescue Team, soprattutto per spostare robot e
oggetti, ma anche per generare dinamicamente mappe. Una volta creato
nella mappa, difatti, esso appare essenzialmente come un cubo che resta
immobile nel punto dove viene creato. Non ha difatti un comportamento
dinamico, si limita a ricevere comandi ed eseguire l'ordine ricevuto. Tali
ordini, come detto, sono la creazione e la rimozione dalla mappa di panelli,
23
cubi, pilastri o modelli statici di robot, ma anche lo spostamento di agenti
robotici dinamici guidati da controller o degli oggetti presenti nella mappa.
Per brevità e soprattutto a causa del "work in progress" a cui è ancora
sottoposto, non viene descritta sintassi e semantica dei comandi eseguibili
dal WorldController.
2.2.3 I Sensori
I Sensori sono modellati in UsarSim come Attori, con la limitazione di non
poter essere inseriti direttamente nella simulazione, ma solo come componenti di un robot. Ogni sensore può essere semplicemente montato sul robot
aggiungendo una riga di codice sul le di testo relativo alla congurazione
del simulatore. Devono essere specicati il nome del sensore, il tipo e la posa
(posizione ed orientamento) in cui è montato.
Possono essere elencate ulteriori proprietà speciche del tipo di sensore,
ad esempio la massima distanza raggiungibile dal laser scanner o il campo di
vista della telecamera; se queste non vengono specicate, UsarSim utilizzerà
dei valori di default, anch'essi modicabili nel le di congurazione.
Esempi di sensori attualmente modellati in UsarSim sono: Range Sensor,
Sensore Infrarosso, Sonar, Laser scanner, Telecamera.
Tutti i sensori ereditano dalla classe astratta Sensor. Le speciche dei
sensori ed il loro comportamento (input accettati, output generati) vengono
descritti in Unreal Script, il linguaggio di scripting interno al sistema. È
quindi possibile denire ulteriori sensori secondo le necessità.
Per permettere al controller del Sony Aibo sviluppato di non eettuare
Image Processing per rilevare la posizione della palla, durante lo stage è stato
creato un sensore rilevatore denominato BHS (Ball Helper Sensor).
2.3 Limiti nell'utilizzo di USARSim
Il principale limite nell'utilizzo di USARSim durante lo stage è stato rilevato sperimentando i robot Sony Aibo. Al crescere del numero di robot
presenti sulla mappa cresce il tempo di frame, ovvero il tempo necessario
all'Engine per calcolare ogni frame. Con un numero di aibo che non supera
i tre le prestazioni del simulatore sono ottime, no a cinque-sei robot sono
accettabili, con un numero di robot superiore divengono inaccettabili.
Ulteriore pesantezza nella produzione del frame è data dal calcolo delle
collisioni da parte del Karma Engine. Se quindi sei Aibo fermi o in movimento ma senza contatto vengono simulati abbastanza bene, le prestazioni
precipitano se due di loro entrano in collisione, no ad essere assolutamente
inaccettabili se le collisioni sono tra più di due di loro [?].
24
Fig. 2.6: Degrado delle prestazione al crescere del numero di robot simulati.
Fig. 2.7: Degrado delle prestazione al crescere del numero di robot simulati.
25
2.4 Unreal Editor
Ogni mappa utilizzata dal gioco Unreal Tournament e dal simulatore USARSim è stata creata e può essere modicata dall'Unreal Editor. Questo
è un editor molto semplice da utilizzare e molto potente, che permette di
creare qualunque tipo di mappa partendo da forme geometriche semplici
o più complesse quali scale o rampe, applicare qualunque tipo di texture,
denire i parametri sici degli oggetti contenuti all'interno della mappa, impostare le fonti di illuminazione e molto molto altro ancora. Tutto ciò che
non può essere fatto con Unreal Editor, può essere importato dopo essere
stato realizzato da programmi specializzati quali 3DS Max, Maya e così via,
rendendo praticamente illimitate le possibilità di creazione di arene.
Fig. 2.8: L'Unreal Editor.
Durante lo stage, è stato utilizzato per generare una semplice mappa
utilizzata poi per valutare le prestazioni degli SPQR Robots Rescue.
26
Capitolo 3
Sony Aibo e SPQR
Four-Legged Team
"Gli italiani prendono le partite di calcio
come se fossero guerre
e le guerre
come se fossero partite di calcio."
(Wiston Churchill)
La SPQR Four-Legged Team è la squadra al anco della quale è stato
svolta la maggior parte dell'attività di stage. In questo capitolo verrà introdotta la piattaforma robotica Sony Aibo ERS 7 sulla quale viene svolto
il lavoro di programmazione dei robot calciatori, accennando brevemente al
suo hardware e al sistema operativo, e presentata l'architettura software e
le scelte realizzative adottate, con particolare attenzione al modulo di coordinamento e ai piani di esecuzione implementati. Inne si parlerà del
modello USARBot.ERS, ovvero il modello virtuale 3D del Sony Aibo, illustrando brevemente i sensori implementati confrontandoli con quelli reali e
commentando le novità introdotte durante il lavoro di stage.
27
3.1 Sony Aibo ERS 7
Fig. 3.1: Sensori e attuatori dell'agente robotico Sony Aibo ERS 7 (Fronte).
Prodotto dalla Sony, nato come cane robotico da compagnia e quindi
con nalità ludiche e commerciali, è stato n dal primo anno della sua commercializzazione consentito nella Sony Four-Legged League della RoboCup
come alternativa al suo predecessore ERS 210. A causa delle sue prestazioni
nettamente superiori, in brevissimo tempo ha completamente sostituito in
ogni squadra la piattaforma precedente diventando lo standard attuale. In
gura vengono presentate le caratteristiche siche dell'agente robotico.
Fig. 3.2: Sensori e attuatori dell'agente robotico Sony Aibo ERS 7 (Retro).
Dal punto di vista software l'agente è invece provvisto del sistema operativo a oggetti APERIOS, prodotto dalla Sony e programmabile tramite
l'ambiente di sviluppo OPEN-R. Il linguaggio di programmazione tramite il
quale possono essere programmati oggetti APERIOS, ovvero i processi che
verranno eseguiti sull'AIBO, è il C++, mentre il dispositivo che permette di
dotare il robot dell' opportuno programma software sviluppato è il supporto
di memorizzazione memory stick, simile alle memorie ash delle fotocamere
digitali, anch'esso prodotto dalla Sony stessa.
28
3.2 Il codice della SPQR Legged Team
3.2.1 Architettura software del SPQR
SPQR (Soccer Player Quadruped Robot) [?] è il nome con cui viene chiamato l'intero sistema sotware sviluppato negli anni dalla squadra. L'attuale
architettura adottata dalla SPQR Team ricalca quella fornita nel 2004 dal
German Team, squadra pluricampione del mondo, anche se nel tempo sono
state introdotte e si stanno valutando modiche migliorative.
Fig. 3.3: Architettura del SPQR Code.
Come si può notare in gura, il modulo centrale fondamentale dal quale
dipendono o con il quale comunicano gli altri moduli è il BehaviorControl.
Ad esso arrivano informazioni dai moduli di Object Modelling circa posizione
della palla, dei robot, delle linee del campo, delle porte e così via, da esso
partono i comandi di agire in un determinato modo, comandi che vengono poi
tradutti in istruzioni di basso livello dai moduli di Motion Control. Al suo interno vengono prese decisioni comportamentali, ovvero il robot decide quale
piano eseguire, se continuare ad continuare in quello in cui è impegnato, o se
è opportuno cambiare le proprie convinzioni date anche le informazioni ricevute dai compagni di squadra. All'interno del Behavior Control è contenuto
il modulo di Coordinamento.
3.2.2 Il coordinamento
Non esiste coordinamento senza comunicazione. Per la comunicazione i robot
comunicano tramite una rete wireless secondo un protocollo 802.11.b e si
scambiano messaggi UDP contenenti informazioni sul proprio stato, sulla
propria posizione, sulla posizione della palla ed altro ancora.
29
Ogni agente ogni qualvolta si rende conto di avere nuove informazioni
disponibili, calcola delle funzioni di utilità per decidere il ruolo più appropriato alle sue condizioni. Per ogni agente soggetto a coordinamento dinamico
ne viene calcolata una per ogni ruolo, da cui nel caso degli Aibo vengono
calcolate nove funzioni di utilità, essendoci tre ruoli (Attaccante, Difensore
e Supporter) e tre robot coordinanti (il Portiere ha ruolo sso).
L'assegnazione dinamica ore prestazioni nettamente migliori di un assegnazione statica dato che la piattaforma hardware è unica e quindi nessun
robot è favorito rispetto ad un altro in un determinato ruolo. Inoltre la difcoltà di localizzazione, e i movimenti rapidi della palla incoraggiano ancora
di più la scelta di uno schema di coordinamento essibile [?].
L'algoritmo semplicato di assegnazione dei ruoli prevede i seguenti passi:
1 ogni agente valuta il tempo necessario a raggiungere la palla e lo
comunica agli altri;
2 ogni agente valuta chi è il robot che più rapidamente stima di raggiungere la palla e gli assegna il ruolo di attaccante;
3 assegnato il ruolo di attaccante, ogni agente valuta chi è il robot più
vicino alla posizione ideale di difesa, ovvero il punto di intersezione tra
la linea limite della propria area di rigore e la retta passante per la
posizione della palla e la propria porta, e a questo assegna il ruolo di
Difensore;
4 ogni agente assegna al robot rimasto il ruolo di Supporter.
Per evitare un'eccessiva oscillazione nella scelte di coordinamento, è stato previsto di sommare un bonus di isteresi alla funzione di utilità di un
determinato ruolo per il robot che al momento del calcolo già ricopriva tali
mansioni. In questo modo, solo quando un agente è in condizioni nettamente
privilegiate rispetto a quello che precedentemente ricopriva quel determinato
task, si opta per uno scambio di ruoli.
Benché il modulo sia stato implementato in modo da permettere l'adozione
di schemi variabili dinamicamente durante la partita, non è attualmente
sfruttata questa possibilità. Ciò signica ad esempio che la squadra una volta in vantaggio potrebbe decidere di adottare uno schema più difensivo con
due difensori e un attaccante, o in caso di svantaggio tentare una formazione
più squilibrata in avanti con due attaccanti e un difensore. Il problema è che
i piano attualmente implementati non permettono queste varianti tattiche.
Di conseguenza lo schema adottato è sempre il seguente: un difensore, un
attacante, un sopporter.
30
3.2.3 I piani
Il comportamento e l'atteggiamento che deve avere durante le diverse fasi
di gioco ogni robot è formalizzato tramite Petri Net Plans [?], una forma
di rappresentazione basata sulle reti di Petri divenuta standard del SPQR
Team, nelle quali vengono espressi le azioni e i sottopiani che il robot deve
compiere quando esegue un determinato task, le condizioni di inizio terminazione o interruzione di una determinata azione o piano e l'obbiettivo nale
del piano stesso. Ovviamente a seconda del ruolo assegnato dal coordinamento, l'agente si troverà in condizioni di dover eseguire un specico piano
anziché un altro. Viene ora brevemente presentato il piano di ogni ruolo
dinamico [?].
L'Attaccante
Primo in ordine di importanza, l'attaccante è l'unico che ha il diritto di
cercare di raggiungere e colpire la palla. Scopo dell'attaccante è ovviamente
fare goal. Per far questo, il piano prevede che l'agente trovi e raggiunga la
palla, cercando di non perderla di vista, e una volta raggiunta la calci verso la
porta avversaria. Nel caso la palla venga persa, cercarla nuovamente nchè
non viene ritrovata.
Fig. 3.4: Plan Attack.
Il Difensore
Il difensore non è, contrariamente a quanto si possa immaginare, colui che
va addosso all'attaccante avversario cercando di sottrargli la palla, bensì è
colui che si frappone tra la palla e la propria porta cercando di coprire il più
possibile dal rischio di un tiro avversario. Il piano del difensore prevede la
ricerca della palla e, una volta trovata, l'esecuzione del sottopiano defending,
31
ovvero cercare di posizionarsi appunto nella migliore zona difensiva, ovvero
tra la palla e la porta.
Fig. 3.5: Plan Defence.
Il Supporter
Il supporter, così come il difensore, assolve al proprio dovere concentrandosi
più sulla propria localizzazione che sulla palla stessa. Compito del supporter
è difatti quello di posizionarsi in una zona del campo tale che se l'attaccante
dovesse perdere palla sia il primo ad accorrere per raggiungerla. La zona più
adatta al sopporting è denita a seconda di dove si trova l'attaccante e la
palla.
Fig. 3.6: Plan Support.
32
3.3 USARBot.ERS
3.3.1 I sensori virtuali
La versione virtuale del robot non è ovviamente identica al robot reale. Se è
vero che si è cercato il più possibile di creare un modello 3D somigliante al
robot reale, la simulazione dei sensori e degli altri componenti hardware non
è così semplice. Come si avrà già avuto modo di intuire nel capitolo dedicato
ad USARSim, sono state utilizzati dei trucchi per avere un comportamento
del robot virtuale il più possibile vicino a quello reale.
I sensori simulati, oltre alla telecamera, sono gli IR Sensors (sensori
infrarossi), l'Acceleration Sensor (l'accelerometro) e il Ball Helper Sensor,
ovvero un sensore ttizio elaborato allo scopo di avere una ball detection
con precisione assoluta.
3.3.2 La telecamera
La telecamera sulla testa del robot virtuale fornisce un'immagine nitida di
ciò che vede l'agente simulato. Questo potrebbe sembrare un vantaggio,
in realtà la telecamera del Sony Aibo reale è decisamente più rumorosa,
quindi un'immagine così pulita risulta inutilizzabile per fare test di Image
Processing. Risulta però molto utile ad un operatore umano per avere un
feed-back visivo di ciò che il robot vede nella telecamera, permettendo così
di sapere se il robot agisce in un certo modo perchè non vede la palla o per
un eventuale bug nel controllore.
Fig. 3.7: Dierenza di immagine presa con la telecamera reale (a) o virtuale
(b).
3.3.3 Ball Helper Sensor
Ultimamente è stato introdotto un sensore virtuale denominato BHS (Ball
Helper Sensor). Questo sensore non ha un corrispettivo reale sul Sony Aibo,
ma è molto utile nella simulazione dei robot. Il suo funzionamento cosiste
nel restituire l'indicazione se nella telecamera del robot è visibile o meno la
33
palla, qual'è eventualmente la sua posizione all'interno della camera e le sue
coordinate assolute nel mondo virtuale. Tramite questo sensore è possibile
conoscere la posizione della palla senza eettuare elaborazioni complesse,
semplicemente estraendo i valori da una stringa.
3.3.4 IR Sensors
I sensori infrarossi sono stati programmati in modo da simulare anche un'attendibilità di misura che rispecchi quella del sensori reali. Questo signica
che è stato cercato di renderli il più possibile realistici, inserendo anche i
difetti che i sensori reali non possono non avere. Questo li rende ancora più
utili nell'eettuare test validi.
IRN: è l' infrared near sensor (corrispondente al sensore di prossimità
dell'aibo reale)
IRF: è l' infrared far sensor (corrispondente al sensore di distanza dell'aibo reale)
EDG: è l' infrared edge sensor (corrispondente al sensore sul petto dell'aibo reale)
3.3.5 Acceleration Sensor
Questo sensore riporta l'accelerazione istantanea a cui è sottoposto il robot.
In realtà il sensore considera solo l'acelerazione relativa del robot trascurando
quella gravitazionale, con il risulta di non restituire valori attendibili. Per
questo motivo non è utilizzabile, ma ciò comporta solamente che il robot non
è in grado di capire di essere capovolto (evento assai raro) e quindi rende
inutilizzabile l'azione di raddrizzamento.
3.3.6 Il comando di movimento MultiDrive
Il comando per il movimento DRIVE utilizzato convenzionalmente per muovere i robot dotati di ruote non è certamente adatto a muovere il modello
del Sony Aibo, dovendo questo muovere 3 giunti per ogni zampa e tutte e
quattro le zampe solo per fare un passo, senza considerare poi i movimenti
della testa. Durante l'attività di stage, in collaborazione con lo sviluppatore di USARSim Ing. Marco Zaratti, è stato introdotto un nuovo comando
che permette con un unica striga di azionare tutti i giunti delle zampe e
della testa che sono necessari per il movimento desiderato, chiamato prima
AIBODRIVE e poi denitivamente MULTIDRIVE [?].
La sintassi è la seguente
MULTIDRIVE joint1 valuejoint2 valuejoint3 value ...
La semantica è piuttosto immediata: jointX è in nome del giunto che si
vuole pilotare, value è il corrispondente valore angolare nale a cui si vuole
che il giunto converga.
34
Questo comando è ora consigliato per tutti i robot che necessitano di
muovere molteplici giunti contemporaneamente. Viene qui mostrato come il
comando si adatta non solo a muove il modello dell'Aibo, ma anche quello
del robot bipede QRIO.
Fig. 3.8: Nome dei giunti per muovere il Sony Aibo tramite MULTIDRIVE.
35
36
Capitolo 4
Lavoro e Tools nella
Four-Legged Team
"Una macchina è in grado di lavorare
come cinquanta uomini comuni,
ma nessuna macchina può svolgere
il lavoro di un uomo straordinario"
(Elbert Hubbard)
Essendo il primo anno che la SPQR Four-Legged Team utilizza USARSim, è stato necessario un lavoro preventivo per poter poi utilizzare il simulatore 3D come strumento per valutare il coordinamento. Questo capitolo
esamina il lavoro svolto durante l'attività di stage per conto della Legged
Team, descrivendo dettagliatamente i tre tools sviluppati: SIMMotion, SIMWorldControllerClient, LogExaminator. Vengono presentati gli strumenti
utilizzati per lo sviluppo dei tools, indicate le motivazioni che ne hanno suggerito la creazione, giusticate le scelte implementative eettuate, illustrate
le modalità e gli scenari di utilizzo, descritti gli output forniti, commentati
gli eventuali difetti.
37
4.1 Introduzione al lavoro svolto
Essendo come detto il primo anno che la SPQR Four-Legged Team utilizza il
simulatore 3D, sono stati molti i problemi riscontrati inizialmente e le parti
su cui si è dovuto lavorare. USARSim è nato per simulare agenti robotici con
ruote, non è stato semplice tarare i valori e modicare i parametri del modello
del Sony Aibo per avere un comportamento il più possibile vicino a quello
reale. Inoltre adattare il codice dell'Aibo al simulatore è stato anch'esso un
lavoro non banale. Non ci si soermerà sull'intero lavoro svolto da tutto
il Team, verranno presentati solo gli strumenti realizzati per raggiungere
l'obbiettivo di valutare le prestazioni del coordinamento, considerando risolti
i problemi non strettamente legati ad esso.
I tools sviluppati nell'ambito del lavoro sono tre: SIMMotion, SIMWorldControllerClient, LogExaminator.
4.2 Strumenti utilizzati
Per lo sviluppo dei tools è stato utilizzato principalmente l'IDE Eclipse 3.1,
anche se a volte per brevità è stato preferito l'utilizzo di editor più semplici
quali Notepad++ per Windows e Kate per Linux. La scelta di Eclipse nasce
dalla necessità di sviluppare codice sia su piattaforma Windows che Linux
(nel primo caso utilizzando il compilatore gcc/g++ di Cygwin). Eclipse ha
permesso quindi di utilizzare sempre lo stesso IDE indipendentemente dal
sistema operativo utilizzato, rendendo più comodo abituarsi a scorciatoie
utili per velocizzare la stesura del codice.
Riferendosi poi ai tool sviluppati in Java, soprattutto se completi di interfaccia graca, l'autocompilazione automatica, il completamento di codice,
lo sviluppo visuale delle interfacce permesso da Eclipse si è rivelato fondamentale per accelerare la produzione di codice pulito ed eciente.
4.3 Tools sviluppati
4.3.1 SIMMotion
Scritto completamente in C++ per adattarsi al codice della SPQR FourLegged Team, nato partendo dai precedenti tools Motion e MotionCoord
sviluppati dal Team, è il primo tool (e attualmente l'unico) che ha permesso
la simulazione su USARSim di una partita di calcio tra due squadre di Aibo
coordinati.
SIMMotion al suo interno utilizza o sostituisce tutti i moduli software
del robot reale, trasforma i comandi che nel Sony Aibo vengono inviati ad
Aperios in stringhe di comando da inviare al simulatore e converte le stringhe
38
ricevute dal simulatore nelle rispettive informazioni e strutture dati che verranno poi utilizzate nell'elaborazione. Sebbene fosse possibile ricevere da
USARSim l'immagine ottenuta dalla telecamera virtuale per utilizzarla come
se provenisse dalla telecamera reale ed eettuare Image Processing, essendo
la visuale simulata praticamente perfetta non è utilizzabile per testare i moduli di Visione e Localizzazione che devono invece essere robusti ad immagini
rumorosissime e condizioni di luce variabili. Per questo motivo entrambi
i moduli non sono utilizzati, le informazioni sulla posizione della palla e
del robot stesso vengono prelevate dalle stringhe ricevute dal sensore BHS
di USARSim e messe nelle opportune strutture dati. Tale semplicazione
alleggerisce enormemente il carico computazionale del processo SIMMotion,
permettendo così di lanciarne numerosi sulla stessa macchina senza problemi.
Su un laptop Acer TravelMate 382Tci con processore Intel Centrino 1,6
GHz utilizzato per i test e per lo sviluppo, con 8 processi SIMMotion funzionanti senza limitazioni e cooperanti tra loro su sistema operativo Windows
XP tramite l'utilizzo di Cygwin (quindi con ulteriore carico) l'utilizzo della
CPU (ad eccezione dell'istante in cui i processi vengono lanciati) oscilla tra
il 10 e il 30 percento, su piattaforme Linux addirittura dicilmente supera
il 20.
Motion non si preoccupava di simulare il coordinamento tra i robot, i
primi tentativi sono stati eettuati con MotionCoord che tramite memoria condivisa cercava senza successo di risolvere il problema dello scambio
dei messaggi. Sfruttando sempre la memoria condivisa, ma apportando alcune fondamentali correzioni, SIMMotion simula correttamente lo scambio
di messaggi permettendo il coordinamento. Purtroppo è stato necessario
"sporcare" il codice del robot inserendo due IFNDEF APERIOS all'interno
delle classi TeamMessage e TeamMessageCollection (le classi contenenti le
informazioni utilizzate dal modulo di coordinamento) per inibire il controllo
che il messaggio ricevuto sia recente, questo perché i timeStamp su cui si
basava il controllo venivano inseriti nei pacchetti UDP da Aperios, di conseguenza non erano presenti nei messaggi scambiati tramite shared memory,
questo trucchetto però non inuisce minimamente sulle prestazioni né del
robot vero né del robot simulato.
Un ulteriore feature inserita nel tool è stata la possibilità di far scrivere
al tool un le di log, nel quale ad ogni pacchetto ricevuto da USARSim
viene scritto il time stamp fornito dal simulatore, la posizione in campo del
robot e il ruolo che sta giocando in quel momento. Questo le di log è
utilizzato per un'analisi a posteriori del comportamento del robot e, insieme
ai log degli altri robot e a quello della palla, per un'analisi a posteriori del
comportamento di tutta la squadra.
Non viene spiegato ulteriormente il funzionamento e la struttura del
39
tool perché questo prevedrebbe una preventiva trattazione esauriente dell'architettura e del funzionamento del codice del robot reale, e tale trattazione,
oltre ad essere estremamente lunga e complessa, esula dagli obiettivi e dal
tema principale di questa relazione. L'utilità del tool e i motivi che hanno
portato a svilupparlo e migliorarlo sono evidenti e comunque sono già stati
espressi.
4.3.2 WorldControllerClient
Spesso nel testare i robot reali si ha il bisogno di spostare manualmente
i robot, per guadagnare tempo o per fare delle prove di localizzazione o
quant'altro. Un grande limite nell'eettuare test sul simulatore era proprio
il poter stare solo a guardare. Con l'introduzione da parte degli sviluppatori di USARSim (nello specico l'Ing. Marco Zaratti) del WorldController,
questo limite è stato superato. Il WorldController permette (una volta inserito all'interno del campo di gioco) di spostare qualunque robot inviando
il comando:
CONTROL Type AbsMove Name nomeRobot Location x,y,z
A questo punto è risultata evidente la comodità di avere un tool che
permettesse di inviare al WorldController tali richieste non scrivendo manualmente le stringhe tramite telnet o simili programmi, ma tramite un'intuitiva interfaccia graca che permettesse di spostare la palla o il robot semplicemente cliccando sul punto di destinazione in un campo disegnato, una
proiezione in 2D del campo reale. Questo tool è WorldControllerClient.
Fig. 4.1: Il WorldControllerClient.
Lasciando a WorldControllerClient l'esclusiva di creare la palla nel simulatore, il tool riceve di continuo informazioni aggiornate sulla posizione
in campo di questa. Diventa quindi estremamente semplice disegnarne la
posizione sul campo e tracciarne di continuo gli spostamenti, così come è
altrettanto semplice far scrivere al tool un le di log che tenga traccia della
posizione della palla ad ogni istante (come nel caso di SIMMotion). Dal
40
momento che il tool conosce la posizione della palla, è anche in grado di
capire se questa è in campo o meno, se una squadra ha segnato o no, e quindi riposizionarla in un punto del campo, sia esso il centrocampo o un altro
punto. Questo è ciò che viene fatto quando è attivo il logger, ovvero quando
si chiede al tool di scrivere su un le la posizione della palla ad ogni messaggio ricevuto da USARSim. Siccome il logger tiene segna anche quando la
palla è fuori campo o è in goal, ogni volta che si verica uno di questi casi la
palla viene riposizionata. Questo per evitare che se la palla resta nella porta
per 5 secondi (considerando che USARSim invia 5 messaggi al secondo) il
logger assegni per 25 volte il goal ad una squadra.
Analizzando i casi in cui si utilizza SIMWorldControllerClient:
• Caso estremo : l'utente vuole che i robots giochino una partita nor-
male e scrivano i log che verranno analizzati a ne partita. Attivando il
logger e quindi il riposizionamento automatico non è più necessario che
un operatore umano si concentri nel guardare la partita rimettendo la
palla in campo ogni volta che esce o contando i goal: la palla è gestita
dal tool, l'operatore deve solo attendere il tempo che ritiene necessario
e valutare i log. In nessun modo il riposizionamento automatico può
corrompere i log.
• Caso medio : l'utente vuole fare dei test, in alcuni casi vuole spostare
i robot e la palla in determinate posizioni e vedere cosa succede, ma
non vuole essere vincolato a controllare che la palla non esca e doverla
rimettere in campo mentre magari è concentrato ad osservare un robot
dall'altra parte del campo. Anche in questo caso il riposizionamento
automatico va in aiuto dell'utente, senza compromettere in alcun modo
i suoi test né l'integrità dei log.
• Caso estremo opposto : l'utente vuole gestire completamente palla
e riposizionamenti perché vuole fare dei test anche con la palla fuori dal
campo. In questo improbabile caso è suciente non attivare il logger
e il riposizionamento automatico sarà disabilitato. Il log non verrà
scritto, ma è leggittimo pensare che non sia necessario considerando il
fatto che non ha senso valutare le prestazioni di una squadra che deve
giocare con la palla fuori campo.
Non avendo vincoli di adattamento al codice di altri moduli software, la
scelta del linguaggio di programmazione da utilizzare per lo sviluppo del tool
è ricaduta su Java per vari motivi:
• maggiore conoscenza e comodità personale
la maggior parte degli esami di programmazione nell'attuale corso
di laurea prevede l'utilizzo di Java.
41
il linguaggio pointerless e le librerie java.io e java.net favoriscono
lo sviluppo di applicazioni in tempi molto brevi.
• la non necessità di prestazioni elevatissime
l'interazione con l'utente avviene in modo ovviamente asincrono,
per cui la programmazione a eventi di Java si adatta perfettamente.
- il tool deve mandare e ricevere periodicamente messaggi su una
socket a intervalli di circa 5 volte al secondo, o comunque di certo
non in RealTime, quindi ad una ricerca di prestazioni elevate è
stata preferita una ricerca di semplicità.
• la facilità di costruire interfacce grache
le librerie AWT e Swing facilitano molto il programmatore.
IDE come Eclipse col plugin Visual Editor permettono di "disegnare" intefacce.
• portabilità e riusabilità
il tool deve poter girare sia su Windows che su Linux.
la struttura del tool ne ha permesso un successivo immediato riutilizzo di varie parti da parte della Rescue Robots Team per scopi
anche piuttosto diversi da quello originario.
Il tool è stato utilizzato ovviamente insieme a SIMMotion nell'eettuare
test sul coordinamento, ma anche nel debug dei piani e nel testare il comportamento dei robot in situazioni particolari, dicili se non impossibili da
testare senza avere la possibilità di spostare manualmente robots e palla.
4.3.3 LogExaminator
Risolto il problema di come prendere i log, resta il problema di come utilizzarli per valutare le prestazioni di una squadra. LogExaminator è un piccolo
e semplice tool, anche questo in Java per i motivi già elencati, che automatizza questa analisi. I le di log sono uguali sia per la palla che per i robot
e sono simili al seguente:
TIME 48.4 X -299.899994 Y 1.500000 EXTRA 1
TIME indica il time stamp fornito dal simulatore, X e Y indicano le
coordinate del robot o della palla sulla mappa. Mentre per i robot il valore
EXTRA indica il ruolo giocato in quel momento dal robot, per la palla tale
valore viene utilizzato per indicare situazioni particolari quali goal o palla
fuori dal campo.
42
Leggendo dai le di log della palla e quelli della squadra prescelta, LogExaminator li esamina i dati ottenuti e restituisce in output i seguenti
valori:
• Tempo totale :
È il numero di TimeStamp valutati, ovvero il numero di linee del le di log distinte che sono stati elaborate. TIME è
l'identicatore univoco della linea. Utile per vericare se il numero di
campioni analizzati è suciente a dare un risultato attendibile.
• Copertura zone : Diviso in DIFESA CENTRO e ATTACCO, indica
la percentuale di tempo in cui almeno un robot era posizionato nella
fascia di campo corrispondente. Utile per valutare la copertura delle
zone di campo.
• Zone scoperte (con palla nella zona) : Diviso in DIFESA CEN-
TRO e ATTACCO, indica la percentuale di tempo in cui nessun robot
era posizionato nella fascia di campo corrispondente mentre la palla si
trovava proprio in quella fascia. Utile per valutare la prontezza con cui
i robot cambiano la disposizione in campo per seguire gli spostamenti
della palla.
• Zone sovraollate (con palla lontana) : Diviso in DIFESA CEN-
TRO e ATTACCO, indica la percentuale di tempo in cui nessun robot
era posizionato nella fascia di campo corrispondente mentre la palla si
trovava proprio in quella fascia. Utile per valutare la prontezza con cui
i robot cambiano la disposizione in campo per seguire gli spostamenti
della palla.
• Palla nella zona : Diviso in DIFESA CENTRO e ATTACCO, indica
la percentuale di tempo in cui la palla si trovava in una determinata
fascia di campo. Utile per valutare in quale zona di campo si è giocato
maggiormente.
• Distanza Media Compagni : Distanza media tra i robot (escluso
il portiere) misurata in millimetri. Utile per valutare la distribuzione
dei robots nel campo.
• Contrasti tra Compagni : Percentuale di tempo per la quale due
robot si sono trovati in posizioni molto ravvicinate. Utile per valutare
in che misura i robots si sono ostacolati tra loro.
• Vicinanza alla palla :
Percentuale di tempo per la quale almeno
un robot si trovava nelle immediate vicinanze della palla. Utile per
valutare il possesso palla.
• Goal/KTime Segnati : Numero di goal segnati ogni mille TimeS-
tamp. Utile per valutare la capacità di segnare astraendo dalla durata
della partita.
43
• Goal/KTime Subiti : Numero di goal subiti ogni mille TimeStamp.
Utile per valutare l'incapacità di evitare di subire goal astraendo dalla
durata della partita.
• Azioni/KTime Eettuate :
Numero di tiri niti a fondo campo
vicino la porta avversaria ogni mille TimeStamp. Utile per valutare la
capacità di portarsi in avanti pur non riuscendo a far goal.
• Azioni/KTime Subite : Numero di tiri niti a fondo campo vicino
la propria porta ogni mille TimeStamp. Utile per valutare l'incapacità
di allontanare la palla dalla propria area pur non subendo reti.
I risultati restituiti, come si può notare, non hanno una valenza assoluta
e univoca. Questo perché non è facile, forse non è possibile, creare una
"funzione di bontà" che associ ad una determinata quaterna di log un univoco
valore maggiore di quello ottenuto con un'altra quaterna di log rispecchiando
così una migliore prestazione della squadra.
LogExaminator quindi non pretende si fornire un unico valore di prestazione,
bensì propone una tabella di valori signicativi che, opportunamente interpretati, possono dare un'idea delle bontà della strategia adottata. Questo è
l'approccio che è stato utilizzato nel valutare le prestazioni del coordinamento
della SPQR Four-Legged Team.
44
Capitolo 5
Four-Legged Test e Risultati
"I computer sono inutili,
possono dare solo risposte."
(Pablo Picasso)
In questo capitolo verranno presentate le considerazioni e le scelte per
quanto riguarda i test di valutazione compiuti sul coordinamento della squadra
di calcio robotico della Four-Legged Team. Verranno presentati il piano di
test preliminare, esaminati i problemi riscontrati e le modiche apportate al
piano per ovviare a queste limitazioni. Delle risposte fornite dai test verrà
presentato uno schema tabellare corrispondente all'output del tool LogExaminator, ne verrà poi fatta un'analisi e fornite le valutazioni risultanti sul
corportamento della squadra in condizioni di coordinamento e di non coordinamento. Verrano inne fatte ulteriori considerazioni sull'utilizzo stesso del
simulatore come strumento di test.
45
5.1 Piano di Test
5.1.1 Considerazioni iniziali
Essendo come si è visto la strategia di coordinamento della SPQR FourLegged Team stata formulata prendendo spunto dall'esperienza della Azzurra Robot Team [?], sembra ragionevole pensare di ricalcarne anche le
metodologie di valutazione delle prestazioni. In realtà, si è deciso di andare
oltre. L'Azzurra Robot Team venivano valutate sistematicamente soltanto
la posizione dei robot in campo e l'assegnazione dei ruoli.
Le due tabelle mostrano un esempio di valutazione di ART:
Fig. 5.1: Esempi di risultati di test valutativi della squadra ART.
Questa valutazione, oltre ad essere riduttiva rispetto a quella permessa
dal tool LogExaminator, ha anche nalità diverse. In una Four-Legged Team
dove i robot sono tutti uguali, non ha molta importanza sapere per quanto
tempo è stato difensore o supporter e quanto tempo è stato in avanti o in
difesa ognuno di loro, bensì interessa sapere se e in che dimensioni c'è stato un
conitto di ruoli e come la squadra si dispone in campo, indipendentemente
dal fatto che il robot in difesa sia il numero 2 3 o 4.
46
Per testare le prestazioni della squadra è necessario selezionare alcune
classi di casi di test, eettuare per ugnuna di queste classi più di una misurazione, in modo che sia possibile ridurre la possibilità di errore dovuta ad
eventi casuali, e considerare quindi come attendibile il risultato più frequente.
Non essendo possibile al momento fare dei test considerando diverse strategie essendo i piani di gioco dell'attaccante, difensore e supporter studiati per
utilizzare solo la strategia adottata dalla squadra SPQR Four-Legged Team,
la valutazione ricadrà sulle dierenze tra il comportamento di una squadra
coordinata ed una non coordinata. La metodologia applicata permette comunque di eettuare gli stessi test e utilizzare gli stessi tool per valutare le
prestazioni di una squadra con tattiche di gioco dierenti nel momento in cui
la SPQR Four-Legged Team deciderà di voler sperimentare nuove strategie
di coordinamento.
5.1.2 Piano di test preliminare
Inizialmente si è deciso quindi di adottare il seguente piano di test:
• Classe 1 : Valutare le prestazioni di una squadra di 4 robot coordinati
durante una partita contro una squdra di 4 robot coordinati che giocano
con la stessa strategia
durante una partita contro una squadra di 4 robot non coordinati
durante una partita contro una squadra di 2 robot non coordinati
• Classe 4 :
Valutare le prestazioni di una squadra di 4 robot non
coordinati durante una partita contro una squadra di 2 robot non
coordinati
La Classe 1 è stata ritenuta interessante per avere un riferimento di
prestazioni da confrontare successivamente con le altre classi di casi di test,
ovvero per valutare se e in che proporzioni migliorano o peggiorano le prestazioni
di una squadra coordinata quando gioca con un avversario coordinato o non
coordinato.
La Classe 2 è la classe più interessante per confrontare una squadre
coordinata e una non coordinata che giocano una contro l'altra.
La Classi 3 e 4 sono state ritenute interessanti per valutare come si comportano le due squadre in situazioni di chiaro vantaggio, ovvero giocando 4
contro 2.
47
5.1.3 Problemi riscontrati
Il problema che è risultato subito evidente n dalle prime prove e che è già
stato esaminato nel capitolo dedicato al simulatore USARSim è il degrado delle prestazioni del simulatore al crescere del numero di robot presenti
nella mappa. Considerando una partita 4 contro 4, il frame rate scende vertiginosamente no anche a 4 - 5 frame al secondo, rendendo assolutamente
inattendibile, non valutabile e privo di signicato il comportamento dei robot
simulati [?].
Un primo tentativo di alleggerire il carico computazionale sul server che
esegue USARSim è stato eliminare i portieri, i quali seppure comunichino
con gli altri robot, non partecipano in alcun modo al coordinamento e all'assegnazione dei ruoli dinamici, avendo essi il ruolo sso di portiere. Con
sei robot le prestazioni del simulatore migliorano notevolmente, ma diventa
ancora insucienti nel momento in cui due robot entrano in collisione. Le
prestazioni precipitano nuovamente se le collisioni sono tra tre robot o due
coppie di robot.
Per questo motivo, per rendere attendibili i risultati delle classi di test che
prevedevano la presenza di robot non coordinati è stato necessario utilizzare
frequentemente il tool SIMWorldControllerClient per spostare manualmente
i robot che andavano a collidere in continuazione. Per riconoscere il numero
di robot all'interno di una squadra, è stato necessario modicare le texture
del modello 3D del robot Sony Aibo. La testa del robot numero 4 è rimasta
del tradizionale colore nero, la testa del numero 2 è stata colorata di verde,
quella del robot numero 3 è stata colorata di bianco. Al portiere ovviamente
non è stato necessario apportare modiche per riconoscerlo in campo.
Ulteriore problema, nei test che prevedono la presenza di robot non coordinati che tendono ad ammassarsi intorno alla palla, la probabilità di ribaltamento cresce molto, rendendo necessaria la presenza davanti al display
di un operatore che provveda a invalidare il test in caso di ribaltamento di
un robot o che intraprenda azioni preventive quali lo spostamento del robot
a rischio tramite il WorldControllerClient.
5.1.4 Piano di test nale
Visti i problemi risontrati, per avere comunque una valutazione del comportamento della squadra in condizioni ottimali di simulazione, ovvero con
meno di 4 robot, sono state introdotte due ulteriori classi di test. Il piano
nale è quindi il seguente:
• Classe 5 :
Valutare il comportamento di una squadra di 3 robot
coordinati che giocano senza avversari, ma con un operatore umano
che sposta la palla manualmente
• Classe 6 : Valutare il comportamento di una squadra di 3 robot non
48
coordinati che giocano senza avversari, ma con un operatore umano
che sposta la palla manualmente
Fig. 5.2: Istantanea di una partita di calcio tra robot virtuali.
5.2 Risultati dei Test
Viene ora riportata una tabella di risultati per ogni classe di test sviluppato.
In realtà i test eettuati (non considerando i casi invalidati da ribaltamento
di un robot) sono stati 4 o 5 per ogni classe di test. I valori riportati in
tabella corrispondono al caso medio, considerato che la varianza tra i diversi
risultati era minima.
49
Totale Time Test
Classe 1
Team RED Cooordinata
2275
Team BLUE Coordinata
2275
Copertura Zone
Difesa
Centro
Attacco
91
72
64
89
79
70
Zone scoperte
Difesa
Centro
Attacco
1
7
0
4
3
3
Zone sovraollate
Difesa
Centro
Attacco
15
8
1
6
10
5
Palla nella zona
Difesa
Centro
Attacco
27
59
13
13
59
27
1615 mm
6
0
1819 mm
3
0
14
1
1
2
2
20
1
1
2
2
Distanza media compagni
Contrasti tra compagni
Conitti di ruolo
Vicinanza alla palla
Goal/Ktime segnati
Goal/Ktime subiti
Azioni/Ktime eettuate
Azioni/Ktime subite
50
Totale Time Test
Classe 2
Team RED Non Coordinata
2013
2013
Copertura Zone
Difesa
Centro
Attacco
80
46
15
90
71
67
Zone scoperte
Difesa
Centro
Attacco
15
16
14
0
4
4
Zone sovraollate
Difesa
Centro
Attacco
29
22
7
12
12
3
Palla nella zona
Difesa
Centro
Attacco
47
31
20
20
31
47
823 mm
37
100
1742 mm
3
0
12
0
4
1
6
29
4
0
6
1
Conitti di ruolo
Goal/Ktime segnati
Goal/Ktime subiti
Azioni/Ktime eettuate
Azioni/Ktime subite
51
Totale Time Test
Classi 3 e 4
2108
2019
Copertura Zone
Difesa
Centro
Attacco
73
41
11
95
86
85
Zone scoperte
Difesa
Centro
Attacco
25
23
21
0
2
1
Zone sovraollate
Difesa
Centro
Attacco
31
24
12
7
5
0
Palla nella zona
Difesa
Centro
Attacco
33
34
32
32
34
33
623 mm
64
100
1813 mm
1
0
12
29
Conitti di ruolo
52
Totale Time Test
Classi 5 e 6
2182
2077
Copertura Zone
Difesa
Centro
Attacco
54
42
42
98
91
88
Zone scoperte
Difesa
Centro
Attacco
25
23
21
0
1
0
Zone sovraollate
Difesa
Centro
Attacco
35
24
22
2
1
0
Palla nella zona
Difesa
Centro
Attacco
33
34
32
32
34
33
523 mm
64
100
1791 mm
1
0
10
22
Conitti di ruolo
5.2.2 Analisi valutativa
Nel caso della classi 3 4 5 e 6, non è stato ritenuto un dato signicativo
il numero delle azioni o dei goal subiti o eettuati, essendo le situazioni di
gioco volutamente articiali.
Mentre nel caso delle squadre coordinate notiamo un miglioramento delle
prestazioni al crescere dell'idealità dell'ambiente, per quanto riguarda i robot
non coordinati, le prestazioni decrementano. Tale signicativo risultato
dipende probabilmente dal fatto che nelle partite con molti robot l'incidenza
del fattore casualità è maggiore rispetto alle partite con campo praticamente
libero. Ne sono un indicatore i valori riguardanti la distanza media tra i robot
e la percentuale di tempo in cui si sono vericati contrasti tra compagni.
Le squadre coordinatate hanno sempre e comunque dimostrato di es53
sere nettamente superiori, coprendo bene le varie zone del campo, facendosi
cogliere dicilmente sbilanciate, trovandosi spesso ad avere un robot pronto
a recuperare la sfera nel caso il compagno ne perdesse il possesso. Per contro,
le squadre non coordinate vincono facilmente il "duello sico", trovandosi
in molte occasioni con i robot concentrati in piccole zone del campo, ma
trovandosi poi impreparate a gestire situazioni in cui la palla si allontana.
Molto spesso addirittura erano gli stessi compagni a togliersi palla a vicenda,
nendo col perderne il possesso e permettere il contropiede agli avversari.
Nella partita tra le due squadre coordinate, si può invece notare come
i valori risultanti siano eettivamente abbastanza attendibili. Due squadre
che giocano allo stesso modo hanno difatti (salvo variazioni dovute a eventi
casuali) più o meno le stesse prestazioni.
5.2.3 Ulteriori considerazioni
Utilizzando in continuazione il simulatore e il codice della SPQR FourLegged Team con l'obbiettivo di prendere log o valutare i comportamenti
della squadra, senza sforzo è stato portato avanti un buon lavoro di debug
non solo del modulo di coordinamento, ma anche delle azioni e dei piani del
robot.
Se generalmente a comportamenti anomali del robot simulato erano associate tarature speciche di parametri ottimizzate per il robot reale che
necessitavano di un adattamento per produrre gli stessi risultati nel mondo
virtuale, in alcuni casi invece sono stati evidenziati bugs che nel robot reale
erano associati a percezioni errate o modellazioni imperfette, e sono stati
prontamente corretti. Non vengono ivi riportati perchè non costituivano
lavoro di stage.
Tale ulteriore inatteso successo ribadisce l'ecacia del simulatore nel
testare senza fatica situazioni di gioco dicilmente ricreabili nel mondo reale
e lo pone come strumento indispensabile come supporto al lavoro futuro.
54
Capitolo 6
P2AT,P2DX e SPQR Rescue
Robots Team
"Non sono avventuriero per scelta,
ma per destino"
Vincent Van Gogh
In questo capitolo verrà presentato brevemente il sistema utilizzato per
l'analisi di squadre di robot per il soccorso. Di questo sitema fanno parte le
due piattaforme robotiche per il salvataggio sulle quali sono state eettuati
test di coordinamento(il P2AT e il P2DX) ed il framework SPQR-RDK,
sviluppato dalla Rescue Robots Team per essere utilizzato con squadre di
robot, del quale verrà fornita una descrizione delle caratteristiche fondamentali, mettendo in evidenza solo le parti inerenti all'attività di stage, con
particolare attenzione alla console Zeus, strumento indispensabile per la valutazione del coordinamento. Inne sarà illustrata la strategia di coordinamento utilizzata dal team.
55
6.1 P2AT e P2DX
I Pioneer della ActiveMedia Robotics presentano dierenze tra loro, ma hanno caratteristiche in comune. Entrambi si muovono su ruote, utilizzando
un modello cinematico uniciclo: il P2AT si muove su quattro ruote motrici
disposte a coppie di due, il P2DX su due ruote motrici ed un castor per mantenere lequilibrio. Per questo motivo, il P2AT eroga una potenza maggiore,
mentre il P2DX riesce ad essere più preciso nell'esplorazione. Entrambi presentano dei laser scanner, sensori ultrasuoni e telecamere con cui valutano
e si costruiscono una rappresenzazione del mondo che li circonda. Il P2AT
possiede più di una telecamera, permettendo anche di sfruttare la stereo visione nella costruzione e dell'ambiente e degli oggetti che circondano il robot
nell'arena, possibilità non necessaria per il lavoro di stage.
Fig. 6.1: Il P2AT.
Queste in breve sono le due piattaforme robotiche su cui è stato svolto
il lavoro di test presso il laboratorio SIED (Sistemi intelligenti per le Emergenze e la Difesa civile) [?], nato dalla collaborazione tra l'ISA (Istituto Superiore Antincendi) ed il DIS (Dipartimento di Informatica e Sistemistica)
con l'obiettivo di svolgere attività di ricerca volte allo sviluppo di metodologie,tecniche e strumenti prototipali da utilizzare in Operazioni di Soccorso.
Fig. 6.2: Il P2DX.
Entrambi i modelli virtuali dei robot vengono forniti col pacchetto di
56
USARSim e non hanno subito modiche o sviluppi durante lo stage, riproducendo già abbastanza fedelmente il comportamente dei robot reali. Le differenze tra i robot sono completamente mascherate dal framework utilizato
dal Team per lo sviluppo del software di questi ed altri robot: l' SPQR-RDK.
6.2 SPQR-RDK
6.2.1 Presentazione della piattaforma di sviluppo Spqr-Rdk
All'interno del DIS è stata creata ed estesa in vari anni di lavoro una piattaforma di sviluppo modulare denominata Spqr-Rdk (Software Per Qualunque
Robot - Robot Development Kit), disponibile per i sistemi operativi Linux
e Mac OS X.
L'Spqr-Rdk è composto da un insieme di librerie software, driver di basso
livello, moduli per comportamenti ad alto livello, interfacce verso gli agenti
robotici ed utility grache. Attualmente viene utilizzato in vari ambienti e
con tipi diversi di robot, compresi ovviamente il P2AT e il P2DX essendo la
valutazione delle prestazioni di questi parte del lavoro di stage.
Tramite la piattaforma Spqr-Rdk è possibile dialogare con un agente
robotico (reale o virtuale), osservarne lo stato e la rappresentazione della
mappa tramite interfaccia graca, inviare istruzioni di movimento o fargli
eseguire alcuni compiti di interesse quali localizzazione, mapping, riconoscimento di persone, navigazione autonoma. Lanciando agenti virtuali, essi si connetteranno al server USARSim e inizieranno ad eseguire i compiti
assegnati.
Fig. 6.3: L'interfaccia Zeus dell'SPQR-RDK all'opera con un P2AT.
L'esplorazione in RDK è basata sul calcolo delle frontiere [?]. Una fron57
tiera è denita come l'interfaccia tra spazio libero (bianco sulla mappa) e
spazio non esplorato (blu sulla mappa). Un algoritmo apposito (basato sul
metodo di wave front expansion) calcola le frontiere e tra di esse individua
quella più conveniente per l'esplorazione. La scelta tra le diverse frontiere
è basata principalmente sulla distanza di queste dal robot. L'esplorazione
viene considerata terminata quando non esistono più frontiere.
6.2.2 Zeus
Zeus è l'interfaccia graca tramite la quale è possibile avere la rappresentazione della mappa costruita dalla collaborazione dei robot, inviare comandi di priorità di esplorare un determinato punto, avviare o fermare l'esplorazione autonoma dei robot, guidare manualmente tramite tastiera gli agenti
e altro ancora. Questo potente strumento è stato utilizzato per testare il
comportamento dei robot in tutte le circostanze studiate per la valutazione,
permettendo di avere anche un feed-back visivo dell'avvenuta esplorazione
completa della mappa. Spiegare il funzionamento interno di Zeus o delle
numerose possibilità oerte dall'RDK esula dall'obbiettivo della presente
relazione.
6.2.3 Il coordinamento
Il coordinamento della SPQR Rescue Robots Team è distribuito e dinamico.
Ciascun robot esplora autonomamente conoscendo e costruendosi una mappa
locale tramite laser. Le lettura laser vengono inoltre mandate al mapper per
creare una mappa globale (quella visibile tramite Zeus), ma questa mappa
globale non è visibile ai robot, che incentrano la loro attività sulle conoscenze
locali. Ciò che si scambiano i componenti di una squada sono i destination
point, ovvero punti di esplorazione che vengono dinamicamente decisi uno
per robot. L'algoritmo di coordinamento consiste nei seguenti passi:
• Broadcast dei destination point agli altri robot della squadra
• Ricezione dei destination point dei compagni
• Compute Best Assignemt, ovvero vengono valutate tutte le possibili as-
segnazioni e scelta tra queste quella con utilità massima per la squadra.
Nel caso la squadra sia congurata con il supporto operatore, i destination
point indicati dall'operatore (i cosiddetti "click") sono considerati prioritari
rispetto agli altri. Solo dopo un'assegnazione ottima di questi, viene fatta
l'allocazione dei rimanenti.
58
Capitolo 7
Lavoro e Tools nella Rescue
Team
"Il lavoro mi piace, mi aascina.
Potrei starmene seduto per ore
a guardarlo."
Jerome Klapka Jerome
Questo capitolo illustra brevemente il lavoro preventivo svolto per conto
della Rescue Robots Team per preparare la possibilità di eettuare test sul
coordinamento. Possedendo già la squadra un backgruond di conoscenze e
tools più che valido e la fortuna che il simulatore USARSim è stato creato
appositamente per i robot di salvataggio, il periodo passato è anco della Rescue Team è stato più che altro di apprendimento e di comprensione
dell'utilità e delle modalità di utilizzo degli strumenti necessari. Verranno
quindi solamente accennati questi tool di cui si è già fornita una descrizione
nei capitoli precedenti e presentata la mappa sviluppata per eettuare i test.
59
7.1 Strumenti utilizzati
Come detto, a dierenza della Four-Legged, nella SPQR Rescue Team non è
stato necessario sviluppare nuovi tools né modicarne altri. Questo perchè
il lavoro eettuato dalla squadra è piuttosto avanti rispetto a quello della
Legged per quanto riguarda l'uso del simulatore, essendo favoriti dal fatto
che USARSim nasce proprio per simulare robot di salvataggio dotati di ruote.
Anche per l'analisi delle prestazioni, non è stato valutato conveniente creare
un tool di valutazione automatica, soprattutto considerando che tale tool si
ridurrebbe ad essere poco più di un cronometro, essendo il tempo impiegato
ad esplorare la mappa l'unico indicatore di prestazioni considerabile parlando
di coordinamento. Inoltre non è immediato creare un tool che riconosca
esattamente il momento in cui l'arena è stata completamente esplorata. Ne
consegue che si è evitato di perdere tempo lavorando per raggiungere un
risultato certamente non entusiasmante.
Il tool fondamentale utilizzato è l'RDK, già presentato nel precedente
capitolo, soprattutto la console di Zeus. A dierenza dei test della Legged,
per la Rescue la congurazione hardware per la simulazioni è stata decisamente meno essibile. Su un server Windows è stato fatto girare il solo server
USARSim, su una macchina necessariamente Linux sono stati lanciati i due
agenti autonomi P2AT e P2DX, mentre per motivi prestazionali la console
Zeus è stata lanciata su un'ulteriore macchina anch'essa con piattaforma
Linux. Davanti la console Zeus un operatore deve necessariamente vericare
l'andamento del test, anche in caso di test di robot autonomi.
7.2 La mappa
Per testare il coordinamento, inizialmente si è pensato di utilizzare le Arene
proposte da USARSim. In realtà in queste arene la vera dicoltà è nel
riconoscere rampe, oggetti trasparenti e specchi, nel Victim Detection, tutte
dicoltà che non dipendono in alcun modo dal coordinamento e che anzi
rischiavano di falsare i risultati dei test. Per questo motivo tramite il tool
Unreal Edit, di cui si è parlato nel capitolo dedicato a USARSim, è stata
creata una nuova mappa più semplice dal punto di vista del Mapping e senza
gli ostacoli del terreno dissestato.
Nel creare la mappa, particolare attenzione è stata posta nel crearla in
modo tale da essere riutilizzata. La mappa consiste in una serie di stanze
vuote unite da un corridoio. Prima personalizzazione eseguibile è utilizzare
il WorldController per creare pannelli che chiudano le strettoie del corridoio, create appositamente per inibire il passaggio dei robot inserendo un
solo pannello nella mappa, avendo così una mappa di dimensioni variabili
congurabile inviando solo due stringhe di testo.
Sempre tramite WorldController vengono inseriti pannelli, pilastri, cubi
60
Fig. 7.1: La pianta della mappa creata.
e oggetti vari per rendere più complessa l'esplorazione della mappa. Sebbene
l'approccio di utilizzare il WorldController per creare dinamicamente la mappa allunghi i tempi di set-up del test, è altresì vero che tale approccio permette di cambiare in pochissimo tempo la congurazione della mappa, senza dover utilizzare l'Unreal Editor che allungherebbe di molto i tempi di
preparazione dell' arena.
Fig. 7.2: Dettaglio di una delle stanze complete di pannelli e pilastri.
La mappa completa è composta da un corridoio centrale lungo 16 metri
e largo circa 3. Tale corridoio è sezionabile in 3 parti circa uguali tramite i
pannelli inseriti dal WorldController.
La mappa piccola è composta dalla prima sezione del corridoio e da due
stanze di 5 metri per 4,5 metri.
La mappa media è composta dalla mappa piccola più la seconda sezione
61
del corridoio e le due stanze ad essa adiacenti, entrambe di circa 6 metri per
5 metri.
La mappa grande è composta da tutta la pianta, ovvero la mappa media
più l'ultima sezione di corridoio e le ultime due stanze, grandi circa 8 metri
per 5.5 metri.
62
Capitolo 8
Rescue Test e Risultati
"Rispondere a stupide domande
è più facile che correggere stupidi errori."
Leonardo Da Vinci
In questo capitolo verranno presentate le considerazioni e le scelte per
quanto riguarda i test di valutazione compiuti sul coordinamento della squadra
di salvataggio robotico della Rescue Robots Team. Verranno presentati il piano di test e le motivazioni che lo hanno fatto preferire ad altri piani, le
modalità di svolgimento e i risultati ottenuti. Di questi risultati verrà fatte
un'analisi e tratte le dovute considerazioni.
63
8.1 Piano di test
8.1.1 Scelta del piano di Test
Nel valutare le prestazioni di esplorazione coordinata, la strategia utilizzata è stata quella di valutare il tempo di esplorazione di un singolo P2AT e
poi comparare il risultato con i tempi di esplorazione di squadre di robot
che utilizzano diverse strategie. Nell'eettuare questo confronto, verrà valutata ovviamente la percentuale di miglioramento (o peggioramento) delle
prestazioni, non il confronto temporale espresso in secondi. La scelta del
P2AT anziché il P2DX come riferimento è giusticata dal fatto che, eettuando varie prove, i tempi di esplorazione dei due erano prossochè coincidenti,
quindi si è scelto il primo perchè più stabile e meno soggetto a ribaltamenti.
Si è deciso quindi di adottare il seguente piano di test, ripetuto su tre
mappe di dimensioni diverse (una piccola, una media e una grande):
• Classe 1 :
Valutare il tempo di esplorazione di un singolo P2AT
completamente autonomo da prendere come riferimento.
• Classe 2 : Valutare il tempo di esplorazione di una squadra composta
da un P2DX e un P2AT completamente autonomi e coordinati tra loro.
da un P2DX e un P2AT completamente autonomi e non coordinati.
da un P2DX e un P2AT coordinati e supportati da un operatore umano
che tramite console indica loro i punti di esplorazione prioritari.
8.1.2 Problemi riscontrati
Anche nel caso di robot completamente autonomi, in realtà la presenza di
un operatore è risultata necessaria. Pur simulando in modo abbastanza
realistico il comportamento dei robot reali, in alcune circostanze le primitive
di collisione e le tarature dei parametri associate ai motori fanno sì che
entrambi i modelli virtuali siano soggetti a ribaltamento in maniera maggiore
rispetto ai corrispettivi reali. Per questo motivo la presenza di un operatore
è utile per invalidare un test in cui un robot dovesse trovarsi in condizione
di impossibilità di movimento.
I risulati ottenuti sono soggetti ad una varianza piuttosto alta, soprattutto al crescere della dimensione della mappa. Per questo motivo, non viene
fornito un valore medio, ma un intervallo di valori percentuali, in modo da
mantenere anche l'informazione sul fatto che i test sono stati ripetuti più
volte
64
8.2 Risultati dei Test
Sono stati necessari numerosi test per avere risultati il più possibile attendibili. La varianza tra i diversi campione talvolta superava il 10% e non
avrebbe quindi molto senso considerare solo il valor medio.
• Vengono riportati in tabella i risultati ottenuti considerando che:
1 AUT = un P2AT completamente autonomo
2 NCA = un P2AT e un P2DX non coordinati e autonomi
2 CCA = un P2AT e un P2DX coordinati e autonomi
2 CSO = un P2AT e un P2DX coordinati con supporto operatore
Tabella dei risultati dei test
Piccola
1 AUT 100%
2 NCA
80%
2 CCA
75%
2 CSO
65%
Media
100%
80% - 85%
70% - 75%
55% - 60%
Grande
100%
80% - 90%
65% - 75%
45% - 55%
8.2.2 Analisi valutativa
Analizzando l'output della fase di test, i risultati inizialmente potrebbero
stupire, ma ad un'analisi più attenta risultano una conseguenza piuttosto
immediata della strategia adottata. Le considerazioni valutative saranno
ora esposte divise per squadra:
Squadra non coordinata
In netta controtendenza con le altre due tipologie di squadra, la congurazione che prevede due robot non coordinati tra loro vede il degradarsi delle
prestazioni al crescere della mappa. La motivazione è semplice. Mentre in
una piccola mappa il numero di robot mette in condizioni di vantaggio maggiore la squadra composta da due robots seppure non coordinati, al crescere
della mappa questi robots si comporteranno praticamente come il singolo
robot autonomo, ignorando completamente la presenza del compagno. Ne
consegue che spesso anzichè collaboare i due robot niscono con l'ostacolarsi a vicenda, perdendo molto tempo ad esplorare le stesse zone. In alcuni
(molto rari) casi, addirittura le prestazioni di questa squadra sono risultate
peggiori di quelle ottenute con il singolo robots. L'ovvia considerazione è
che una squadra coordinata, sia essa supportata da un operatore o meno, è
assolutamente da preferire ad una non coordinata.
65
Squadra autonoma coordinata
Nel caso della mappa piccola, il tempo di esplorazione è stabile intorno al
75%. I due robots non riescono ad avere prestazioni nettamente superiori
del singolo robot a causa del numero limitato delle zone da esplorare. Al
crescere della dimensione della mappa, il lavoro di squadra produce risultati
migliori, comunque non avvicinandosi mai al 50%. La motivazione immediata di questa "mancata prestazione" risiede nel fatto che i robot, seppure
coordinati, non condividono la mappa esplorata, ma si scambiano solamente
i punti di esplorazione per velocizzare le esplorazioni. Si verica comunque
piuttosto di frequente che un robot vada ad esplorare una zona già esplorata
dall'altro.
Squadra coordinata con supporto dell'operatore
Questa è senza dubbio la congurazione migliore al momento attuale. Avendo una rappresentazione della mappa costruita dalle informazioni inviate da
entrambi i robot, l'operatore è in grado di indicare come prioritari i punti di
ricerca che velocizzano maggiormente l'esplorazione e il coordinamento tra
robots permette loro di scegliere quale dei due è in condizione di vantaggio
nell'andare a esplorare il punto indicato dall'operatore, con il risultato di
ottenere una velocità di esplorazione decisamente elevata. Se questo enorme
vantaggio non è così evidente nel caso della mappa piccola, è ben visibile nel
caso della mappa grande, dove il tempo di esporazione molto spesso viene
ridotto a meno della metà di quello ottenibile con un singolo robot autonomo.
Bisogna però considerare che la quantità di informazioni e di pacchetti
TCP/UDP che vengono inviati in rete è talmente elevata che non è nemmeno comparabile con le altre squadre. Negli scenari in cui i Rescue Robots
dovrebbero in futuro essere utilizzati, non sempre si avrà la possibilità di
scambiare così tanti dati tra i robot e tra robot e operatore. La direzione
di ricerca su cui si deve cercare di continuare a lavorare è quindi quella dei
robots completamente autonomi.
66
Capitolo 9
Conclusioni
"Non abbiamo tanto bisogno dell'aiuto degli amici,
quanto della certezza del loro aiuto."
Epicuro
In questo capitolo conclusivo verrà esposta una personale valutazione del
lavoro svolto durante il periodo di stage, con riferimenti a possibili ulteriori
sviluppi futuri. Verranno poi espressi i sentiti ringraziamenti, sia a livello
accademico che a livello personale, alla persone che mi hanno aiutato a raggiungere questo importante traguardo, considerando non soltanto il lavoro
nale che ha portato a questa relazione, ma tutta il percorso universitario
dal primo al terzo anno di corso che mi ha consentito il conseguimento della
Laurea di primo livello in Ingegneria Informatica.
67
9.1 Sviluppi futuri
Con la prossima uscita dell'Unreal Engine 3 all'interno del videogame UT2007,
molti dei problemi legati alla simulazione dovrebbero essere risolti. Si avranno quindi modelli molto più vicini alla realtà, ci si aspetta un miglioramento
nella simulazione della sica, la possibilità di congurare ogni singolo giunto
di un robot permettendo un movimento ancora più vicino a quello del robot
reale.
Dal punto di vista prestazionale dovrebbe essere inserito il supporto al
Dual Core dei moderni processori, permettendo così di sfruttarne a pieno
la potenza. Molto probabilmente questo non sarà ancora suciente per
simulare uidamente 6-8 robot che collidono tra loro. Per una simulazione
completa di una partita di calcio robotico 4 contro 4 si dovrà attendere
che lo sviluppo dell'hardware per pc porti ad avere una potenza di calcolo
suciente a sfruttare a pieno questo potente strumento.
Per quanto riguarda i tools sviluppati, al momento sono abbastanza funzionali a ciò per cui sono stati creati. La loro modularità ne permetterà
comunque un rapido sviluppo qualora si presentassero necessità diverse col
passare del tempo. Un miglioramento possibile di SIMMotion, oltre al completamento della possibilità di sostituire la shared memory con un supporto
allo scambio di messaggi tramite UDP, è inserire il supporto al GameController, arbitro virtuale uciale delle competizioni RoboCup. Migliorando il
sensore di accelerazione sul robot virtuale, si potrebbe sfruttarlo per permettere al robot di raddrizzarsi nel (raro) caso che questo durante la partita si
ribalti.
Considerando invece le strategie della SPQR Four-Legged Team, l'utilizzo
degli schemi variabili sembrerebbe essere una delle più immediate migliorie
che possono essere apportate al codice, creando piani e azioni che sfruttino
nel miglior modo questa possibilità.
9.2 Conclusioni personali
Credo che il lavoro svolto sia stato un buon lavoro, abbia prodotto risultati
positivi e interessanti e permetta a chi continuerà ad utilizzare i tools prodotti
e la metodologia di test proposta di essere facilitato nel proprio lavoro. Questa è la mia soddisfazione più grande, quella di non aver soltanto imparato
tanto, ma aver avuto anche la possibilità di aiutare altri e soprattutto lasciare
loro strumenti funzionali.
Nel corso dello stage ho avuto la fortuna di lavorare con persone capaci,
preparate e disponibili, due gruppi ben aatati che lavorano sinergicamente
68
e con passione per raggiungere importanti obbiettivi. Mi è stata data la possibilità di partecipare al Rescue Robotic Camp 2006, incontro internazionale
sulla robotica tenutosi presso l'ISA (Istituto Superiore Antincendio) di Roma, durante il quale ho avuto modo di conoscere molto di più gli attuali
studi e sviluppi nel campo della robotica. Mi è stato proposto di partecipare
alla manifestazione RoboCup, tenutasi quest'anno a Brema in Germania, alla quale purtroppo per motivi personali non ho potuto essere presente, ma
alla quale conto di partecipare nei prossimi anni.
E' mia intenzione continuare a collaborare con le SPQR Teams anche
negli anni a venire, apprendendo sempre di più da loro e ricambiando orendo la mia disponibilità e competenza. Credo che questa mia esperienza possa
tornarmi molto utile in questo primo anno di specialistica che frequenterò
in Spagna nell'ambito del progetto Erasmus, durante il quale spero di poter
scambiare conoscenze e tecniche con il gruppo di Robotica dell'Universidad
Politecnica de Madrid, proponendo quindi al mio rientro in Italia una possibilità di confronto nel valutare le scelte migliorative che verranno via via
intraprese nell'ambito della ricerca.
9.3 Ringraziamenti
Un ringraziamento speciale spetta di diritto al professor Luca Iocchi per
avermi dato la possibilità di avvicinarmi a questo meraviglioso e stimolante
mondo dell'intelligenza articiale, per la sua disponibilità e cortesia, la ducia dimostratami nel corso di questo anno di lavoro insieme e l'aiuto che non
mi ha mai fatto mancare nei momenti di dicoltà.
Un grazie di cuore va a tutti i ragazzi che appartengono al gruppo
Robocup, sia nella SPQR Four-Legged Team che nella SPQR Rescue Team,
per la loro disponibilità e simpatia, il supporto e l'aiuto fornitomi ogni volta
che ne avevo bisogno, i numerosi consigli ricevuti e l'innità di cose che mi
hanno insegnato.
Senza nulla togliere a tutti gli altri, particolare ringraziamento va a Marco
Zaratti per tutto l'aiuto e le spiegazioni fornitemi riguardo USARSim, a
Alessandro Farinelli e Daniele Calisi della Rescue Team per l'aiuto riguardo
l'utilizzo di Linux e del framework RDK, ma soprattutto a Stefano La Cesa
della Legged Team per il "tutoraggio" oertomi praticamente in ogni campo,
dal Java al C++, dall'utilizzo di Eclipse a quello dei tool della legged, da
Linux a Windows, dall'Erasmus alla burocrazia universitaria, dallo spagnolo
al greco.
Guardando indietro alla mia carriera universitaria, vorrei ringraziare tutti
i miei compagni di corso, quelli che hanno seguito tre anni con me, quelli
69
che ho conosciuto strada facendo, ma anche i tanti che hanno iniziato con
me e poi purtroppo sono rimasti indietro o hanno cambiato strada. Grazie
per le ore passate insieme, gli appunti prestati, lo scambio di opinioni, la
collaborazione nello studio, la compagnia e il divertimento regalatomi, le
tavolate a mensa, le dritte su come arontare esami e professori. E tutto il
resto.
Ancora più indietro, mi sento di dover ringraziare la professoressa Carmela
Varriale del liceo Antonio Meucci di Aprilia, per avermi fornito ottime basi
per arontare con successo il delicato primo anno di università, ma soprattutto la mia classe, il glorioso 5F, i migliori compagni e amici che una persona
possa desiderare, e il corso di teatro, esperienza quest'ultima che mi ha aiutato molto nel costruirmi una personalità forte e sicura, che si è rivelata
utilissima in molti momenti della vita reale e universitaria.
Ringrazio innitamente la mia famiglia. Grazie ai miei genitori per le
tante opportunità che mi hanno dato e che continuano a darmi, per aver cercato sempre di capire le mie esigenze, aver appoggiato i miei obiettivi, avermi lasciato sbagliare e aiutato a recuperare, dimostrandomi in continuazione
rispetto e cieca ducia. A mio fratello e mia sorella, per la comprensione,
l'appoggio, la complicità, la stima dimostratami in ogni momento, grazie
di essermi stati sempre vicini anche e soprattutto nei momenti peggiori, di
avermi spronato a cercare di migliorarmi sempre, aver pianto con me quando le cose proprio non andavano ed avermi aiutato a venirne fuori, credendo
sempre in me e nelle mie capacità e possibilità.
Per ultimo ma certo non in importanza, un grazie a tutti i miei amici.
Per avermi capito, per essersi ostinati a voler credere in me anche senza
capire, per non avermi voltato mai le spalle anche in questi ultimi due anni,
indubbiamente i più dicili della mia vita a livello personale, ed avermi
insegnato così il vero valore della parola amicizia. Grazie per essere come
siete, grazie di essere cresciuti con me ed avermi trasmesso così tanto, grazie
per la stima dimostrata sempre e comunque al di là di tutto, grazie per i
tanti ricordi che con voi porterò dentro per tutta la vita, grazie per avermi
permesso di essere parte della vostra vita e di essere parte integrante della
mia.
Grazie di tutto cuore.
70
Appendice A
Utilizzare SIMMotion
Lanciare il programma nel seguente modo:
./motion [-p <playerNumber>] [-t <teamColor>] [-h
<USARSimHost>] [-log] [-udp]
Opzioni:
• -p <playerNumber> = Utilizzando questa opzione è possibile denire
il numero del robot che si desidera avviare. Inserire un numero da 1 a
4. Per default, il robot lanciato è il numero 4.
• -t <teamColor> = Utilizzando questa opzione è possibile denire la
squadra di appartenenza del robot che si desidera avviare. Inserire
"red" o "blue". Per default, il robot lanciato appartiene alla squadra
"red"
• -h <USARSimHost> = Utilizzando questa opzione SIMMotion tenta
di connettersi ad un server USARSim in rete. Per default, l'host al
quale tenta di connettersi è "localhost"
• -log = Utilizzando questa opzione, SIMMotion scrive nella cartella da
cui è stato lanciato un le di log che avrà come nome ERS-<playerNumber><teamColor>.log
• -udp = "Work in progress". L'opzione permetterà di utilizzare lo
scambio di messaggi tramite udp anzichè tramite shared memory, permettendo a SIMMotion lanciati su macchine distinte di coordinarsi
ugualmente. L'opzione non è ancora supportata.
Terminare il programma:
Premere CTRL + C
71
72
Appendice B
Utilizzare
WorldControllerClient
java WorldControllerClient
Utilizzare il programma:
• BALL: Invia ad USARSim la richiesta di creare la palla nella mappa.
La palla apparirà sia sul simulatore che sul display 2D del tool.
• LOG: Lancia il LogWriter che scrive il le di log SoccerBall.log. Ver-
rà attivato contestualmente il riposizionamento della palla in campo:
ogni volta che nel simulatore la palla esce dal campo questa verrà riposizionata all'interno; ogni volta che la palla entra in una delle due
porte, verrà riposizionata a centrocampo e tutti i robot riposizionati
nelle rispettive posizioni di partenza.
• KICK: La palla viene calciata verso la porta BLUE o YELLOW, dipen-
dentemente dalla lettera selezionata nel menù a tendina accanto al
bottone KICK, con una forza dipendente dal valore inserito nella Text
Area accanto alla parola Speed. Si consiglia di non utilizzare valori
superiori a 3.
• Moving : il nome del robot o della palla selezionato nel menù a ten-
dina determina quale Attore verrà spostato nella rispettiva posizione
sulla mappa nel momento in cui l'utente clicca in un punto del dislay
2D che ragura il campo
Chiudere la nestra di esecuzione
73
Fig. B.1: Il WorldControllerClient.
74
Appendice C
Utilizzare LogExaminator
java logExaminator.Examinator [-team <teamColor>] [-start
<initialTime>] [-end <nishTime>]
Opzioni:
• -team <teamColor> = Utilizzando questa opzione è possibile denire
la squadra da esaminare. Inserire "red" o "blue". Per default, verrà
analizzata la squadra "red"
• -start <initialTime> = Utilizzando questa opzione è possibile denire
il TimeStamp da cui si vuole che inizi la valutazione. Tutti i precedenti verranno ignorati e non inuiranno sul risultato. Per default,
initialTime = 0;
• -end <nishTime> = Utilizzando questa opzione è possibile denire
l'ultimo TimeStamp che si desidera sia valutato. Tutti i successivi verranno ignorati e non inuiranno sul risultato. Per default, nishTime
= 1000000000;
Vincoli:
Nella cartella devono essere presenti i le:
- SoccerBall.log
- ERS-<teamColor>-2.log
Premere CTRL + C
75

Università degli studi di Roma "La Sapienza" Facoltà

Transcript

Documenti analoghi

Robot Chicken 3x03

not afraid to be different

Invasione robot al Museo della figurina – Corriere di Bologna, 29/03

"L`intelligenza artificiale" di Irene Perfetti

Io Robot - DivxMania

CS SRF ONO arte

Articolo "Un robot nello spazio"

L`Herakles a Vito Teti - Confraternita del SS. Crocifisso

RC 4000 Dati tecnici RC 4000 Robot per le pulizie domestiche

L`ITIS “GEROLAMO CARDANO GEROLAMO CARDANO” di Pavia