Implementazione di una piattaforma per Embodied

Transcript

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 -
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-
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-
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-
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-
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-
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-
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-
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-
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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
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 -
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 -
•
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 -
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 -
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"
</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 -
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 -
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 -
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 -
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 -
<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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
- 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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
- 66 -
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 -
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 -
{
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)
{
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 -
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)
{
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 -
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 -
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 -
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 -
{
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 -
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"
<section name="Network"
</sectionGroup>
</configSections>
<Agents_Workspace>
<Network>
<add key="Port" value="6666"/>
<add key="LocalPort" value="6667"/>
<add key="BodyMapHost" value="localhost"/>
- 75 -
</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 -
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 -
•
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 -
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 -
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 -
}
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 -
}
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 -
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 -
•
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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
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 -
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 -
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 -
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 -
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 =
right =
}
- 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;
n =
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();
n =
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 -
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 -
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 -
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 -
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 -
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 -
[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 -

Implementazione di una piattaforma per Embodied

Transcript

Documenti analoghi

Il tirocinio formativo in Accenture Technology Solutions è rivolto a

Io Robot - DivxMania

Campetella Robotic Center Srl

ANAPA-saluta-il-presidente-e-i-nuovi-vicepresidenti-di-ANIA-con

2016.02.10full

Visualizza PDF

Clicca qui per scaricare il Curriculm Vitae del professionista (file )

Comau industrial robot - LaDiSpe

WürthPhoenix neteye 2011 – 2012

Anglani/Minuto Rizzo - Associazione Antitrust Italiana

Comau Robotics per la scuola

Manuale d`istruzioni