Implementazione di una piattaforma per Embodied
Transcript
Implementazione di una piattaforma per Embodied
FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI CORSO DI LAUREA SPECIALISTICA IN TECNOLOGIE INFORMATICHE ANNO ACCADEMICO 2003/04 TESI DI LAUREA Implementazione di una piattaforma per Embodied Agent CANDIDATO Diego Colombo RELATORI CONTRORELATORE Prof.ssa Maria Simi Prof. Franco Turini Dott. Antonio Cisternino Ringrazio tutta la mia famiglia (anche quella “allargata”), Alessia, Mushra, Lilla, Ugo, Il Maestro C-Sternino, Daniele Picciaia, Giorgio Ennas, Francesco Romani, Gennaro, Lucciolone, Nonno Marco, Spazio, Marco Combetto (MarcoSoft), gli amici che mi hanno aiutato ad arrivare fino in fondo, Nathan Fish, Mr. TechEd, il teletrasporto di Startrek, la Coca Cola, Gundam, George Lucas, chi mi sopporta e mi dovrà sopportare. Dedicato a Jacques, Fofo, Liliana, Gargia, Emo , Benzina ed a “colui che null’altro è se non l’amor che move il sole e tutte l’altre stelle” . Che sempre possa essere tutto giusto e perfetto. 1 Introduzione e definizioni 1.1 Introduzione 1.2 Agenti e definizioni 1.2.1 Memoria 1.2.2 Agenti autobiografici ed agenti sociali 1.2.3 Società, cultura ed intelligenza 2 3 4 Processo di Embodiment -1-1-4-4-6-8- 11 - 2.1 Embodiment Software (o virtuali) - 11 - 2.2 Embodiment Fisico - 13 - 2.3 On-World, In-World e BodyImage - 15 - 2.4 Corpo ed apprendimento - 17 - 2.5 Emozioni e comportamento - 18 - Tecnologie e supporti - 21 - 3.1 Microsoft .NET Framework e C# - 22 - 3.2 Custom Attribute - 25 - 3.3 Performance Counter - 26 - 3.4 XML, serializzazione e configurazione 3.4.1 Serializzatore XML 3.4.2 Il file di configurazione - 27 - 27 - 29 - 3.5 - 30 - XML Web Services e crypto service 3.6 Microsoft .NET Remoting 3.6.1 AppDomain, Boundaries e Proxy 3.6.2 MarshalByRef e ContextBoundObject 3.6.3 Infrastruttura, serializzazione ed Hosting 3.6.4 Una nota sulla classe Process e sulle finestre di WindowsForms - 31 - 32 - 34 - 35 - 36 - 3.7 Microsoft Message Queue - 36 - 3.8 PInvoke - 37 - 3.9 ACS (Annotated C Sharp) - 39 - 3.10 ER1 Interface - 42 - 3.11 DirectX 3.11.1 DirectShow 3.11.2 DirectSound - 44 - 45 - 45 - 3.12 OpenCV - 46 - 3.13 ExoCortex.DSP - 47 - 3.14 NDIS, Miniport e Windows Driver Development Kit - 47 - Il progetto R2D2 4.1 Design del sistema 4.2 Architettura 4.2.1 Vision 4.2.2 Audio 4.2.3 Self Sensing 4.2.4 Network - 49 - 49 - 52 - 53 - 55 - 55 - 57 - 4.2.5 4.2.6 4.2.7 4.3 5 6 7 8 Motion Skin BodyMap Base di conoscenza, simulazione, sogno e pianificazione Piattaforma ad agenti - 59 - 60 - 63 - 64 - 67 - 5.1 “Anatomia” del sistema software 5.1.1 AgentBase 5.1.2 AgentBroker e MessageDispatcher 5.1.3 Messaggi, comunicazione e CustomAttribute 5.1.4 BodyMap 5.1.5 NodeAgent - 67 - 68 - 72 - 77 - 79 - 83 - 5.2 - 86 - Geni, Memi ed Evoluzione Moduli ed Interfacce - 89 - 6.1 Moduli e componenti 6.1.1 Brain 6.1.2 Networking 6.1.3 Audio 6.1.4 Vision 6.1.5 Obstacle Avoidance 6.1.6 Home Agent - 89 - 89 - 89 - 90 - 90 - 91 - 92 - 6.2 Interfacce 6.2.1 Chat, e-mail ed Instant messaging 6.2.2 Ink 6.2.3 Gesture 6.2.4 Voice - 92 - 94 - 96 - 97 - 97 - Test - 99 - 7.1 Simple Roaming 7.2 NetTest1 Conclusioni - 99 - 104 - 110 - Appendice - 112 - Bibliografia - 116 - Introduzione e definizioni 1 Introduzione e definizioni 1.1 Introduzione Il lavoro di tesi si inquadra all’interno di un progetto finanziato da Microsoft su sistemi Embedded, finalizzato alla realizzazione di una piattaforma sperimentale per embodied agents. La piattaforma è costituita da hardware1 e da un sistema software che offre accesso ai suoi servizi. Da qui infatti parte l’idea di voler dare un corpo fisico alla piattaforma ed un look che fosse facilmente accettabile dall’utenza che con esso si troverà ad interagire. La scelta doveva essere accattivante e di facile costruzione per cui abbiamo optato per dare al nostro robot le sembianze del droide R2D2 della celebre saga di George Lucas: “Star Wars”. In realtà la struttura a pendolo del droide, anche se di facile realizzazione come requisiti tecnologici, ha richiesto molte strutture di controllo ed accorgimenti per rendere sicura e stabile l’architettura meccanica. E’ stato scelto di dotarlo anche della possibilità di cambiare la propria configurazione, come avviene sul grande schermo, e ne analizzeremo in seguito le motivazioni e le implicazioni. Il fatto che comunque il suo look sia noto e già visto “in azione” rende meno drastico l’inserimento del nostro robot all’interno di un contesto ad alta interazione uomo – macchina. In questo primo capitolo daremo tutte le definizioni necessarie ad inquadrare il contesto e la terminologia che in seguito svilupperemo. Nel secondo capitolo daremo più dettagli circa il fatto di fornire ad un agente software un corpo e quali sono le implicazioni ed i vantaggi che questo comporta. Il terzo capitolo è dedicato ad introdurre ed illustrare le tecnologie utilizzate per la costruzione della piattaforma in 1 Per hrdware intendiamo tutto ciò che é solido, non solo la componentistica per PC -1- Implementazione di una piattaforma per Embodied Agent oggetto mentre nel quarto discuteremo l’architettura del sistema R2D2 (d’ora in avanti faremo spesso riferimento al robot con tale sigla). Il possedere o meno un corpo introduce nel sistema una serie di aspetti e problematiche che sono di enorme interesse sia per il settore dell’intelligenza artificiale che per il settore della vita artificiale. Proprio quest’ ultimo ha svolto un ruolo di assoluto rilievo nello studio e nella valutazione dell’ “embodiment” tentando di avvicinare i propri modelli a quelli biologici per individuare il meccanismo con cui i concetti emergono, di come la struttura sociale sia instaurata su basi di comunicazioni fisiche. Soprattutto gli agenti sociali (di cui ne daremo a breve una definizione) basano la propria esistenza e funzionalità sulle strutture sociali con cui interagiscono, che sono comprensibili al sistema e da esso instaurabili. In questa tesi accenneremo solamente all’intelligenza sociale ed alle strutture di controllo, che però rendono ancora più interessante il mondo degli agenti dotati di corpo. Non è raro poter osservare robot al giorno d’oggi, alcuni colossi industriali giapponesi stanno introducendo nel mercato nuovi giocattoli2 largamente autonomi. In manifestazioni come RoboCup [RoboCup] si possono vedere robot giocare a calcio, ma spesso il fatto di essere robot può non bastare a definire un embodied agent. In molte architetture presentate alla manifestazione si possono rilevare elementi di controllo generale, o di percezioni condivise (come una singola telecamera che riprende la scena ed informa tutti i membri della squadra) o di meccanismi di orchestrazione centralizzati. Tali elementi non rendono perfettamente autonomi gli agenti, annullano la necessità di comunicazioni peer to peer, ma soprattutto rendono omogenee le percezioni e minime le comunicazioni fisiche. Fatto ancor più rilevante è che i protagonisti di robocup non interagiscono con gli esseri umani, ma solo col “mondo della competizione”. Di per sé questo può non sembrare un elemento rilevante, ma quando due macchine interagiscono fra loro lo fanno alla 2 Attualmente vengono chiamati giocattoli o elettrodomestici, ancora non esiste la cultura sociale per definire il robot che entra in casa ed interagisce con la famiglia, ed è proprio quello che SONY ed HONDA stanno tentando di costruire tramite l’immissione nel mercato dei propri prodotti di robotica. -2- Introduzione e definizioni velocità delle macchine, cosa che comporta l’introduzione del calcolo in tempo reale3, mentre il mondo degli esseri umani è molto più sfumato da questo punto di vista per cui vengono collassati molti vincoli di real time (inteso in senso stretto). Che nell’interazione con l’uomo certi vincoli di tempo reale si assottiglino lo dimostra anche la scelta commerciale della Evolution Robotics [ER], azienda che produce e commercializza un kit per robotica denominato ER-1. Fondamentalmente ER-1 è composto da una batteria, un controllo motori, una coppia di motori passo passo, una telecamera ed una serie di profilati di alluminio con cui assemblare i propri robot; tutto l’ hardware è interfacciato tramite USB ad un portatile (non fornito nel kit) che monti sistemi operativi Microsoft. Windows XP non è assolutamente un sistema operativo real time (l’unico prodotto da Microsoft è il CE.NET 4.2), tuttavia il robot riesce ad avere interazioni con l’ambiente e gli esseri umani senza grossi problemi. In realtà il sistema passa a lavorare in tempo reale a più basso livello grazie alla scheda di controllo di ER-1 e vedremo più avanti come anche la nostra soluzione in realtà sposti le problematiche di controllo macchina rendendole invisibili allo sviluppatore. Essere un embodied agent vuol dire usare il proprio corpo per percepire il mondo ed attuare i propri piani, nel secondo capitolo vedremo il corpo proprio sotto questo punto di vista, come se fosse esso stesso la funzione con cui l’agente percepisce (o forse sarebbe meglio dire comprende) il mondo di cui fa parte. In effetti due individui con corporatura diversa percepiscono l’ambiente in cui si trovano grazie alle percezioni che il loro corpo invia al cervello, percezioni che sono in maniera mediata rendendo così la fase di “acquisizione dati” altamente soggettiva, dipendente dalla conformazione dell’individuo che la effettua. 3 Il calcolo in tempo reale (o real time) si suddivide principalmente in due categorie : soft e hard. Un sistema soft real time è tenuto ad effettuare una computazione entro determinati quanti di tempo, allo scadere dei quali viene lasciato tutto perché il risultato è ritenuto inattendibile, mentre un sistema hard real time deve garantire la risposta agli interrupt con precisioni < 1 msec. -3- Implementazione di una piattaforma per Embodied Agent 1.2 Agenti e definizioni Innanzi tutto è necessario introdurre il concetto di agente. Anche se ne esistono molte definizioni e molte specie, possiamo fare riferimento a quanto scritto da Russell e Norvig in Artificial Intelligence a Modern Approach [RusNor95, pag. 33]: “An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through effectors”. Oltre questo c’è da dire che quando parleremo di agenti faremo riferimento ad entità software (a prescindere dal livello del linguaggio usato per implementarlo) come definito in [CIST]: AGENTE : Un agente è un software situato in un ambiente dal quale riceve delle percezioni ed è in grado di modificarlo attraverso i suoi effettori; è in grado di reagire in un tempo ragionevole ai cambiamenti dell’ambiente. È autonomo in quanto in grado di modificare il proprio comportamento in base all’esperienza accumulata. Infine è capace di comportamenti sociali interagendo con altri agenti. Useremo tale definizione perché quella fornita da Russell e Norvig (ma anche quelle di altri colleghi) non riescono a ben definire la differenza tra un programma ed un agente, mentre con quella da noi adottata emergono quattro aspetti fondamentali: l’autonomia, la socialità, l’esperienza ed il tempo di reazione. Per quanto riguarda l’autonomia dovremo riprendere più avanti il discorso perché un agente può essere (come nel nostro caso) composto a sua volta da un insieme di agenti e software più o meno autonomi pur dimostrando a macro livello una decisa autonomia di comportamento. Più avanti inizieremo ad aggiungere definizioni e categorie di agenti, anche se queste diversificazioni dovranno essere intese non in modo assoluto, poiché gli aspetti di caratterizzazione renderanno a volte persino impossibile tracciare in modo netto una linea di demarcazione. 1.2.1 Memoria Per memoria non si intende il concetto puramente informatico del termine, ma la memoria dal punto di vista biologico. -4- Introduzione e definizioni L’uomo durante la propria esistenza immagazzina concetti, nomi, colori, sensazioni, colleziona esperienza. Ma non è possibile definire con precisione le aree in cui risiedono le informazioni e nemmeno esiste un modello formale dell’atto del ricordare. Le strutture sociali che gli animali instaurano e, nel caso umano, fanno evolvere, evidenziano l’esistenza di due livelli, o tipologie, di memoria: • Memoria individuale • Memoria condivisa o Cultura sociale. La memoria è stata spesso contrapposta alla conoscenza, quest’ultima ha avuto un ruolo importante nel panorama scientifico tanto da far nascere l’ingegneria della conoscenza ed i sistemi esperti. Esistono esperimenti con sistemi che tentano di estrarre conoscenza dalla cultura enciclopedica [DOU]. Brooks[Brooks85] e la comunità A-Life nel loro modo di procedere sacrificano totalmente la componente memoria per architetture basate su comportamenti e reazione, eliminando anche la fase di manipolazione simbolica. Il lavoro di questo settore si rivolge prevalentemente al mondo dei robot dove la logica del comportamento è modellata in termini hardware, cioè collegamenti tra componenti elettroniche, sensori e motori. Un approccio che si è rilevato interessante ma, al contempo, estremamente inflessibile e privo di generalità. Fino ad ora il panorama della ricerca in questo senso è stato diviso tra l’approccio ALife o A-Intelligence, tra il comportamentale, il reattivo e la conoscenza, esistono architetture ibride che riescono a fondere il meglio dei due approcci ma ancora manca un elemento chiave: la memoria. Negli ultimi anni è nato molto interesse verso i sistemi cognitivi, architetture in grado di estrarre conoscenza dall’esperienza e creare memoria: in grado di conoscere. Per questo molto si è attinto agli studi in scienze cognitive, psicologia, biologia e neurologia, per trovare quale modello dovesse essere usato per modellare la memoria. Molto spesso i database hanno influenzato il design di questo “componente” che ha necessità di memorizzare e recuperare informazioni, quindi si è formata l’idea di un modulo di memorizzazione che contiene i concetti e le -5- Implementazione di una piattaforma per Embodied Agent loro rappresentazioni, cosa che ha introdotto problematiche di codifica e di indicizzazione. Quindi la necessità di un meccanismo che sia in grado di recuperare ciò che si è memorizzato sotto un determinato stato (che viene chiamato pattern di attività neurale) al ripresentarsi di una situazione simile (con un certo grado di tolleranza). Da studi fatti in neuropsicologia emergono alternative a questo tipo di modello basato su memorizzazione e recupero. Rosenfield [ERI] nel proprio lavoro propone un approccio frutto dell’osservazione di casi di studio clinici ed arriva ai seguenti punti: • Non esiste memoria, ma solo il processo di ricordare • I ricordi non sono elementi statici che vengono immagazzinati e recuperati, sono il risultato di un processo di costruzione • Il corpo è il punto di riferimento per tutti gli eventi di ricordo • Il corpo, il tempo ed il concetto di sé sono estremamente correlati Barlett [KER01 4] aveva dato una descrizione simile 60 anni prima preferendo usare il termine ricordare (remembering) invece di memoria. 1.2.2 Agenti autobiografici ed agenti sociali In [KER02] e [KER01] viene introdotta la definizione di agente autobiografico come un agente dotato di corpo (embodied) che dinamicamente ricostruisce la propria storia autobiografica durante la propria vita. La necessità che porta alla nascita di questa definizione è quella di modellare il comportamento umano. Gli esseri umani spesso motivano il proprio comportamento fornendo un background storico credibile, non necessariamente consistente. Importante è notare il fatto che “durante la propria vita” implica che non esiste una fase di training ed una fase di uso per quanto riguarda l’agente autobiografico, questo tenta di modellare l’aspetto dinamico ed evolutivo dell’esistenza umana, Barlett infatti dice: “L’impressione soggettiva di essere una personalità statica è un illusione e potrebbe essere solo una buona approssimazione per tempi di vita brevi[BAR]” -6- Introduzione e definizioni Dunque gli esseri umani sono sistemi che al contempo agiscono ed apprendono durante tutta la loro esistenza, accumulando così “esperienza”; al Dizionario della lingua italiana De Mauro : “esperienza : sostantivo femminile. 1. Fondamentale: conoscenza diretta di qualcosa, per osservazione, per prova o per percezione: conoscere per esperienza, avere esperienza di qualcosa, parlare per esperienza, avere esperienza dei modi di vivere di molti paesi | Tecnico specialistico filosofico: modalità di conoscenza della realtà che deriva immediatamente dai sensi 2. Fondamentale: conoscenza pratica della vita e del mondo: è un uomo di grande esperienza, avere esperienza del mondo, è un ragazzo senza esperienza | abilità che deriva dall’esercizio assiduo di un mestiere, una professione ecc.: avere esperienza negli affari | fare esperienza, impratichirsi: non ti rimane che fare un po’ di esperienza 3. Fondamentale: lo sperimentare una situazione, un’attività e sim.: fare un’interessante esperienza di lavoro, realizzare un’esperienza pilota in ambito didattico; vicenda che provoca in chi la vive nuove sensazioni e modificazioni interiori: avere un’esperienza positiva, traumatica, formativa, dolorosa | spec. al pl., avventura amorosa: quel ragazzo ha avuto tante esperienze 4. Tecnico specialistico scientifico:, riproduzione sperimentale di un fenomeno, esperimento, prova di laboratorio: condurre un’esperienza di termodinamica; verifica: le esperienze fatte convalidano la teoria |Comune: estens., prova, sperimentazione: le esperienze artistiche del dopoguerra, l’esperienza della comune”. Ancora più interessante è come viene definita l’esperienza comune: “patrimonio collettivo di conoscenze acquisite nel corso dello sviluppo storico”. Accumulare esperienza significa dunque accumulare conoscenza per percezione, per contatto diretto ed immersivo e non come semplice osservatore. Come esecutore avente parte nell’azione e come ambiente nell’effetto, l’ambiente in cui l’essere umano vive è popolato da molte altre entità con cui continuamente esso sperimenta rapporti e relazioni e con cui costruisce contesti. -7- Implementazione di una piattaforma per Embodied Agent L’interpretazione dell’operato di un individuo da parte di estranei non necessita solo di un filone storico plausibile, occorre inserire l’evento all’interno di un contesto per poter estrarre informazioni significative. Ecco che il modello “uomo” suggerisce una definizione di agente ancora più stretta, un uomo occupa spazio e consuma risorse durante la propria esistenza, ogni uomo ha il proprio scopo, obiettivo individuale, gli uomini condividono (a vari livelli) l’ambiente e le risorse costituendo di fatto comunità, instaurando così diversi protocolli di interazione e comportamento, diversi gradi di strutture sociali. Nasce dunque la necessità di mantenere funzionali le comunità di cui si è membro (se non altro quelle di rango più stretto) per soddisfare i propri scopi e le proprie esigenze, nasce l’obiettivo comune. Per Dautenhan la caratteristica fondamentale per gli agenti autobiografici è di essere embodied, di poter percepire l’esperienza attraverso un corpo, gli agenti sociali sono particolari agenti autobiografici. A volte vengono anche direttamente chiamati Robot Sociali [CYN], che nel proprio ambiente mescolano esseri umani ed altri Robot. Come già detto in precedenza molte definizioni di agenti sono difficilmente separabili, con le due date ora abbiamo introdotto un elemento forte di caratterizzazione, cioè il possedere un corpo, tra loro la differenza è veramente molto sottile. 1.2.3 Società, cultura ed intelligenza Le società sono insiemi di “individui” che interagiscono secondo schemi di interazione scambiandosi risorse e comunicazioni. Un individuo è caratterizzato dalla propria storia (autobiografia) che ne costituisce l’esperienza e la cultura, gli elementi che concorrono alla costruzione dei propri comportamenti durante il soddisfacimento dei propri obiettivi, il fatto che possieda un corpo “unico come configurazione” fa sì che due elementi non possono mai condividere contemporaneamente la stessa locazione fisica, inoltre da ciò deriva un’esperienza ed una percezione unica ed estremamente personale. In [KER03] si discute di come i sistemi di intelligenza artificiale in genere non modellino abilità (o attitudini) sociali, di come siano in realtà esperti in alcuni settori di -8- Introduzione e definizioni applicazioni o attività. Ma un tale modello di riferimento può essere adeguato al mondo reale? Può essere vantaggioso in uno scenario che veda collaborare uomini e robot nei compiti quotidiani? La vita all’interno di nuclei sociali è un elemento di importanza assoluta nella teoria dell’intelligenza sociale. In questa ipotesi gli individui imparano ed attuano schemi sociali all’interno del gruppo, ma non hanno conoscenza di cosa stiano compiendo. Gli uomini invece sono in grado di comprendere cosa stanno facendo e di applicare così le relazioni che attuano tra simili ad altri elementi, estranei ai rapporti tra esseri umani. Sono in grado quindi di trasformare la cultura sociale in intelligenza individuale ed astratta. Il rapporto alla base di questo meccanismo è l’imitazione, cosa facilmente riscontrabile durante lo sviluppo dei bambini (elemento di enorme attualità per via di fenomeni di imitazione di modelli televisivi). Mitchell in [RWM] definisce così l’imitazione: “l’imitazione avviene quando un organismo e/o una macchina è in grado di produrre qualcosa che assomiglia ad un modello; occorre che il modello sia appreso e che la cosa prodotta sia costruita in modo da assomigliare al modello” e la descrive come composta da cinque livelli. Il primo livello è puramente mimico ed ancora non ci sono interazioni tra C (la copia) ed M (il modello), al livello due M influenza la costruzione di C. Al livello tre il modo di costruire C può essere modificato in relazione ad M e l’imitatore tenta di raggiungere per quanto più possibile M con il proprio comportamento. Al quarto livello l’imitatore controlla la relazione tra C ed M ed è in grado di modificare C in modo più fine, alterandone solo alcuni aspetti: l’imitatore raggiunge la consapevolezza di copia ed originale, la consapevolezza di sé. All’ultimo stadio, il quinto livello, l’imitatore è in grado di adattare il proprio comportamento in relazione alla percezione dello stato di un altro organismo, in pratica sviluppa l’empatia. Un individuo può applicare la conoscenza del comportamento per manipolare direttamente il modello, applicandolo così ad entità -9- Implementazione di una piattaforma per Embodied Agent estranee a sé stesso. Gli esseri umani adulti sono esperti di questo stadio di imitazione secondo Mitchell. E’ importante mantenere vivo il concetto di mimica, nei prossimi capitoli lo riprenderemo per argomentare l’apprendimento e l’evoluzione sociale. - 10 - Processo di Embodiment 2 Processo di Embodiment Effettuare il processo di embodiment significa dotare un agente di un corpo. Tale processo è osservabile in diverse forme ed è ben lontano da essere una procedura standard e ben definita, infatti, anche una interfaccia grafica può essere interpretata come il corpo di un agente, dato che ne diventa la sembianza, l’effige. Quindi occorre, in prima istanza, fare distinzione tra i corpi fisici ed i corpi virtuali e soffermarsi a riflettere sul significato del corpo per un agente e sul significato del fatto di possederlo. Se osserviamo il comportamento di qualunque individuo (di qualunque specie) possiamo notare come il corpo svolga un ruolo comunicativo e sociale di non poco conto. Nei comportamenti sociali l’interpretazione del corpo è utilizzata di continuo durante tutti i processi di interazione tra individui e gruppi. Oltre a tale ruolo comunicativo il corpo viene usando come primo strumento di apprendimento e per apprendere il primo concetto fondamentale : “IO”. Come punto di partenza usiamo la definizione di corpo come insieme di attuatori e sensori ed analizziamo alcuni approcci all’embodiment. 2.1 Embodiment Software (o virtuali) A prima vista si potrebbe pensare che un agente che interagisce col mondo attraverso un corpo simulato sia indistinguibile da uno che ne ha a disposizione uno reale: Un simulatore potrebbe generare sequenze di percezioni plausibili di un modo virtuale in sostituzione dei segnali provenienti da sensori. Kerstin Dautenhahn sostiene che questo non è vero [KER01]. Ciò in realtà mette in risalto due problematiche che riguardano l’agente: l’utente e la fisicità del mondo. - 11 - Implementazione di una piattaforma per Embodied Agent Nell’articolo [NIC] viene discussa proprio la problematica delle simulazioni di robot attraverso il metodo della “minimal simulation”. L’autore infatti discute il problema del modello reale e della simulazione sottolineando quando costoso e difficile sia simulare in modo preciso e dettagliato la fisica del mondo per via della continuità degli eventi e del rumore a cui questi sono esposti e che a loro volta generano. Tutto questo fa perdere i vantaggi del poter usare una simulazione anziché ambienti reali per far evolvere i controllori dei robot. Nell’esperimento documentato è utilizzato un robot dotato di 8 zampe e dotato di pochi sensori ad infrarossi e sensori sensibili alla luce, il problema che vogliono affrontare è di far evolvere il controllore dell’ octapode fino ad apprendere come evitare gli ostacoli incontrati ed individuati durante il proprio percorso. Punto fondamentale di tale approccio è riuscire a costruire un set minimo di tutte le interazioni rilevanti robot-ambiente, nel caso di agenti sociali parte dell’ambiente sono proprio gli altri “individui” e grossa parte delle interazioni prevede scambi tra gli individui e l’agente e alcune di queste interazioni posso persino essere richieste o comandi che scatenano un’altra serie di interazioni, sicuramente un ambiente del genere è difficilmente collassabile o enumerabile, tanto meno è sensato pensare di poter costruire un set minimale di tali eventi. Se si pensa al set di richieste che l’automa sa soddisfare, i modi di porle e gli individui che le possono porre ci si accorge subito della dimensione delle combinazioni possibili, insieme a questo tipo di interazione rimangono ancora vive tutte le problematiche di muoversi all’interno di un ambiente altamente dinamico ed evitarne gli ostacoli continuando magari a percepire richieste e comandi. Sulla base di questo si deduce che l’ambiente degli agenti sociali non ricade in quel gruppo di sistemi che posso trarre effettivi vantaggi da un ambiente facilmente modellabile con interazioni finite. Oltretutto il robot usato nell’esperimento anche se sfrutta un sistema neurale che viene fatto evolvere nel simulatore rientra ancora nel caso di automi simili a quelli descritti da Brooks o delle architetture reattive, al massimo gerarchiche ma - 12 - Processo di Embodiment sicuramente non dotato di sistema di pianificazione o interpretazione simbolica del mondo e delle sue componenti. In questi casi la costruzione di simulatori risulta impossibile o talmente svantaggiosa da rendere preferibile l’approccio fisico e reale, proprio come l’autore asserisce nel proprio lavoro. Oltretutto stiamo discutendo di agenti sociali, elementi che vedono come parte del loro ambiente l’essere umano: se fossimo in grado di costruirne un modello significativo da porre in un simulatore affinché un agente software possa comprenderne i comportamenti ai fini di simularne l’intelligenza sarebbe un paradosso. 2.2 Embodiment Fisico Embodiment fisico significa costruire un corpo reale per l’agente, dotarlo di percezioni ed attuazioni, dotarlo di meccanismi di interazione con l’ambiente in cui si dice sia “embedded”, cioè integrato, come viene detto in [KER01]. In tale articolo si parla di embodiment statico per sottolineare che un vero e proprio embodiment dovrebbe dotare gli agenti di un corpo con le stesse caratteristiche di quelli dei sistemi biologici. Al momento la difficoltà più lampante che si può notare è l’impossibilità di realizzare un corpo che sia in grado di rigenerare e riorganizzarsi (in sostanza di crescere ed evolversi) o che reagisca alla morte in maniera irreversibile come fanno gli esseri viventi. Se l’agente fosse in grado di apprendere l’irreversibilità dello stato di morte potremmo osservare l’insorgere di comportamenti sempre più simili a quelli che gli esseri viventi attuano, ma questo tema appartiene più alla sfera filosofica dell’intelligenza artificiale ed ancor di più ai temi cari della cinematografia degli ultimi anni4. 4 Da “Short circuit” ad “AI” il tema dell’automa che ha paura di morire ed attua comportamenti simili all’istinto di sopravvivenza è stato di enorme attrazione per storie riguardanti agenti che, alla luce delle definizioni usate fino ad ora, potremmo chiamare Sociali. - 13 - Implementazione di una piattaforma per Embodied Agent Il corpo svolge un ruolo importante nella comunicazione tra gli individui. Già a livello animali ci si rende conto come sia fondamentale la mimica corporea ai fini del mantenimento della struttura sociale, il gesticolare degli esseri umani durante le discussioni e le variazioni di espressione facciale servono per sottolineare concetti. Oltre alla mimica associata allo scambio vocale anche negli esseri umani pose ed atteggiamenti fisici realizzano comunicazione ed opera sociale. Per gli Embodied Social Agent in [KER01] viene sviluppato anche il termine “Believable Agents” (agenti credibili) in virtù del fatto che la loro credibilità e l’aspettativa degli utenti viene creata e condizionata dal design fisico del robot, fattore importante soprattutto in architetture con apprendimento con rinforzo dove la soddisfazione dell’aspettativa degli utenti è il parametro di rinforzo. Come già detto in precedenza molte definizioni di agenti sono difficilmente separabili. Con le due che abbiamo fornito sopra , nonostante la loro differenza sia veramente molto sottile, è stato introdotto un forte elemento di caratterizzazione : il possedere un corpo. In [KER04] l’autrice definisce così il termine Embodiment : “Embodiment means the structural and dynamic coupling of an agent with its environment, comprising external dynamics (the physical body embedded in the world) as well as the phenomenological dimension, internal dynamics of experiencing and reexperiencing of self and, via empathy, of other. Both kinds of dynamics are two aspects emerging from the same state of being-in-the-world” Oltre questa definizione la stessa autrice conclude [KER02] “...Embodiment is linked to a concept of a body and is not necessary given when running a control program on a robot hardware... ...Embodiment should always be seen as a characteristic of an individual and socially embedded cognitive system... ” Alla luce di quanto appena detto ci si rende conto che montare un sistema PC su un qualche tipo di hardware in grado di farlo muovere e dotato di qualche sensore non è di per sé sufficiente nella costruzione di un Robot sociale, cosa che riprenderemo anche nel Capitolo 6 sottolineando la necessità di interfacce uomo macchina diverse. - 14 - Processo di Embodiment 2.3 On-World, In-World e BodyImage La caratteristica di essere parte dell’ambiente è fondamentale affinché si instaurino rapporti e strutture sociali tra gli individui. In [BRI] si introducono i termini “Being-InThe-World” e “Being-On-The-World” come elementi di classificazione per l’embodiment che si affianca ai concetti di forte e debole e di autopoiesis ed allopoiesis. Il grado con cui il robot riesce ad adattarsi ai cambiamenti dell’ambiente è la prima discriminante da utilizzare per distinguere un sistema In-World da uno On-World. L’ intelligenza artificiale classica5 viene inquadrata come un sistema che osserva il mondo ed utilizza il corpo come “periferica” dotata di motori e su cui sono alloggiati dei sensori. Per contro l’intelligenza artificiale moderna6 (termine coniato soprattutto per lo studio di sistemi cognitivi e robot mobili) si focalizza sull’osservazione delle relazioni tra corpo, mente ed ambiente che interagiscono come partner dello stesso livello [CLA]. Adesso l’ambiente è composto dal mondo e dal corpo del robot stesso, cioè percepisce sé stesso nell’ambiente e l’ambiente in sé stesso; come detto in precedenza l’estrazione di un modello formale e preciso del mondo reale è un qualcosa di altamente complesso e, in prima approssimazione, quasi impossibile, un sistema autonomo non ha bisogno della precisione, ha bisogno di apprendere comportamenti utili e vantaggiosi per raggiungere determinati risultati. Ancora in [BRI] si legge: “Phenomenologists also argue against the use of symbolic representations or mental states saying that an embodied agent can dwell in the world in such a way as to avoid the task of formalizes everything because its body enables it to bypass this formal analysis” Da questo emerge che un sistema In-World trae beneficio dall’alto livello di integrazione nell’ambiente in cui opera più che dalla precisione della rappresentazione e del modello usati in pianificazione; anche se non si parla direttamente di architetture reattive o a subsumption in qualche modo il corpo svolge da “funzione di trasferimento”, 5 In [006] viene anche riferita come Classical AI ed affiancata all’approccio di Rappresentare il mondo In [006] viene chiamata New AI e viene associata alla percezione del mondo e legata alle interazioni tra il corpo e la mente. 6 - 15 - Implementazione di una piattaforma per Embodied Agent robot autonomi sono spesso architetture multi agenti, gerarchiche e composte da elementi reattivi ed altri “comportamentali” (behavioral approach). Altra caratteristica importante che in [BRI] emerge è la capacita di interpretare le percezioni e di saper “focalizzare l’attenzione sui dati rilevanti al raggiungimento di un determinato scopo”, più avanti vedremo la problematica dell’evoluzione, dell’emergere dei comportamenti e del focalizzare l’attenzione. Il fatto di porre così in enfasi l’importanza delle relazioni che si instaurano tra il sistema e l’ambiente fa ribadire la necessità di interfacce uomo macchina adeguate, visto che questi scambi bidirezionali di informazione rientrano ancora nelle dinamiche sistema-ambiente. Vediamo anche che abbiamo ripreso una delle caratteristiche date nella definizione di agente: l’autonomia, dandone una immagine in termini di capacità di movimento e di tempi di reazione agli stimoli percepiti, sempre meno si farà riferimento alla precisione di calcolo, una buona approssimazione al momento giusto è quanto basta, purché l’ambiente rispecchi il più possibile le “aspettative” che il robot si è creato al momento della pianificazione. Ancora una volta viene sottolineata l’importanza dell’aspetto In-World, solo in tale condizione è ragionevole parlare di differenze rispetto alle aspettative, cosa che risulterebbe estremamente difficile nel caso OnWorld, questo lo si può dire anche alla luce di quanto affermato nella definizione degli agenti autobiografici e sociali, la loro conoscenza dell’ambiente è codificata utilizzando sequenze storiche dell’ambiente stesso, ciò non significa che siano memorizzate sequenze di eventi passati, ma che sia possibile ricordarli una volta imparato come “rivivere virtualmente” la situazione desiderata e vedere così riprodotto lo stato che era stato percepito originariamente. Se il corpo dell’agente è parte integrante dell’ambiente se ne deduce che la percezione del robot dovrebbe essere una fotografia di “sé stessi” e di come la realtà si codifica attraverso i sensi di cui è dotato, ma in definitiva lo stato del corpo racchiude in sé anche la percezione dell’ambiente esterno. Queste sono quelle che in [KER03] ed in [KER02] vengono definite “Immagini del Corpo”. - 16 - Processo di Embodiment Da ciò ne consegue che deve esistere un posto nell’”organismo” del robot in cui tali immagini vengono costruite, in cui si possa avere una istantanea dello stato corrente, una mappa del corpo. 2.4 Corpo ed apprendimento In [KER01], [MIC] e [KER02] si evidenzia spesso il ruolo sociale del corpo e di come questo strumento possa essere utilizzato come mezzo di apprendimento o di “cognizione” (compare infatti frequentemente il termine ”Embodied Cognition”). I metodi di apprendimento descritti nei vari esperimenti sono tutti derivati dell’apprendimento per condizionamento, metodi utilizzati anche nell’insegnamento delle discipline sportive. In questo paradigma non è fondamentale costruire un preciso modello formale del mondo, ma bensì una profonda percezione dell’unione di sé stessi e dell’ambiente. Prima di discutere l’argomento dal punto di vista dell’intelligenza artificiale occorre darne degli esempi che siano di facile e comune lettura. Per iniziare individuiamo il paradigma: siamo nello scenario in cui esistono lo studente ed il maestro. Il maestro condiziona il comportamento dell’allievo facendo ripetere delle azioni finché queste non soddisfano il modello che voleva trasmettere (la differenza tra aspettativa e stato attuale è minima). Questo modo di procedere fa sviluppare e maturare lo schema motorio che lo studente sta apprendendo rendendolo così estremamente automatico, facendo cioè emergere anche elementi di sincronia e temporizzazione. Nell’insegnare la disciplina sportiva l’allenatore non si è minimamente preoccupato di insegnare al proprio atleta i principi della meccanica del corpo rigido o della chimica degli organismi: è riuscito a far “emergere la cognizione” di tali regole, lavorando esclusivamente sulle sensazioni dello studente. Sono molto interessanti gli esperimenti svolti in [KER01], [MIC] e [KER02] proprio perché riescono a far emergere lo stesso comportamento nei robot. Quindi è proprio - 17 - Implementazione di una piattaforma per Embodied Agent come se il semplice fatto di avere (sentire) un corpo, che gli permette di essere parte integrante dell’ambiente, rende superfluo il compito di creare una rappresentazione formale del mondo circostante e delle regole che lo compongono: il corpo stesso ne rappresenta la formalizzazione sulla base di sé stessi. Altri esperimenti importanti sulla scia del condizionamento sono stati intrapresi da ricercatori della Sony per studiare l’emersione della comunicazione all’interno di società. Gli Aibo (opportunamente modificati) iniziavano a scambiare suoni che costituivano “comunicazione” a mano che i “vocaboli” venivano associati ad oggetti. Altre caratteristiche importanti che sono emerse dalla sperimentazione in questa direzione riguardano la sincronia, questo soprattutto in virtù del fatto che si lavora a far emergere schemi di reazione, senza la necessità di una esatta pianificazione. Alla luce di quanto detto e di quanto si descrive nei testi citati si rafforza sempre di più l’idea di corpo come strumento sociale e di società come insieme culturale e modello di riferimento. Nel Capitolo 5 parleremo dei memi come elementi di cultura socialmente trasmissibile per meccanismi basati su mimica ed imitazione. Nel prossimo paragrafo intendiamo dare una idea di come la componente emotiva si colloca nel modello di cui discutiamo. 2.5 Emozioni e comportamento Le teorie di insegnamento sportivo, durante la loro evoluzione, hanno messo in evidenza due componenti importanti nel processo dell’apprendimento: la motivazione e l’emozione. In qualche modo l’essere umano percepisce un “rinforzo” nell’apprendimento frutto dell’interazione tra motivazione personale ed emozioni percepite. Questo ci sembra evidente quando si assiste a sessioni di allenamento da parte di professionisti, deve esistere un qualcosa che li spinge al migliorarsi sopportando le fatiche e gli errori (qualcuno sostiene “no pain, no gain”). Anche nello studio circa l’usabilità del software il feedback negativo (magari per eccessiva segnalazione di errori da parte dell’utente) - 18 - Processo di Embodiment intacca la performance con lo strumento. In definitiva le motivazioni ci spingono ad attuare certi comportamenti, misuriamo la qualità dell’operato (distanza tra aspettativa e risultato) e “valutiamo” il tutto inserendo la componente emotiva, questo pare essere lo schema gerarchico del pianificatore umano. In [CYN] viene riportata l’esperienza svolta con un robot sociale “emotion Driven” che, in breve, può essere descritto nei seguenti termini: è un sistema gerarchico composto da comportamenti che vengono elaborati da un pianificatore e combinati secondo una serie di scopi che il robot persegue contemporaneamente (motivazioni) e modulati dall’emozione manifestata. Questo sistema modifica quindi il proprio comportamento sulla base dello “stato d’animo”, modello in contrasto con quello che Damasio [LEC] e molti altri sostengono. In effetti, per quanto detto fino ad ora, l’emozione è una sorta di funzione di rinforzo che agisce durante la fase di apprendimento e non post pianificazione. Se ci riflettiamo un attimo tendiamo a non ripetere le esperienze negative e non a vivere male un esperienza positiva. Notare che abbiamo usato il termine esperienza, proprio perché siamo ancora nel mondo degli agenti autobiografici, mondo in cui il modello utilizzato per gli esperimenti in [CYN] non rispecchia molto il modello biologico (anche se indubbiamente il fatto di poter manifestare “emozioni” resta una sperimentazione avvincente). Il fatto di parlare di agenti che motivano i propri comportamenti sulla base della propria storia fa immaginare la componente emozionale traslata verso il passato piuttosto che come elemento di modulazione finale. Nelle tecniche di addestramento orientali tale modello è sfruttato per arricchire gli schemi motori di “stato emozionale”. Il fatto di imparare il pugno del drago, la posizione tigre stretta, o qualunque altra figura si voglia, non significa imparare a tirare pugni come farebbe un drago (cosa evidentemente improbabile) ma l’elemento figurativo, l’atmosfera del tempio e la disciplina fanno sì che alla posizione fisica vada a sommarsi (ripetutamente) un ben determinato stato d’animo con cui si vuole potenziare la componente difensiva od offensiva di una particolare tecnica. La costante ed - 19 - Implementazione di una piattaforma per Embodied Agent esasperante ripetizione dell’esercizio serve proprio a fissare in unʹunica “struttura dati”, e con estrema precisione (minima differenza tra il proprio stato in tutte le ripetizioni) una immagine di sé completa di stato d’animo (ed emozionale) appropriato. Quello che emerge di fondamentale da queste teorie è la nozione ci corpo, la percezione di sé come parte dell’ambiente che si rispecchia in noi stessi: occorre possedere un corpo e farne parte. - 20 - Tecnologie e supporti 3 Tecnologie e supporti In questo capitolo vengono descritti gli aspetti salienti relativi alle tecnologie impiegate nella realizzazione di R2D2. Il software realizzato viene eseguito dai seguenti sistemi operativi: • Microsoft Windows XP Tablet Edition • Microsoft Windows CE .NET 4.2. XP Tablet Edition è stato scelto per avere a disposizione tutte le funzionalità esposte da XP Professional come, ad esempio, le message Queue, IIS e i performance monitor, uniti alla tecnologia Ink che è disponibile solo sulla versione tablet del sistema. Tale tecnologia fornisce il supporto alla scrittura manuale, consente di gestire i tracciati generati dalla penna e di effettuarne eventualmente il riconoscimento come testo o come gesto. Ovviamente non sarà il robot ad avere l’hardware necessario per ricevere input da penna, tale hardware sarà nelle mani degli utenti che lo useranno anche per comunicare informazioni al robot. Questa tecnologia inoltre potrà anche essere usata da sottosistemi che niente hanno a che fare con le penne: l’API che viene usata per memorizzare e manipolare gli strokes, i tratti scritti con la penna, è un’implementazione completa di un sistema di grafica vettoriale. Windows CE .NET è stato scelto principalmente perché si tratta di un sistema operativo hard real time e quindi più che indicato per essere interfacciato con la gestione dei motori e dei sensori, cioè per gestire tutte quelle situazioni in cui la risposta tempestiva è d’obbligo. Oltre a questa peculiarità CE gode del fatto di richiedere minori risorse computazionali (memoria e processore) con un conseguente consumo energetico ridotto. Riprenderemo più avanti l’argomento Ink per trattarlo meglio nella sezione dedicata ai meccanismi di interazione tra R2D2 e gli utenti. - 21 - Implementazione di una piattaforma per Embodied Agent 3.1 Microsoft .NET Framework e C# Il Framework .NET di Microsoft si colloca nel panorama degli ambienti di esecuzione basati su una macchina virtuale come Java [JVM]. Il Common Language Runtime [CLR] (CLR) esegue codice rappresentato in linguaggio intermedio MSIL[IL]. L’ambizione di Microsoft è quella di avere un largo numero di linguaggi che compilano eseguibili per il CLR. Oltre a Visual Basic e C++, un nuovo linguaggio con caratteristiche analoghe a Java, chiamato C#[CS], è stato introdotto per supportare lo sviluppo per questa nuova piattaforma. Molti altri linguaggi sono in grado di essere eseguiti da CLR tra cui SML [SML.NET], Mercury [MER], Python [IronPython], Scheme [SCH], Perl [PRL], e molti altri. Poiché il CLR adotta una strategia di caricamento dinamico dei tipi (come la JVM) per garantire la consistenza dell’esecuzione la macchina virtuale effettua un controllo sui tipi senza limitarsi a dare credito al type-checking effettuato dal compilatore. Contrariamente a quanto avviene in Java, in .NET un file binario, chiamato assembly, contiene la definizione di più tipi, che include il codice espresso in linguaggio intermedio, e la definizione delle interfacce dei tipi. I metadati contenuti negli assembly, ovverosia i dati che descrivono i tipi, sono resi disponibili ai programmi in esecuzione attraverso un meccanismo chiamato reflection. L’ambiente d’esecuzione infatti mette a disposizione dei programmi in esecuzione un insieme di oggetti che rappresentano la struttura dei tipi caricati dalla macchina virtuale. In [ACC] è descritto un esempio di come i metadati ed il linguaggio intermedio possono essere utilizzati per realizzare altri scopi oltre la mera esecuzione. Oltre a poter analizzare la struttura degli assembly caricati, l’API di reflection (usando le classi contenute nel sotto-namespace System.Reflection.Emit) consente la generazione dinamica di assembly attraverso l’emissione delle singole istruzioni del linguaggio intermedio. La generazione dinamica di codice viene usata da numerose applicazioni per migliorare l’efficienza dei programmi specializzandoli a runtime, come ad esempio fa la libreria delle espressioni regolari presente nella libreria - 22 - Tecnologie e supporti di classi. Esistono anche strumenti avanzati per la generazione e la manipolazione del codice intermedio che offrono astrazioni più convenienti della manipolazione esplicita delle singole istruzioni, come ad esempio CodeBricks[CB]. C# C++ Unmanaged Managed x86 GC x86 Security ML Managed CIL BCL Loader VB JIT CLR … Figura 1 Struttura di esecuzione La Figura 1 mostra l’architettura di esecuzione della piattaforma .NET. Il codice intermedio generato dai compilatori viene caricato dal loader nel sistema e compilato dal Just in Time Compiler (JIT), che contrariamente a quanto accade in Java è sempre usato. Il codice eseguibile generato dal JIT in memoria viene collegato a tutti i moduli che offrono i servizi del runtime: sicurezza, garbage collection, e molti altri. Proprio perché il codice intermedio viene arricchito con chiamate alle routine interne del sistema, per essere “amministrato” dal runtime, si usa il termine managed code per indicarlo. Il codice nativo (altrimenti detto unmanaged in opposizione a managed) può essere linkato con quello generato dal runtime, consentendo l’interoperabilità tra il codice espressamente compilato per la piattaforma e quello nativo. Lo standard che definisce la Common Language Infrastructure (CLI) [CLI] definisce, insieme all’ambiente di esecuzione, meccanismi standard per garantire l’interoperabilità, che sono conosciuti col nome di PInvoke. Il supporto all’interoperabilità si è rivelato - 23 - Implementazione di una piattaforma per Embodied Agent fondamentale nello sviluppo del progetto poiché ha semplificato l’interazione tra il software di controllo e il sistema sottostante, fino ad arrivare agli attuatori e ai sensori. Il sistema dei tipi in .NET, mostrato in Figura 2, è radicato nella classe Object da cui tutti i altri tipi derivano. È importante notare come, a differenza di Java, anche i tipi di base derivano da Object. Questo non significa che gli interi siano oggetti veri e propri, ma che vengono inseriti in oggetti quando serve trattarli come tali (questa operazione è conosciuta come boxing). Quando un oggetto contenente un intero viene convertito in intero il valore contenuto al suo interno viene recuperato. Il sistema dei tipi definisce tipi valore, i tipi che definiscono oggetti che vengono trattati per valore e copiati risiedendo sullo stack piuttosto che nello heap. La possibilità di controllare l’allocazione di oggetti strutturati unita alla possibilità di passare oggetti per riferimento consente di esprimere codice molto più performante di quanto consente Java che limita l’allocazione di oggetti strutturati allo heap. Array Object Type interface T String ValueTyp e T[] Struct T int class T Enum Delegate Delegate T Figura 2 Type System del Framework .NET - 24 - Base types Enum T Tecnologie e supporti 3.2 Custom Attribute Il modello di reflection implementato da CLR è estendibile: i programmatori possono introdurre annotazioni associate agli elementi che costituiscono i tipi (assembly, classi e loro membri). Il runtime ignora queste annotazioni e l’unico servizio che offre è quello di renderle accessibili attraverso la reflection. Consideriamo il seguente esempio di Web service scritto in C# class MioWebService { [WebMethod] int add(int i, int j) { return i+j; } } La classe MioWebService contiene un unico metodo che è stato annotato con il custom attribute WebMethod. Dal punto di vista della semantica dell’esecuzione del programma la presenza dell’attributo è del tutto indifferente. È però possibile scrivere un programma che utilizzando la reflection cerchi queste annotazioni per fare qualcosa. Nel caso dei WebServices, ad esempio, è una libreria di Microsoft che quando trova metodi con attributo WebMethod genera un’interfaccia Web Service per il metodo (genera quindi il WSDL[WSD] che descrive il servizio, e l’interfaccia SOAP [SOA] per la sua invocazione). La definizione di un attributo consiste nella creazione di una classe che eredita (direttamente o indirettamente) dalla classe System.Attribute. Microsoft ha definito WebMethod come: class WebMethodAttribute : System.Attribute { ... } Osserviamo che il compilatore C# consente di omettere il suffisso Attribute presente nel nome della classe che definisce l’attributo. Per recuperare le annotazioni a runtime è sufficiente usare il metodo getCustomAttributes presente in tutte le classi che definiscono gli oggetti della reflection. Ad esempio il codice che genera l’interfaccia Web Service avrà uno schema simile al seguente: - 25 - Implementazione di una piattaforma per Embodied Agent foreach (MethodInfo m in t.GetMethods()) { WebMethodAttribute[] attrs = m.getCustomAttributes(typeof(WebMethodAttribute)); if (attrs.Length > 0) { // Genera l’interfaccia Web service } } Nell’esempio si scorrono tutti I metodi definiti nel tipo descritto da t e si genera l’interfaccia Web Services a tutti quelli che sono stati annotati dal programmatore con l’attributo opportuno. La reflection è da sempre stata usata nelle applicazioni di intelligenza artificiale; il LISP è stato spesso usato proprio perché dati e codice sono rappresentati nella stessa forma. Le annotazioni custom consentono nuovamente di scrivere programmi che ragionano su altri programmi, caratteristica usata dall’architettura descritta in questa tesi. 3.3 Performance Counter I performance counter sono servizi esposti dal sistema operativo ed accessibili attraverso le interfacce esposte dal Framework .NET. Si tratta di un insieme estendibile di contatori che forniscono informazioni sullo stato dei vari componenti della macchina (hardware e software). Il Framework stesso espone anche parte del proprio stato attraverso performance counter. Avendo a disposizione le necessarie credenziali si possono accedere anche counter su computer remoti. Abbiamo usato i performance counter con lo scopo di misurare lo stato dei computer all’interno del robot. Abbiamo reso disponibili i seguenti counter al resto dell’architettura: • carico del processore • memoria fisica ancora disponibile • dimensioni memoria virtuale • spazio disco libero totale • numero di threads in esecuzione - 26 - Tecnologie e supporti • numero di processi • allocazione totale degli heap del Framework .NET • stato e dimensione del garbage collector • eccezioni intercettate nel Framework .NET • bytes inviati tramite le interfacce di rete • bytes ricevuti tramite le interfacce di rete . Queste informazioni non sono utilizzate in modo esplicito ma fanno parte della descrizione dello stato interno del robot, elementi che concorrono alla definizione della percezione propriocettiva del robot. 3.4 XML, serializzazione e configurazione Il Framework .NET contiene nella propria class library un ricco set di strumenti per la manipolazione di dati in formato XML. In particolare abbiamo fatto uso delle seguenti funzionalità: • Serializzatore XML • Gestione di configurazione. 3.4.1 Serializzatore XML La serializzazione di oggetti in formato XML si basa sulla reflection API. Grazie alla reflection e al caricamento dinamico un programma può caricare una libreria ed utilizzare gli oggetti in essa contenuti ispezionandoli a runtime, riuscendo ad ottenere una descrizione in termini di nome della classe, campi, proprietà, membri, accessori e custom attribute. Grazie a queste informazioni non è difficile scrivere un programma che, dato un oggetto, ne ricavi la descrizione e la restituisca in formato xml. Tutto questo viene fatto dalla classe XML.Serializzation.XmlSerializer in modo del tutto automatico grazie al fatto che il costruttore richiede come parametro un - 27 - Implementazione di una piattaforma per Embodied Agent oggetto Type da cui estrae le informazioni necessarie a costruire uno schema XML per serializzare e deserializzare7 oggetti. Per poter serializzare/deserializzare un oggetto è necessario che il tipo dell’oggetto in questione sia stato annotato con l’attributo [Serializable] o che implementi l’interfaccia Iserializzable; inoltre possono essere necessarie ulteriori annotazioni per aiutare il serializzatore a trattare riferimenti polimorfi, come ad esempio accade nel seguente esempio: public class AgentInterface : AgentMessage { [XmlArray(ElementName="InputMessages", IsNullable=true)] public object[] InputMessages; [XmlArray(ElementName="OutputMessages", IsNullable=true)] public object[] OutputMessages; } . . . internal void SendState(AgentMessage msg, object sender, Type[] external) { msg.BrokerHost = Dns.GetHostByName(Dns.GetHostName()).AddressList[0].ToString(); msg.BrokerPort = localPort; MemoryStream ms = new MemoryStream(4096); XmlSerializer s = external == null ? new XmlSerializer(msg.GetType()) : new XmlSerializer(msg.GetType(), external); s.Serialize(ms, msg); byte[] data = ms.GetBuffer(); bodymap.Send(data, (int)ms.Length); } La serializzazione di un oggetto della classe object non è possibile poiché il sistema deve conoscere i tipi degli oggetti coinvolti nella serializzazione. Si fa quindi uso dell’attributo XmlArray e viene specificato il nome che tale collezione avrà nel documento xml generato, inoltre il serializzatore viene costruito passando come 7 Durante la deserializzazione si effettuano automaticamente controlli di validazione, se il messaggio xml non rispecchia lo schema prodotto a partire dal type passato a tempo di costruzione viene generato un errore e la deserializzazione non va a buon fine - 28 - Tecnologie e supporti parametro i tipi non direttamente deducibili dalle dichiarazioni della classe e coinvolte nel processo di serializzazione (vengono chiamati esterni), le cui istanze sono contenute nell’array generico. 3.4.2 Il file di configurazione Il runtime si affida a XML come linguaggio per esprimere i file di configurazione delle applicazioni. Il file di configurazione di un’applicazione può controllare svariati aspetti della sua esecuzione, come ad esempio la sicurezza e i percorsi in cui ricercare gli assembly contenenti i tipi da caricare. Questo file di configurazione può inoltre contenere informazioni che dipendono dall’applicazione specifica. Il framework mette a disposizione un’apposita API per consentire ai programmi di accedere alle informazioni specificate nel file di configurazione. Il seguente esempio mostra un file di configurazione in cui la sezione Agent_Workspace è definita dall’applicazione, e il codice usato per leggere i valori in essa contenuti: <?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <sectionGroup name="Agents_Workspace"> <section name="Agents" type="System.Configuration.NameValueSectionHandler"/> <section name="Network" type="System.Configuration.NameValueSectionHandler"/> </sectionGroup> </configSections> <Agents_Workspace> <Network> <add key="Port" value="6666"/> <add key="LocalPort" value="6667"/> <add key="BodyMapHost" value="localhost"/> </Network> <Agents> <add key="Agent1" value="NetworkAgent.Wifi,NetworkAgent"/> <add key="Agent3" value="Node.NodeAgent,NodeAgent"/> </Agents> </Agents_Workspace> <appSettings> <add key="NodeAgent.MachineName" value="Mordor"/> </appSettings> </configuration> - 29 - Implementazione di una piattaforma per Embodied Agent System.Configuration.AppSettingsReader configurationAppSettings = new System.Configuration.AppSettingsReader(); . . this.Processes = new System.Diagnostics.PerformanceCounter(); . . // // Processes // this.Processes.CategoryName = "System"; this.Processes.CounterName = "Processes"; this.Processes.MachineName = ((string)(configurationAppSettings.GetValue("NodeAgent.MachineName", typeof(string)))); 3.5 XML Web Services e crypto service I Web Services stanno vivendo una vera e propria età dell’oro: stanno rapidamente divenendo elementi importanti in architetture distribuite e eterogenee, in cui le implementazioni di modelli RPC (chiamata di procedura remota) esistenti si dimostravano inadeguate. Fino ad ora Corba[COR] e DCOM[SCO] hanno fatto da padroni nello scenario delle applicazioni distribuite ma il modello dei web service si è dimostrato molto vantaggioso per due motivi: • L’utilizzo di messaggistica interamente basata su XML e SOAP[SOA] semplifica l’interoperabilità tra sistemi e piattaforme altamente eterogenee (ad esempio mainframe, PC e palmari) • Sfruttare http e SOAP per il trasporto dei messaggi rende di facile soluzione il problema sicurezza e firewall. I web service sfruttano infatti tutto il background delle applicazioni web per quanto riguarda la sicurezza potendo sfruttare https, ssl e X509 per crittografare le comunicazioni. Il Framework .NET fornisce un supporto alla realizzazione di Web Services che, come abbiamo visto a proposito dei custom attribute risulta essere molto efficace e di semplice uso: IIS, il web server Microsoft, sfrutta i metadati ed i custom attribute per costruire tutta l’infrastruttura per generare la descrizione dei servizi Web nel formato - 30 - Tecnologie e supporti standard WSDL[WSD] e la pubblicazione dei servizi con interfaccia SOAP [SOA]. Il modello adottato per l’esecuzione di un Web Services è per default SingleCall (singola chiamata): ad ogni richiesta viene creato un nuovo oggetto su cui viene invocato il metodo esposto come servizio. Quindi il suo ciclo di vita vede la sua attivazione al momento di una richiesta, e distruggerli al completamento della funzionalità da svolgere8, tale paradigma può essere modificato dal programmatore introducendo un po’ di trucchi per rendere lo stato dell’oggetto persistente e condiviso (realizzando di fatto un pattern Singleton). Grazie al fatto che il web server può usare i metadati a decorazione dell’oggetto da pubblicare come servizio rende estremamente facile sia la creazione di web service che il loro consumo nelle applicazioni 3.6 Microsoft .NET Remoting La tecnologia denominata .NET Remoting è una delle novità offerte dalla piattaforma in termini di applicazioni distribuite. Prima di descrivere, in breve, la struttura ed il modello realizzato occorre dare una visione dell’ambiente di esecuzione dei programmi .NET e del loro spazio di memoria. Remoting permettere di utilizzare oggetti remoti con l’apparenza di lavorare con istanze locali, tramite il supporto del runtime le invocazioni di metodo o l’accesso alle risorse viene trasmesso all’host del servizio. La parte che effettua la comunicazione su rete prevede l’uso di messaggi SOAP su http o di messaggi binari su TCP. Ovviamente è possibile modificare ed estendere questi meccanismi per adattare la componente di comunicazione alle proprie esigenze, per questo si consiglia [rem] come testo di riferimento. 8 Per motivi di efficienza non vengono realmente distrutti ma mantenuti nell’application pool del web service, ciò che viene perso e reinizializzato è lo stato dell’oggetto esposto come servizio web - 31 - Implementazione di una piattaforma per Embodied Agent 3.6.1 AppDomain, Boundaries e Proxy Esistono dei limiti di visibilità delle istanze di oggetti durante l’esecuzione dei programmi .NET, questo perché la memoria è gestita dal framework e quindi non ci sono meccanismi di puro accesso diretto. Non è difficile pensare che il limite estremo è lo spazio di processo, nessun programma può vedere direttamente gli oggetti nella memoria di un altro processo. In realtà il sistema di esecuzione introduce una nozione di confine all’interno dello stesso processo: AppDomain (Dominio Applicativo). Un AppDomain rappresenta il confine che il runtime utilizza per caricare tipi e quindi i relativi oggetti. È un meccanismo ideato per consentire ad un’applicazione di isolare l’esecuzione di una porzione di codice all’interno di un programma. Sebbene all’interno dello stesso spazio di memoria, oggetti che risiedono in AppDomain differenti non possono comunicare direttamente: devono utilizzare canali del tutto simili a quelli utilizzati nelle comunicazioni interprocesso. Quindi i processi sono aggregati di AppDomain e le comunicazioni tra processi con Remoting vengono chiamate CrossDomain Communications. Un dominio applicativo è composto a sua volta da Context (contesti), elementi usati dai thread per contenere le proprie risorse ed i campi delle classi marcati threadstatic. Spesso i Context sono usati per creare meccanismi di protezione e di accesso alle risorse particolari, non è la sede per la descrizione di questi meccanismi che potrete trovare su [rem]. - 32 - Tecnologie e supporti Process Application Domain Context Application Domain Context Figura 3 Boundaries Come si può allora far comunicare istanze di oggetti che risiedono in boundaries diversi o addirittura su macchine diverse? Partiamo dal caso base, passare alle comunicazioni CrossMachine è un passo breve e facile. Se un oggetto X del dominio A invoca un metodo su un oggetto Y del dominio B come è riferito Y da X? Esiste l’oggetto TransparentProxy che espone l’interfaccia dell’oggetto a cui fa riferimento, dando la parvenza ad X di usare Y come se fosse istanziato nello stesso boundary, per poter fare questo viene utilizzata la reflection per produrre le segnature dei metodi, dei campi e delle proprietà di Y. L’utente può estendere la classe RealProxy per implementare le politiche da realizzare al momento in cui si faccia accesso alle risorse ed i metodi dell’oggetto remoto. Per ottenere l’istanza del TransparentProxy si possono usare due approcci. Usando i file di configurazione ed il metodo Activator.GetObject(Type type, string url, object state). Configurazione di remoting per client: <configuration> - 33 - Implementazione di una piattaforma per Embodied Agent <system.runtime.remoting> <application> <client> <wellknown type="RemotableType, RemotableType" url="http://localhost:8989/RemotableType.rem" /> </client> </application> </system.runtime.remoting> </configuration> Se si registra il tipo remoto come descritto sopra o a programma è possibile ottenere l’attivazione dell’oggetto remoto utilizzando l’operatore new. 3.6.2 MarshalByRef e ContextBoundObject Gli oggetti che derivano dalla classe MarshalByRef o dalla classe ContextBoundObject hanno la caratteristica di attraversare i boundaries passati per riferimento e non per copia: al momento della loro serializzazione invece di una copia viene ottenuto un oggetto ObjRef che contiene tutte le informazioni ed i metadati necessari per poter costruire degli oggetti proxy. Oltre all’oggetto remoto c’è da considerare che anche i parametri dei metodi remoti ed i loro eventuali valori di ritorno devono attraversare i confini che separano il client dal server, questo introduce problematiche di marshalling degli oggetti. Di base gli oggetti sono passati per copia ma chi deriva da MarshalByRef o ContextBoundObject viene passato per riferimento. All’interno del quadro di remoting in realtà vengono trasmesse copie e nel caso andassero trattate come riferimenti il runtime si preoccupa di riflettere le modifiche effettuate durante l’esecuzione dei metodi. - 34 - Tecnologie e supporti Nelle segnature dei metodi esistono anche le parole chiave ref e out per indicare che il parametro è da passare per riferimento9. 3.6.3 Infrastruttura, serializzazione ed Hosting Oggetto Client Oggetto Server Proxy Scambio Messaggi Remoting Remoting Figura 4 Schema della struttura di .NET Remoting La Figura 4 rappresenta lo schema che .NET Remoting realizza all’interno delle applicazioni in cui viene utilizzato. Il client crea un istanza dell’oggetto remoto tramite la classe Activator o l’operatore new (avendo preventivamente registrato i tipi che sono remoti) e nel suo dominio applicativo viene costruito un TransparentProxy con l’interfaccia del tipo richiesto. Lato Server l’oggetto viene creato se prima non esisteva e viene rimandato al client l’ObjRef necessario alla costruzione del proxy. A questo punto viene costruita l’infrastruttura di comunicazione. Tale struttura è bidirezionale è vede coinvolti principalmente due elementi: • Canale di comunicazione • Serializzatore/Deserializzatore di messaggi. 9 La differenza tra ref ed out risiede nel controllo che il runtime di .Net fa sui parametri, un parametro marcato con ref deve essere inizializzato prima di essere passato mentre se fosse stato marcato con out questo non è fondamentale e viene trattato semplicemente come valore di ritorno. - 35 - Implementazione di una piattaforma per Embodied Agent Di base i canali a disposizione sono http e TCP e la serializzazione può essere SOAP o binaria, il flusso dei messaggi è bidirezionale e sotto le opportune condizioni di policy si possono serializzare e deserializzare anche gli oggetti Delegate, realizzando di fatto un sistema ad eventi distribuito. Estendendo i canali ed i serializzatori è possibile ottenere il comportamento desiderato dal sistema di gestione dei messaggi. Una nota va fatta sul modo di attivazione degli oggetti server, questi possono essere attivati dall’applicazione host o dal client e può realizzare un modello SingleCall o Singleton. 3.6.4 Una nota sulla classe Process e sulle finestre di WindowsForms Tramite la classe Process si possono controllare processi esterni ed eseguire alcune operazioni come terminarli, conoscere l’entità delle risorse in uso e farsi dare l’handle della finestra principale. Con l’handle si può ricostruire la classe Form che espone il metodo CreateObjRef. Ridefinendo nella classe che costituisce la finestra principale (quella sulla quale viene invocato Application.Run()) tale metodo si possono fornire a processi esterni tutte le informazioni necessarie per costruire un TransparentProxy e fornire così un interfaccia con cui poter costruire in modo dinamico ed a programma applicazioni distribuite (in questo scenario sono residenti sulla stessa macchina i processi in questione) con comunicazioni CrossProcess. 3.7 Microsoft Message Queue Anche le Message Queue sono parte delle tecnologie offerte per la realizzazione di applicazioni distribuite ma, a differenza di Remoting, sono gestite dal sistema operativo. Come il nome stesso suggerisce il modello realizzato è quello dello scambi di messaggi tra entità in esecuzione. La creazione e la gestione delle code può essere fatta a programma o direttamente con gli strumenti di amministrazione di Windows. Una volta create, i programmi - 36 - Tecnologie e supporti effettuano la sottoscrizione ed iniziano ad effettuare lo scambio di messaggi. I messaggi possono essere semplici od oggetti serializzati. Di base le code sono realizzate come area di memoria condivisa ma possono essere caratterizzate con: • Persistenza • Acknowledgment • Journaling 3.8 PInvoke Platform Invoke è un meccanismo standard che il runtime mette a disposizione per consentire a codice managed di invocare codice unmanaged. Il meccanismo è dichiarativo e consente di collegare a metodi di classi funzioni di librerie a collegamento dinamico. Un metodo implementato da una DLL viene dichiarato come extern e annotato con una specifica annotazione per indicare in quale libreria va cercata una certa funzione. Se ad esempio si vuole invocare la funzione add nella libreria a collegamento dinamico mylib.dll è sufficiente inserire la seguente dichiarazione in una classe: [DllImport(“mylib.dll”)] internal static extern int add(int i, int j); Quando viene invocato il metodo add, il runtime carica la libreria a collegamento dinamico utilizzando le API apposite fornite dal sistema operativo, e invoca la funzione che ha lo stesso nome del metodo, utilizzando la convenzione di chiamata opportuna richiesta dalla libreria. Ovviamente l’esempio presentato nasconde la vera natura del problema: il marshalling degli argomenti: spesso le funzioni C si aspettano puntatori a valori, compresi puntatori a funzione. Per favorire l’interoperabilità il runtime di .NET offre la possibilità di controllare il layout delle strutture dati in memoria in modo da renderle compatibili con lo standard C. Inoltre è possibile utilizzare l’aritmetica dei puntatori e passare puntatori ad oggetti managed al codice unmanaged. Infine è possibile passare oggetti delegate dove è - 37 - Implementazione di una piattaforma per Embodied Agent atteso un puntatore a funzione: il runtime genererà il chunk di codice necessario a interfacciare la chiamata C col codice managed riferito dal delegate. La possibilità di invocare codice nativo si è rivelata fondamentale per esporre meccanismi del sistema operativo all’interno del codice managed. Ad esempio l’agente che si occupa di gestire le connessioni Wireless attraverso l’interfaccia NDISUIO che consiste nella comunicazione col driver di rete mediante una named pipe e chiamate alla funzione DeviceIoControl. Questa funzione è stata definita come segue: [DllImport("kernel32", SetLastError=true)] private static extern bool DeviceIoControl( Handle hDevice, IOCTL dwIoControlCode, IntPtr lpInBuffer, int nInBufferSize, IntPtr lpOutBuffer, int nOutBufferSize, out int lpBytesReturned, IntPtr lpOverlapped); Il seguente frammento di codice invoca la funzione per impostare il dispositivo di rete con cui il programma interagirà: if (current != null) { Close(); Init(); } string name = value.Name + "\0"; int bytesReturned; unsafe { fixed (char* s = name) { if (!DeviceIoControl(DriverHandle, IOCTL.IOCTL_NDISUIO_OPEN_DEVICE, new IntPtr((void*)s), 2*value.Name.Length, IntPtr.Zero, 0, out bytesReturned, IntPtr.Zero)) throw new WiFiException(string.Format("WiFiMan: {0}", GetLastErrorMessage())); current = value; } } Osserviamo che la stringa contenente il nome del dispositivo viene convertita da una stringa del runtime (una COMString [Rotor]) in una stringa wchar*. In altre - 38 - Tecnologie e supporti interazioni è necessario passare strutture dati. La keyword fixed informa il garbage collector di non spostare la stringa s poiché un suo riferimento è stato passato a codice C che non è a conoscenza delle strategie di copy collection adottate dal runtime. Il seguente è invece un esempio di come una struttura del runtime viene dichiarata per poter essere passata per riferimento al codice di una DLL: [StructLayout(LayoutKind.Sequential)] internal struct NDISUIO_QUERY_BINDING { internal uint BindingIndex; internal uint DeviceNameOffset; internal uint DeviceNameLength; internal uint DeviceDescrOffset; internal uint DeviceDescrLength; } // // // // // 0-based binding number from start of this struct in bytes from start of this struct in bytes L’attributo Sequential richiede al runtime di disporre i membri della struttura sequenzialmente, secondo la strategia adottata dal compilatore C. 3.9 ACS (Annotated C Sharp) I Custom Attribute in .NET possono essere utilizzati per la decorazione di classi, campi, metodi e parametri ma non istruzioni o blocchi di codice. Annotated C Sharp (ACS) è un’estensione del linguaggio C# che estende il meccanismo dei custom attribute ai blocchi di codice. Il compilatore è stato implementato come una trasformazione da codice sorgente in codice sorgente. Manipolare il codice ha quindi richiesto la costruzione del tool di trasformazione ed una piccola estensione al parser ed alla grammatica di C#. Per fare questo è stato utilizzato COCO[COC], un parser LL(k) esteso per poter gestire linguaggi che, come C#, non appartengono a questa classe di linguaggi. Per rendere semplice ed user friendly l’utilizzo di ACS tutti i tool sono stati integrati all’interno di Visual Studio 2MIC. Una volta annotati i blocchi di codice è possibile reperire da ogni metodo l’albero delle annotazioni contenute ed i loro offset all’interno del codice binario. Queste sono le caratteristiche di ACS, poi sta agli sviluppatori formularne un uso ed un’utilità - 39 - Implementazione di una piattaforma per Embodied Agent effettiva. Gli scopi che hanno portato alla realizzazione di un sistema di annotazione sono stati principalmente tre: • Service discovery • Code Evolution • SelfKnowledge L’ esempio che segue mostra come ACS ed i custom attribute abbiano fornito elementi interessanti nello sviluppo del software legato ai nostri esperimenti di robotica e service discovery . Figura 5 Braccio Robotico Abbiamo utilizzato un braccio robotico della Lynxmotion[LXM] (Figura 5) connesso ad un server che lo espone tramite .NET Remoting. Il servizio “Arm” doveva essere scoperto ed utilizzato secondo un meccanismo che ne rendesse comprensibili le funzionalità. Alla prima implementazione il codice era il seguente public class Arm : MarshalByRef, IArm, I6DOF, IGripper { public Arm(){…} } public void Reset(){…} public void Move(int x, int y, int z){…} public void Catch(int x, int y, int z){…} internal void IKS(int x, int y, int z){…} public void OpenGripper(){…} public void CloseGripper(){…} - 40 - Tecnologie e supporti Le interface usate servono per scoprire tramite reflection che l’istanza di Arm è un braccio (IArm), che ha 6 gradi di libertà (I6DOF) e che possiede una pinza (IGripper). L’interfaccia IGripper costringe all’implementazione dei metodi OpenGripper e CloseGripper, che modellano le funzionalità di apertura e chiusura, il metodo Move non sembra difficile da comprendere ma la presenza di Catch solleva qualche dubbio sulla sequenza di operazioni che sono coinvolte. Con ACS e custom attribute il codice equivalente è il seguente [Arm, Dof(6), Gripper] public class Arm : MarshalByRef { public Arm(){…} } public void Reset(){ Open(); Move(0,0,0); } public void Move(int x, int y, int z){ [MoveEffector] { IKS(x,y,z); [SetMotor]{…} [SetMotor]{…} …} } public void Catch(int x, int y, int z){ Open(); Move(x,y,z); Close(); } internal void IKS(int x, int y, int z) { [InverseKinematicSolver] {…} } public void OpenGripper(){ [OpenGripper] {…} } public void CloseGripper(){ [CloseGripper] {…} } Grazie ad alcune funzioni di supporto è possibile estrarre l’albero degli attributi di annotazione per i metodi della classe Arm e, una volta definito il significato dei termini, comprendere le funzionalità che realizzano. - 41 - Implementazione di una piattaforma per Embodied Agent Per il metodo Catch l’albero estratto è il seguente 1. OpenGripper 2. MoveEffector a. InverseKinematicSolver b. SetMotor c. SetMotor 3. CloseGripper Da questo albero si può capire l’algoritmo usato e che cosa compia il metodo Catch, altro fatto rilevante è che invece dell’interfaccia I6DOF sia stato usato l’attributo DOF con il parametro 6, con una sola classe riusciamo a decorare ed etichettare qualunque sistema possieda gradi di libertà, senza dover definire un’interfaccia per ogni variazione. Adesso un sistema, con l’opportuno supporto, è in grado di scoprire l’esistenza del braccio robotica e di capire le funzionalità esposte dalla sua interfaccia e la sequenza logica con cui sono correlate. Questo è stato il motivo principale che ha portato alla progettazione e realizzazione di ACS anche se, come vedremo in seguito, il sistema può essere usato in molti modi e con scopi diversi poiché tutto quello che in realtà permette è semplicemente di poter annotare con attributi codice ed istruzioni. 3.10 ER1 Interface Abbiamo accennato in precedenza ad ER1 (Figura 6), la piattaforma prodotta dalla Evolution Robotics[ER] su cui sono stati ideati e realizzati il design ed i test del sistema prototipale che, in seguito, avrebbe adottato R2D2. In termini hardware ER1 è composto due blocchi motori di tipo passo passo, una telecamera, un braccio con pinza e tre sensori ad infrarossi, il tutto connesso al PC tramite collegamento USB. - 42 - Tecnologie e supporti Il software di controllo fornito dalla Evolution Robotics comprende un semplice sistema di controllo a regole if-then-else, un modulo di feature extraction, obstacle avoidance e detection; utilizza inoltre SAPI di Microsoft per il riconoscimento della voce e la sintesi vocale, e può gestire file, e-mail. Figura 6 ER1 Il software development kit di base consiste in un piccolo terminale telnet in grado di accettare comandi ed interrogazioni, il lavoro che abbiamo fatto è stato quello di esporre in una classe tutti i servizi della piattaforma. Per rimpiazzare l’interfaccia originale stiamo costruendo un nuovo controllore per interfacciare l’hardware di ER1 con i nostri sistemi in modo diretto, così da poter ottenere una vera e propria libreria di supporto in .NET. Adesso illustreremo la prima versione dell’interfaccia che abbiamo costruito, il wrapper al controllo via Telnet (Figura 7), elemento che è stato utilizzato nei test riportati nel capitolo 7 a causa dei tempi di realizzazione del sistema in versione finale. - 43 - Implementazione di una piattaforma per Embodied Agent HALServer Telnet Client ER1 Control Software API Figura 7 Wrapper .NET ad ER1 3.11 DirectX DirectX[DDX] è il sistema di supporto per lo sviluppo delle applicazioni multimediali su piattaforma Microsoft che si compone di: • DirectDraw Sistema per la gestione della grafica bidimensionale • Direct3D Sistema per il supporto alla grafica 3D ed all’accelerazione HW • DirectSound Sistema della gestione Audio e dell’hardware preposto • DirectMusic Sistema per la direzione degli eventi sonori • DirectInput Sistema per la gestione dei device di input e controllo degli effetti di force feedback • DirectPlay Sistema per la gestione del supporto di rete, creazione lobby, chat e voice chat • DirectShow - 44 - Tecnologie e supporti Descrivere questo sistema è difficile, in pratica consente di montare blocchi scritti con i supporti di DirectX citati fin ad ora per integrarli e concatenarli all’interno di una applicazione 3.11.1 DirectShow DirectShow è la sezione di DirectX che gestisce la presentazione dei contenuti multimediali e la creazione dei componenti per effettuare • Acquisizione video • Codifica audio/video • Decodifica audio/video • Filtri (in place e non) • Riproduzione audio/video • Mux DeMux La tecnologia con la quale è realizzato è COM[COM] ed è stato utilizzato questo sistema per costruire la classe FrameDispatcher per gestire l’acquisizione di frame da telecamere, filmati e finestre per effettuare in seguito i filtri necessari ai moduli di computer vision. 3.11.2 DirectSound DirectSound è l’api di DirectX per l’accesso ai device audio, consente di gestire interamente l’hardware audio del sistema per compiti di riproduzione, sintesi ed acquisizione. Grazie alle interfacce esposte si può accedere ai buffer di input/output delle schede audio, poiché alcuni di questi buffer sono hardware in generale il modo di accedere ai byte contenuti è tramite le funzioni Lock e Unlock esposte dall’interfaccia DSBuffer (e tutte le sue derivate). Sarà compito di DirectSound produrre l’aggiornamento dei buffer HW. Il modo alternativo a DirectSound più famoso per gestire l’audio è quello dei driver ASIO. Abbiamo introdotto il termine driver proprio perché in realtà è grazie al fatto che i produttori di device audio realizzino e distribuiscano driver DirectSound, che tale sistema esiste. Tra i due standard esiste una - 45 - Implementazione di una piattaforma per Embodied Agent profonda differenza e per i professionisti la più saliente è la latenza che in DirectSound raggiunge i 20 msec, cosa non tollerabile per la realizzazione di sistemi di sintesi audio software in tempo reale. In realtà uno dei più famosi software (o forse sarebbe meglio dire linguaggi) per la costruzione di strumenti musicali (e non solo) software è il CSound[CSN]. Con tale strumento si possono creare programmi per generazione sonora sia off line (cioè renderizzando su file) che on line (cioè in tempo reale) e in ambiente Windows sfrutta proprio un core scritto con direct sound. All’interno della nostra architettura, DirectSound è stato usato per sviluppare la gestione dell’ interfaccia audio sia in input che in output. 3.12 OpenCV OpenCV [OCV] è una libreria costruita da Intel [INT] che implementa buona parte degli algoritmi più noti il letteratura per quanto riguarda la manipolazione ed il trattamento delle immagini orientate alla computer vision. Con questa libreria sono stati scritti quasi tutti i moduli collegati al sistema di visione come i blocchi di: • Face Detection • Face Recognition • Gesture Recognition La libreria mette a disposizione degli sviluppatori primitive costruite per essere efficienti su piattaforme Intel e chipset Intel con software compilato utilizzando il compilatore proprietario e le librerie di supporto Intel Performance Primitives. Tutto il sistema Intel10 prevede lo sviluppo in C++, cosa che avevamo già preventivato per il software di computer vision perché altamente critico a causa di una complessità in termini di tempo e memoria elevata. 10 I compilatori Intel e le Intel Performance Primitives sono librerie proprietarie e rilasciate dietro acquisto di licenza d’uso mentre le OpenCV e le OpenAVR sono rilasciate sotto licenze GPL. - 46 - Tecnologie e supporti 3.13 ExoCortex.DSP La libreria ExoCortex.DSP[EXO] implementa funzioni necessarie al trattamento dei segnali come le trasformate di Fourier. La libreria è scritta in C# e permette di realizzare le trasformate e le controtrasformate fino a 3 dimensioni. Inoltre contiene anche funzioni statistiche e matematiche per i numeri complessi. Strumento fondamentale per la costruzione degli algoritmi legati al trattamento dei segnali audio e video, nel nostro caso è stata utilizzata solo per la gestione dell’audio dato che per il video siamo ricorsi a codice C++ ed OpenCV. 3.14 NDIS, Miniport e Windows Driver Development Kit Per la realizzazione dei supporti di rete si è dovuti ricorrere all’architettura driver di rete di Windows, cioè NDIS. Con il supporto di query NDIS ed il driver miniport ci è stato possibile utilizzare, configurare e gestire le interfacce di rete e, soprattutto, quelle di protocollo 802.11x . Tutte le funzionalità di questo livello sono esposte ai 11 programmatori dal DDK (Driver Development Kit) che permette di costruire driver per tutto l’hardware che si vuole, non solo per i supporti di rete. 11 802.11x è il nome generico con cui ci si riferisce a tutti i protocolli wireless, a seconda della lettera al posto della x il device fornisce ampiezze di banda diverse. Il diffusissimo 802.11b fornisce connettività fino a 11 Mbps (anche se alcune schede possono fornire anche 22Mbps) la versione a e la versione g raggiungono i 54 Mbps. - 47 - Implementazione di una piattaforma per Embodied Agent - 48 - Il progetto R2D2 4 Il progetto R2D2 Progettare R2D2 ha comportato una grande quantità di lavoro non direttamente correlato al mondo informatico ma che hanno consentito di imparare alcuni aspetti che si sono rivelati fondamentali anche ai fini della piattaforma software. 4.1 Design del sistema L’architettura del droide è stata disegnata rifacendosi in buona parte al testo “L’errore di Cartesio”[LEC] e quindi ispirandosi al modello biologico umano. Nel tracciare la struttura, il design software e fisico si sono intrecciati per buona parte del processo di progettazione, proprio in virtù del fatto che negli esseri umani parte della gestione motoria si specializza nel tragitto nervoso dal cervello ai muscoli attuatori. Il design della carrozzeria, ad esempio, non è stato un compito rivolto solo alla questione estetica, si è dovuto tener conto dei problemi dovuti ad attriti meccanici, alla manutenzione del robot, a come i sensori dovevano essere alloggiati e distribuiti su di essa, a come moduli di input/output dovevano essere costruiti e disposti in alloggi opportunamente ricavati nella vetroresina. La pelle ricopre un ruolo importantissimo negli esseri umani sia da un punto di vista funzionale che psicologico. Su di essa sono distribuiti moltissimi recettori che ci permettono di percepire le temperature, la rugosità delle superfici, la presenza di correnti d’aria (anche grazie alla presenza di peluria) e rappresenta quindi un importantissimo organo sensoriale distribuito su tutta la superficie corporea (anche se le aree e la qualità della percezione variano da zona a zona), oltre a questa caratteristica la pelle funziona per noi da involucro e fornisce al cervello un ‘importante informazione : l’ultimo perimetro che separa definitivamente sé stessi da tutto il resto del mondo, una delimitazione fisica e tangibile del corpo. - 49 - Implementazione di una piattaforma per Embodied Agent Quindi la carrozzeria del droide ospita la sensoristica ad infrarossi ed ultrasuoni ed alcuni connettori come RJ45, RS232, VGA, PS2, etc. (Figura 8 e Figura 9), necessari per la connettività del robot, per la ricarica dei sistemi di alimentazione ed alcune fasi di manutenzione. Figura 8 Alloggio porte Figura 9 Particolare USB Le connettività poste sulla parte frontale del busto sono considerate di output o manipolazione mentre quelle poste nel dorso sono le connessioni che consentono le fasi di manutenzione e docking. Il fatto che possieda capacità di connessione implica che averne percezione sia un fatto importante. La testa ospita, oltre i sensori ad ultrasuoni (Figura 10) ed infrarossi, un gruppo di due camere telescopiche per visione stereo ed i microfoni che compongono il sistema di cattura audio. Sulla calotta e’ anche posto un display lcd grafico per dare una veloce immagine dello stato del robot. - 50 - Il progetto R2D2 Figura 10 Alloggio sensore ultrasuoni Per mantenere coerenza col droide protagonista di Star Wars anche il nostro modello è in grado di assumere due configurazioni, cosa utile soprattutto quando vengono utilizzate velocità superiori ai 40 cm/sec occorre dare al robot una maggiore stabilità e sicurezza di manovra assumendo la configurazione a tre piedi, in modo da aumentare la superficie d’appoggio e la centratura del baricentro. Il fatto di possedere una struttura fisica a pendolo richiede una gestione delle accelerazioni accurata per non compromettere l’equilibrio del droide e di conseguenza la propria ed altrui integrità fisica (il sistema pesa complessivamente circa 85 Kg e può raggiungere velocità come i 40 Km/h). Lo stato della configurazione assunta e del sistema telescopico delle camere sono informazioni importanti perché oltre che parti dello stato propriocettivo del droide comportano anche una deformazione delle percezioni esterne. Per prima cosa vediamo come Damasio affronta il corpo e la sua relazione col cervello umano. Il cervello umano è composto da una serie di zone funzionalmente specializzate e preposte a determinati compiti. Il cervelletto svolge un ruolo importantissimo nella sfera motoria, è qui che vengono costruiti, elaborati ed utilizzati gli schemi motori, in pratica si può pensare agli schemi motori come un insieme di risorse ed algoritmi che vengono “etichettati”, praticamente un meccanismo simile a quello dell’invocazione di metodi nei programmi. Questo fa sì che a livello di pianificazione vengono prodotti ed inviati segnali che vengono denominati “pacchetti motori” che nel cervelletto vengono già tradotti nell’equivalente - 51 - Implementazione di una piattaforma per Embodied Agent schema motorio. Dal cervelletto partono quindi segnali già più specializzati “di livello più basso” che, durante il loro percorso fino alle terminazioni nervose direttamente implicate nell’attuazione muscolare, vengono specializzati e possono provocare la generazione di altri segnali. Potremmo pensare a qualcosa tipo: Livello1.EseguiSchemaX() { Livello2.termA.GeneraSegnale(); . . Livello2.termK.GeneraSegnale(); } dove Livello2.termA.GeneraSegnale() { Livello3.termF.GeneraSegnale(); . . Livello3.termL.GeneraSegnale(); } e così via. 4.2 Architettura Come detto nel paragrafo precedente l’aspetto hardware e software sono estremamente accoppiati per cui il termine architettura farà riferimento al sistema per intero che può essere in primo luogo schematizzato come in Figura 11. - 52 - Il progetto R2D2 Brain BodyMap Vision Motion Audio Self Sensing Network Figura 11 Architettura software/hardware di R2D2 La parte di interesse per la tesi (ed oggetto del progetto) è quella che riguarda la BodyMap ed i livelli sottostanti; questa porzione è quella che abbiamo definito “Piattaforma per Embodied Agent”. Nella descrizione che stiamo per fare partiremo dal basso e lasceremo la BodyMap come ultimo elemento. 4.2.1 Vision Il gruppo Vision risiede nella calotta, o testa, del droide che alloggia una coppia di camere montate su un supporto telescopico. Come camere sono state scelte due webcam Logitech Pro4000 USB 2.0 con tecnologia a CCD. In Figura 13 si vede il modello wireframe dell’interno della testa, i due sistemi di visione sono stati montati su un meccanismo in grado di effettuare movimenti di tilt (rotazione sull’asse che le congiunge, Figura 14). I due elementi realizzano un’ architettura di visione stereoscopica a fuoco fisso, le rotazioni verso destra e sinistra non modificano l’angolo di convergenza dei due fuochi. Figura 12 Prima bozza della testa con oblò - 53 - Implementazione di una piattaforma per Embodied Agent Figura 13 Le due camere usb nel progetto Figura 14 Tilt Il supporto telescopico (Figura 15) è stato inserito per massimizzare la qualità del sistema di visione in quanto gli algoritmi di face detection e recognition sono tanto più accurati quanto più gli occhi osservano in modo normale il piano su cui giace il volto da analizzare. Il robot è in tutto alto circa 120 cm e grazie al supporto delle camere queste possono raggiungere l’altezza di 150 cm circa dal suolo. Quando non è attivato il sistema l’alloggio nella cupola permette di sfruttare un oblò, come si vede in Figura 12, che originariamente12 alloggiava il sistema radar. La visione stereoscopica permette di triangolare i punti nelle immagini rilevate e ricavare così una stima della profondità spaziale del pixel ed è l’unico tipo di operazione che richiede di elaborare due immagini alla volta. Figura 15 Telescopio Il flusso dati di questo sistema è alto, motivo per cui è stata scelta la banda di USB 2.0 e di lasciare quasi sgombra la scheda dedicata, un Pentium 4 a 3.06 GHz con 12 Ricordiamo che il termine originariamente fa riferimento alle funzionalità attribuite nella finzione cinematografica, e non ad una funzionalità realmente posseduta. - 54 - Il progetto R2D2 tecnologia HyperThreading. Questo elemento ha anche il controllo diretto sul motore della testa, che è in grado di compiere rotazioni verso destra e sinistra per un angolo complessivo di circa 240 gradi. 4.2.2 Audio La gestione dell’audio riguarda sia l’input che l’output del droide, come hardware si compone di due microfoni, una scheda audio SoundBlaster Audigy 2NX su USB 2.0 e sei casse. Il torso del droide è utilizzato come cassa di risonanza e le sei casse sono disposte a 60 gradi l’una dall’altra secondo lo schema in Figura 16. Figura 16 Disposizione degli altoparlanti I due microfoni sono alloggiati nella testa e costituiscono un sistema binaurale di acquisizione audio, cosa rilevante nel capire da dove provenga un suono. I padiglioni auricolari svolgono un ruolo importante, molti animali possiedono la capacità di orientarli e sfruttano così la percezione auditiva come strumento di localizzazione delle prede o dei predatori. 4.2.3 Self Sensing Questa parte raccoglie le informazioni sullo stato interno delle componenti del droide, ciò significa avere la percezione dell’assetto corrente, della configurazione del sistema di visione, livello delle batterie e accelerazioni subite. - 55 - Implementazione di una piattaforma per Embodied Agent Buona parte di questo sistema ha richiesto lo sviluppo di schede ed elettronica dedicata per interfacciare alcuni dei motori utilizzati ed i sensori con i PC tramite protocollo seriale. Figura 17 Prototipo del controllore Tilt e periscopio In Figura 17 si può vedere il prototipo realizzato per controllare i motori necessari al modulo di visione, per costruire questo (e gli altri componenti) sono stati utilizzati microprocessori PIC (Figura 18) che possono essere programmati con codice C che viene compilato per questo tipo di processori. Figura 18 PIC Micro Figura 19 Programmatore di PIC Oltre allo stato proveniente da componenti hardware vengono raccolte informazioni circa la condizione di carico dei sistemi software tramite i Performance counter, aggiungendo così dati relativi al carico dei sistemi operativi, della rete, dei processi, dei thread, della memoria e della macchina virtuale del Framework .NET. - 56 - Il progetto R2D2 Negli organismi esiste la percezione del proprio corpo e dei propri organi interni, di solito l’attenzione è più focalizzata sulla percezione della propria configurazione spaziale, di come gli arti sono disposti nello spazio. Al cervello arrivano anche impulsi nervosi dagli organi interni. Questo è l’aspetto che si vuole modellare attraverso la conoscenza di come i sistemi interni, hardware e software, sono disposti e di quale sia lo stato dell’ “organismo” di R2D2. Per le definizioni date, e per il modello a cui ci siamo ispirati, la percezione di sé è importante almeno quanto quella dell’ambiente, visto soprattutto che abbiamo detto che i Social Embodied Agent sono “embedded” cioè integrati nell’ambiente: percepirlo vuol dire percepire anche il proprio corpo. 4.2.4 Network La rete rappresenta per il droide parte del mondo, l’agente R2D2 è capace di attuare sia nel mondo reale che in quello virtuale. Usare servizi informatici fa parte della “manipolazione” che il robot sa compiere e i dati sulla presenza di rete e del suo stato sono percezioni che riceve dal “mondo esterno”. Il droide è dotato di una rete interna a 100 Mbps costruita con uno switch Advantech Adam 6521, l’utente si può collegare tramite una porta RJ45 ed R2D2 fornirà i servizi di gateway e DHCP. - 57 - Implementazione di una piattaforma per Embodied Agent Home Agent Trainer NWAgent MSN Messenger Adam Internal NetWork Gateway External NetWork Figura 20 R2D2 Networking Grazie ad un adattatore wireless il robot può accedere alle reti senza fili che incontra nell’ambiente in cui si muove. In assenza di reti lui stesso crea una rete senza fili “Ad Hoc” dotata di chiave WEP13. La connettività senza fili non è solamente un servizio che il robot può usare per completare i propri compiti, rappresenta anche un’importante informazione sensoriale e ricca di dati. Dal sistema è possibile individuare tutte le entità che pubblicano una rete, conoscerne il MAC Address, il nome, la modalità, la quantità di segnale. Tutte informazioni che possono concorrere alla caratterizzazione dell’ambiente e della posizione spaziale del droide. Quindi la rete costituisce di fatto un’estensione alla manipolazione ed alla percezione del robot; diversi lavori di ricerca nel settore della cibernetica sono rivolti proprio all’estensione sensoriale oltre quella “di dotazione” anche negli individui. 13 La chiave WEP viene utilizzata per crittografare i messaggi che vengono scambiati tra i nodi della rete wireless. - 58 - Il progetto R2D2 L’attuazione e la percezione sono i flussi di input/output che esponiamo, rappresentano la nostra interfaccia uomo-mondo e più avanti ritorneremo proprio sul problema dell’interfaccia Uomo-Macchina e Macchina-Uomo. 4.2.5 Motion Questo sottosistema è il più delicato di tutta la struttura, non in termini di complessità o di risorse richieste, ma dal punto di vista di sicurezza per il robot e per gli utenti. Il robot pesa complessivamente 85 Kg ed i motori montati possono spingerlo ad elevate velocità, rendendolo così potenzialmente pericoloso. Il blocco di gestione del moto è costituito da due motori passo passo (Figura 21) e schede di attuazione Mind S3 (Figura 22). Figura 21 Motori Passo Passo Le schede consentono di essere montate in cascata ed essere indirizzate a software, l’interfaccia nei confronti del PC è di tipo seriale RS232 e consente di scaricare istruzioni nella memoria della scheda o di inviare istruzioni dirette. Le schede sono costruite per l’utenza dell’automazione industriale e quindi portano nel proprio design una serie di caratteristiche dovute a criteri di sicurezza e risposta in tempo reale. La latenza di trasmissione di un comando tramite comunicazione seriale è circa 1.04 X (LC + LR) + 1.5 msec (dove LC è la lunghezza del comando in caratteri mentre LR quella della risposta) ed è per questo che il produttore non ha permesso di inviare direttamente i comandi di attuazione dei motori dal controllore alla scheda. - 59 - Implementazione di una piattaforma per Embodied Agent Quindi il modo di procedere è quello di produrre una sequenza di istruzioni per il Mind S3 (Figura 22), scaricarle ed inviare il comando di start, ovviamente tenendo conto della latenza che questo modo di procedere introduce. La scheda di controllo permette anche di inserire collegamenti hardware tra la sensoristica ed i motori, questo consentirebbe la reazione in tempo reale alle variazioni sensoriali. Figura 22 Controllori azionamento Mind S3 In questo modo è possibile modellare e costruire “l’arco riflesso”, cioè un meccanismo totalmente autonomo di reazione agli stimoli esterni, il meccanismo dei riflessi non è legato ad alcuna struttura di ragionamento, sono schemi di reazione simili agli schemi motori tranne che per il fatto che non è il cervello a sviluppare ed inviare il pacchetto motorio. Quindi si distinguono due sistemi e due tempi di reazione diversi, al di sopra della BodyMap (Figura 11) si sviluppa il “ragionamento” ed il tempo reale come requisito sfuma mentre più ci si avvicina alla struttura hardware maggiore diventa l’esigenza di reagire ed impartire comandi nel minor tempo possibile. 4.2.6 Skin Abbiamo già parlato dell’importanza sensoriale della pelle, sulla carrozzeria del robot sono integrati diversi sensori ad infrarosso per la percezione della distanza degli oggetti da sé, nella testa sono stati montati anche dei sensori ad ultrasuoni. - 60 - Il progetto R2D2 Diversificare i sensori è importante, sulla nostra pelle sono diversi i tipi di neurorecettori presenti, e la loro distribuzione non è uniforme (ma soprattutto non è uguale tra individui). Per poter interfacciare i sensori con il software sono state realizzate altre schede di controllo con microprocessori integrati, a differenza di quelle realizzate per il controllo dei motori è stato necessario risolvere il problema del rumore dei sensori. I sensori ad ultrasuoni emettono il loro segnale realizzando un cono in cui questo si diffonde e viene letto, disponendoli sulla testa in modo ravvicinato si creano conflitti dovuti alle interferenze tra gli emettitori ed i lettori. Per ovviare a tale problema i sensori ad ultrasuoni (Figura 24) sono stati montati su un bus controllato al PIC che è in grado di indirizzarli poiché i sensori sono digitali ed hanno la nozione di indirizzo. Il programma li tratta come indirizzi di memoria che, durante la lettura, vengono accesi, attivati e poi spenti. Con una politica simile realizziamo una scansione lungo l’arco su cui sono disposti e ne viene ricavata un’ informazione che costruisce una linea passante per i punti rilevati. I sensori di questo tipo (ma di qualità superiore) vengono impiegati per realizzare la “scansione a tempo di volo” un metodo con cui è possibile acquisire le informazioni di geometria anche per elementi molto grossi come strutture architettoniche. Figura 23 Scansione a tempo di volo in R2D2 - 61 - Implementazione di una piattaforma per Embodied Agent In Figura 23 si mostra l’idea e la limitazione della scansione a tempo di volo, il profilo davanti al droide è molto frastagliato ma la natura discreta del processo fa sì che sia percepito il profilo disegnato in nero, oltre questo i processi di scansione sono molto sensibili alla variazione dell’ambiente. Muovere il robot o la dinamicità dell’ambiente compromettono ulteriormente la precisione del profilo acquisito. Questo problema in realtà non affligge il nostro sistema, quello che viene percepito è l’avvicinamento di ostacoli lungo quelle sei direzioni marcante in rosso nella figura. Oltre agli ultrasuoni il droide possiede sensori ad infrarossi (Figura 25) e di luminosità che arricchiscono la percezione dell’ambiente. Anche se ultrasuoni ed infrarossi servono allo stesso scopo, cioè misurare distanze, la diversificazione nella natura del sensore è importante perché diversifica anche le debolezze, i sensori ad infrarossi sono estremamente sensibili alla presenza di superfici trasparenti e riflettenti (il sensore sfrutta i fenomeni dell’emissione luminosa) mentre i sensori ad ultrasuoni accusano la presenza di materiali fonoassorbenti (questi sono legati alla fenomenologia delle onde acustiche). Figura 24 Sensore luminosità ed ultrasuoni Figura 25 Sensore infrarossi In questo modo si può far fronte alla presenza di materiali problematici all’interno dell’ambiente, comunque sia i sensori descritti sopra non sono ad alta precisione per cui non ci interessa una misura esatta delle distanze ed una elevata tolleranza agli errori: a noi interessa la percezione dell’ambiente non la misurazione e quindi ciò che si vuole acquisire tramite i sensori è una stima delle variazioni che il droide e l’ambiente generano nel tempo. - 62 - Il progetto R2D2 4.2.7 BodyMap Cos’è la BodyMap? Letteralmente Mappa del Corpo e questo già fornisce un’idea di cosa si vuole rappresentare con questa componente. Nei capitoli precedenti si è introdotto il termine BodyImage relativamente alla classificazione degli agenti in base al coinvolgimento con l’ambiente ed il proprio corpo. Nel modello biologico di riferimento esiste una zona simile, in [LEC] Damasio mette in evidenza proprio questo fatto. Il cervelletto trova tutto l’insieme delle percezioni nella zona del tronco encefalico, là è rappresentato tutto lo stato del corpo : elementi propriocettivi ed esterocettivi. E’ un componente con elevata importanza fisica e logica per il nostro progetto, ha condizionato moltissimo il design dell’architettura software e di comunicazione del droide. Con l’introduzione di tale elemento diventa difficile catalogare in modo rigido l’architettura globale di R2D2, che comunque rimane di fatto un sistema multi agente gerarchico, distribuito e collaborativo. Di fatto la BodyMap rappresenta l’ambiente per gli agenti che costituiscono il sistema, ambiente di cui essi stessi fanno parte insieme a tutto il software, l’hardware, le percezioni ed i comandi che in essa vengono iniettati, oltre questo definisce il linguaggio comune degli agenti e quindi ne diventa di fatto mezzo di comunicazione. Non esistono, infatti, comunicazioni dirette tra le componenti se non quelle previste dalla gerarchia di basso livello (controllo assi – modulo di avoidance), tutti gli stimoli sono manifestati tramite la mappa del corpo (o l’immagine del corpo, come avevamo già incontrato). Qui vengono inviati i pacchetti motori che poi si trasformano in schema motori ed, in fine, sequenza di attuazioni e frequenze di passo. In questa ottica potremmo quindi definire il nostro sistema In-World. Probabilmente sarebbe più corretto e coerente col modello adottato parlare di “sistemi periferici” più che di agenti, come vedremo più avanti le comunicazioni non sono simmetriche nei confronti della BodyMap e del Brain, sono soggetti ad arbitraggio da parte dei livelli più alti. - 63 - Implementazione di una piattaforma per Embodied Agent 4.3 Base di conoscenza, simulazione, sogno e pianificazione Durante lo svolgersi di un sogno il cervello agisce reagendo alle situazioni che si presentano sviluppando l’attuazione (o a questo punto potremmo anche dire “proiettando l’intenzione di agire”) come durante il normale stato di veglia, il meccanismo che confina l’attuazione finale al solo mondo del sogno di fatto interrompe e filtra la propagazione del movimento fino alle terminazioni che produrrebbero il movimento reale. In caso di anomalie a questo meccanismo si osservano i fenomeni di sonnambulismo. Nel mondo onirico spesso le regole fisiche che conosciamo non sono poi così rispettate, ma lasciamo il mondo onirico perché quello che ci interessava era l’introduzione del fenomeno del sognare in sé. Sempre nel testo di Damasio si fa riferimento alla pianificazione ed alla valutazione di questa secondo un meccanismo simile a quello che abbiamo descritto per i sogni. Il tutto avverrebbe secondo un algoritmo di questo tipo: • Costruzione di un piano • Recupero dell’esperienza • Comprensione dello stato attuale • Simulazione secondo l’esperienza acquisita e lo stato corrente • “Valutazione” della previsione ottenuta. La misura della bontà del piano costruito è ottenuta tramite l’uso delle emozioni, componente talmente complessa da essere ben lontana dal possedere un modello scientifico ben definito. Di fatto però è proprio con le esperienze, le emozioni ed il dolore che l’essere umano affronta la problematica della pianificazione. Un punto molto interessante e spesso citato ritorna fuori nelle ultime righe: il tema della simulazione. Quindi gli esseri viventi sono in grado di costruire un modello abbastanza raffinato dell’ambiente? Indubbiamente sì, e pare proprio che tale modello si crei e venga perfezionato grazie all’esperienza che l’individuo accumula nel corso della propria esistenza, durante la quale compie continue sperimentazioni e correzione di misura e previsione. Ma in fondo cosa è l’esperienza di un - 64 - Il progetto R2D2 organismo se non la propria storia in termini di insieme di percezioni? Da ciò sembra che gli esseri viventi abbiano anche le caratteristiche degli agenti autobiografici, che dunque scrivano la propria storia come condensato di memorie sensoriali. Quali sono allora il modello e le regole che si imparano su tali basi? Cosa simuliamo durante la fase di costruzione dei piani di attuazione? Apprendiamo e simuliamo noi stessi, le correlazioni tra azioni e variazione di stato14, meccanismo che rimarca l’importanza del possedere un corpo composto di attuatori e sensori capaci di produrre un’immagine dell’ambiente esterno e di quello interno. Gli esseri umani aggiungono a questo tipo di conoscenza anche una serie di regole simboliche che rendono possibile il ragionamento e la correlazione di molte informazioni che, senza un’ adeguato supporto, risulterebbero difficilmente utilizzabili. 14 Per stato si intende l’insieme di tutte le percezioni che il corpo ci fornisce. - 65 - Implementazione di una piattaforma per Embodied Agent - 66 - Piattaforma ad agenti 5 Piattaforma ad agenti Adesso verrà trattata la piattaforma software realizzata con le tecnologie introdotte nel capitolo 3 e secondo il design del capitolo precedente. Da ora in avanti saranno trascurati gli aspetti hardware per evidenziare il modello logico e quello delle comunicazioni in atto tra le parti del sistema. Anche alcuni dei sistemi hardware producono direttamente nel loro PIC lo stesso protocollo dei sistemi software per cui vengono trattati allo stesso modo degli agenti software. 5.1 “Anatomia” del sistema software Brain BodyMap Agent 1 Agent 3 Nodo Agent 2 Agent 4 Agent K Thread Processo Figura 26 Anatomia del sistema software - 67 - Implementazione di una piattaforma per Embodied Agent In Figura 26 è illustrata l’anatomia del sistema software implementato per realizzare il modello descritto fino ad ora, con il termine nodo si intende una unità capace di calcolo come una delle schede PC o uno dei sistemi realizzati ad hoc. Occorre adesso introdurre le classi e gli elementi che costituiscono il framework con cui è stato costruito il modello illustrato in figura. In realtà esistono anche comunicazioni che vedono coinvolti solo agenti per modellare comportamenti reattivi. Analizzeremo di seguito le classi del framework, i loro ruoli ed i principi di comunicazione. 5.1.1 AgentBase Figura 27 AgentBase L’Agent Base (Figura 27) è la classe base per la costruzione di agenti da istanziare nel framework e vedremo come. Ogni agente possiede il proprio thread di esecuzione che viene avviato al momento della creazione, il nome dell’agente viene usato anche per etichettare il thread. Il metodo Run è quello che deve essere esteso con la logica da implementare mentre Exec (quello con cui viene costruito in ThreadStart che andrà in esecuzione) svolge il seguente ciclo: private void Exec() { int attempts = 50; while (attempts > 0) - 68 - Piattaforma ad agenti { try { this.Run(); Console.WriteLine("Exiting {0}", this.Name); } catch(Exception e) { SendState(new AgentException(e)); } System.Threading.Thread.Sleep(100); attempts--; } } SendState(new AgentDead()); Prima di terminare a causa di eccezioni vengono tentate 50 invocazioni del metodo Run e l’eccezione viene inviata al sistema centrale, nel caso si superino i tentativi previsti un messaggio notifica la morte dell’unità. Con tale meccanismo abbiamo voluto modellare la dinamica del dolore inteso come malfunzionamento del sistema periferico. Lo sviluppatore può quindi controllare l’invio di segnali di dolore verso la BodyMap e decidere l’eventuale politica di riattivazione del nodo. Tutta la comunicazione è fatta inviando strutture dati serializzate in XML, rimandiamo ai paragrafi successivi i dettagli che riguardano la scelta di XML ed il meccanismo della messaggistica, adesso osserviamo il metodo che si occupa dell’invio dei segnali (così abbiamo chiamato i messaggi scambiati nel framework) protected void SendState(AgentMessage msg, Type[] external) { msg.AgentID = this.ID; msg.Name = this.Name; AgentBroker.Dispatcher.SendState(msg, this, external); } protected void SendState(AgentMessage msg) { msg.AgentID = this.ID; msg.Name = this.Name; AgentBroker.Dispatcher.SendState(msg, this, null); } L’agente aggiunge così le informazioni circa il proprio nome ed il proprio ID al messaggio prima di inviarlo tramite il Dispatcher (descritto nel prossimo paragrafo), - 69 - Implementazione di una piattaforma per Embodied Agent vengono allegati eventuali metadati necessari per la gestione dei tipi utilizzati se non sono quelli contenuti nella base class ma definiti dall’utente. Il metodo seguente serve per la costruzione di canali di comunicazione diretta tra agenti senza passare per la BodyMap. protected void SendState(string friend, AgentMessage msg, Type[] external) { msg.AgentID = this.ID; msg.Name = this.Name; FriendInfo f = (FriendInfo)Friends[friend]; AgentBroker.Dispatcher.SendState(f.AgentID, f.BrokerHost, f.BrokerPort, msg, this, external); } Tale meccanismo è importante per modellare l’arco riflesso, il sistema di reazione istintiva per cui quando poggiamo una mano sopra superfici roventi la ritraiamo senza effettuare alcun ragionamento, questo perché esistono connessioni anche dirette tra alcune fibre muscolari ed alcuni percettori. Il campo Friends è un Hashtable che contiene oggetti di tipo FriendInfo con le informazioni necessarie per raggiungere gli agenti con cui esiste un legame diretto ed asimmetrico. L’asimmetria di tali comunicazioni è stata voluta per modellare in modo fedele la propagazione dei segnali elettrici all’interno del sistema nervoso. Nel Capitolo 7, dove illustreremo gli esperimenti condotti durante la progettazione dell’architettura, vedremo come tale astrazione ci ha permesso di semplificare il codice riguardante la reattività del robot utilizzato. Il metodo SendInterface svolge un ruolo fondamentale: comunica alla BodyMap l’interfaccia di ingresso e di uscita che l’agente espone in termini di messaggi. Al momento della prima comunicazione viene invocato questo metodo se non è presente nella BodyMap la descrizione dell’interfaccia posseduta. Questo permette di inviare segnali dal “cervello” al sistema periferico prelevando dalla BodyMap la struttura del messaggio che si vuole inviare all’agente e compilarne i campi con i valori che si vogliono usare. - 70 - Piattaforma ad agenti Grazie al meccanismo costruito per le eccezioni si può pensare ad approcci in cui i valori vengono provati fino a quando la cessazione del “dolore” permette di individuare valori accettati dal destinatario del messaggio. La definizione dell’interfaccia è ottenuta utilizzando i custm attribute e la reflection, rimandiamo ai paragrafi successivi per i dettagli che riguardano la struttura e la definizione dei messaggi. Il codice seguente riguarda la gestione dei segnali in ingresso e la sequenza di azioni che si sviluppa al momento della ricezione è la seguente: 1. DeliverSignal 2. OnSignal 3. Signal internal void DeliverSignal(XmlNode message) { if (Signals != null) Signals.Add(message); OnSignal(message); } In questo metodo il segnale viene immesso nell’ArrayList se questo esiste e poi viene invocata la OnSignal, la quale controlla solo se il delegate Signal ha sottoscrizioni ed eventualmente ne effettua l’invocazione (di seguito è riportato il codice) public event OnSignalHandler Signal; protected virtual void OnSignal(XmlNode message) { if (Signal != null) Signal(message); } Questa logica è stata utilizzata per esporre allo sviluppatore due modelli di gestione del segnale ricevuto. Si può effettuare la ridefinizione del metodo OnSignal introducendo nel suo corpo il codice necessario alla reazione o si può sfruttare il modello multicast dei delegate per scatenare l’esecuzione (anche asincrona) di più - 71 - Implementazione di una piattaforma per Embodied Agent gestori in contemporanea, semplicemente sottoscrivendo metodi (che ne rispettino la segnature) con il seguente meccanismo: AgentBase ag; Unit1 g1; Unit2 g2; … … ag.Signal += new OnSignalHandeler (g1.handler); ag.Signal += new OnSignalHandeler (g2.handler); Dove il metodo handler delle classi Unit1 e Unit2 rispetta la signature Void methodName(XmlNode message) 5.1.2 AgentBroker e MessageDispatcher Figura 28 AgentBroker e MessageManager Le classi AgentBroker e MessageManager (Figura 28) costituiscono un punto chiave per l’intera architettura: esse realizzano di fatto l’infrastruttura di comunicazione ed il meccanismo di gestione degli agenti. - 72 - Piattaforma ad agenti Nell’AgentBroker si fa molto uso di reflection e dei file di configurazione (elementi descritti nel Capitolo 3) per la creazione degli agenti e la gestione del servizio; alla sua creazione viene invocato il metodo seguente per inizializzare i parametri necessari: public static void UpdateSettings() { NameValueCollection netconfig = System.Configuration.ConfigurationSettings.GetConfig("Agents_Workspace /Network") as NameValueCollection; int port = 6666; string host = "localhost"; int localport = 6667; if (netconfig["Port"] != null) port = int.Parse(netconfig["Port"] as string); if (netconfig["LocalPort"] != null) localport = int.Parse(netconfig["LocalPort"] as string); if (netconfig["BodyMapHost"] != null) host = netconfig["BodyMapHost"] as string; Dispatcher = new MessageManager(localport, host, port); running = true; } if (Listener != null) Listener.Abort(); Listener = new Thread(new ThreadStart(MessageListener)); Listener.Name = "MessageListener"; Listener.Start(); Per prima cosa viene caricato il file di configurazione XML e recuperata la sezione contenente i parametri necessari per l’impostazione dei servizi di rete, una vola letti i valori di interesse viene istanziato il MessageManager (opportunamente settato) ed iniziata l’esecuzione del thread che si occuperà di gestire i messaggi in arrivo al broker. Il codice preposto a tale compito è il seguente: private static void MessageListener() { IPEndPoint ep = new IPEndPoint(IPAddress.Any, Dispatcher.localPort); UdpClient incoming = new UdpClient(Dispatcher.localPort); while (running) { byte[] data = incoming.Receive(ref ep); string xmldata = System.Text.Encoding.UTF8.GetString(data); if (xmldata == "") continue; XmlDocument doc = new XmlDocument(); doc.LoadXml(xmldata); if (doc.ChildNodes[1].Name == "MetaDataRequest") - 73 - Implementazione di una piattaforma per Embodied Agent { AgentBase ag = (AgentBase)RunningAgents[int.Parse(doc.SelectSingleNode("/*/AgentID"). InnerText)]; ag.SendInterface(); } else if (doc.ChildNodes[1].Name == "RestartAgent") { int id = int.Parse(doc.SelectSingleNode("/*/AgentID").InnerText); if (!((AgentBase)RunningAgents[id]).Thread.IsAlive) { AgentBase ag = (AgentBase)Activator.CreateInstance(RunningAgents[id].GetType()); ag.ID = id; RunningAgents[id] = ag; } } else { // deliver the message to the box or launch interrupt AgentBase ag = (AgentBase)RunningAgents[int.Parse(doc.SelectSingleNode("/*/AgentID"). InnerText)]; ag.DeliverSignal(doc.ChildNodes[1]); } } } Il ciclo prevede la lettura dal socket e l’estrazione del segnale ricevuto. I segnali (o messaggi) sono dati Xml e, una volta costruito il nodo, è possibile iniziare le operazioni di trattamento. Nel caso sia stata ricevuta dalla BodyMap la richiesta di interfaccia utilizziamo XPath per recuperare i dati necessari: il destinatario della richiesta. L’AgentBroker possiede una lista di tutti gli agenti in esecuzione nel proprio processo e passa quindi ad invocare il metodo SendInterface sull’agente interrogato dalla BodyMap. Nel caso si tratti della richiesta di far ripartire un agente (magari a seguito della notifica della terminazione, o morte, di questo) si procede all’identificazione del destinatario, si controlla che non sia già in esecuzione, ed eventualmente si procede con la riattivazione. - 74 - Piattaforma ad agenti Se il messaggio non è di nessuno dei tipi sopraccitati si procede inoltrandolo al destinatario, che se ne prenderà in carico la gestione, invocando su di esso il metodo DeliverSignal. Sempre tramite la configurazione caricata da file vengono reperite le informazioni necessarie alla creazione degli agenti che saranno in esecuzione nel processo controllato dall’AgentBroker, questo avviene all’invocazione del seguente metodo: public static void Start() { NameValueCollection agtconfig = System.Configuration.ConfigurationSettings.GetConfig("Agents_Workspace /Agents") as NameValueCollection; foreach (string key in agtconfig.Keys) { if (key.ToLower().StartsWith("agent") ) { string[] s = (agtconfig[key] as string).Split(','); AgentBase ag = (AgentBase)Activator.CreateInstance(s[1], s[0]).Unwrap(); ag.ID = RunningAgents.Add(ag); } } } Con le poche righe di codice che abbiamo riportato vengono create le istanze di tutti gli agenti indicati nella sezione apposita del file. La classe Activator utilizza il nome della classe (o tipo dell’agente) e dell’assembly in cui è contenuto per ricavarne un’istanza tramite la reflection. Vale la pena riportare un semplice file di configurazione per AgentBroker <?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <sectionGroup name="Agents_Workspace"> <section name="Agents" type="System.Configuration.NameValueSectionHandler"/> <section name="Network" type="System.Configuration.NameValueSectionHandler"/> </sectionGroup> </configSections> <Agents_Workspace> <Network> <add key="Port" value="6666"/> <add key="LocalPort" value="6667"/> <add key="BodyMapHost" value="localhost"/> - 75 - Implementazione di una piattaforma per Embodied Agent </Network> <Agents> <add key="Agent1" value="NetworkAgent.Wifi,NetworkAgent"/> <add key="Agent2" value="Node.NodeAgent,NodeAgent"/> </Agents> </Agents_Workspace> <appSettings> <add key="NodeAgent.MachineName" value="mordor" /> </appSettings> </configuration> L’applicazione che è necessario scrivere affinché l’AgentBroker sia costruito e tutta l’infrastruttura venga istanziata è costituita da tutto e solo il codice seguente: using System; using BrainMap; namespace AgentsContainer { public class AgentRunner { public static void Main(string[] args) { AgentBroker.Start(); } } } Il MessageDispatcher viene condiviso da tutti gli agenti contenuti nel processo ed è l’unico elemento ad avere il canale di comunicazione UDP tramite cui viaggiano i messaggi diretti alla BodyMap o verso altri agenti. Oltre la funzione di gestori dei canali di trasmissione le due classi che stiamo descrivendo compilano parte del protocollo inserendo informazioni importanti ai messaggi che viaggiano nel sistema lasciando al programmatore il solo compito di concentrarsi sui dati rilevanti che vuole scambiare con il resto dell’architettura, ma rimandiamo alla sezione seguente il dettaglio circa la messaggistica. - 76 - Piattaforma ad agenti 5.1.3 Messaggi, comunicazione e CustomAttribute Figura 29 Messaggi base In Figura 29 sono rappresentati i messaggi base offerti dall’architettura e la loro relazione. Tutti i messaggi, compresi quelli definiti dall’utente, estendono la classe AgentMessage che contiene informazioni basilari come: • Il Nome del Mittente • L’ID assegnata al mittente dal proprio AgentBroker • L’indirizzo IP del proprio AgentBroker • La porta del proprio AgentBroker • La categoria del messaggio La categoria di default è Data ed è impostata dal costruttore della classe, il programmatore che implementa i propri messaggi può specificarla scegliendone una tra le seguenti: - 77 - Implementazione di una piattaforma per Embodied Agent • Data • UrgentData • Problem • CriticalProblem • Exception Le altre informazioni vengono inserite dietro le quinte grazie alla collaborazione di AgentBase, AgentBroker e MessageManager. L’AgentBroker assegna l’ID all’agente e rende disponibili al MessageManager i dati riguardanti il proprio indirizzo e la propria porta, l’AgentBase compila la parte inerente il proprio nome ed il proprio ID dopodichè il MessageManager costruisce la rappresentazione XML del messaggio, la trasforma in Array di byte che viene inviato alla BodyMap tramite un socket UDP. Per i campi ID e Name occorre fare una precisazione: quando il messaggio viene inviato da un agente rappresenta le informazioni del mittente mentre, quando viene inviato dalla BodyMap o da un Friend l’ID rappresenta il destinatario mentre Name il mittente. Il sistema fornisce alcuni messaggi per segnalare la morte di un agente, la generazione di un eccezione e problemi generici. La classe per la notifica delle eccezioni viene utilizzata per la costruzione del ciclo Execute di AgentBase che abbiamo descritto nei paragrafi precedenti. Un ruolo particolare è ricoperto da i messaggi MetaDataRequest, FriendInfo e AgentInterface: questi costituiscono il cuore ed il supporto del protocollo, insieme agli attributi riportati in Figura 30. Per i dettagli sui tre messaggi appena citati rimandiamo al paragrafo che descrive la BodyMap, per adesso daremo dettagli sul significato dei custom attribute definiti. - 78 - Piattaforma ad agenti Figura 30 CustomAttribute definiti Gli attributi di Figura 30 sono dedicati alla decorazione delle classi e vengono usati per definire la lista dei tipi di messaggi accettati come Input e come Output, oltre ciò informano sulla necessità di costruire comunicazioni dirette verso i tipi usati come parametro di costruzione dell’attributo Friend. Da questi attributi vengono ricavati i dati necessari per la costruzione del messaggio AgentInterface. 5.1.4 BodyMap Figura 31 BodyMap La classe di Figura 31 è il punto cardine di tutto il sistema, è ciò che in primo luogo implementa il modello Embodied Agent dal punto di vista software. - 79 - Implementazione di una piattaforma per Embodied Agent Nei Capitoli precedenti abbiamo parlato spesso delle BodyImage, della loro importanza e del loro significato, abbiamo detto che queste “fotografie” sono reperibili in una “zona del corpo” che si occupa di contenere l’insieme delle percezioni e di inoltrare comandi di alto livello verso i sistemi periferici. La classe non può essere istanziata perché astratta, questa scelta di design costringe lo sviluppatore a dover estendere la classe base ed effettuare così l’implementazione del metodo OnSignal. Tale metodo viene invocato quando alla BodyMap arrivano segnali dal sistema periferico per gestirne la manipolazione, in realtà prima di invocarlo il sistema ha filtrato e manipolato i messaggi “di servizio”. Adesso possiamo descrivere completamente l’handshake che AgentBase, AgentBroker e BodyMap realizzano dietro le quinte per costruire la struttura di comunicazione ed i canali necessari. Nella descrizione di AgentBroker abbiamo detto che una volta invocato il metodo Start vengono costruiti tutti gli agenti che compaiono nel file di configurazione ed inizializzato tutti i parametri e gli oggetti necessari al setup della rete. Durante il proprio ciclo di esecuzione gli agenti inviano i propri segnali alla BodyMap15. Alla prima ricezione la BodyMap controlla se ne conosce l’interfaccia, ovvero l’insieme di messaggi che può inviare e ricevere tale agente, se l’esito di tale test è negativo allora viene preparata ed inviata la richiesta MetaDataRequest. Per riuscire a comporre ed inviare tale richiesta utilizziamo i dati presenti nel messaggio ricevuto per ricavare destinatario e broker responsabile della messaggistica. Il codice che realizza tale compito è il seguente: private void SendMetadataRequest(XmlDocument doc) { MetaDataRequest r = new MetaDataRequest(); r.AgentID = int.Parse(doc.SelectSingleNode("/*/AgentID").InnerText); r.Name = "BodyMap"; r.BrokerHost = doc.SelectSingleNode("/*/BrokerHost").InnerText; r.BrokerPort = int.Parse(doc.SelectSingleNode("/*/BrokerPort").InnerText); SendState(r); 15 Abbiamo visto che questo accade anche nel caso di eccezioni o di morte prematura a causa di errori. - 80 - Piattaforma ad agenti } Vediamo adesso il metodo Run: public void Run() { IPEndPoint ep = new IPEndPoint(IPAddress.Any, port); UdpClient incoming = new UdpClient(port); while (true) { byte[] data = incoming.Receive(ref ep); string xmldata = System.Text.Encoding.UTF8.GetString(data); XmlDocument doc = new XmlDocument(); doc.LoadXml(xmldata); string agentName = doc.ChildNodes[1].ChildNodes[0].InnerText; // Interface sent by some agent if (doc.ChildNodes[1].Name == "AgentInterface") { // Stores the interface into the appropriate map AgentsW[agentName] = doc; FriendsMap[agentName] = new ArrayList(); // Read friends foreach (XmlNode n in doc.SelectNodes("/*/Friends/*")) { string f = n.InnerText; ((ArrayList)FriendsMap[agentName]).Add(f); if (!InverseFriendsMap.ContainsKey(f)) InverseFriendsMap[f] = new ArrayList(); if (!((ArrayList)InverseFriendsMap[f]).Contains(agentName)) ((ArrayList)InverseFriendsMap[f]).Add(agentName); // Inform friends of the incoming agent //SendFriendInfo(f, agentName); // Do we want this? } if (InverseFriendsMap.ContainsKey(agentName)) foreach (string f in (ArrayList)InverseFriendsMap[agentName]) { // Inform agents registered as friends of the one sending the interface SendFriendInfo(f, agentName); } // Other message: store it into the message map. } else { AgentsR[agentName] = doc; // Notify the agent OnSignal(doc); if (!AgentsW.ContainsKey(agentName)) // Uh-oh, unknown agent! SendMetadataRequest(doc); } } - 81 - Implementazione di una piattaforma per Embodied Agent } In questo metodo viene ricevuto il messaggio dal socket e poi trasformato in documento xml per procedere alla manipolazione. Il primo test controlla se si è ricevuta la risposta ad un MetaDataRequest, se il test è positivo allora vengono estratte le informazioni circa i Friend memorizzandole in due tabelle pre rendere è possibile la relazione molti a molti. Le tabelle rappresentano le connessioni dirette tra agenti, analizzandole potremmo tracciare il grafo che rappresenta il “sistema nervoso” dell’architettura. Abbiamo visto che il canale di comunicazione su rete è gestito dagli AgentBroker e che per raggiungere un agente si deve conoscere l’indirizzo del broker e l’ID del destinatario. Queste informazioni sono centralizzate nella BodyMap che, al momento di costruzione dei rapporti diretti tra agenti, informa i sistemi periferici della locazione dei propri friend. Dopo aver immagazzinato i dati circa le connessioni dirette si passa a compilare un messaggio FriendInfo che viene spedito all’agente, quest’ultimo provvede ad immagazzinare tali informazioni che riutilizzerà al momento opportuno. Fatto questo si memorizza l’interfaccia dell’agente in una tabella hash AgentW nella posizione relativa all’agente. Nel caso di messaggi qualunque si procede alla registrazione del messaggio nella tabella AgentR prima di invocare il metodo OnSignal per passarne la gestione al codice definito dal programmatore (ricordiamo che è sempre così visto che non si può utilizzare mai la classe base BodyMap ma una sua specializzazione). Introducendo l’opportuna logica di programmazione all’interno del metodo OnSignal si posso costruire sistemi reattivi che trattano direttamente i messaggi che arrivano. Per illustrare il ruolo delle tabelle AgentR ed AgentW e del metodo PropagateSignal occorre ricordare che il nostro obiettivo è quello di modellare lo schema di Figura 26, in cui il Brain percepisce il mondo nella BodyMap ed invia tramite questa i comandi verso i blocchi periferici. - 82 - Piattaforma ad agenti Con un’opportuna manipolazione dei nodi XML contenuti in AgentR viene costruito l’albero XML che costituisce la BodyImage, una volta costituita tale struttura dati è possibile usare XPath per navigarlo fino a raggiungere gli elementi di interesse. Dopo aver costruito il piano di azione occorre impartire i comandi al sistema periferico. Questo è possibile ricavando da AgentW le interfacce di cui si ha bisogno, compilandone i campi secondo quanto deciso e invocare il metodo PropagateSignal per inviare i segnali all’interno del sistema. Un aspetto interessante del fatto di avere la BodyImage rappresentata come albero XML risiede nella possibilità di usare XSLT per trasformare il proprio stato, ad esempio se si effettua una potatura si può ”focalizzare l’attenzione” sui dati rilevanti ai fini del piano che si sta producendo, riducendo così la dimensione delle informazioni da manipolare. Oppure possiamo costruire sottoalberi che siano rappresentativi di un particolare stato o di un concetto. 5.1.5 NodeAgent Descriviamo adesso uno dei primi agenti sviluppati per evidenziare i vantaggi che il framework costruito ci offrono nella progettazione e nella realizzazione di elementi software. Il NodeAgent (Figura 32) non è un vero e proprio agente, è in realtà una unità percettiva che permette di recuperare informazioni circa lo stato del nodo hardware su cui è istanziato tramite l’uso dei Performance Counter (Capitolo 3). La classe estende AgentBase e contiene un componente che aggrega gli strumenti necessari per il reperimento di: • Numero totale di Thread attivi • Numero totale di processi in esecuzione • Carico CPU • Tempo di Idle • Stato dello Heap del .NET Framework • Bytes inviati tramite interfacce di rete • Bytes ricevuti tramite interfacce di rete - 83 - Implementazione di una piattaforma per Embodied Agent • Quantità totale di memoria disponibile • Numero totale di eccezioni lanciate Dati simili non hanno, in genere, un uso specifico ma riescono a modellare molto bene una snapshot del sistema: lo stato interiore. Per quanto riguarda il nostro progetto, infatti, non abbiamo pensato di usarli in modo diretto per effettuare pianificazioni o raggiungere il completamento di particolari task, semplicemente servono a corredare e rinforzare la “percezione di sé” (percezione interna o propriocettiva) di cui vogliamo sia dotato il robot per soddisfare i requisiti necessari alla modellazione di un Embodied Agent e che fino ad ora abbiamo tanto sottolineato. Figura 32 NodeAgent Il messaggio è costruito come mostra la Figura 33 e contiene un NodeState che aggrega le informazioni reperite tramite i Counter ed un Beat. - 84 - Piattaforma ad agenti Figura 33 Struttura Messaggio Una volta definiti i messaggi occorre utilizzare gli attributi per descrivere l’interfaccia dell’agente (in questo esempio l’interfaccia prevede solo messaggi di output) nel modo seguente: [OutputMessage(typeof(Message))] public class NodeAgent : AgentBase { internal CounterHolder Counters; public NodeAgent() : base("NodeAgent"){} protected override void Run() { Counters = new CounterHolder(); Message m = new Message(); m.state = new NodeState(); m.state.nodename = Counters.Processes.MachineName; while (true) { m.beat = new Beat(); m.state.threads = (int)(Counters.Threads.NextValue()); m.state.processes = (int)(Counters.Processes.NextValue()); m.state.freememory = (int)(Counters.MemoryAvaliable.NextValue()); m.state.cpu = Counters.TotalCPU.NextValue(); m.state.idle_cpu = Counters.Idle.NextValue(); m.state.paincount = (int)(Counters.Exceptions.NextValue()); m.state.heap = (int)(Counters.Heap.NextValue()); - 85 - Implementazione di una piattaforma per Embodied Agent m.state.sentbytes = (int)(Counters.SentBytes.NextValue()); m.state.receivedbytes = (int)(Counters.ReceivedBytes.NextValue()); SendState(m); System.Threading.Thread.Sleep(1000); } } } Come si può notare dalla dimensione del codice, la costruzione di nuovi componenti per l’architettura è estremamente semplice e si focalizza sui soli aspetti rilevanti, sollevando il programmatore dalla gestione delle comunicazioni e da eccessivi vincoli di design. Utilizzare i Custom Attribute solleva dalla necessità di un eccessivo numero di interfacce secondo il modello classico, soprattutto non è facile prevedere tutte le interfacce di cui si potrebbe aver bisogno negli sviluppi futuri e riuscire ad isolare un insieme minimale, altamente significativo. Nell’approccio che abbiamo seguito occorre solo una classe di base per i messaggi ed una per i nodi, il resto è esprimibile per il programmatore nella più ampia libertà. 5.2 Geni, Memi ed Evoluzione L’evoluzione delle specie secondo Darwin si realizza nel raggiungimento dell’organismo stabile, cioè che non necessita di ulteriori adattamenti per sopravvivere nell’ambiente. Questo processo si attua nella modifica della struttura genetica degli organismi, nella selezione di catene genetiche robuste. Di fatto è un processo che riguarda prevalentemente la componente “hardware” degli esseri viventi e la possibilità di modificare la propria configurazione in modo selettivo attraverso la combinazione degli elementi caratteristici della struttura genetica dei genitori. Nei primi capitoli abbiamo accennato ai sistemi Strongly Embodied come sistemi in grado di manifestare i comportamenti della riconfigurazione e della morte. Tali meccanismi, parlando da un punto di vista tecnologico, non sono al momento così a - 86 - Piattaforma ad agenti portata di mano. Forse le nuove ricerche nel campo delle nanomacchine e sulle strutture create da loro aggregazioni potranno arrivare alla modellazione degli esseri viventi partendo da un modello puramente cellulare. In [KER01] ed in [RD] si parla di “MEMI”, un termine ottenuto dal greco mimema, con il quale si intende modellare l’idea di “unità di trasmissione culturale o unità di imitazione”. A tale elemento è dato lo stesso ruolo delle unità genetiche : i geni. I memi vengono trasmessi tramite il meccanismo dell’imitazione e quindi fanno parte di tutti i sistemi di apprendimento che prevedano lo studio di un modello di riferimento. Il comportamento del singolo individuo è quindi frutto della concatenazione di memi vincenti, secondo una qualche metrica, a cui viene applicato un criterio di selezione simile a quello cui sono soggetti i geni che compongono il DNA degli organismi. In questo modello la cooperazione sociale assume un ruolo principe nella selezione dei memi e possiamo interpretare un piano di esecuzione elaborato per risolvere un task come una sequenza di memi. Questa, al momento, è l’unica evoluzione di cui possono essere capaci i robot: l’evoluzione comportamentale. Utilizzando ACS (Capitolo 3) si possono etichettare blocchi di codice da usare come elementi base per la costruzione dei comportamenti. Approntando un sistema metrico per valutare la bontà della sequenza di memi usati e CodeBricks si può realizzare un sistema in grado di evolvere manipolando sé stesso, manipolando il proprio codice. Abbiamo parlato della misura della distanza tra aspettativa e realtà come caratteristica fondamentale per gli Embodied Agent, alla luce delle ultime cose scritte potremmo ripensare all’importanza di essere In-World, di come un robot sociale abbia in sé tutte le caratteristiche per sfruttare in modo ottimale un meccanismo evolutivo, avere percezione di sé vuol dire anche poter concepire il proprio “miglioramento” imitando il modello di riferimento ed adattandolo alle proprie peculiarità hardware/software. - 87 - Implementazione di una piattaforma per Embodied Agent Grazie al meccanismo di imitazione ed evoluzione, il comportamento tenuto da un robot sociale può essere considerato frutto di un processo di sintesi anziché di una semplice ricombinazione degli elementi provenienti da un insieme chiuso di primitive. Ritornando un passo indietro possiamo comunque sostenere che la conoscenza della propria composizione di memi introduce un grande valore alla conoscenza di sé stessi: la conoscenza di come reagiamo. - 88 - Moduli ed Interfacce 6 Moduli ed Interfacce R2D2 nasce con una serie di funzionalità di base di cui non daremo in questa sede una trattazione dettagliata, ma ci limiteremo a darne un descrizione ai fini di comprendere meglio la struttura del lavoro intrapreso dal Medialab. 6.1 Moduli e componenti 6.1.1 Brain Il cervello è la parte chiave della componente “intelligente” del robot, nel nostro progetto tutto il lavoro fatto è necessario per costituire la piattaforma su cui poter “innestare” un intelligenza. L’unica connessione a disposizione del cervello è la BodyMap, attraverso questa vengono raccolte le percezioni e sviluppati i comandi impartiti dal sistema intelligente. Vista l’architettura della piattaforma resta di fatto un modello gerarchico a prescindere dal tipo di software prodotto per il controllo delle azioni. 6.1.2 Networking Il sistema di networking è costituito a sua volta da un insieme di programmi ed agenti che riprendono la struttura del livello più alto e la replicano anche se il linguaggio utilizzato a questo livello è più basso di quello usato tra la BodyMap e Brain. Qui si controllano tutti gli strumenti necessari per il servizio di connettività wireless. E’ qui che viene riconosciuto se la connettività rilevata è effettiva e permette così al droide di lavorare effettivamente o se ci si trova in presenza di una rete ad hoc o semplicemente non connessa ad internet o ai server di riferimento per R2D2. Per costruire il blocco di networking è stata usata l’infrastruttura realizzata per le connessioni a livello più alto e così anche questa sottoparte può essere distribuita su - 89 - Implementazione di una piattaforma per Embodied Agent più nodi (purché siano risolti i problemi che insorgerebbero alla presenza di più gateway). Il blocco più rilevante è il sistema per il controllo dei device 802.11b tramite un wrapper al driver NDIS (architettura per i driver di rete di windows) realizzato grazie all’uso del meccanismo di PInvoke e alla possibilità di usare i servizi di interoperabilità per definire il layout in memoria delle strutture costruite all’interno di programmi C#. Il droide al proprio interno ospita una rete a 100 Mbps e fornisce servizio di gateway e DHCP per il traffico dalla rete interna verso internet, se ci si collega alla presa RJ45 posta sulla parte frontale della carrozzeria si entra a far parte della rete privata e si può utilizzare i servizi per ottenere connettività, come se R2D2 fosse in definitiva un bridge wireless. 6.1.3 Audio Il sistema di gestione audio è stato costruito utilizzando DirectSound e ExoCortex,.DSP ha una struttura abbastanza complessa perchè questo sistema necessita di una serie di filtri che pretrattino il segnale prima di poter essere utilizzato. Questo blocco realizza un’interfaccia sia di input che di output per il sistema, in primo luogo l’output vocale viene prodotto utilizzando un motore di sintesi TTS (Text To Speech) ma sono già in preparazione degli approcci alternativi. Per quanto riguarda l’interfaccia di input sono principalmente due gli elementi che interessano il nostro progetto: • Identità vocale • Simboli sonori. 6.1.4 Vision Il blocco dedicato alla visione è indubbiamente uno tra i moduli più critici, processare immagini in tempo reale comporta una enorme mole di calcoli da svolgere. Vision ha a disposizione due webcam USB 2.0 montate su un sistema telescopico per poter raggiungere altezze come 150 cm dal suolo, cosa necessaria per l’affidabilità del sistema di riconoscimento facciale. Questa parte del sistema è stata quasi interamente sviluppata in C++ per motivi di prestazioni e realizza alcune delle funzionalità più - 90 - Moduli ed Interfacce interessanti come object detection, face detection, face recognition e features extraction. Questo blocco realizza di per sé un’architettura gerarchica ed espone alla BodyMap solo informazioni ad alto livello simbolico. In letteratura sono sempre più frequenti articoli su sistemi autonomi che fanno massiccio uso di image processing (o vision driven), non credo ci siano dubbi nel dare alla visione un ruolo sensoriale predominante visto il tipo di informazioni che può estrarre dall’ambiente. Grazie ad approcci di apprendimento automatico è possibile usare la visione per imparare a rilevare al presenza di determinati oggetti, sta poi al livello Brain associare un significato a quanto viene percepito. Per etichettare gli ambienti viene usato un approccio che estrae il colore medio dell’ambiente e cerca di disporre dei cerchi sull’immagine percepita allineandoli ad elementi come discontinuità, linee, angoli. Fondendo queste percezioni visive con le altre provenenti dal corpo il droide tenta di imparare a riconoscere dove si trova affidandosi ai propri sensi, sfida interessante per tentare di risolvere, almeno in parte, il problema del Kidnapping (rapimento) a cui gli automi sono soggetti se vengono spostati impedendo loro la percezione dello spostamento effettuato. 6.1.5 Obstacle Avoidance Questo modulo è stato scritto in C e compilato per Windows CE .NET 4.2 perchè questo tipo di funzionalità hanno bisogno di requisiti di tempo di calcolo stretti, anche per assicurare sicurezza e prontezza di “riflessi”. Il sistema di gestione del movimento usa una implementazione tratta da [fiorini], approccio denominato Velocity Obstacle, che permette di trattare ambienti con ostacoli sia statici che in movimento effettuando pianificazione on line. L’approccio descritto da Fiorini è molto interessante perché in realtà costruisce vere e proprie manovre di superamento ostacoli e può essere combinato con sistemi a base euristica per enfatizzare scopi da soddisfare durante lo spostamento e la gestione degli ostacoli. La pianificazione dei percorsi viene fatta a livello del modulo Brain e poi scritta nella BodyMap. Il modulo di Avoidance legge una sequenza di velocità (in - 91 - Implementazione di una piattaforma per Embodied Agent senso vettoriale) che il robot dovrà assumere durante il tempo. Quindi la codifica di un percorso è fatta costruendo una sequenza di punti e velocità lineari che, in caso di ostacoli non previsti viene modificata tentando di soddisfare l’obiettivo della missione intrapresa. Diciamo non previsti per intendere che alcuni ostacoli, sia statici che dinamici, saranno tenuti in considerazione direttamente dal pianificatore se sono talmente frequenti da poter essere collassati all’interno della memoria16 che si possiede dell’ambiente. 6.1.6 Home Agent L’home agent ha il ruolo di costituire, tramite la rete, un punto di riferimento per il droide e chi lo utilizza, a questo elemento il droide si rivolge e comunica l’indirizzo ip che utilizza muovendosi tra le reti wireless che incontra. Per motivi di sicurezza la parte che realizza il DNS dinamico accetta aggiornamenti di indirizzo solo se firmati con l’opportuno certificato, in modo da non compromettere l’inoltro dei pacchetti che riceve per conto del robot rischiando di inviarli ad un indirizzo che non corrisponde a quello corretto, magari a causa dellʹinvio di un indirizzo diverso da parte di qualche utente non ʺcertificatoʺ. In definitiva è una specie di proxy che ospita anche il servizio di messaggistica MSN Messenger[MSN] e che il droide usa tramite interfaccia di Remoting. Muovendosi il droide rischia di perdere la connettività o di cambiare rete: in queste situazioni tutti i servizi di rete esposti sarebbero soggetti ad errori e disconnessione. In presenza di home agent gli utenti non si accorgono dei momenti di black out della connessione perché questo bufferizza le comunicazioni e poi le inoltra a R2D2 appena diviene raggiungibile. 6.2 Interfacce Vale la pena fare una piccola discussione circa le interfacce uomo-macchina. Precedentemente abbiamo detto che un “PC con le ruote” non costituisce di per sé un 16 Si ricorda che per agenti come questo la memoria è costituita dall’esperienza fatta precedentemente. - 92 - Moduli ed Interfacce embodied agent e tanto meno un Robot sociale: tastiera, mouse e monitor non sono interfacce vantaggiose ed “ergonomiche” da usare in un conteso di mobilità ed autonomia. Fino a pochi anni fa si confondeva l’interfaccia grafica con l’interfaccia uomo-macchina, cosa sbagliata, la vera interfaccia, TASTIERA E MONITOR, non era cambiata passando dai display a caratteri ai display grafici. L’ HCI Interface è dunque prevalentemente hardware. La prima innovazione in questo senso l’ha attuata l’esplosione dei mouse (originariamente progettati dalla Xerox). Oltretutto per molto tempo il flusso di interfaccia è stato quasi monodirezionale, dall’uomo alla macchina; questa è stata per molto tempo in grado di produrre elementi grafici e suoni, senza la possibilità di instaurare un canale sensoriale completo, senza poter esprimere un feedback sensoriale adeguato. Lo studio di interfacce aptiche con ritorno di forza è stato di estremo interesse: avere un dispositivo che potesse produrre sensazioni di force feedback ha permesso di rendere più preciso l’uso di strumenti per telemedicina, la costruzione di simulatori per addestramento professionale ed innalzato la qualità dell’esperienza di gioco17. La Wacom ha introdotto sul mercato interfacce (o meglio sarebbe dire periferiche di interfaccia) in grado di utilizzare il PC per creazioni pittoriche con estremo controllo e feedback da parte dello strumento, una penna in grado di catturare tutta l’espressione che in generale gli artisti esprimo con gli strumenti classici del disegno. Per quanto detto circa il rapporto tra gli embodied agent e l’”ambiente”, il ruolo dell’interfaccia uomo macchina è fondamentale perché permette all’utente di entrare a far parte del mondo percepito dal robot in modo bidirezionale, il robot può dunque attuare e compiere azioni che vedano l’utente come oggetto da “manipolare”. Un fattore importante da considerare è dove si trovi l’hardware di interfaccia: se nel sistema stesso o sull’utente. I sistemi del primo tipo sono diffusi già adesso sul mercato (anche quello consumer) e spaziano da particolari Joystick a guanti più o meno evoluti, il wearable computing si 17 Buona parte delle accelerazioni nello sviluppo hardware è stato pilotato e finanziato negli anni dal mondo del videogame, se è possibile visualizzare in modo interattivo una TAC con PC di costo medio lo si deve probabilmente al Sig.PacMan più che alla ricerca scientifica. - 93 - Implementazione di una piattaforma per Embodied Agent basa proprio sul fatto che il sistema sia indossabile. Non è difficile trovare “monitor” che sposino questa filosofia: vengo chiamati spesso head mounted o glass mounted display. Una delle prossime novità sarà il display “lavabile e piegabile” di cui uno dei prototipi realizzati vede installato il monitor direttamente sul polsino delle camicie. Il fatto che i dispositivi di interfaccia risiedono su gli utenti non è uno scenario plausibile (almeno per ora) per un robot che agisca in un ambiente pubblico e con molte frequentazioni sporadiche e casuali. 6.2.1 Chat, e-mail ed Instant messaging Visto che il droide è in grado di utilizzare gli strumenti messi a disposizione dalla rete ci sembrava interessante dotarlo di interfaccia E-Mail e Instant Messaging. Il primo punto che ci siamo posti nel design di questo sistema è che gli utenti non devono aver bisogno di installare nuovi software per interagire col robot, devono invece percepirlo come parte della comunità on line. Il supporto E-Mail soddisfa questo requisito visto che ogni utente può usare il client di posta a cui è abituato e quindi è bastato costruire un interfaccia POP ed SMTP affinché R2D2 potesse ricevere ed inviare posta elettronica. Molto più interessante é il problema rappresentato dagli Instant Messages, elemento ormai parte integrante del modo di vivere comune che si manifesta principalmente in due forme: • Chat, Online Communities • SMS. E’ stato scelto il protocollo MSN9 per dotare di sistema di chat il droide, tale protocollo è quello implementato dai client Window ed MSN Messenger (Figura 34), consente di avere informazioni sullo stato dei contatti che sono nella lista, reperire informazioni circa gli utenti, inviare e riceve file, features molto interessanti che hanno portato all’implementazione del protocollo come componente di interfaccia del robot. - 94 - Moduli ed Interfacce Figura 34 Finestra di chat MSN Messenger Tramite il componente realizzato il droide è percepito dagli utenti come semplice membro della comunità MSN, così che basti il comune client, o qualunque delle versioni compatibili (come Trillian o AMessenger) per poter interagire via rete con R2D2, scambiare messaggi di testo, sapere se è on-line, inviare documenti che magari vogliamo recapiti per noi ad altri utenti. Nelle ultime versioni del client e del protocollo è possibile sfruttare gli strokes della tecnologia Ink, inviando così disegni e messaggi scritti a mano tramite gli appositi digitalizzatori. Per quanto riguarda l’utilizzo degli SMS sono stati implementati i comandi AT estesi per sfruttare i banali terminali GSM per inviare e ricevere i brevi messaggi di testo, elementi di utilizzo diffusissimo. Grazie alla dotazione di connessione e servizi Bluetooth il droide è in grado di usare in modo remoto i telefoni cellulari per svolgere questo tipo di comunicazione sfruttando la virtualizzazione del protocollo seriale, uno dei servizi di base esposto da tutti i device dotati di tecnologia Bluetooth. - 95 - Implementazione di una piattaforma per Embodied Agent 6.2.2 Ink Ink è la tecnologia che Microsoft utilizza nei Tablet PC per il trattamento dell’input da penna. I tratti eseguiti con le penne si chiamano strokes e possiamo dire che sono l’insieme dei punti tracciati durante lo spostamento del dispositivo sopra lo schermo. La libreria gestisce queste strutture dati anche ai fini di riconoscere la scrittura come testo o come gesto. Figura 35 Esempio di input da penna con tecnologia Ink La possibilità di utilizzare tale strumento di interfaccia permette di costruire un elevato numero di applicazioni basate su input da penna. L’utente potrebbe per esempio disegnare a mano libera il percorso che vuole sia eseguito da R2D2, o può anche inviare comandi scritti a penna che saranno riconosciuti o addirittura tentare di interpretare una serie di simboli o comportamenti (gesti) tenuti con la penna. Quindi gli utenti potrebbero utilizzare il Tablet PC anche per comunicare con il robot e richiedere i suoi servizi. - 96 - Moduli ed Interfacce 6.2.3 Gesture Il riconoscere le posture ed i movimenti è parte fondamentale della comunicazione umana che in tali elementi trova arricchimento o addirittura mezzo (comunicazioni primitive o linguaggio per audiolesi). Il TabletPC, Mind Manager X5[MMX] e myIE2[MIE] sono esempi di software che usano i gesti dell’utente per eseguire operazioni “associabili” al movimento compiuto, la gesture di scratch è spesso usata per effettuare rimozioni e cancellazioni, cosa molto intuitiva visto che il movimento da compiere assomiglia proprio alla cancellazione con la gomma. 6.2.4 Voice L’espressione vocale rappresenta una delle forme più complesse e ricche di espressione per gli esseri umani, la comunicazione verbale è indubbiamente una delle principali interfacce di cui disponiamo. Esistono in commercio molti sistemi di sintesi vocale a partire da testo (denominati motori TTS Text To Speech) prodotti da IBM,Microsoft e Dragon. Sono prodotti in grado di partire da un testo scritto e produrre output sonoro, molto particolare è il sistema costruito dalla Yamaha che è persino in grado di sintetizzare performance sonore. Esistono anche i loro simmetrici, cioè software in grado di produrre testo a partire da input vocale, molto utili come supporti per dettature. Utilizzando questo tipo di architetture si finisce però per scaricare il problema al campo del trattamento del linguaggio naturale. Un’alternativa a questo approccio è quella di trattare l’input vocale come stream di “simboli sonori”, tecnica usata dai sistemi a comando vocale. Il voice commander della Microsoft possiede un simbolo per ogni comando e quando un suono prodotto dall’utente assomiglia a quello fornito viene eseguita l’operazione associata. Il fatto che basta la “somiglianza” dei simboli in ingresso ha ripercussioni molto positive sulla performance del programma, cosa che sottolinea - 97 - il fatto che non sempre una Implementazione di una piattaforma per Embodied Agent computazione altamente precisa e rigorosa sia da preferire ad una soluzione approssimata e generalizzata. Dai simboli sonori è possibile ottenere due tipologie di caratteristiche: • Timbrica • Forma d’onda. Elementi sufficienti per estrarre informazioni di identità e struttura, grazie allo spettro del segnale si può riconoscere l’utente mentre la forma d’onda ne caratterizza il “simbolo”. La fase di sintesi che utilizza tali aspetti si chiama Wave Shaping, consiste nel prendere uno spettro ed utilizzarlo in modo congiunto con una forma d’onda per generare un simbolo da parte del Robot. Di fatto potremmo chiamare lo spettro usato “voce”. Oltre al wave shaping e’ possibile usare algoritmi di sintesi granulari per generare elementi con timbrica umana, come accade negli strumenti che producono suoni di “coro”. Nelle architetture di questo tipo non si fa quindi uso di regole grammaticali o di supporto linguistico per generare l’output sonoro, uno sviluppo di frasi articolate richiede un periodo di training molto lungo e paragonabile a quello che viene fatto nei primi anni di vita degli esseri umani. Per questo motivo abbiamo affiancato i due approcci, soprattutto nel flusso di uscita del sistema. Figura 36 Calibrazione del sistema audio con un clarinetto - 98 - Test 7 Test Al momento della scrittura di questa tesi i test sono stati effettuati prevalentemente su ER1 e sui singoli pezzi dell’architettura hardware di R2D2. Gli esperimenti qui riportati sono stati condotti durante lo sviluppo ed il design della piattaforma e mostrano l’evoluzione degli approcci utilizzati nel trattare problemi di navigazione, evidenziando così le trasformazioni introdotte nel modello rappresentato dal software. Durante tutto il periodo di sperimentazione non è mai stata variata la struttura fisica del robot che è quella in Figura 37. Figura 37 ER1 nella configurazione usata nei test 7.1 Simple Roaming Il primo test modella il sistema “programma di controllo in esecuzione su un robot”, l’obiettivo era quello di esplorare l’ambiente evitando gli ostacoli e marcando i problemi incontrati lungo il percorso per costruire un grafo con i punti che hanno - 99 - Implementazione di una piattaforma per Embodied Agent imposto un cambio di direzione. La localizzazione è stata ottenuta utilizzando il sistema di odometria fornito dal software di controllo proprietario. Principalmente il programma di controllo è composto da tre metodi: • • • SavePosition() ReadSensors() Move() Ora analizzeremo il codice dell’applicazione a partire dal metodo responsabile dello movimento. private void Move() { bool moving = false; while(work) { ReadSensors(); if(!moving) { robot.Move(100.0, RobotSRV.Units.meters, false); Saveposition(); moving = true; } if(central>soglia) { robot.Move((left > right) ? -90.0 : 90.0, RobotSRV.Units.degrees, true); moving = false; } else { int delta = left-right; if(Math.Max(left, right) > soglialr && Math.Abs(delta)>sogliad) { robot.Move(delta/5.0, RobotSRV.Units.degrees, true); moving = false; } } } } Il metodo ha il totale controllo sul robot, la guardia del ciclo while lo dimostra, esso viene eseguito per tutta la durata dell’operatività del robot che ogni volta che si ferma scrive la propria posizione. Osserviamo che il codice fa l’assunzione che il robot non riuscirà mai a fare 100 metri nel dipartimento senza dover effettuare alcuna correzione, - 100 - Test in caso contrario si fermerebbe; ciò non compromette l’esecuzione del task, rispecchia il fatto che il Dipartimento di informatica è uno spazio in cui ci sono individui che si muovono, cosa difficile da modellare, ma che produrrà un ovvio risultato: ER1 dovrà evitare la collisione. Modificare in modo non predicibile il percorso costringerà il programma di controllo a compiere ulteriori aggiustamenti se quelli precedenti rischiano di far urtare il robot contro elementi statici come le pareti, le porte ed i divani. La struttura del programma di controllo è a sussunzione tipica di un agente reattivo [Müller96, Brooks 85]: il ciclo principale legge il valore dei sensori e vari “moduli” (i rami dell’if) propongono un’azione che viene decisa in base alla loro “priorità” (l’ordinamento dei test nell’if). La strategia è semplice ma si è rivelata efficace: quando la lettura del sensore infrarosso centrale (Figura 38) supera la soglia prestabilita significa che un oggetto si sta avvicinando in modo frontale a noi e che la distanza è corta, questo implica dover cambiare in modo radicale la direzione di marcia verso la direzione più “libera”. Va detto che i sensori ad infrarosso generano un valore numerico intero compreso tra 0 e 100, dove 0 individua una lunga distanza (o fuori dalla portata del sensore) mentre un valore come 60 significa che un oggetto si trova a circa 30 cm di distanza. Figura 38 Distribuzione dei sensori e coni di percezione Se non ci sono problemi sulla percezione centrale allora il programma tenta di bilanciare le letture riportate dai sensori del lato destro e sinistro, in modo non esatto - 101 - Implementazione di una piattaforma per Embodied Agent ma con errore contenuto sotto una soglia imposta. Con questo accorgimento siamo riusciti ad ottenere ottimi comportamenti nei corridoi e nell’approccio alle porte aperte. Le manovre di aggiustamento impostano il valore false alla variabile moving, ciò fa scrivere la posizione in cui ci si trova e richiede l’esecuzione di uno successivo spostamento di 100 metri in direzione frontale, che come abbiamo visto è un modo di dire “vai avanti fino a nuovo ordine”. Questo metodo è eseguito come ciclo di un thread che termina al momento in cui la variabile work assume il valore false. La struttura del controllore segue il classico ciclo percezione-azione descritto in [RusNor95]. Questo è il codice del metodo invocato per la lettura dei sensori ad infrarosso: private void ReadSensors() { double alfa = (double)numericUpDown4.Value; central = (int)Math.Floor((alfa * robot.IrSensors(2)) + (1 alfa) * central); left = (int)Math.Floor((alfa * robot.IrSensors(3)) + (1 - alfa) * left); right = (int)Math.Floor((alfa * robot.IrSensors(1)) + (1 - alfa) * right); textBox1.Text = ""+left; textBox2.Text = ""+central; textBox3.Text = ""+right; } La variabile alfa serve per compensare l’instabilità dei sensori che compivano escursioni enormi e quindi rendevano impossibile un movimento fluido, allora l’aggiornamento delle variabili viene utilizzando la media esponenziale: n m(t ) =αt + ∑ (1 − α)i tn −i i =1 Con tale media a seconda del valore di alfa e di n si ottiene un valore più o meno influenzato dai valori precedenti, nel nostro caso n vale 1 e il valore di alfa è 0.55. In questo modo l’andamento delle letture dei sensori è molto ammorbidito e viene disturbato per variazioni molto ampie, cosa che non inficia il comportamento del sistema che è in grado di reagire a cambiamenti repentini dei valori dei tre sensori. - 102 - Test private void Saveposition() { double x; double y; double angle; robot.Position(out x, out y, out angle); PointF p = new PointF((float)x, (float)y); tw.WriteLine("{0}\t{1}\t{2}", DateTime.Now.Ticks, x, y); tw.Flush(); } Questo pezzo di codice serve per registrare le posizioni in cui è stato necessario cambiare direzione, i punti sono molti ma nelle zone di elevate densità ha senso eliminare i punti per sostituirli con il baricentro (Figura 39). Le soglie fanno scattare il meccanismo di stop senza fare distinzione tra elementi statici che fanno parte dell’architettura dell’ambiente ed elementi dinamici come le persone in movimento. Questo fatto non crea problemi perché basta avere un grafo di punti accessibili per le successive pianificazioni con approccio WayPoint Network. Utilizzare una rete di punti di navigazione vuol dire disporre di un grafo composto da punti raggiungibili e gli archi rappresentano la possibilità di passare da un nodo all’altro (in alcuni grafi si usano due archi per esprimere la possibilità di percorso bidirezionale), una volta eseguito un algoritmo di navigazione su grafi si ottiene l’albero dei cammini che congiungono la partenza e la destinazione. In alcune soluzioni non è interessante la lista degli archi da usare quanto la successione di locazioni da raggiungere: per rendere ancora più fluido e verosimile lo spostamento non occorre nemmeno passare precisamente su tutte le tappe previste, basta avvicinarsi. In questa ottica si possono usare modelli fisici come quello di campo elettrico e grazie ad una discesa di gradiente ottenere le sequenze di velocità da impostare sui motori. Alla luce di questo si può decidere che il fatto di aver tenuto un insieme di punti diversi da quelli raggiunti, o che in prima istanza sia impossibile decidere quali sono stati frutto dell’avvicinamento a pareti (od elementi statici) anziché l’interferenza con persone od oggetti che non occupano sempre quella locazione, non compromette il risultato finale. - 103 - Implementazione di una piattaforma per Embodied Agent Figura 39 Riduzione dei waypoint L’architettura dell’esperimento così strutturato è quella riportata in Figura 40 Control Program HAL Hardware Figura 40 Architettura del sistema Simple Roaming 7.2 NetTest1 In questo esperimento abbiamo utilizzato una prima versione dell’architettura proposta. La percezione è stata allargata includendo stato della batteria del portatile ed integrando nel sistema un NodeAgent ed il NetworkAgent. Lo scopo di questo esperimento è di esplorare il dipartimento registrando anche informazioni sulla condizione dell’infrastruttura di rete wireless percepibile. Non è più un semplice programma di controllo come nel test precedente, adesso viene utilizzata la BodyMap per la lettura delle percezioni avute. Durante lo sviluppo di questo test abbiamo fatto riferimento all’architettura proposta nel Capitolo 5. Il primo codice sviluppato per il controllo modellava in sostanza un’architettura a sussunzione che per un task così semplice, ma ben definito, - 104 - Test ha creato molti problemi nell’utilizzo delle risorse hardware, oltre a gravi conflitti dovuti alla concorrenza del modello. BodyMap/Brain MoveAgent SensorAgent HAL WifiAgent NDIS Figura 41 Struttura NetTest1 In Figura 41 è rappresentata l’architettura costruita per il nuovo esperimento. Uno dei maggiori problemi riscontrati è stato dovuto al sistema driver di ER1 che, oltre alla latenza di circa mezzo secondo introdotta dal layer basato su telnet, non ci pone nella condizione di avere una effettiva percezione del corpo. Molte informazioni sono state ottenute da pure previsioni basate sulla natura dell’azione che il robot intendeva intraprendere e questo, senza un’adeguata nozione di stato, non soddisfa i requisiti per la costruzione di un embodied agent. Durante la sperimentazione abbiamo misurato la latenza di trasmissione dei segnali fra agenti sullo stesso nodo ottenendo degli ottimi risultati: circa 10 msec considerando la serializzazione XML, la spedizione, la ricezione, la deserializzazione del nodo e le query XPath. Altra nota dolente circa il sistema della Evolution Robotics: l’odometria esposta risente di un accumulo di errore impressionante tanto da aver deformato in modo evidente il percorso seguito dal robot (Figura 42). - 105 - Implementazione di una piattaforma per Embodied Agent Figura 42 Deformazione dovuta ad errori sull'odometria Nonostante questi inconvenienti la “missione” è stata portata a compimento e la copertura WiFi del Dipartimento di Informatica è stata rilevata dal robot in fase di esplorazione. Il punto di partenza per l’esperimento è stato il Medialab ed è terminato di fronte la sala riunioni Est. Nel design scelto per questo sistema Brain e BodyMap sono fusi nello stesso oggetto e tutta la logica di gestione è effettuata nel seguente metodo: protected override void OnSignal(System.Xml.XmlDocument doc) { if (!AgentsW.ContainsKey("MoveAgent")) // Wait for the interface return; XmlDocument d = null; XmlNode n = null; if (doc.SelectSingleNode("/NetworkInfo") != null) { XmlNode r = doc.CreateNode(XmlNodeType.Element, "Position", null); XmlNode v = doc.CreateNode(XmlNodeType.Element, "X", null); v.InnerText = lastx.ToString(); r.AppendChild(v); v = doc.CreateNode(XmlNodeType.Element, "Y", null); v.InnerText = lasty.ToString(); r.AppendChild(v); doc.ChildNodes[1].AppendChild(r); log.WriteLine(doc.OuterXml); log.Flush(); } else if (doc.SelectSingleNode("/Sensor") != null) { central = (int)double.Parse(doc.SelectSingleNode("/*/Sensor2").InnerText); left = (int)double.Parse(doc.SelectSingleNode("/*/Sensor3").InnerText); right = (int)double.Parse(doc.SelectSingleNode("/*/Sensor1").InnerText); } - 106 - Test else if (doc.SelectSingleNode("/MotorState") != null && double.Parse(doc.SelectSingleNode("/MotorState/angularspeed").InnerTex t) == 0) { lastx = double.Parse(doc.SelectSingleNode("/MotorState/pos/x").InnerText); lasty = double.Parse(doc.SelectSingleNode("/MotorState/pos/y").InnerText); if (central > 60) { d = (XmlDocument)AgentsW["MoveAgent"]; n = d.SelectSingleNode("/*/InputMessages/anyType[@*='Move']").CloneNode(tr ue); n.SelectSingleNode("/amount").InnerText = ((left > right) ? -120.0 : 120.0).ToString(); n.SelectSingleNode("/rotate").InnerText = "true"; SendState(n); } else if(Math.Max(left, right) > 60 && Math.Abs(leftright)>30) { int delta = left-right; d = (XmlDocument)AgentsW["MoveAgent"]; n = d.SelectSingleNode("/*/InputMessages/anyType[@*='Move']").CloneNode(tr ue); n.SelectSingleNode("/amount").InnerText = (delta/5.0).ToString(); n.SelectSingleNode("/rotate").InnerText = "true"; SendState(n); } else if (double.Parse(doc.SelectSingleNode("/MotorState/angularspeed").InnerTe xt) < 1 && double.Parse(doc.SelectSingleNode("/MotorState/linearspeed").InnerText ) == 0) { SetSpeed(); d = (XmlDocument)AgentsW["MoveAgent"]; n = d.SelectSingleNode("/*/InputMessages/anyType[@*='Move']").CloneNode(tr ue); n.SelectSingleNode("/amount").InnerText = "10000"; n.SelectSingleNode("/rotate").InnerText = "false"; SendState(n); } } } Il metodo viene invocato all’arrivo di nuovi messaggi nella BodyMap e realizza la politica di gestione appropriata. Qui si effettuano le decisioni che riguardano i - 107 - Implementazione di una piattaforma per Embodied Agent movimenti, le variazioni di velocità e la scrittura dei valori percepiti tramite SensorAgent e WiFiAgent. La gestione delle velocità in proporzione alla lettura dei sensori ha reso ancora più efficace la reattività del robot, grazie anche al fatto di aver diviso completamente la gestione del moto (affidata al MoveAgent) dalla lettura dei sensori. Rispetto all’esperimento precedente il comportamento del robot durante l’esplorazione si è rivelato di gran lunga più robusto e sicuro, ma soprattutto adeguato alle condizioni ambientali percepite. 6000 5000 4000 3000 00:A0:C5:80:2A:97 00:A0:C5:67:FA:63 00:A0:C5:80:2A:82 00:40:05:C7:28:5E 2000 00:A0:C5:67:FA:59 00:40:96:38:D4:C5 00:A0:C5:67:FA:04 1000 00:A0:C5:80:2A:90 00:40:05:C7:28:45 Path 0 -5000 -4000 -3000 -2000 -1000 0 1000 2000 3000 -1000 -2000 -3000 Figura 43 Grafico Copertura Wireless La Figura 43 illustra la copertura di rete percepita durante lo spostamento lungo il corridoio del Dipartimento di Informatica, un’informazione che si è rivelata estremamente interessante. - 108 - Test Grazie alla conoscenza puntuale della qualità e dell’entità dell’infrastruttura di rete si può usare tale percezione per risolvere il problema del kidnapping (rapimento). Nel caso in cui il robot venga spento e trasportato in una qualunque zona del Dipartimento di Informatica (che è già stato esplorato e conosciuto)grazie al numero di access point visibili, al loro mac address e la potenza di segnale di ognuno di questi è possibile determinare (con ovvie approssimazioni) il luogo in cui si trova il robot. - 109 - Implementazione di una piattaforma per Embodied Agent 8 Conclusioni In questa tesi abbiamo presentato un’architettura software ed hardware che fornisce un corpo ad agenti embodied. La piattaforma è stata realizzata con lo scopo di essere un laboratorio per la sperimentazione. Le caratteristiche di tale modello abbiamo visto essere: • Possedere un corpo • Essere situato nel mondo. Gli agenti embodied fanno uso del corpo come elemento fondamentale del processo di conoscenza; come abbiamo avuto modo di vedere nel Capitolo 2 la simulazione è di scarso aiuto nella loro realizzazione. D’altronde la conoscenza che deriva dal possedere un corpo è direttamente collegata alla capacità percettive disponibili: in robot come ER1 il sistema di sensori fornisce informazioni veramente scarse sull’ambiente in cui è situato. R2D2 è stato quindi accuratamente progettato per supportare l’architettura software descritta nel Capitolo 5: la sua dimensione è dovuta alla volontà di supportare in modo adeguato il riconoscimento di volti; la carrozzeria garantisce stabilità nel posizionamento dei sensori per garantire una consistenza nelle letture; l’elettronica di controllo della sensoristica implementa lo stesso protocollo basato su XML e utilizzato dall’architettura ad agenti. L’architettura software che fornirà i servizi di base è stata implementata e verificata su ER1 in attesa che il robot vero e proprio sia completo. Le sue prestazioni si sono rivelate del tutto soddisfacenti su tale architettura che abbiamo visto soffrire di difetti decisamente rilevanti. Come visto nel Capitolo 7 la nostra soluzione si è rivelata vantaggiosa e performante. La struttura della libreria software si è inoltre dimostrata robusta e facilmente estensibile (ed anche parzialmente dichiarativa). Questa flessibilità è rilevante poiché riduce il tempo necessario per iniziare a sviluppare l’architettura e - 110 - Conclusioni consente di provare differenti soluzioni a tutti i livelli per la realizzazione del programma di controllo del Robot. Quanto descritto nel Capitolo 6 è in parte realizzato e sarà il cuore del sistema di interfaccia con l’uomo e l’ambiente. Una volta completata la struttura meccanica e testata l’adeguatezza del framework sviluppato potremo procedere alla costruzione di modelli di apprendimento ispirati a quanto scritto nel Capitolo 2. Tra i risultati ottenuti siamo rimasti estremamente soddisfatti delle prestazioni che il sistema presenta, dalla sua estendibilità estremamente semplice e libera da vincoli di ereditarietà e di implementazione stringenti grazie all’uso di Custom Attribute e manipolazione di strutture XML. In questo modo abbiamo potuto disegnare un framework costituito di poche classi (ma di ben chiara natura), flessibile e che, pur tentando di modellare un sistema complesso come quello umano, nasconde ed automatizza tutti i meccanismi necessari al proprio funzionamento, lasciando così allo sviluppatore il solo compito di concentrarsi sul proprio obiettivo anziché doversi addentrare in un dedalo di funzioni e servizi da conoscere e gestire. La costruzione del robot più ricco e complesso di quello utilizzato nei test sarà ultimata a breve (probabilmente prima della discussione di questa tesi) e sarà oggetto di nuovi esperimenti volti a confermare la validità dell’architettura software. - 111 - Implementazione di una piattaforma per Embodied Agent Appendice In questa sede vogliamo dare un po’ di informazioni circa lo stato ed i numeri del progetto, un qualcosa come i classici “dietro le quinte”. Il robot ha richiesto un anno di lavoro, la maggior parte del tempo è stata assorbita in modellazione dell’architettura e studio dei materiali. Complessivamente ha comportato una spesa complessiva di circa 37.000 euro escludendo il valore del lavoro di progettazione e di realizzazione del software. Sono state coinvolte molte persone durante l’anno di lavorazione ma quasi tutte per brevi periodi o consulenze: il vero e proprio gruppo di lavoro è stato costituito di 4 persone. Il robot pesa circa 85 Kg ed è capace di raggiungere velocità di circa 40 Km/h nonostante i motori siano stati ridotti di 10 volte. Per arrivare a completare il progetto sono state intraprese collaborazioni con il laboratorio Scalbatraio del Dipartimento di Ingegneria (grazie al Prof. Carcassi e l’Ing. Cerchiara, Figura 44) e con i laboratori di Fisica per la fotoincisione delle schede PCB. Figura 44 Trapanazione per alloggio sfere - 112 - Appendice Oltre questi partner hanno collaborato con noi per la costruzione di tutta la componente estetica e l’alloggiamento dei sensori la NuovaModellistica (Arzilli, Figura 45) e l’associazione modellistica IrBastione (Fossi e Mariotti). Figura 45 Parti di dettaglio realizzate da Arzilli A causa dell’enorme accoppiamento tra le componenti del sistema il lavoro di progettazione e realizzazione ha coinvolto il gruppo del Medialab in ogni aspetto poiché l’hardware doveva riflettere determinate esigenze di modello software e vice versa. - 113 - Implementazione di una piattaforma per Embodied Agent Durante lo sviluppo del sistema siamo stati aiutati da alcuni docenti nel definire algoritmi ed approcci. Il Prof. Francesco Romani ed il Prof. Leonello Tarabella hanno supportato Giorgio Ennas nel design del sistema audio. Daniele Picciaia si è fatto carico del sistema di visione ed ha interamente progettato e realizzato il sistema elettronico per la gestione dei motori e dei sensori. Diego Colombo si è dovuto occupare di affiancare la progettazione meccanica ed estetica del sistema, al momento è immerso nel lavoro manuale per completare la carrozzeria e l’ancoraggio dei sistemi di percezione. A tal proposito è d’obbligo sottolineare che: “Un ancorante per resine da imbarcazioni riesce a tirare senza problemi anche su vetroresine polieuretaniche e vetro polistirolo mantenendo un ottima flessibilità” Diego Colombo e Antonio Cisternino hanno di fatto costituito il progetto (anche dal punto di vista di reperimento fondi economici) e disegnato il modello di riferimento. Tuttavia, per quanto riguarda il gruppo del Medialab, non è possibile delineare il lavoro svolto da ogni singola persona a causa delle enormi correlazioni tra le parti (anche quelle hardware) del sistema. Siamo comunque spiacenti di dover dare la notizia che nel 2004 abbiamo perso la guerra della configurazione delle porte seriali in CE.NET 4.2, il fatto che sdrammatizza l’accaduto è che pare nessuno del team di Platform Builder di Microsoft sapesse cosa fare con le seriali: si apre un nuovo tema di ricerca “nacque prima il sistema operativo o il driver per la porta seriale?”. Questo problema ci ha costretto a muovere momentaneamente il modulo che gestisce i motori passo passo su uno dei nodi XP Tablet e ad utilizzare il nodo CE.NET come nodo di computazione, senza possibilità di output. Stiamo lavorando per risolvere questo problema insieme ad alcuni membri del gruppo di prodotto in Microsoft Corporation (Redmond). - 114 - Appendice Hanno reso possibile R2D2 Prof. Giuseppe Attardi Prof. Maria Simi Prof. Marco Carcassi Prof. Francesco Romani Letizia Petrellese Dott. Marco Combetto Hanno partecipato alla costruzione Dott. Antonio Cisternino Giorgio Ennas Daniele Picciaia Ing. Gennaro Maria Cerchiara Michele Rosellini Alessio Capperi Arzilli Alberto Giuseppe Ottaviano Maurizio Sambati Daniele Fossi Luca Mariotti - 115 - Implementazione di una piattaforma per Embodied Agent Bibliografia [KER01] Kerstin Dautenhan. Embodiment and Interaction in Socially Intelligent Life-Like Agent. [DOU] Douglas B. Lenat and R. V. Ghua. Building Large Knowledge-Based Systems, 1997 [ERI] Erich Prem. Epistemological aspects of embodied artificial intelligence, 1997 [NIC] Nick Jakobi. Running Across the Reality Gap: Octopod Locomotion Evolved in a Minimal Simulation. [MIC] Michael L. Anderson. Embodied Cognition: A field guide. [KER02] Kerstin Dautenhan. Embodied Cognition in Animals and Artifacts. [BAR] Barlett, F.C. Remembering – A study in experimental and social psychology. Cambridge University Press, 1932 [KER04] Kerstin Dautenhan, Ants don’t have friends- thoughts on socially intelligent agents, AAAI Press 1997 [CYN] Cynthia Breazeal. Emotion and sociable humanoid robots. [BRI] Brian R. Duffy and Gina Joue. Intelligent Robots: The Question of Embodiment [CLA] Clark A. Being There: Putting Brain, Body and World Together Again. MIT Press, 1997 [KER03] Kerstin Dautenhan. Getting to Know Each Other: Artificial Social Intelligence for Autonomous Robots, 1995 [RWM] R. W. Mitchell. A comparative-developmental approach to understanding imitation, 1987 [ACC] Attardi Giuseppe Cisternino Antonio Colombo Diego. CLI + MetaData > Executable, JOT 2003 [RD] Richard Dawkins. The Selfish Gene. Oxford University Press, 1976. [rem] .NET REMOTING, Microsoft Press [ER] http://www.evolution.com/ [LXM] http://www.lynxmotion.com/ [MSN] http://messenger.msn.com/ - 116 - Bibliografia [MMX] http://www.mindjet.com/eu/products/mindmanager_x5pro/mmx5pro.php [MIE] http://www.myie2.com/ [SML.NET] http://www.cl.cam.ac.uk/Research/TSG/SMLNET/ [IronPython] http://ironpython.com/ [RoboCup] http://www.robocup.org/ [RusNor95] S.J. Russel, Norvig P., Artificial Intelligence: A Modern Approach, Englewood Cliffs, NJ: Prentice Hall, 1995. [LEC] Damasio A., L’Errore di Cartesio. [OCV] http://www.intel.com/research/mrl/research/opencv/overview.htm [INT] http://www.intel.com [EXO] http://www.exocortex.org/dsp/ [DDX] http://www.microsoft.com/windows/directx/default.aspx [CLI] ECMA 335, Common Language Infrastructure (CLI), http://www.ecma.ch/ecma1/STAND/ecma-335.htm. [JVM] Lindholm, T., and Yellin, F., The Java™ Virtual Machine Specification, Second Edition, Addison-Wesley, 1999. [IL] Serge Lidin. Inside Microsoft IL Assembler, Microsoft Press [CS] ECMA 334, C# Language Specification, http://www.ecma.ch/ecma1/STAND/ecma334.htm. [MER]http://www.cs.mu.oz.au/research/mercury/information/dotnet/mercury_and_dotnet. html [SCH] http://www.cs.indiana.edu/~jgrinbla/ [PRL] Larry Wall, Tom Christiansen, Jon Orwant.Programming Perl, 3rd Edition 3rd Edition. O’ReillyJuly 2000 [CB] Cisternino, A., Multi-Stage and Meta-Programming Support in Strongly Typed Execution Engines, PhD Thesis, 2003, available at http://www.di.unipi.it/phd/tesi/tesi_2003/PhDthesis_Cisternino.ps.gz. - 117 - Implementazione di una piattaforma per Embodied Agent [CLR] http://msdn.microsoft.com/netframework/ [WSD] http://www.w3.org/TR/wsdl [SOA] http://www.w3.org/TR/soap/ [COR] http://www.corba.org/ [DCO] http://www.microsoft.com/com/tech/DCOM.asp [Rotor] http://msdn.microsoft.com/library/default.asp?url=/library/enus/dndotnet/html/mssharsourcecli2.asp [COC] http://cocotools.sscli.net/ [COM] Rogerson, D., Inside COM, Microsoft Press, Redmond, Wa, 1997. [CSN] http://www.csounds.com/ [Müller96] J.P. Müller, The Design of Intelligent Agents: A Layered Approach, 1996, LNAI sub series of LNCS, 1177, Berlin: Springer-Verlag. [Brooks85] R.A. Brooks, A Robust Control System for a Mobile Robot, A.I. Memo 864, Massachusetts Institute of Technology Artificial Intelligence Laboratory, 1985. [CIST] Cisternino A. Una proposta di un’architettura per la pianificazione in tempo reale. - 118 -