Università degli studi di Roma "La Sapienza" Facoltà
Transcript
Università degli studi di Roma "La Sapienza" Facoltà
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 • Classe 2 : Valutare le prestazioni di una squadra di 4 robot coordinati durante una partita contro una squadra di 4 robot non coordinati • Classe 3 : Valutare le prestazioni di una squadra di 4 robot 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 5.2.1 Output della fase di 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 Team BLUE Coordinata 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 Distanza media compagni Contrasti tra compagni Conitti di ruolo Vicinanza alla palla Goal/Ktime segnati Goal/Ktime subiti Azioni/Ktime eettuate Azioni/Ktime subite 51 Totale Time Test Classi 3 e 4 Team RED Non Coordinata 2108 Team BLUE Coordinata 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 Distanza media compagni Contrasti tra compagni Conitti di ruolo Vicinanza alla palla 52 Totale Time Test Classi 5 e 6 Team RED Non Coordinata 2182 Team BLUE Coordinata 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 Distanza media compagni Contrasti tra compagni Conitti di ruolo Vicinanza alla palla 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. • Classe 3 : Valutare il tempo di esplorazione di una squadra composta da un P2DX e un P2AT completamente autonomi e non coordinati. • Classe 4 : Valutare il tempo di esplorazione di una squadra composta 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 8.2.1 Output della fase di 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 Lanciare il programma nel seguente modo: 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 Terminare il programma: Chiudere la nestra di esecuzione 73 Fig. B.1: Il WorldControllerClient. 74 Appendice C Utilizzare LogExaminator Lanciare il programma nel seguente modo: 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 - ERS-<teamColor>-3.log - ERS-<teamColor>-4.log Terminare il programma: Premere CTRL + C 75