1
Proposta di progetto
Sia assegnato un ambiente chiuso con ostacoli. Assegnata una tana, si
vogliono raccogliere una serie di cubi accumulati in alcuni luoghi
non noti all’interno dell’ambiente.
Raccogliere un cubo alla volta e portarlo alla tana, evitando gli
ostacoli e cercando il percorso migliore. Terminati i cubi accumulati
in un posto cercare gli altri.
Gli ostacoli sono di colore blu, i cubi di colore rosso, la tana di colore
giallo.
Dotare il robot di un sistema sensoriale facendo ricorso a sensori
disponibili sul mercato (sonar, bumper, bussole, luminosità (colore),
suoni, etc.).
Può esserci una piccola memoria ma il paradigma di riferimento deve
essere quello reattivo.
http://www.informatik.uni-bremen.de/simrobot/index_e.htm
2
Obiettivi della lezione
• Usare lo schema theory per progettare behavior usando la
programmazione a oggetti.
• Progettare un sistema comportamentale completo, includendo il
coordinamento e il controllo di behavior concomitanti e multipli.
• Per un dato sistema comportamentale, disegnare una tabella
comportamentale che specifichi i releasers, gli schemi percettivi e motori
per ogni comportamento.
• Descrivere due metodi per assemblare e coordinare behavior primitivi
all'interno di un behavior astratto: automi a stati finiti e script.
•Essere capaci di rappresentare una sequenza di behavior con un
3
diagramma di stato o con uno pseudocodice in script.
Equipaggiamenti come Lego Mindstorms, con accoppiamento rapido di
sensori ed attuatori, facilitano gli utenti a costruire behavior reattivi.
I problemi sono come mettere più intelligenza nel software e come
sfruttare meglio i sensori.
Le buone intenzioni spesso sono frustrate da due deficit.
Primo, progettare behavior è più un'arte che una scienza. Spesso i
giovani robotici sono incerti su come iniziare il processo di
progettazione, e come sapere quando hanno realizzato un sistema
ragionevole.
Il secondo deficit è più sottile. Una volta che il progettista ha alcuni
behavior bene progettati e testati, come si integrano in un sistema?
4
Nei primi lavori sul paradigma reattivo, come abbiamo visto, si avevano
robot caratterizzati da un set molto piccolo di behavior i quali erano
combinati internamente per produrre un behavior emergente e
complessivo.
Si è mostrato che i componenti chiave di un'architettura reattiva sono i
behavior più il meccanismo di fusione dei behavior concomitanti.
Molte
applicazioni
sono
state
progettate
come
una
serie
comportamenti, che funzionano secondo una sequenza riconoscibile.
5
di
Una delle prime applicazioni alla quale molti robotici guardarono
consisteva nel raccogliere e depositare in un secchio una lattina di una
qualche bevanda.
Questo problema implica che il robot vada alla ricerca di una lattina, si
muova verso la lattina, quando l’ha trovata la raccolga, cerchi il bidone
della spazzatura, si muova verso il bidone, lasci cadere la lattina.
E’ controintuitivo pensare che questi behaviors siano concorrenti o fusi.
(C'è certamente la possibilità di concorrenza, per esempio quando evita
gli ostacoli mentre si muove verso la lattina o il bidone.)
6
Le tecniche introdotte per controllare sequenze di behavior sono per la
maggior parte concettualmente equivalenti alla costruzione di macrobehavior, dove la struttura dello schema è usata ricorsivamente per
semplificare la programmazione del programma di controllo.
Questo capitolo tenta di aiutare il progettista a costruire un sistema di
robot reattivo, alla luce di questi due deficit.
Primo, è presentato un approccio diretto alla programmazione a oggetti
per i behavior.
Questo approccio è basato sullo schema theory presentato nella lez. 3.
Il caso di studio enfatizza l'importanza di stabilire una nicchia ecologica
per un robot reattivo.
7
Behaviors e Schema Theory
Nella applicazione fatta da Arbib dello schema theory verso una teoria
computazionale dell'intelligenza, un behavior è uno schema che è
composto da un schema motorio ed uno schema percettivo.
Lo schema motorio rappresenta la modalità per l'attività fisica;
lo schema percettivo incarna il sentire.
Lo schema motorio e lo schema percettivo sono come pezzi di un
puzzle; entrambi i pezzi devono essere messi insieme prima di avere un
behavior.
Releaser
Sensory
Input
BEHAVIOR
Schema
percettivo
Schema
motorio
Pattern
of Motor
Action
8
Secondo, sono presentate due tecniche per maneggiare sequenze di
behavior : automi a stati finiti e script.
Vedremo ancora come era da aspettarsi dal materiale presentato nella
Lez. 3, che entrambe queste tecniche sembreranno molto simili all’ IRM
di Tinbergen e Lorenz.
9
Behavior come Oggetti in OOP
Anche se la Programmazione a Oggetti non era ancora popolare nel
periodo in cui si è sviluppato il Paradigma Reattivo, è utile guardare i
behavior in termini di OOP.
Lo Schema theory va bene per trasferire concetti teorici in termini di
OOP.
Lo Schema theory sarà anche usato come ponte tra i concetti
dell'intelligenza biologica e quella robotica, rendendo possibile una
realizzazione pratica della reattività che sfrutta meccanismi di releasing
innati ed affordances.
10
Si ricordi che un oggetto consiste di dati e metodi, anche chiamati
attributi ed operazioni.
Come notato in precedenza, gli schemi contengono conoscenza specifica,
dati locali, strutture e altri schemi.
In Fig. si vede come potrebbe essere definito uno schema. Secondo
Arbib, uno schema in programmazione a oggetti sarà una classe. La
classe avrà un metodo opzionale detto programma di controllo
coordinato. Il programma di controllo coordinato è una funzione che
coordina alcuni metodi o schemi nella classe derivata.
Fig. 5.1 Classi: a.) schema e b.) behavior
11
Tre classi sono derivate dalla Classe Schema:
Schema motore, Schema Percettivo e Behavior.
I Behavior sono composti da almeno uno Schema Percettivo ed uno
Schema motore; questi schemi si comportano come metodi per la classe
Behavior.
Lo Schema Percettivo ha almeno un metodo; tale metodo prende in input
il sensore e lo trasforma in una struttura dati detta percetto.
Lo Schema motore ha almeno un metodo che trasforma il percetto in un
vettore o altra forma di rappresentazione in un'azione.
Lo Schema Percettivo è collegato ai sensori, mentre lo Schema motore è
collegato agli attuatori del robot. I sensori e gli attuatori possono essere
rappresentati se necessario dalle loro proprie classi software; questo è
utile quando si usano driver software per l’hardware.
12
Usando l’UML (Unified Modeling Language) le classi Schema e
Behavior appaiono come in fig. L'organizzazione degli OOP permette ad
un behavior di essere composto di schemi percettivi multipli, schemi
motore e behavior, il che equivale a dire che la definizione di un
behavior è ricorsiva.
Perché è utile avere schemi percettivi e schemi motore multipli?
Ad esempio in qualche caso, può tornare utile avere due schemi
percettivi, uno per sapere le condizioni di luce di giorno se si usa una
telecamera ed uno per la notte se si usano gli infrarossi.
13
Si ricordi che un behavior primitivo è composto solo di uno schema
percettivo e uno schema a motore; non c'è nessun bisogno di avere alcun
programma di controllo per il coordinamento.
Si può pensare che i Behavior primitivi siano monolitici, in quanto essi
fanno solo una cosa. Poiché di solito essi sono un semplice mapping tra
lo stimolo e la risposta, sono spesso programmati come un solo metodo,
non composti da metodi multipli od oggetti.
I Behavior che sono assemblati da altri behavior o hanno schemi
percettivi multipli e schemi motore li chiameremo “behavior astratti”,
perché, rispetto a un behavior primitivo, sono alquanto lontani dai
sensori e dagli attuatori.
L'uso del termine “behavior astratto" non deve essere confuso con una
classe astratta in OOP.
14
Esempio: Un behavior primitivo di move_to_goal
Questo esempio mostra come può essere progettato un behavior
primitivo che usa i principi della OOP.
Nel 1994, l’annuale AAAI Mobile Robot Competition aveva una gara su
”Raccogli l'Immondizia", gara che fu ripetuta nel 1995 all'AAA-IJCAI
Mobile Robot Competition.
L'idea di base era che un robot era messo in un'arena vuota grande circa
quanto un ufficio. Nell'arena ci sarebbero state lattine di CocaCola e
tazze bianche collocate a caso. In due dei quattro angoli, c’era un bidone
di raccolta blu; negli altri due, un bidone di immondizia colorato
diversamente.
Il robot che raccoglieva più immondizia e la metteva nel bidone giusto
nel tempo assegnato era il vincitore.
Per molto tempo, la strategia fu di trovare e riciclare le lattine di
CocaCola, perché erano più facili da percepire per gli algoritmi di
visione del robot essendo di colore rosso e blu.
15
Uno dei behavior di base necessario per raccogliere una lattina rossa e
muoversi verso un bidone blu è move_to_goal.
Quando il robot vede una lattina rossa, deve muoversi verso di essa.
Quando ha raccolto una lattina, allora deve trovare e poi muoversi verso
un bidone blu.
È corretto dal punto di vista dell’ingegneria del software scrivere un
behavior generale per muovere verso il goal, dove solo quello che è il
goal regione rossa o blu può variare.
Il goal in questo esempio può essere passato come una instanziazione
attraverso il costruttore dell’oggetto.
Scrivere un solo behavior generico per move_to_goal (color) è
preferibile rispetto a scrivere un behavior move_to_red ed un behavior
move_to_blue. Dal punto di vista dell’ingegneria del software, scrivere
due behavior che fanno la stessa cosa è un’occasione per introdurre bug
16
di programmazione.
Behavior generici condividono anche la stessa filosofia come la
fattorizzazione in matematica.
Si voglia semplificare l'equazione 45x2 + 90x + 45. Il primo passo è
semplificare l'equazione trovando i fattori comuni. In questo caso, 45
può essere messo in evidenza e l'equazione riscritta come
45(x + 1)2.
Il colore del goal, rosso o azzurro, è come il coefficiente comune 45; è
importante, ma tende a nascondere che la chiave alla soluzione era la x in
questo caso la direzione in move_to_goal.
17
Un codice modulare, generico può essere ben gestito dagli schemi.
Il behavior move_to_goal consisterà di uno schema percettivo che sarà
chiamato extract_goal ed uno schema motore che usa un campo
attrattore chiamato pfields.attraction.extract_goal che usa l'affordance
del colore per estrarre dove è nell'immagine il goal, e poi calcolare
l'angolo al centro della regione colorata e la grandezza della regione.
Queste informazioni formano il percetto del goal; l’affordance della
lattina di Coca cola può essere il colore, mentre le informazioni estratte
dalla percezione sono l'angolo e la grandezza.
Lo schema motore attrattivo riceve il percetto ed è responsabile di far
girare il robot verso il centro della regione rossa e muoverlo in avanti.
Questo si può fare facilmente usando un campo attrattivo, in cui più
grande è la regione, più forte è l'attrazione e più velocemente si muove il
robot.
18
Releaser
Sensory
Input
move_to_goal
Pattern
of Motor
Action
Schema
extract_goal
pfields.attraction.extract_goal
19
Il behavior move_to_goa1 può essere implementato come un behavior
primitivo, dove goal_color è una maniera per rappresentare colori diversi
come rosso e blu:
move_to_goal (goal_color):
Object
Behavioral Analog
Identifier
Data
percept
Methods
perceptual_schema
motor_schema
goal_angle
goal_strength
extract_goal(goal_color)
pfields.attraction(goal_angle,goal_strength)
20
La tabella implica alcuni punti molto importanti per la programmazione
con i behavior.
1. Il behavior è la "colla" tra gli schemi percettivo e motore. Gli schemi
non comunicano nel senso che sono entrambi entità indipendenti; lo
Schema Percettivo non sa che lo schema motore esiste. Invece, il
behavior mette il percetto creato dallo Schema Percettivo in un luogo
dove lo schema motore può trovarlo.
2. I behavior possono (e dovrebbero) usare biblioteche di schemi. Il
suffisso pfields su pfields. attraction() vuole dire che quell'attrazione è
un metodo all'interno di un altro oggetto identificato come pfields.
I cinque campi di potenziali primitivi visti precedentemente potrebbero
essere incapsulati in una classe chiamato PFields che ogni schema
motore potrebbe usare.
PFields servirebbe come una libreria.
Una volta che i campi potenziali in PFields sono scritti e verificati, il
21
progettista non deve più programmarli di nuovo.
3. I Behavior si possono riusare se scritti adeguamente. In questo
esempio, il behavior move_to_goal è scritto per accettare una struttura
(od oggetto) definito da un colore e si muove poi verso una regione di
quel colore. Questo vuole dire che il behavior può essere usato con
lattine di Coca cola rosse e secchi di immondizia blu.
22
Esempio: Un behavior astratto di follow_corridor
Nell’esempio move_to_goal abbiamo usato un solo schema motore con
un solo schema percettivo.
Questo esempio mostra come può essere implementata una metodologia
a campi potenziale che usa schemi.
Nell’esempio seguente del corridoio, il follow_corridor a campo di
potenziale visto nella lezione 4 consisteva di due campi primitivi:
due istanze di perpendicular ai muri ed
una di uniform parallela ai muri.
Il campo follow_corridor può essere implementato in schemi in almeno
due modi diversi come mostrato di seguito.
In qualche maniera, ognuno dei campi primitivi
può essere uno schema motore separato.
23
Lo schema motore di follow_corridor consiste di tre primitive e di un
programma di controllo coordinato.
Il programma di controllo coordinato è la funzione che sa che un campo
è perpendicolare al muro sinistro e va verso il centro del corridoio in che
modo è diretto, ecc.
Questi campi sono sommati dal programma di controllo coordinato nello
schema comportamentale per produrre un solo vettore di uscita.
VF
VL
VR
DR
DL
VF+L+R
VR-L
VF
DL, DR
VF
VR-L
VR
VL
24
Lo Schema Percettivo di follow_corridor esamina il diagramma polare
del sonar ed estrae l'ubicazione relativa dei muri del corridoio. Lo
Schema Percettivo ritorna la distanza dal muro sinistro e dal muro
destro.
VF
VL
VR
DR
DL
VF+L+R
VR-L
VF
DL, DR
VF
VR-L
VR
VL
25
Un altro modo per realizzare lo stesso behavior complessivo è avere follow_wall
composto di due istanze di un behavior segui il muro: follow_wall (sinistro) e
follow_wall (destro). Ogni istanza di segui il muro riceve il plot polare del sonar ed
estrae il muro corrispondente.
In entrambe le realizzazioni, gli schemi motore funzionano continuamente, ed i vettori
sono sommati internamente per produrre un solo vettore di output. Poiché ci sono
schemi motore multipli, il programma di controllo coordinato per follow_corridor non è
nullo come era per move_to_goal. La sommatoria vettoriale e la concorrenza formano
in questo caso il programma concettuale di controllo coordinato.
VF+R
VF
VR
VF+L
VL
VF+L
VF+R
VF+L+R
VF+R
VF
VL
VF+L
VL
DL
VR
DR
VR
26
DL
DR
Dove vanno a finire i releasers in OOP?
Gli esempi precedenti mostrano come i behavior possono essere
implementati usando costrutti OOP, come le classi.
Un'altra importante aspetto di un behavior è come esso è attivato.
Come è stato discusso nella lezione 3, la percezione serve a due scopi:
rilasciare un behavior e guidarlo.
Gli schemi Percettivi sono chiaramente usati per guidare il behavior, sia
per muoversi verso un goal diversamente colorato sia per seguire un
muro.
Ma quale oggetto o struttura contiene il releaser e come è "attaccato" al
comportamento?
27
La risposta alla prima parte della domanda è che il releaser è esso stesso
uno schema percettivo.
Può funzionare indipendentemente da tutto quello che sta accadendo al
robot; è uno Schema Percettivo non limitato da uno schema motore.
Supponiamo per esempio, che il robot sta cercando lattine di Coca cola
rosse con lo schema percettivo di extract_color.
Un modo di implementare questo è: quando lo schema vede rosso, allora
può segnalare al programma principale che c'è rosso.
Il programma principale può stabilire che il releaser per il behavior
move_to_goal è stato soddisfatto, e quindi instanziare move_to_goal()
con goal = red.
28
move_to_goal può instanziare una nuova istanza di extract_color o il
programma principale può passare un puntatore all’extract_color
attualmente attivo.
move_to_goal deve poi instanziare pfield.attraction, altrimenti gli
schemi di attrazione motore non potrebbero funzionare.
In questo approccio, il programma principale è responsabile di
chiamare gli oggetti corretti al momento giusto; il releaser è attaccato
al behavior dal progettista con piccoli meccanismi formali per
assicurarsene la correttezza.
29
Un altro approccio più comune di programmare è quello che il releaser è
parte del behavior: in questo caso il singolo Schema Percettivo svolge
un doppio compito.
Questo stile di programmazione richiede un programma di controllo
coordinato. Il behavior è sempre attivo, ma se il releaser non è
soddisfatto, il programma di controllo coordinato cortocircuita
l’elaborazione.
Il behavior ritorna una funzione identità, cioè un vettore (0,0) nel caso di
campi di potenziale il che equivale ad un behavior non attivo.
Questo stile di programmare può limitare alcune risorse, ma è un modo
semplice ed efficace di programmare.
30
In entrambi i casi, una volta che il robot vede rosso, l'aspetto osservabile
di move_to_goal (cioè muoversi direttamente verso il goal) comincia.
Gli schemi extract_goal aggiornano i dati del percetto (angolo relativo
del goal e dimensione della superfice rossa) ogni volta che viene
chiamato.
Questi percetti sono poi disponibili per lo schema motore che può a sua
volta produrre un vettore.
31
In seguito si mostrerà che i releaser devono essere progettati per
sostenere una sequenza corretta.
A seconda di dove il robot si trova nella sequenza delle attività, il robot
usa move_to_goal per andare verso una lattina di Coca cola rossa o un
bidone di riciclaggio blu. Altrimenti, il robot potrebbe perseguire una
Coca cola rossa o un bidone di riciclaggio blu simultaneamente.
In questa situazione, dovrebbero esserci due oggetti move_to_goal , uno
instanziato con goal "rosso" e l'altro con goal "blu."
Si noti che il behavior move_to_goal può usare qualunque Schema
Percettivo che può produrre un angolo e una forza per il goal.
Se il robot avesse bisogno di muoversi verso una luce brillante
(fototropismo), si dovrebbe cambiare solo lo schema percettivo.
Questo è un esempio di riusabilità del software.
32
Passi per progettare un Sistema Reattivo
La fig. mostra i passi per progettare un sistema con behavior reattivi ed è
presa da un articolo di Murphy. In questa parte si farà prima una ampia
discussione sul processo di progettazione, poi si esamineranno i vari
passi usando un approccio del 1994.
La metodologia in fig. presume che a un progettista è dato: il task che il
robot deve fare (1), una piattaforma robotica (2) (o dei vincoli, in genere
economici). Il goal è progettare un robot come un agente situato (3).
Perciò, i primi tre passi servono a ricordare al progettista di specificare la
nicchia ecologica del robot.
33
Al quarto passo comincia un processo iterativo in cui si fa
l’identificazione e il raffinamento del set di behavior per il task.
Viene posta la domanda: cosa farà il robot (4)? Definire la nicchia
ecologica determina i vincoli e le opportunità ma non presenta
necessariamente altri suggerimenti nella situatedness del robot: come
esso agisce e reagisce alla variabilità nella sua nicchia ecologica. Questo
passo è dove un novizio comincia a capire che progettare behavior è
un'arte.
34
Qualche volta, una decomposizione in behavior appare ovvia al
Robotico dopo avere pensato alla nicchia ecologica.
Per esempio, nelle gare del 1994 e 1995 la maggior parte delle squadre
usarono la seguente divisione di compiti:
• ricerca casuale fino a che vedi il rosso, muovi verso il rosso,
raccogli,
• ricerca casuale fino a che vedi il blu, muovi verso il blu, rilascia la
lattina.
35
I Robotici spesso tentano di trovare un'analogia con un compito
portato a termine da un animale o da una creatura umana, e quindi
studiano la letteratura etologica o cognitiva per ulteriori informazioni
su come l'animale o l’uomo porta a termine quella classe di compiti.
Questo, chiaramente schiva la domanda di come i Robotici fanno a
capire a quale classe di compiti animali può essere simile il compito
del robot.
In pratica, i Robotici che usano suggerimenti biologici e cognitivi
tendono a leggere e a rimanere al corrente della letteratura etologica
così da poter poi trovare qualche collegamento.
36
I passi 5-7 sono meno astratti. Una volta che l’insieme di behavior
candidato è stato proposto, il progettista lavora sul progetto di ogni
behavior individuale, specificando il suo Schema Percettivo e motore.
A questo punto descrive l'algoritmo per trovare in maniera casuale
macchie rosse in un'immagine televisiva e, quando scopre il rosso si
muove verso di esso con il behavior rosso. Il progettista di solito
programma ogni schema indipendentemente (5), poi li integra in un
behavior e prova il behavior da solo prima (6) di integrare tutti i
comportamenti (7). Questo stile di test è consistente coi principi
dell’ingegneria del software, ed enfatizza i vantaggi pratici del
Paradigma Reattivo.
37
L'elenco dei passi per implementare un sistema reattivo può essere
fuorviante. Nonostante le frecce di ritorno, il processo complessivo in
fig. sembra essere lineare.
In pratica, esso è iterativo. Per esempio, una certa affordance potrebbe
essere impossibile per il robot da scoprire affidabilmente coi suoi
sensori, o un affordance non prevista nella prima analisi della nicchia
ecologica potrebbe emergere improvvisamente.
La sola maniera di iterare può essere quella di provare tutti i behavior
insieme nel " mondo reale”. Il software che spesso in simulazione ha
funzionato perfettamente fallisce nel mondo reale.
38
Un caso Studio: Unmanned Ground Robotics Competition
Questo caso di studio è basato sull'approccio introdotto dalla squadra
della Colorado School of Mine (CSM) che partecipò alla gara all’aperto
per veicoli senza equipaggio del 1994. L'obiettivo della competizione era
avere un piccolo veicolo non controllato (non più grande di un carrello
da golf) che autonomamente navigasse in uno spazio aperto seguendo
linee bianche dipinte sull'erba.
Il CSM vinse il primo posto ed un premio di $5,000.
Vediamo ora il progetto passo passo e discutiamo i vari passi.
Questo caso di studio illustra l'uso effettivo solo di alcuni behavior,
sviluppati incrementalmente, e l'uso di affordances combinate con una
conoscenza della nicchia ecologica.
39
Step 1: Descrivere il task.
Lo scopo di questo passo è specificare quello che il robot deve fare per
avere successo.
Il compito del robot (veicolo) è di seguire un percorso con svolte
brusche, ostacoli fermi sul percorso ed una buca di sabbia. Il robot che
va più lontano possibile senza andare fuori dei limiti è il vincitore, se
due o più robot raggiungono la stessa distanza o completano il corso,
il vincitore è quello più veloce. La velocità massima è di 5 mph. Se il
robot va parzialmente fuori dei limiti (una ruota o simili), viene data
una penalità. Se il robot spinge un ostacolo per rimuoverlo, viene data
un'altra penalità sempre in termini di distanza raggiunta. Perciò, la
competizione favorisce quelli che completano il percorso senza
accumulare alcuna penalità, che sono più veloci, non escono fuori dai
confini o non abbattono ostacoli.
I concorrenti dovevano fare tre corse in un giorno e due giorni per
prepararsi ed esaminare la pista del percorso; l’ordine di partenza
fu
40
sorteggiato.
Step 2: Descrizione del robot.
Lo scopo di questo passo è determinare le abilità fisiche e di base del
robot e le sue limitazioni.
In teoria, ci si aspetta, che il progettista voglia avere il controllo sul
robot (costruirlo lui stesso), decidere quello che può fare, di quali
sensori essere dotato ecc.
In pratica, la maggior parte dei Robotici opera con piattaforme
commerciali che possono avere limitazioni su hardware e sui sensori
che possono essere aggiunti, o sulle piattaforme sotto forma di kit con
equipaggiamento poco costoso ma dove ci sono vincoli sulla potenza.
Al progettista di solito sono perciò imposti dei vincoli fissi dalla
piattaforma del robot che hanno un impatto sulla relativa
progettazione.
41
In questa competizione si stabilì che il veicolo robotico doveva avere
una base di almeno 90cm per 105cm e comunque doveva essere non
più grande di un carrello da golf. Inoltre, il robot doveva portare onboard la sua alimentazione elettrica e il suo sistema di elaborazione
(non era permessa nessuna comunicazione radio con un processore
non a bordo), infine essere in grado di trasportare un peso di 9 Kg.
In fig. è mostrato il robot del CSM (Omnibot).
42
Il veicolo di base era una jeep con ruote motorizzate acquistata in un
negozio di giocattoli. La base soddisfaceva esattamente le richieste
minime per le dimensioni. Venne usato uno sterzo Ackerman (come
nelle auto) per il governo, un motore per muovere le ruote posteriori
ed un motore per le ruote anteriori. Il veicolo aveva un angolo di
rotazione di 22°. Il calcolatore on-board era un PC 486 a 33MHz.
L’insieme dei sensori consisteva di tre apparecchiature:
•shaft encoders sui motori di movimento e rotazione,
•una videocamera montata su un albero vicino al centro del veicolo ed
• un sonar panoramico montato sotto una grata sul davanti.
L’output della videocamera veniva digitalizzata da un sistema bianco e
nero.
Il sonar era un Polaroid. L'apparecchiatura aveva una panoramica di
180°.
Ogni codifica era fatta in C++.
43
A causa del sistema di motori e di rotazione, Omnibot poteva andare
solo a 1.5 mph.
Questa limitazione implicava che avrebbe potuto vincere solamente se
fosse andato più lontano con un minor numero di penalità. Questo
significava anche che bisognava aggiornare la lettura dei sensori
almeno ogni 150ms o il robot sarebbe potuto andare fuori dei limiti
senza accorgersi che lasciava il percorso previsto.
Una acquisizione in bianco e nero eliminò il problema del colore.
Inoltre, la velocità di aggiornamento del framegrabber era di circa
150ms; l’algoritmo che tratta la visione deve essere molto veloce
altrimenti il robot si muove prima di un nuovo aggiornamento.
Le riflessioni dovute all’erba disuguale ridussero il range standard del
sonar da 7.5mt a circa 3mt.
44
Step 3: Descrizione dell'Ambiente.
Questo passo è critico per due ragioni.
Primo, è un fattore chiave nel determinare la situatedness del robot.
Secondo, identifica le opportunità percettive per i behavior, sia su
come un evento percettivo instanzierà un behavior, sia su come
funzioneranno gli schemi percettivi per i behavior.
Si ricordi dalla lezione 4 che il paradigma Reattivo favorisce la
percezione diretta o percezione basata su affordance perché ha una
fase di esecuzione rapida e non comporta nessun ragionamento o
memoria.
45
Il percorso era all’aperto su un campo erboso con piccoli pendii.
Consisteva di una corsia larga 3 mt marcata con vernice bianca, della
forma di Fig. La lunghezza esatta del percorso e la configurazione
degli ostacoli non era nota fino al giorno della gara, e alle squadre non
era permesso di misurare il percorso o fare prove su di esso. Gli
ostacoli erano fissi e consistevano in balle di fieno avvolte in teli di
plastica di colore bianco o rosso. Le balle erano di circa 60x120 cm e
non occupavano mai più di 90 cm nella corsia.
46
Il sonar era capace di scoprire affidabilmente le balle coperte e di
plastica da più angoli di approccio da una distanza massima di 2,4 mt.
I veicoli dovevano correre tra le 9 e le 17 del 22 maggio, anche con
tempo coperto.
Oltre ai problemi di visione dovuti al cambiare dell’illuminazione
causata dalle nubi, le balle proiettavano ombre sulle linee bianche tra
le 9 e le 11 e tra le 15 e le 17.
La buca di sabbia era lunga solo
1,2 mt e messa su una parte
diritta del percorso.
47
L'analisi dell'ambiente permise una semplificazione del compito. Il
posizionamento degli ostacoli lasciava uno spazio libero di 1,2 mt.
Poichè Omnibot era largo solo 0,90 mt, questo permetteva di trattare il
percorso come privo di ostacoli se il robot fosse potuto rimanere al
centro della corsia con una tolleranza di 0.15mt. Questo eliminò la
necessità di un behavior per evitare gli ostacoli.
48
L'analisi dell'ambiente identificò anche un affordance per controllare il
robot. L'unico oggetto di interesse per il robot era la linea bianca che
avrebbe dovuto avere un forte contrasto con il verde (grigio scuro)
dell'erba. Ma il valore dell’illuminazione della linea bianca cambiava
col tempo. Comunque, se la telecamera fosse stata puntata
direttamente su una linea, invece di tentare di vedere entrambe le linee
la maggioranza dei punti più brillanti nell'immagine sarebbero
appartenuti alla linea (con una riduzione del rapporto segnale/rumore
perché la maggior parte dell'immagine conteneva la linea). Alcuni dei
punti brillanti potevano essere attibuiti a riflessioni, ma questi si
presumeva fossero distribuiti casualmente. Perciò, se il robot tentava
di tenere il centroide dei punti bianchi nel centro dell'immagine, si
poteva collocare al centro della corsia.
49
Step 4: Descrizione delle reazioni del robot in risposta
all’ambiente.
Lo scopo di questo passo è identificare l’insieme di uno o più behavior
primitivi; questi behavior saranno raffinati o eliminati successivamente.
Non appena il progettista descrive come il robot dovrebbe agire, di
solito appare il behavior.
Si mette in evidenza che a questo passo è solo necessario concentrarsi
su quello che dovrebbe fare il robot, non su come lo farà, anche se
spesso il progettista vede le due cose insieme.
Nel caso della CSM, inizialmente fu proposto solo un behavior:
follow_line.
Lo schema percettivo doveva usare la linea bianca per calcolare la
differenza fra dove era il centroide della linea bianca e dove il robot
avrebbe dovuto essere, mentre gli schemi motori dovevano convertire
questa differenza in un comando per lo sterzo del motore.
50
Al fine di ricavare i behavior per un task, è spesso vantaggioso
costruire una tavola dei behavior così da avere tutti i behavior su un
solo foglio di carta.
Il releaser per ogni behavior è utile per confermare che il behavior
opererà correttamente senza conflitti. E’ spesso utile per il progettista
classificare gli schemi percettivi e motori.
Per esempio, si consideri quello che accade se una implementazione
ha uno schema motorio puramente riflessivo, move_to_goal, ed un
behavior AVOID per evitare gli ostacoli.
Cosa accade se il behavior AVOID causa la perdita della percezione
del goal da parte del robot? In questo caso, lo Schema Percettivo dice
che non c’è un goal ed il behavior move_to_goal è terminato!
Probabilmente quello che il progettista suppone è che il behavior ha
un modello con un pattern di azione fisso e quindi persiste nel
muoversi verso l'ultima ubicazione nota del goal.
51
Behavior Table
Releaser
Behavior
Motor Schema
always on
follow-line() stay-on-path(c_x)
Percept Perceptual schema
c_x
Computecentroid(image,white)
Come si vede dalla tavola dei behavior, la squadra del CSM propose
inizialmente solamente un behavior: follow-line .
Il behavior di follow-line consisteva di un schema motore, stay-onpath(centroid) che era riflessivo (stimolo-risposta) e taxonomico
(orientava il robot in funzione dello stimolo).
Lo Schema Percettivo, compute-centroid(image,white), estraeva un
affordance del centroide del bianco dall'immagine come se fosse la
linea.
Solamente la componente x, c_x, o ubicazione orizzontale, del
52
centroide veniva usata.
Step 5. Raffinare ogni behavior.
A
questo
punto,
il
progettista
ha
un'idea
complessiva
dell'organizzazione del sistema reattivo e cosa sono le attività.
Ora bisogna concentrarsi sul progetto di ogni singolo behavior.
Quando il progettista costruisce le strutture degli algoritmi per gli
Schemi motore e percettivo, è importante essere sicuri di considerare
sia l’insieme delle condizioni normali ambientali in cui il robot si
aspetta di operare sia quando il behavior fallisce.
53
Il behavior di follow-line fu basato sull'analisi che le uniche cose
bianche nell'ambiente erano le linee e le balle di fieno coperte di
plastica. Pur se questa era una buona assunzione, accadde un evento
umoristico durante il secondo turno della competizione. Mentre il
robot seguiva la linea bianca lungo il percorso, uno dei giudici capitò
nel mirino della telecamera. Sfortunatamente, il giudice portava scarpe
bianche, ed Omnibot girò in una direzione a metà tra le scarpe e la
linea. Il capitano della squadra del CSM, Floyd Henning si rese conto
di quello che stava accadendo e gridò al giudice di spostarsi. Troppo
tardi, le ruote anteriori del robot erano già sulla linea; la telecamera
ora guardava fuori della linea e non c'era nessuna possibilità di
recuperare. Improvvisamente, giusto prima che la ruota posteriore
sinistra lasciasse il confine, Omnibot si raddrizzò e cominciò ad
procedere parallelamente alla linea! Il percorso girava a destra,
Omnibot attraversò di nuovo il percorso e riacquisì la linea.
Probabilmente era uscito fuori della linea per un capello. La folla
diventò pazza, mentre la squadra di CSM si scambiò occhiate confuse.
54
Cosa era accaduto da fare tornare Omnibot nei confini? Lo Schema
Percettivo stava usando il 20% dei pixels più brillanti dell'immagine
per calcolare il centroide. Quando si girò verso l'erba, Omnibot
proseguì diritto perché la riflessione sull'erba era largamente casuale e
le posizioni erano state annullate, mentre il centroide era rimasto
sempre al centro dell'immagine. I giardinieri avevano tagliato
solamente l'erba nelle aree dove doveva passare il percorso. Lungo il
percorso e in parallelo ad esso vi era un pezzo di erba intonsa pieno di
fiorellini di dente di leone. La fila di fiorellini bianchi agì come se
fosse una linea bianca, ed una volta che Omnibot la vide corresse
leggermente il suo percorso per rimanere parallelo a loro. Fu una
fortuna pura e semplice che il percorso curvasse in quel punto così che
quando i dente di leone furono fuori quadro, Omnibot continuò diritto
e si intersecò di nuovo col percorso. Quindi Omnibot non era stato
programmato per reagire a scarpe o ai dente di leone, ma reagì
55
considerando correttamente la sua nicchia ecologica.
Step 6: Verifica ogni behavior indipendentemente.
Come in ogni progetto di ingegneria del software, moduli o behavior
sono esaminati individualmente. Idealmente, il test si fa in
simulazione prima di esaminare il robot immerso nell’ambiente.
Molti robot commerciali disponibili, come Khepera e Nomads,
vengono forniti con simulatori impressionanti.
Comunque, è importante ricordare che i simulatori spesso imitano solo
le meccaniche del robot, non le capacità percettive. Essi sono utili per
verificare che il codice dello schema motore è corretto, ma spesso
l'unico modo di verificare lo Schema Percettivo è quello di provarlo
nel mondo reale.
56
Step 7: Test con gli altri behavior.
Il passo finale del progetto e dell’implementazione del sistema reattivo
è fare un test sull’integrazione quando cioè i behavior sono combinati
insieme.
Questo include anche il collaudo dei behavior nell'ambiente reale.
Anche se il behavior di follow_line funzionò bene quando fu fatto il
test con le linee bianche, non funzionò però bene quando fu fatto con
linee bianche ed ostacoli. Gli ostacoli, balle di fieno avvolte di plastica
luccicante poste vicino alla linea, erano spesso più brillanti dell'erba.
Perciò lo schema percettivo di follow_line nel calcolare il centroide
teneva conto di pixels che facevano parte della balla. Invariabilmente
il robot si fissava sulla balla, e seguiva il suo perimetro piuttosto che
la linea.
57
Le balle erano viste come "distrazioni visuali."
Le balle fortunatamente erano relativamente piccole. Se il robot avesse
potuto chiudere gli occhi per circa due secondi e quindi andare diritto,
sarebbe rimasto certamente sul percorso. Questo fu chiamato il
behavior della mossa_in_avanti (move_ahead).
Esso usava la direzione del robot (angolazione, direzione)
essenzialmente per produrre un campo uniforme. Il problema divenne
come sapere quando ignorare l’input visivo e far intervenire
move_ahead.
L'approccio al problema di quando ignorare la visione era di usare il
sonar come un releaser per move_ahead. Il sonar era puntato sulla
linea ed ogni qualvolta faceva una lettura, move_ahead interveniva
per due secondi.
58
A causa delle difficoltà di lavorare sotto DOS, il CSM doveva usare
una sincronizzazione e uno scheduling per tutti i processi. Fu più
facile e più affidabile far funzionare ogni processo ad ogni ciclo di
aggiornamento, anche se poi i risultati venivano scartati. Di
conseguenza i releaser del sonar per move_ahead essenzialmente
interdivano follow_line, mentre la mancanza di un releaser del sonar
interdiva move_ahead.
Entrambi i behavior funzionavano continuamente, ma solo uno aveva
qualche influenza su quello che il robot faceva.
In fig. si vede questa inibizione, e la nuova Behavior Table.
59
Nuova Behavior Table
Releaser
Inhibited by
Behavior
Motor Schema
Perc
ept
Perceptual schena
always on
Near=read_sonar()
follow-line()
stay-on-path(c_x)
c_x
Computecentroid(image,white)
always on
Far=read_sonar()
Move_ahead(dir)
Uniform(dir)
dir
Dead_reckon(shaftencoders)
sonar
Move_ahead
TV cam Follow_line
T
60
La versione finale funzionò abbastanza bene per la squadra del CSM
che arrivò prima.
Il robot percorse la pista fino a circa 90 cm dalla linea di fine.
I giudici avevano messo una buca di sabbia poco profonda per
esaminare la trazione. La buca di sabbia dava qualche preoccupazione
perchè la sabbia era di un colore chiaro, e poteva essere interpretata
come parte della linea.
Siccome la sabbia era a livello del suolo, il lettore di distanza non
poteva essere usato come inibitore. Infine, la squadra decise che
siccome la grandezza della buca di sabbia era circa metà della
lunghezza di una balla, non avrebbe avuto abbastanza influenza sul
robot da fargli cambiare il delicato scheduling programmato.
61
La squadra ebbe ragione perchè la buca di sabbia era troppo piccola
per essere una distrazione visuale significativa. Comunque, si
dimenticarono del problema della trazione. Per trovare più trazione la
squadra optò per veri pneumatici invece che ruote di plastica lisce, ma
dimenticò di collegarli. Una volta nella sabbia, il robot iniziò a slittare.
Dopo che il limite di tempo fu superato, alla squadra fu permesso di
spingere leggermente il robot in avanti (fatto con un colpetto da parte
del capo equipe) per vedere se avesse completato il percorso intero.
Effettivamente lo fece. Nessuna altra squadra andò tanto lontano dalla
buca di sabbia.
È chiaro che un sistema reattivo andava bene per questa applicazione.
L'uso di behavior reattivi primitivi era computazionalmente molto
poco costoso, permettendo al robot di aggiornare gli attuatori
pressocché alla stessa velocità di aggiornamento del framegrabber
62
della visione.
Ci sono molte importanti lezioni che possono essere estratte da questo
caso di studio :
• La squadra del CSM sviluppò un robot che andava bene per la sua
nicchia ecologica. Comunque, essa era una nicchia molto limitata. I
behavior non funzionerebbero per un dominio del tipo: segui un
marciapiede o un percorso di linee bianche con intersezioni. In realtà,
il robot reagì ad un oggetto inaspettato nell'ambiente come le scarpe
bianche del giudice.
•In questo caso il releaser o lo stimolo inibitore per il behavior non è
costituito dalla stessa percezione necessaria per portare a termine il
compito. Infatti per interdire il behavior fu usato un sonar.
Follow_line usava la visione, mentre move_ahead integrava i dati
degli shaft encoder per continuare a muoversi verso l'ultima direzione
buona.
Questo esempio illustra anche la tendenza negli schemi motore
63
puramente reattivi di assegnare un sensore per behavior.
Assemblaggi di Behavior
Il caso di studio precedente ha illustrato i principi di base del progetto
di behavior reattivi. In esso, ci sono un numero banale di behavior.
Cosa accade quando ci sono molti behavior, alcuni dei quali devono
funzionare concomitantemente ed altri in sequenza?
Ci sono, da qualche parte nel sistema, dei releasers che determinano la
sequenza. Il problema è come rappresentare formalmente i releasers e
le loro interazioni in una qualche forma di sequenza logica.
Se un set di behavior forma un pattern prototipico di azione, essi
possono essere considerati “meta" o "macro" behavior, dove un
behavior è compattato, a partire da altri behavior primitivi, in un
behavior astratto.
Di qui il problema di come incapsulare il set di behavior e la64 loro
sequenza logica in un modulo separato.
La stessa struttura a schema dell’OOP, usata per raccogliere uno
Schema Percettivo ed uno schema motore in un behavior, può essere
usata per raccogliere più behavior in un behavior astratto, come
mostrato in Fig dal behavior composto di behavior.
Il programma di controllo coordinato, membro del behavior astratto,
fornisce il releasers per i behavior componenti.
65
Resta il problema di come rappresentare formalmente i releasers in
maniera che il robot li possa eseguire ed il progettista umano li possa
visualizzare e diagnosticare.
Ci sono tre maniere per compattare una sequenza di behavior:
automi a stati finiti, scripts e skills.
Gli automi a stati finiti (FSA) e gli scripts sono logicamente
equivalenti, ma danno luogo a modi lievemente diversi di
implementazione.
Gli skills raccolgono i tipo-behavior primitivi, chiamati ReazioneAzione Packages (RAPs), in un "piano abbozzato" che può essere poi
riempito man mano che il robot li esegue.
Coordinazione e controllo con behavior tipo FSA furono usati con
successo dal team della Georgia che vinse nel 1994 la gara di raccolta
della spazzatura dell’AAAI, e dal team LOLA vincente nella 66
stessa
competizione dell’JCAI nel 1995.
Gli Scripts furono usati dalla squadra della CSM nella competizione
del 1995; essi dal punto di vista comportamentale funzionarono come
per le squadre vincenti ma la squadra non entrò in classifica a causa di
una penale dovuta alla mancanza di un manipolatore. Queste squadre
usarono al massimo otto behavior, anche se LOLA aveva un gripper
più sofisticato della squadra del Georgia Tech. Al contrario, CHIP la
squadra che vinse il secondo posto nella competizione dell’IJCAI,
aveva 34 skill e 80 RAP per fare lo stesso task.
Poiché in generale gli skills portano ad una implementazione più
complessa degli FSA e degli scripts, non li tratteremo.
Il punto più importante da ricordare nell'assemblaggio dei behavior è
di tentare di avere un sistema di trigger, o releaser, per decidere il
prossimo passo nella sequenza, piuttosto che contare su un modello
interno di quello che il robot ha fatto recentemente.
67
68
Automi a Stati Finiti (FSA)
Gli Automi a Stati Finiti (FSA) sono un meccanismo utile per
specificare quello che un programma dovrebbe fare ad un certo tempo
o circostanza.
Il FSA può essere scritto come una tavola o progettato come un
diagramma di stato, dando così al progettista una rappresentazione
visiva. La maggior parte dei progettisti fanno entrambe le cose.
Ci sono molte varianti di FSA, ma lavorano tutte pressappoco allo
stesso modo.
69
Per cominciare, il progettista deve essere capace di specificare un
numero limitato di stati distinti nei quali il robot potrebbe trovarsi. Il
set di stati è rappresentato da K, e ogni stato q  K è una lista dei
behavior che dovrebbero essere attivi contemporaneamente. Nel caso
della competizione precedente, c’erano solamente due stati: seguire la
linea e muoversi in avanti. Gli stati sono rappresentati in una tavola
sotto l'intestazione q, e da cerchi in un grafico. (Vedi fig.).
70
Per convenzione, vi è sempre un stato di Start, ed il robot dovrebbe
partire sempre di là. Lo stato di Start è spesso scritto come s o q0 e
disegnato con un doppio cerchio. Nel caso dell'UGR, lo stato di
following-line era sempre lo stato di inizio poichè il robot cominciava
col behavior di follow-line attivo.
La successiva parte del FSA è l’input (anche detto alfabeto). Gli input
sono i releasers comportamentali, ed appaiono sotto la colonna dove
capeggia . La tavola del FSM considera quello che accade ad ogni
stato q per tutti i possibili input.
71
Come mostrato in Fig., ci sono solamente due releasers per l'esempio
di UGR, così la tavola non ha molte righe.
72
La terza parte del FSM è la funzione di transizione, detta  che
specifica in che stato va il robot dato uno stimolo in input. Il set di
stimoli o affordances che può essere riconosciuto dal robot è
rappresentato da . Questi stimoli sono rappresentati da frecce. Ogni
freccia rappresenta il releaser per un behavior. Il nuovo behavior
triggerato dal releaser dipende dallo stato nel quale il robot è. Questo è
lo stesso dell’IRM, dove l'animale letteralmente ignora i releasers che
non sono rilevanti per il suo stato corrente.
Si ricordi anche che nella Lez. 3 nella implementazione del
programma seriale dell’IRMs l'agente "osservava“ i releasers ogni
secondo. Ad ogni iterazione, l’agente avrebbe potuto avere fame e
“sarebbe entrato" nello stato di alimentarsi. Nella successiva
iterazione, ancora avrebbe potuto avere fame e sarebbe rientrato nello
stato di alimentarsi. Questo può essere rappresentato avendo frecce
che partono dallo stato di alimentarsi e puntano di nuovo allo stesso
73
stato.
Il codice C è implementato come una sequenza implicita, dove
l’ordine di esecuzione dipende dal valore dei releasers. Una
implementazione come sequenza esplicita potrebbe essere la
seguente:
Releaser
food, hungry, nursed, predator;
while (TRUE)
{
predator = sensePredator() ;
if (predator==PRESENT)
flee() ;
food = senseFood();
hungry = checkStateHunger() ;
parent = checkStateParent() ;
if (hungry==PRESENT)
searchForFood () ;
feed() ;
nurse() ;
sleep() ;
74
}
Per l'esempio in fig, il robot comincia nello stato di seguire una linea.
Questo vuole dire che il robot non è preparato a gestire una distrazione
visuale (range near) finché non ha cominciato a seguire una linea. Se
lo fa, il programma può fallire perché il FSA chiaramente mostra che
non risponderà alla distrazione per almeno un ciclo di aggiornamento.
In questo periodo, il robot può dirigersi in direzioni sbagliate.
Cominciare nello stato di following-line andava bene per la
competizione di UGR, dove si sapeva in anticipo che non c'erano balle
di fieno vicino alla linea iniziale.
75
Un caso più generale è mostrato in Fig. 5.9, dove il robot può partire
sia su un percorso libero sia in presenza di una balla.
76
Il quarto pezzo di informazione che un progettista ha bisogno di
sapere è quando il robot ha completato il task.
Ogni stato che il robot può raggiungere e che termina il task è un
membro del set di stati finali, F.
Nell'esempio di UGR il robot non si ferma mai e non c’è uno stato
finale - il robot funziona finché non è spento a mano o si scarica la
batteria.
Così, entrambi gli stati sono stati finali.
Se il robot potesse riconoscere la linea di arrivo, allora potrebbe avere
un stato finale.
Lo stato finale potrebbe essere giusto fermati o potrebbe essere un
altro behavior, come in caso di vittoria agitare la telecamera.
Si noti che questo aggiunge altre righe alla tabella del FSA, poiché vi
deve essere una riga per ogni singolo stato.
Da molti punti di vista, la tabella del FSA è una estensione della
tabella comportamentale. La tabella risultante è nota come una
macchina a stati finiti (FSM) abbreviato M.
77
La notazione
M = K, , , s, F
è usata per ricordare che per usare un FSA il progettista deve sapere
tutti i q stati (K), gli input  le transizioni tra gli stati , lo stato
iniziale speciale q0 e lo stato/i finale (F). Ci deve essere una freccia nel
diagramma di stato per ogni riga nella tabella .
La tabella sotto compendia le relazioni tra gli FSA e i behavior:
FSA
Behavior
K
Tutti i behaviors per un task

I releasers for ciascun behavior in K

La funzione che calcola il nuovo stato
s
Behavior di start per il robot
F
Behavior che il robot deve eseguire per smettere
78
In domini più complessi, i robot hanno bisogno di evitare ostacoli
(specialmente le persone).
AVOID dovrebbe essere sempre attivo, per cui è spesso implicito nel
FSA.
Move_to_goal è spesso inteso come move_to_goal e AVOID.
Questo raggruppamento implicito di “behavior interessante per il
task" e "quei behavior che proteggono il robot" sono anche visti come
behavior strategici e tattici.
Un altro punto importante circa l’uso dei FSA è che essi descrivono il
behavior complessivo di un sistema, mentre le implementazioni
possono variare.
79
In fig. c’è una descrizione accurata dei cambi di stato all’inizio
dell’UGV. Il controllo per i behavior poteva essere implementato
come indicato dal FSA: se following-line è attiva e range ritorna
range near, allora move-ahead.
Gli esempi seguenti mostreranno come il concetto di FSA può essere
implementato con la sussunzione e i sistemi a schema-theory.
80
Un FSA per la raccolta dell‘immondizia
Come altro esempio di come costruire ed applicare un FSA, si
consideri il task della raccolta dell’immondizia. Supponiamo che il
robot sia un piccolo veicolo, come quelli usati dalla Georgia Tech o il
Pioneer mostrati in Fig., con una telecamera ed un bumper per dire
quando il robot ha urtato qualche cosa. In entrambi i casi, il robot ha
un semplice gripper. Si presume che il robot può dire se il gripper è
vuoto o pieno. Un modo per fare questo è mettere un sensore a IR
attraverso la mascella del gripper. Quando l'IR ritorna uno short range,
il gripper è pieno e si può immediatamente chiudere, con un riflesso di
presa.
Un problema con i grippers è che non sono efficienti come una mano
umana. Così, c'è sempre la possibilità che la lattina scivoli o cada fuori
del gripper.
Il robot dovrebbe però rispondere adeguatamente se mentre sta
81
portando una lattina o della immondizia la perde.
L'ambiente in questo esempio è visualmente semplice, e ci sono ovvie
affordances. Le lattine di Coca-cola sono gli unici oggetti rossi
nell'ambiente, e i bidoni di immondizia sono gli unici oggetti blu.
Estrarre perciò visualmente macchie rosse e blu dovrebbe essere
sufficiente. Tutti gli oggetti sono sul pavimento, così il robot si deve
preoccupare solamente di dove sono gli oggetti sull'asse x.
Uno scenario di base per il robot è cominciare a vagare nella stanza
alla ricerca di macchie rosse. Dovrebbe tirare diritto verso il centro
della macchia rossa più grande finché non vede la lattina. Poi
dovrebbe tentare tre volte di afferrare la lattina, e, se ci riesce,
dovrebbe cominciare a vagare cercando una macchia blu. Ci dovrebbe
essere solamente una macchia blu alla volta nell'immagine perché i
due bidoni di immondizia sono messi in angoli opposti della stanza.
Non appena vede una macchia blu, il robot deve muoversi diritto al
centro della macchia finché la macchia diventa di una certa grandezza
nell'immagine (potendo essere vista anche da lontano).
82
Il robot allora dovrebbe fermarsi, lasciare cadere la lattina, rivolgersi
in una nuova direzione casuale e riprendere il ciclo. Il robot dovrebbe
evitare ostacoli, ma muovendosi verso una macchia rossa o blu
dovrebbe avere un'azione di riferimento prefissata, altrimenti
immediatamente il robot dimentica dove stava andando.
La tavola dei behavior è:
83
Le chiamate di funzione nella tavola mostrano per brevità solo gli
argomenti rilevanti.
Il behavior AVOID è interessante. Il robot quando urta qualche cosa
indietreggia o a destra o a sinistra (usando un NaT). Può urtare un
muro dell’ambiente in diverse posizioni, allora si muoverà in wander
in una qualunque direzione. Se il robot urta una lattina (invece di
afferrarla con il suo gripper), indietreggiando ha una seconda
opportunità. Questa tavola mostra che il progetto conta sul gripper per
sapere a che punto della sequenza nominale si trova il robot. Un
gripper vuoto vuole dire che il robot dovrebbe essere nella fase di
raccolta dell’immondizia, oppure sta cercando una lattina o si sta
muovendo attorno ad essa. Un gripper pieno vuole dire che il robot è
nella fase di deposito. Il releaser significativo estrae la taglia della
regione blu in pixels e la paragona ad una taglia N prefissata. Se la
regione è maggiore o uguale a N allora il robot è abbastanza vicino al
84
bidone e può gettare la lattina
Ci sono due problemi con la tavola dei behavior.
Il primo è che essa non mostra la sequenza o il flusso di controllo
chiaramente.
Il secondo è come fa il progettista a mettere giù questi behavior?
Qui è dove un FSA può essere particolarmente utile. Esso permette
al progettista di saldare le varie sequenze e rappresentare il progetto
dei behavior graficamente.
In fig. è mostrato un FSA equivalente alla tabella
85
86
L’FSA permette di esprimere la sequenza dei behavior. Questo avviene
al prezzo di non poter mostrare con precisione come la sequenza vada
implementata, incoraggiando così il progettista a creare stati interni.
Nel caso in esame il programmatore dovrebbe implementare due
behavior di wander, ciascuno istanziato da releasers differenti, e due
move-to-goal.
Molti progettisti disegnano e interpretano gli FSA come estrattori di
releasers. Per esempio la transizione corretta da GRAB TRASH a
WANDER FOR TRASH CAN (cerca il bidone per le lattine) è FULL
AND NO_BLUE, ma un progettista potrebbe essere tentato di
etichettare le frecce solo come NO_BLUE perchè per raggiungere
quello stato il gripper deve essere FULL.
Questo è un errore molto pericoloso poichè presume che
l’implementazione terrà conto in quale stato interno sia il robot
(inizializzando una variabile), invece di permettere che attributi
direttamente percepibili dal mondo informino il robot in quale stato
egli
87
si trovi. Il concetto di stato interno è incompatibile con la reattività.
Il FSA nasconde anche il ruolo del behavior di AVOID.
L' AVOID behavior sta sempre funzionando, mentre gli altri behavior
sono instanziati e de-instanziati asincronamente.
È difficile con un FSA mostrare behavior concorrenti.
Altre tecniche, in particolare le reti di Petri sono usate in ingegneria
del software ma non sono usate comunemente in robotica.
L' AVOID behavior non è un problema in questo caso.
Esso è sempre attivo e l’output del vettore di campo potenziale
dell'AVOID può essere sommato con l’output di un altro qualunque
behavior attivo.
88
Esempi di realizzazione
In una implementazione in termini di schema-theory, la logica degli
FSA può vedersi da due punti di vista.
Se l’unico compito del robot è riciclare scatole di coca cola, la logica
di controllo potrebbe essere messa nel programma principale.
Se il robot avesse molti compiti da fare, la capacità di riciclare
immondizia sarebbe un behavior astratto, chiamato dal programma
principale ogni qualvolta il robot ha bisogno di riciclare immondizia.
In questo caso, la logica del FSA sarebbe messa nello slot del
programma di controllo coordinato dello schema behavior.
Sebbene la discussione corrente è su dove va messo il FSA, è utile
guardare un momento la realizzazione complessiva.
Mentre i behavior di wander-to-goal e di move_to_goal possono
essere implementati facilmente con una metodologia a campi
potenziale, drop-trash non lo può.
89
Drop-trash in realtà non è un behavior di navigazione. Esso è però
riconducibile ad un behavior rappresentato in termini di schema theory:
ha ovviamente uno schema motore (apri il gripper, gira le ruote),
ha uno schema Percettivo (leggi gli encoders del gripper, e delle ruote),
ha un programma di controllo coordinato (apri THEN gira), ed un
releaser (il bidone delle lattine).
Mentre le implementazioni in termini di schema-theory usano
metodologie a campo di potenziali e vettori somma per il controllo
dell’effettore, non ogni behavior genererà un vettore basato su un
campo potenziale.
90
Un vantaggio degli FSA è che sono astratti, e possono essere
implementato in diversi modi.
La tavola di behavior ha mostrato un modo con cui il FSA potrebbe
essere implementato con un meccanismo di schema-theory.
La Fig. mostra una modo con cui potrebbe essere implementato invece
tramite la sussunzione. Questo esempio mostra il potere dell'inibizione
e soppressione che non sono ben rappresentate dai diagrammi di stato
degli FSA.
91
Nell'idea della modularità e delle aggiunte incrementali di behaviors, il sistema parte
con un behavior esplicito di AVOID che gira sopra il Livello 0 (non mostrato).
Al livello successivo il robot vaga finché vede il rosso.
Poi move_to_trash sopprime wander e sostituisce l’heading con la direzione verso
l'immondizia.
Il behavior di move_to_trash continua finché la lattina è nel gripper. Una volta che il
gripper è pieno, il gripper si chiude ed stringe l'immondizia.
Solo ora il behavior di move_to_trash è inibito.
Questo impedisce a move_to_trash di fornire alcuna direzione, e quindi l’output è di
nuovo la direzione di wandering.
92
Il successivo livello di competenza è depositare l’immondizia nel bidone delle
lattine.
Quando vede bidone delle lattine blu, move_to_trash sopprime wander e dirige il
robot verso il bidone delle lattine.
Se il gripper è vuoto, l’output di move_to_trash è inibito.
Il robot sta cercando simultaneamente macchie rosse e blu, ma finché il gripper è
vuoto, risponde solamente a macchie rosse.
Anche drop_trash viene eseguito continuamente. Se al robot accade di passare
vicino ad un bidone blu, segnalerà di lasciare cadere l’immondizia e ci girerà
attorno. La nuova direzione sopprime ogni altra direzione proveniente da
move_to_trash can.
Ma il robot non aprirà il suo gripper e non girerà attorno se il gripper è vuoto, perché
empty inibisce l’intera linea.
L'esempio con la sussunzione produce un sistema meno complesso di quello fatto
con un FSA.
93
Behavior astratti
Gli automi a stati finiti sono uno strumento utile per scrivere un
programma di controllo coordinato di un behavior astratto e quindi
diventano uno buono strumento di programmazione per i behavior
astratti stessi.
In primo luogo in molti casi, l'assemblaggio di behavior rappresenta,
una sequenza prototipica di eventi che dovrebbero essere adattati
facilmente a situazioni diverse, in pratica, un template o behavior
astratto.
Nel caso della gara Raccogli l’Immondizia, riciclare le lattine di Coca
cola era solo una parte del compito; si supponeva che i robot
trovassero anche tazze bianche e le depositassero in bidoni di
immondizia gialli.
I behavior rappresentati dal FSA possono allora essere raccolti in un
behavior astratto: pick-up-the-trash (trash-color, trash-can-color,
94
size-trash-can).
In secondo luogo, i templates hanno bisogno di gestire condizioni di
inizializzazione diverse.
L’inizializzazione non è un grande problema per Pic-up-the-trash, ma lo
può essere per le altre applicazioni.
Per esempio, il behavior emergente del robot descritto precedentemente
per la competizione di Unmanned Ground Vehicle potrebbe essere
descritto come un behavior astratto di "follow-path".
Si ricordi che il programma del robot presumeva che esso partisse con
la telecamera rivolta verso la linea bianca.
Per gestire una più ampia gamma di condizioni iniziali sarebbe
necessario un general purpose behavior di follow-path riutilizzabile
come ad esempio partire di fronte ad una balla di fieno o non essere
perfettamente allineato alla linea bianca.
95
Un altro behavior comune usato per l’inizializzazione è l’imprinting,
dove al robot è presentato un oggetto e esso si ricorda il colore
percepito (o qualche altro attributo dell'oggetto) per usarlo con un
behavior nominale.
Nella competizione del Pick up the Trash, molte squadre letteralmente
mostrarono al robot la lattina di Coca cola per consentirgli di
determinare i migliori valori di "rosso" nelle condizioni di
illuminazione correnti.
Analogamente, alcuni behavior astratti avrebbero bisogno di speciali
behavior di terminazione.
Nel caso della gare del UGR, i behavior di terminazione erano NULL,
ma sarebbero potuti essere la danza della vittoria.
96
In terzo luogo, delle volte i robot falliscono nel loro compito; questi
eventi spesso sono chiamati eccezioni.
Un'eccezione potrebbe essere quando il robot non raccoglie la lattina
di coca cola entro 10 minuti. Allora può intervenire un altro behavior
(fai una scansione raster piuttosto che un wander casuale) o usa un set
alternativo di parametri (l'uso di valori diversi per il rosso).
97
Gli script
I Behavior astratti spesso usano script o una struttura analoga
chiamata skills, per creare template di assemblaggi di behavior
generici.
Gli script offrono un modo diverso di generare la logica per un
assemblaggio di behavior.
Essi incoraggiano il progettista a pensare al robot e al suo compito
letteralmente in termini di una sceneggiatura.
Gli script sono stati usati originariamente nella elaborazione del
linguaggio naturale (NLP) per aiutare il pubblico (un computer) a
capire gli attori (persone che parlano col computer o scrivono
sommari di quello che fanno).
Nel caso dei robot, gli script possono essere usati più letteralmente,
dove gli attori sono robot che leggono lo script.
Lo script ha più spazio per l’improvvisazione.
Se il robot incontra una condizione inaspettata (un'eccezione), allora il
98
robot comincia a seguire un sub-script.
La Fig. mostra un raffronto tra gli elementi dello script per un attore e
quelli di uno script per un robot.
La sequenza principale di eventi è chiamata una catena causale. La
catena causale è critica, perché incarna il programma logico di
controllo coordinato così come avviene in un FSA.
Può essere implementato nello stesso modo.
In NLP, gli script permettono al computer di tenere conto di una
conversazione che può essere abbreviata.
99
Per esempio, si consideri un computer che tenta di leggere e tradurre
un libro dove i protagonisti principali si sono fermati in un ristorante.
I buoni scrittori spesso eliminano tutti i dettagli di un evento per
concentrarsi su quelli significativi. Questa informazione mancante, ma
implicita, è facile da estrarre.
Supponiamo che il libro cominci con "John ordinò un’aragosta."
Questo è un indizio che serve come un indice rispetto all'evento
corrente o rilevante dello script (mangiare al ristorante), ignorando gli
eventi passati (John è arrivato al ristorante, John ha chiesto un menu,
ecc.).
Gli script concentrano inoltre l'attenzione del sistema sul prossimo
evento più probabile (cerca una frase che indica che John ha fatto una
ordinazione), così il computer può instanziare la funzione che cerca
questo evento. Se la prossima frase è "Armand servì l'aragosta e versò
di nuovo il vino bianco", il computer può inferire che Armand è il
cameriere e che John prima aveva ordinato ed aveva ricevuto del vino
bianco, senza che questo fosse stato detto esplicitamente.
100
Nel programmare un robot, le persone spesso preferiscono abbreviare le
parti delle routine di controllo e si concentrano sulla rappresentazione e
il debug della sequenza di eventi più importanti.
Gli automi a stati finiti costringono il progettista a considerare ed
enumerare ogni possibile transizione, mentre gli script semplificano la
specifica.
I concetti di indexing e focalizzazione dell’attenzione sono
estremamente preziosi per coordinare i behavior nei robot in una
maniera efficiente ed intuitiva.
Le realizzazioni effettive richiedono processi asincroni, ma
l’implementazione di questi processi è oltre lo scopo di questo corso.
101
Per esempio, immaginiamo che un robot per la raccolta della
spazzatura parta.
La prima azione nella catena causale è di cercare le lattine di Coca
cola. Il progettista comprende che questo behavior potrebbe generare
una direzione casuale e muovere il robot, perdendo una lattina che sta
giusto di fronte a lui. Perciò, il progettista vuole che un codice che
permette al robot di ignorare la ricerca nello spazio circostante, non
appena vede una lattina di Coca cola, e che cominci a raccogliere la
lattina senza chiamare il behavior di wander-for-goal(red).
Il progettista sa anche che il prossimo releaser dopo che grab-trash si
attiva per guardare se è blu, perché l'indicazione per muoversi verso il
bidone dell'immondizia e lasciare cadere la lattina è il colore blu.
La scrittura risultante per un behavior astratto che porti a termine un
task è di solito la stessa di quella della programmazione logica dedotta
da un FSA.
Nel caso della Raccolta dell’immondizia, lo script apparirebbe102come
segue:
Per ogni aggiornamento
\\ look for props and cues first: cans, trash cans, gripper
rStatus=extract_color(red, rcx, rSize);
\\ ignore rSize
if (rStatus==TRUE)
\\ stato del rosso
SEE_RED=TRUE;
else
SEE_RED=FALSE;
bStatus=extract_color(blue, bcx, bSize);
if (bStatus==TRUE){
SEE_BLUE=TRUE; NO_BLUE=FALSE; \\ stato del blue
} else {
SEE_BLUE=FALSE; NO_BLUE=TRUE;
}
AT_BLUE=looming(size, bSize);
\\ grandezza del blue
gStatus=gripper_status();
\\ stato del gripper
if (gStatus==TRUE) {
FULL=TRUE; EMPTY=FALSE;
} else {
103
FULL=FALSE; EMPTY=TRUE;
}
\\index
chain
if
into
the correct
step
in
the causal
(EMPTY){
if
(SEE_RED){
move_to_goal(red);
else
wander ();
}
else{
grab_trash();
if
(NO_BLUE)
wander();
else if (AT_BLUE)
drop_trash();
else if
(SEE_BLUE)
move_to__goal (blue) ;
}
104