Gestione dell'informazione per una rappresentazione concettuale del mondo

2 Introduzione
• I tempi di risposta del sistema devono mantenersi entro limiti molto
bassi in modo da poterlo utilizzare nei sistemi che operano in tempo
reale.
Per capire meglio i problemi connessi alla gestione di un modello concet-
tuale del mondo, abbiamo analizzato in dettaglio l’architettura di gestione di
robot autonomi prodotta dall’AIRLab (Artificial Intelligence And Robotics
Laboratory) del Politecnico di Milano.
Questa architettura è composta da diversi moduli, i più importanti sono
il modulo MAP, che si occupa di costruire la rappresentazione concettuale del
mondo, BRIAN, che utilizza questa rappresentazione per decidere le azioni
che il robot dovrà svolgere, e SCARE che si occupa della coordinazione.
Il modulo MAP definisce le strutture dati proprietà e concetto. Semplifi-
cando, una proprietà è una coppia nome-valore mentre un concetto è compo-
sto da un nome, un insieme di proprietà sostanziali, il cui valore è fissato e che
vengono usate per il processo di riconoscimento del concetto, e da un insie-
me di proprietà accidentali il cui valore può cambiare nel tempo. Il processo
che porta alla creazione della rappresentazione concettuale del mondo passa
attraverso tre fasi, per prima cosa c’è un processo di matching che produce
istanze di concetti partendo dai dati sensoriali (modulo TIGER), poi c’è una
fusione di questi concetti che elimina i duplicati e migliora l’identificazione
(modulo FUSION), infine c’è un processo di tracciamento temporale, che lega
i concetti percepiti attualmente con quelli passati (modulo TRACKING).
L’analisi di MAP e della struttura generale ha permesso di ricavare nel
dettaglio le modalità di accesso all’informazione, facendo emergere i problemi
da noi già individuati. Infatti si nota la mancanza di un sistema evoluto
di gestione del modello del mondo, che permetta ai moduli decisionali un
accesso semplice all’informazione tramite la valutazione di query e predicati.
Lo scopo di questa tesi consiste proprio nella definizione e nello sviluppo
di questo sistema, che abbiamo chiamato BASE (BASE Allows Symbolic
Environment).
1.2 BASE
BASE è un sistema software che si posiziona all’interno di un’architettura
di gestione di un agente robotico, e deve interagire principalmente con altri
sistemi che hanno esigenze diverse: un world modeller e i moduli decisionali.
Il sistema è sviluppato in modo indipendente dalle implementazioni dei mo-
duli con cui interagirà. L’informazione proveniente dal world modeller deve
essere inserita in BASE. Questo processo, che include anche l’eventuale tra-
sformazione dell’informazione in un formato diverso, ha dei vincoli per quan-
to riguarda le prestazioni, in quanto il world modeller produce un modello
del mondo aggiornato diverse decine di volte al secondo. I moduli decisiona-
li hanno la necessità primaria di estrarre informazioni e valutare predicati,
1.2 BASE 3
quindi è necessario definire un appropriato linguaggio di interrogazione, che
dovrà essere il più possibile semplice e potente. Un’altra funzione utile ai mo-
duli decisionali è avere a disposizione dei concetti non percepiti, cioè concetti
che non derivano dalle percezioni sensoriali elaborate dal world modeller, ma
che sono creati direttamente da BASE e gestiti in modo trasparente.
In base ai requisiti sono state analizzate diverse soluzioni, la migliore è
risultata quella di utilizzare una struttura dell’informazione e un linguaggio
di interrogazione derivati dal sistema CLIPS. L’informazione proveniente dal
world modeller viene trasformata in fatti e memorizzata in una base dei fatti.
Il linguaggio CLIPS è stato modificato per permettere l’interrogazione della
base dei fatti e la generazione di concetti non percepiti. Il funzionamento di
BASE è differente da quello di CLIPS, in quanto le caratteristiche richieste
sono diverse.
L’utilizzo di un sistema derivato da CLIPS permette di avere un lin-
guaggio semplice e potente, che permette la manipolazione di qualsiasi ti-
pologia di informazione, inoltre di solito è già noto a chi opera nel campo
dell’intelligenza artificiale e quindi risulta più semplice da utilizzare.
La progettazione di BASE è partita dalla definizione del linguaggio di
interrogazione, che rappresenta il metodo principale di interazione tra BASE
e gli altri moduli. La struttura delle classi di BASE vede la classe Base come
classe dominante, il cui metodo executeCommand() è utilizzato per eseguire
tutti i comandi scritti seguendo la sintassi del linguaggio di interrogazione
scritto in precedenza.
L’implementazione di base è sviluppata con un insieme di classi che se-
guono la struttura del linguaggio, la cui valutazione avviene attraverso algo-
ritmi in molti casi ricorsivi. É presente una classe BaseValue che permette
di rappresentare indifferentemente tutti i tipi di dati manipolabili da BASE,
siano essi valori numerici, stringhe o insiemi fuzzy.
A sistema ultimato è stato possibile valutare l’attinenza ai requisiti, in
particolare il linguaggio di interrogazione si è rivelato molto semplice e po-
tente. É stata effettuata anche un’accurata analisi delle prestazioni, che sono
un elemento chiave per il successo di BASE. Le performance sono risultate
molto buone anche quando si è trattato di valutare predicati piuttosto com-
plessi, rendendo BASE utilizzabile anche in sistemi real time. Il merito per
questi risultati è da ricercarsi anche nella serie di ottimizzazioni che sono
state implementate, come, ad esempio, un sistema di caching.
Abbiamo ipotizzato diversi possibili sviluppi futuri di BASE. Si potrebbe
ad esempio estendere il linguaggio al fine di inserire vincoli di coerenza sulle
percezioni, oppure definire dei predicati che si comportino come eccezioni,
cioè avvisino automaticamente i moduli decisionali quando vengono verifica-
ti. Proponendo sviluppi più impegnativi si potrebbe pensare alla creazione
di una memoria storica, modificando opportunamente il linguaggio in modo
da permettere interrogazioni sul passato. Similmente a come si rappresenta
il passato potrebbe essere possibile rappresentare anche il futuro, in modo
4 Introduzione
da ottenere le possibili conseguenze delle proprie azioni e costruire un albero
composto da basi dei fatti ipotetiche. Per fare ciò è necessario disporre di
un modulo che permetta di simulare il mondo fisico. Come ultimo e più az-
zardato sviluppo si potrebbe proporre l’apprendimento automatico di nuovi
concetti a partire dalle percezioni.
1.3 Contributi originali
Lo sviluppo di BASE permette di inserire all’interno dell’architettura di
controllo di un sistema robotico un ulteriore livello di astrazione delle in-
formazioni. Questo livello stabilisce un’indipendenza dei moduli funzionali
dal modulo di modellazione del mondo.
BASE è indipendente dal dominio applicativo ed è quindi utilizzabile
nelle più diverse applicazioni, adattandosi a gestire informazioni con strut-
tura eterogenea e a interagire con le diverse implementazioni del modello del
mondo.
Il linguaggio di BASE è semplice e nello stesso tempo potente, permet-
te sia l’estrazione di informazioni sia la valutazione di predicati (nonché la
definizione di concetti non percepiti), dando la possibilità di ragionare in
logica fuzzy e gestire l’incertezza delle percezioni. Tramite di esso i moduli
decisionali hanno un accesso completo al modello del mondo.
BASE permette di aumentare il livello di astrazione dell’informazione
tramite i concetti non percepiti. Ogni concetto non percepito è derivato da
un ragionamento su altri concetti, siano essi percepiti o no. Questa struttura
permette di definire concetti non percepiti con un sempre più alto livello di
astrazione.
Infine le prestazioni di BASE lo rendono realisticamente utilizzabile in
sistemi robotici, che nella pratica operano in tempo reale.
1.4 La struttura della tesi
La tesi è strutturata nel seguente modo. Nel capitolo 2 si illustra un’intro-
duzione al problema della rappresentazione concettuale del mondo e vengono
presentate le principali soluzioni che sono state proposte storicamente. Nel
capitolo 3 si approfondisce nel dettaglio un’architettura di gestione di un
agente robotico, cioè il sistema software sviluppato dall’AIRLab (Artificial
Intelligence And Robotics Laboratory) del Politecnico di Milano, e si valu-
tano problemi e carenze. Nel capitolo 4 si esplicitano i requisiti, si presenta
la struttura generale e si ricavano le specifiche per BASE. Nel capitolo 5 si
descrive lo sviluppo di BASE partendo dalla struttura generale del sistema e
scendendo poi nel dettaglio implementativo dei vari componenti. Nel capito-
lo 6 si da una valutazione del sistema in termini di funzionalità e prestazioni.
1.4 La struttura della tesi 5
Nel capitolo 7 si traggono le conclusioni e si propongono idee per possibili
sviluppi futuri.
Nell’appendice A si presenta il progetto RoboCup, utilizzato spesso come
dominio di esempio. Nell’appendice B si approfondisce il processo di creazio-
ne del modello del mondo. Nell’appendice C si riporta la RFC2234 che defi-
nisce la notazione ABNF, utilizzata per descrivere la sintassi del linguaggio
di interrogazione utilizzato in BASE.
Capitolo 2
La rappresentazione
concettuale del mondo
Per rappresentazione concettuale del mondo di un agente si intende una serie
di strutture dati e di meccanismi che servono per tradurre le osservazioni del
mondo effettuate dal robot in un modello da utilizzare per la pianificazione
dei comportamenti. In questo capitolo cercheremo di dare una definizione
di modello del mondo, elencando quali caratteristiche dovrebbe avere, do-
podiché introdurremo i mattoni che sono alla base del modello concettuale,
ovvero i concetti. Durante la discussione di questi argomenti, metteremo in
evidenza i problemi legati alla gestione del modello del mondo e analizzeremo
in modo critico le soluzioni esistenti attualmente.
Nel paragrafo 2.1 daremo una definizione di modello del mondo, spieghe-
remo dove esso sia collocato all’interno dell’architettura software dei robot,
introdurremo i concetti e faremo una breve panoramica sulla gestione del
modello nei sistemi multi agente. Nel paragrafo 2.2 faremo una panoramica
sulla struttura informativa dei robot, prenderemo in rassegna alcune soluzio-
ni adottate per costruire il modello del mondo, esamineremo le architetture
software utilizzate e introdurremo il problema dell’incertezza. Nel paragrafo
2.3 vedremo più da vicino le problematiche legate alla gestione dell’informa-
zione e cercheremo di inquadrare bene la collocazione di questo lavoro nel-
l’ambito di un sistema robotico. Infine, nel paragrafo 2.4 trarremo le somme
enunciando le nostre scelte progettuali.
2.1 Il modello del mondo
2.1.1 Definizione
La prima cosa da fare quando si parla di modello del mondo è quella di
darne una definizione. Cos’è un modello del mondo? Quali requisiti deve
soddisfare per poter essere ritenuto un buon modello del mondo? Un inte-
8 La rappresentazione concettuale del mondo
ressante spunto per una definizione viene dato dal SINGIST [36]. A questa
definizione si perviene prendendo in considerazione ciò che distingue gli es-
seri intelligenti dagli altri: “L’intelligenza è un vantaggio evolutivo perché ci
rende in grado di modellare, predire e manipolare la realtà”. I modelli, dun-
que, sono utili nel momento in cui corrispondono alla realtà. Più avanti in
questo stesso capitolo, le parole “modellare”, “predire” e “manipolare” saran-
no trattate con maggiore dettaglio e si vedrà come queste tre azioni possano
(e debbano) essere inserite in un robot affinché i suoi comportamenti possa-
no realmente definirsi intelligenti. Prima di ciò, è però necessario chiarire in
che senso ci deve essere corrispondenza tra modello e realtà. Esistono vari
livelli di corrispondenza, elenchiamo di seguito i quattro da noi ritenuti più
significativi:
• Corrispondenza sensoriale: si ha quando c’è corrispondenza tra la strut-
tura dati del modello e le caratteristiche del mondo esterno. Ad esem-
pio, se nel modello del mondo esiste un oggetto, la cui posizione è de-
scritta da una coppia di coordinate, ci deve essere corrispondenza tra
il valore delle coordinate e la posizione dell’oggetto istante per istante.
• Corrispondenza predittiva: si ha quando il modello può essere utilizzato
per generare predizioni corrette sui futuri input dei sensori. Si dice che
c’è corrispondenza predittiva quando le predizioni corrispondono alla
realtà.
• Corrispondenza decisionale: si ha quando il modello è in grado di pre-
dire gli effetti di diverse possibili azioni sul mondo esterno, selezio-
nando quale azione dà luogo al miglior risultato (in base a qualche
criterio). Questo tipo di corrispondenza implica che il modello abbia la
possibilità di compiere azioni e di definire degli obiettivi.
• Corrispondenza manipolativa: si ha quando è possibile ipotizzare un
futuro e pianificare una sequenza di operazioni che portino a quel futu-
ro. Quindi, dato un futuro “desiderabile”, deve essere possibile costruire
una sequenza di azioni che portano il modello in corrispondenza con
quel futuro.
Ciascuno di questi tipi di corrispondenza svolge un ruolo importante e costi-
tuisce una condizione necessaria perché il modello del mondo sia completo e
possa dar luogo a comportamenti intelligenti nel robot.
Dopo aver chiarito questi punti, possiamo quindi definire un modello del
mondo come una qualunque struttura (dati e funzioni) atta a rappresentare
il mondo la quale possa essere messa in corrispondenza con esso nei sensi di
cui sopra. La bontà del modello stesso dipende dal grado di corrispondenza
raggiunto per ciascun tipo.
2.1 Il modello del mondo 9
2.1.2 Collocazione e funzionalità
Una volta definito il modello del modo possiamo domandarci quali sono le
funzionalità che deve avere e dove deve essere collocato, cioè come deve
interagire con i vari moduli funzionali dei robot.
Il modello del mondo si trova al servizio dei moduli decisionali e strategici
dai quali riceve le direttive e ai quali invia le informazioni sullo stato del
mondo. Il modello del mondo, inoltre, comunica con il sistema di sensori e
di attuatori (o con delle opportune interfacce di basso livello) per ricevere le
informazioni sul mondo esterno (che deve poi modellare) e convertire le azioni
dei moduli strategici in azioni di basso livello da trasmettere agli attuatori.
I moduli superiori accedono al modello del mondo tramite un’opportuna
interfaccia la quale potrà fornire una serie di funzioni, tra cui:
• Interrogazione: i moduli di livello superiore (decisionale e strategico)
potrebbero essere (e in genere sono) interessati a sapere se un dato
oggetto è presente o meno nel mondo, o se una certa situazione si è ve-
rificata. Ad esempio, un robot che deve raggiungere una meta potrebbe
voler sapere se un oggetto gli ostacola la strada e interrogare il model-
lo a tal proposito. Un buon modello deve poter fare anche di meglio:
esso deve saper fornire ai moduli superiori direttamente il concetto di
“ostacolo”1, aggiornandone il significato automaticamente in funzione
della configurazione del mondo reale.
• Definizione: spesso i moduli superiori hanno necessità di creare dei
concetti che non possono essere dedotti tramite mera osservazione del-
l’ambiente. Ad esempio, i moduli strategici di un robot che gioca a
calcio possono ritenere che una particolare configurazione dei giocatori
rappresenti un pericolo per la propria squadra. Questa informazione
non può essere in alcun modo dedotta osservando semplicemente il
mondo esterno, quindi è necessario che il modello del mondo crei un
concetto sulla base delle informazioni passategli dai moduli superiori.
• Previsione: dev’essere possibile effettuare delle interrogazioni al mo-
dello del mondo riguardanti situazioni future. Il modello, grazie alla
corrispondenza predittiva, deve essere in grado di fornire previsioni
attendibili circa l’evoluzione del mondo.
• Test : Un buon modello del mondo deve poter fornire le primitive per
effettuare dei test sull’ambiente. i test sono utili nei casi in cui sia
necessario pianificare un’azione scegliendola tra diverse disponibili. Il
modello deve essere in grado di evolvere in simulazione, consentendo
ai moduli strategici di valutare i presunti effetti di varie azioni.
1Si tratta di un cosiddetto “concetto non percepito”, che verrà approfondito in seguito.
10 La rappresentazione concettuale del mondo
Per poter svolgere tutte queste funzioni, il modello del mondo dovrà rispet-
tare alcune specifiche, che indichiamo in maniera informale.
• Linguaggio di comunicazione: questo è il requisito base che deve esse-
re soddisfatto da ciascun modello del mondo. Se un modulo superiore
deve poter interrogare il modello, esso deve quanto meno fornire all’in-
terfaccia un opportuno linguaggio di comunicazione, che permetta un
accesso alle informazioni presenti nel modello stesso.
• Trasparenza: L’utente non deve necessariamente essere a conoscenza
dei dettagli implementativi del modello ma interfacciarsi a esso solo
tramite il linguaggio (anche se non si esclude che una conoscenza della
struttura interna possa essere sfruttata per ottimizzare le richieste).
• Sicurezza: Non deve essere possibile modificare il modello del mondo
se non utilizzando le primitive fornite dal sistema.
• Potenza: Il linguaggio non deve essere troppo semplice altrimenti non
sarà possibile fare interrogazioni di una certa complessità sul sistema
per elaborare delle strategie e nemmeno generare concetti non percepiti
(questo punto verrà approfondito in seguito).
• Velocità: La velocità è un requisito fondamentale se si vuole che il mo-
dello del mondo venga usato da sistemi che operano in tempo reale,
come ad esempio i robot che operano in ambienti dinamici. Conside-
rando l’attuale potenza dei processori che possono essere installati sui
robot e che parte di questa potenza viene utilizzata per altre operazioni
all’interno del robot stesso, i tempi per la valutazione di un’interroga-
zione devono mantenersi sotto il centesimo di secondo, possibilmente
nell’ordine di pochi millisecondi.
• Meccanismo di attenzione: può essere utile dotare il modello di un
meccanismo di attenzione, che sollevi i moduli sovrastanti dall’onere
di richiedere informazioni con troppa frequenza. Il modulo superiore,
semplicemente, potrebbe richiedere che gli venga inviato un segnale se
si verifica una certa condizione. Questo stesso meccanismo, potrebbe
anche essere usato in maniera inversa: il modello del mondo, in base
a qualche criterio, potrebbe decidere che un evento è significativo e
segnalarlo ai moduli superiori in maniera autonoma, senza che vi sia
stata una richiesta esplicita.
• Modalità simulata: un altro requisito opzionale ma molto interessante
potrebbe essere quello di una modalità simulata, che premetta di valu-
tare i possibili esiti di un’azione, permettendo così una pianificazione
strategica efficace.
2.1 Il modello del mondo 11
2.1.3 Concetti
Nei paragrafi precedenti abbiamo introdotto e usato con una certa disin-
voltura i termini “concetto” e “concetto non percepito”, senza però darne
una definizione formale. Tuttavia, per avere un panorama completo delle
problematiche legate alla gestione dell’informazione, occorre quanto meno
spiegare meglio cosa significano queste parole e che ruolo rivestono i concetti
all’interno dei robot.
I concetti sono delle entità utilizzate dal robot per rappresentare carat-
teristiche del mondo, siano esse oggetti fisici o no. Il modello del mondo
è dunque popolato dai concetti, i quali possono essere di vario genere, dai
più concreti ai più astratti. Alcuni concetti presenti nel modello del mondo
possono essere: “Albero”, che indica l’esistenza di un albero nel mondo (le
proprietà quali posizione, dimensioni etc potranno essere ricavate interro-
gando il modello stesso), “Palla”, “Casa”, ma anche entità più astratte tipo
“Pericolo”, “Avversario”, “Duemilacinquecentouno”.
Per poter generare dei concetti è necessario avere alla base un meccanismo
composto da diversi moduli, hardware e software, che si occupano di leggere
le informazioni dal mondo esterno, filtrarle, catalogarle e infine tradurle in
concetti. Tutta questa serie di processi è di sicuro molto interessante e degna
di attenzioni, tuttavia non è scopo di questo documento approfondire troppo
le problematiche legate a questa fase. Qualche dettaglio in più, corredato da
interessanti spunti, si può trovare in appendice B (pag. 139).
Esiste tuttavia una categoria di concetti che non sono associabili diretta-
mente a delle percezioni sensoriali, pur essendo di indubbia utilità. Facciamo
l’esempio di un robot che deve muoversi in un ambiente ostile. Oltre ai con-
cetti che descrivono le mere percezioni sensoriali, potrebbe essere di grande
utilità per i moduli decisionali un concetto del tipo “situazione di perico-
lo”. Questo concetto può essere inserito in un modello del mondo, in quanto
una situazione pericolosa altro non è che una particolare configurazione del
mondo esterno che compromette l’integrità del robot stesso, ma d’altro can-
to non può essere associato direttamente a nessuna percezione sensoriale,
bensì deriva da diverse percezioni valutate in maniera opportuna. Inoltre, il
concetto “Situazione di pericolo”, come molti altri, ad esempio: “Avversario
in vantaggio”, “Missione compiuta”, hanno senso solo se immersi nel domi-
nio applicativo. In altri termini, pur conoscendo tutti gli input dei sensori,
nessuno sarebbe in grado di generare il concetto “Situazione di pericolo” se
non conoscesse il dominio applicativo, perché il significato del concetto varia
a seconda della situazione. Tutti questi concetti, pur non avendo nulla di
diverso dal punto di vista del modello dai concetti più “semplici”, per via
della loro particolare natura vengono chiamati concetti non percepiti.
12 La rappresentazione concettuale del mondo
Collocazione dei concetti non percepiti
Poco fa, abbiamo asserito che i concetti non percepiti possono essere inseriti
in un modello del mondo. Abbiamo però fatto questa asserzione in maniera
volutamente subdola, solo per introdurre il discorso, ma ora quest’afferma-
zione merita di essere approfondita. La domanda è: “i concetti non percepiti
fanno parte del modello del mondo?”. Per poter rispondere a questa domanda
bisogna chiedersi cos’è un modello del mondo. La definizione data nel para-
grafo 2.1.1 (pag. 7) è abbastanza generale e lascia spazio all’interpretazione.
Le particolari caratteristiche dei concetti non percepiti, discusse poc’anzi, si
prestano a due diversi punti di vista, i quali li collocano rispettivamente fuori
e dentro il modello del mondo, cerchiamo di approfondire meglio.
Secondo un primo modo di vedere le cose, si potrebbe dire che i concetti
non percepiti non fanno parte del modello del mondo. Riprendiamo l’esem-
pio della situazione di pericolo: il fatto stesso di dire “di pericolo” implica
l’aver definito il pericolo. Si potrebbe replicare che anche il dire, ad esempio,
“albero” implica l’aver definito un albero. Il fatto è che, per ciò che riguarda
il pericolo, una stessa configurazione di eventi (e quindi di percezioni sen-
soriali) può essere pericolo oppure no, a seconda del momento in cui viene
percepita, o del soggetto che effettua la percezione. Ad esempio, una condi-
zione di “temperatura elevata” può essere pericolo per un robot i cui circuiti
sono estremamente sensibili al calore, ma può non esserlo per un robot dif-
ferente. Un albero, invece, è sempre un albero, indipendentemente da chi o
quando lo percepisce2. Un concetto non percepito, secondo questo punto di
vista, non fa parte del modello del mondo, ma andrebbe collocato più in alto,
in un modulo decisionale o strategico.
Esiste però la possibilità di vedere le cose sotto un altro punto di vista.
Per quale motivo un modello del mondo non dovrebbe includere concetti
del tipo “situazione di pericolo”? D’accordo, si tratta di un concetto che
può variare nel tempo e in dipendenza dall’osservatore, ma questo basta a
escluderlo da un buon modello del mondo? Sempre ricalcando l’esempio di
prima non si può dire che modellare una situazione di pericolo rappresenti un
compito da delegare a un modulo strategico, in quanto è comune a un numero
molto elevato di domini applicativi (se non tutti). Secondo questa logica, un
buon modello del mondo non può limitarsi a descrivere oggetti, deve invece
integrare concetti non percepiti allo scopo di diventare più completo e fornire
una base più solida ai moduli superiori, svincolandoli nel contempo dal dover
gestire informazioni di troppo basso livello.
Passati in rassegna questi punti di vista la domanda sorge spontanea:
“chi ha ragione?”. La risposta, altrettanto spontanea, è che, come spesso
accade, la verità sta nel mezzo. I concetti non percepiti rappresentano un
utile strumento per perfezionare e rendere più completo e usabile il modello
del mondo, ma si collocano anche sulla linea di confine che separa il modello
2A meno di speculazioni filosofiche per le quali rimandiamo a testi specifici.
2.1 Il modello del mondo 13
del mondo dai moduli strategici, questo proprio per come sono stati definiti.
In questo progetto abbiamo abbracciato la seconda linea di pensiero, cioè
quella che vuole i concetti non percepiti facenti parte integrante del modello
del mondo, anche se non escludiamo che approcci differenti portino comunque
a buoni risultati.
2.1.4 Modello del mondo locale e globale
Nella letteratura si fa spesso una distinzione tra modello del mondo locale
e modello del mondo globale. Questa distinzione riguarda esclusivamente i
domini in cui diversi robot vengono fatti interagire in maniera cooperativa
(RoboCup3 ne è un tipico esempio). Dato che questo lavoro prescinde dal
particolare dominio applicativo, è bene spendere alcune parole in merito a
questa distinzione, ricordando che tutte le considerazioni che saranno fatte
nei futuri paragrafi saranno valide, mutatis mutandis, tanto per il modello
globale che per quello locale.
Il modello locale altro non è che il modello del mondo così come viene
memorizzato all’interno del robot. Chiaramente il mondo esterno non cam-
bia, sia che venga percepito da un robot piuttosto che da un altro. Quello
che cambia radicalmente (a meno di oggetti che possono comparire e scom-
parire a causa dei diversi punti di vista) è il sistema di coordinate. Infatti, le
percezioni di ciascun robot sono fatte relativamente al robot stesso, quindi
due modelli del mondo generati da due differenti robot possono risultare ra-
dicalmente diversi, specie nel momento in cui si è interessati a farli interagire
(per esempio cercando di sapere se un oggetto visto da un robot è stato visto
anche da un altro e se la posizione è la stessa). Per questo motivo, nei domini
multi-agente, si cerca di utilizzare un modello del mondo globale, costruito
cioè con un sistema di coordinate fisso e indipendente dalla posizione dei ro-
bot. Questo modello viene poi utilizzato da tutti i robot per la pianificazione
delle azioni, in maniera tale da rendere estremamente facile l’interazione.
La costruzione di un modello del mondo globale, implica sostanzialmente
due tipi di problematiche:
• Conversione del sistema di coordinate.
• Sincronizzazione del mondo tra i diversi agenti.
Non è scopo di questo documento trattare in maniera approfondita le due
problematiche. Spunti molto interessanti si possono però trovare nel lavoro
di Roth, Vail e Veloso [59].
3Per maggiori informazioni si veda l’appendice A (pag. 135).
14 La rappresentazione concettuale del mondo
2.2 Struttura dell’informazione: pregi e limiti dei
sistemi attuali
2.2.1 Introduzione
La robotica si è affermata all’interno dell’IA cosiddetta “classica” nei primi
anni settanta. In tale approccio, il controllo veniva visto come un problema a
sé che si poteva studiare e implementare in modo relativamente indipendente
dal resto del sistema e si assumeva che il robot dovesse possedere una rap-
presentazione completa ed esplicita del mondo esterno. A partire dagli anni
ottanta, soprattutto a seguito delle ricerche condotte da Rodney Brooks [25]
al MIT, si sono sviluppati approcci diversi che da una parte hanno integrato
il sistema di controllo con il sistema percettivo e motorio e dall’altro han-
no mostrato come un robot possa operare nel mondo reale anche mediante
rappresentazioni incomplete e implicite. Nei paragrafi seguenti vedremo qua-
li soluzioni sono state implementate per la gestione dell’informazione e del
modello del mondo nei robot.
2.2.2 Tipi di modello
La definizione di modello del mondo data nella sezione 2.1.1 (pag. 7) si
presta a più di una interpretazione e lascia molte libertà in fase di design.
Infatti il modello del mondo, come tutti i modelli, può essere arbitrariamente
complesso in funzione dell’utilizzo che se ne vuole fare. Ad esempio, nella
realizzazione di un circuito elettronico che lavora a bassa frequenza si potrà
scegliere un modello semplificato, che non potrà invece essere scelto qualora il
circuito lavori in alta frequenza. Bisognerà in quel caso ricorrere a un modello
più dettagliato per tenere conto del comportamento dei vari componenti in
alta frequenza (capacità parassite etc).
Il modello, quindi, è funzionale all’uso che se ne fa. Christian Freksa,
Reinhard Moratz e Thomas Barkowsky [38] hanno proposto un modello a
mappe schematiche che vengono in parte inserite da un operatore nel modello
del robot e in parte il robot stesso si costruisce da sé facendo uso di un sensore
laser. Freksa, Moratz e Barkowsky hanno adottato questa soluzione ibrida
per sopperire ai limiti del robot nella costruzione del modello. Nel lavoro di
Steen Kristensen, Sven Horstmann, Jesko Klandt, Frieder Lohnert e Andreas
Stopp [48], invece, si fa uso di un grafo per rappresentare il modello del
mondo. In questo caso, però, il robot non sembra aver bisogno di un bagaglio
informativo proveniente dall’esterno, essendo esso in grado di istruirsi da solo.
Il grosso limite di questi due modelli è quello di non essere sufficiente-
mente astratti ma di rimanere legati al dominio. Se nel lavoro di Kristensen,
Horstmann, Klandt, Lohnert e Stopp è almeno presente un planner proget-
2.2 Struttura dell’informazione: pregi e limiti dei sistemi attuali15
AMBIENTE
Sensori Attuatori
MODELLO
Planner
AMBIENTE
Sensori Attuatori
MODELLO
Planner
MODELLOESTESO Abstraction
layer
(a) (b)
Figura 2.1: Interponendo tra il planner e il modello del mondo un livello di
astrazione (Abstraction layer) è possibile sganciare il modello del mondo dal
dominio. L’insieme di abstraction layer e modello del mondo costituisce un
modello del mondo esteso.
tato ad hoc usando una rappresentazione STRIPS-like4, in quello di Freksa,
Moratz e Barkowsky non sembra nemmeno esserci un vero e proprio planner.
Il gestore dell’informazione di alto livello è un banale algoritmo di cammi-
no minimo che addirittura interpella l’operatore in assenza di informazioni
sufficienti.
Nonostante questo limite sia notevole, in ambedue i casi potrebbe essere
facilmente superato interponendo tra il planner e il modello un sistema (vedi
fig. 2.1, pag. 15) che svolga il compito di astrarre ulteriormente il modello e
interfacciarsi con il planner, andandosi così a integrare nel modello del mondo
estendendolo. Proprio a questo livello si colloca il sistema BASE5, oggetto
di questo lavoro. Vedremo fra poco come questa collocazione permetta di
risolvere altri problemi e di implementare funzioni nuove molto interessanti,
il tutto con prestazioni più che ragionevoli.
2.2.3 Architetture software
La gestione dell’informazione all’interno di un robot è legata al linguaggio
usato per interfacciarsi con esso il quale, a sua volta, è legato all’architettura
4Per dettagli in merito a questa rappresentazione si veda il lavoro di Fikes e Nilsson
[34] oppure http://ai.eecs.umich.edu/cogarch0/common/prop/strips.html.
5BASE è l’acronimo di BASE Allows Symbolic Environment.
16 La rappresentazione concettuale del mondo
software del robot. Per capire a fondo i problemi legati alla gestione dell’in-
formazione è quindi necessario prendere in considerazione l’architettura del
robot.
Come visto in precedenza, possono esistere diversi tipi di architetture, ad
esempio le due che abbiamo preso in considerazione poc’anzi erano sostan-
zialmente composte da un modulo che raccoglie le informazioni sensoriali
e costruisce un modello del mondo e un modulo che funge da planner. Un
tipo di architettura simile, come già detto prima, è piuttosto limitata. Un
tipo di architettura decisamente più efficace la si può trovare nel lavoro di
Armin Müller, Alexandra Kirsch e Michael Beetz [52] i quali hanno propo-
sto un’architettura a tre livelli molto simile a quella proposta da noi nella
sezione precedente. Müller, Kirsch e Beetz sollevano inoltre alcuni problemi
legati all’aggiunta di un livello che risolvono in maniera efficace potenziando
il linguaggio di programmazione del planner.
Questo tipo di approccio sembra essere ben concepito e sicuramente mi-
gliore dei due visti in precedenza (tant’è che è stato applicato con discreto
successo anche al dominio RoboCup). Gli autori, però, mettono in evidenza
alcuni limiti del loro lavoro. Citiamo testualmente:
. . . “On this basis we plan to include learning mechanisms as
well as lightweight reasoning techniques. We still need to im-
plement higher-level concepts like a belief-desire-intention ar-
chitecture or logic representations to facilitate reasoning in the
controller.”
Il sistema attuale, secondo gli autori, è carente in ciò che loro definiscono
“higher-level concepts”. Questi concetti di alto livello che gli autori desiderano
implementare non sono altro che ciò che in questo testo è stato definito
“concetto non percepito”. Anche questa è una delle lacune che desideriamo
colmare con questo progetto, rimandiamo ai capitoli seguenti per i dettagli
implementativi.
2.2.4 Incertezza
Un ostacolo con il quale ci si scontra quando si gestisce informazione ac-
quisita dall’ambiente è quello dell’incertezza. Incertezza significa che i dati
che vengono acquisiti e che vengono, dopo opportune trasformazioni, inseri-
ti nella memoria del robot, non sono affidabili al 100%. Le cause di questa
inaffidabilità sono almeno due:
1. Errori di misura dei sensori: le misurazione fatte dai sensori possono es-
sere affette da errore e questo può influire negativamente sulla corretta
identificazione dell’oggetto osservato. Si pensi, a titolo di esempio, al
comportamento di una telecamera quando si fa una ripresa con poca
luce.