1
LEZ. 16
2
Obiettivi della lezione
• Usare lo schema theory per progettare behavior con la
programmazione a oggetti.
• Progettare un sistema comportamentale completo, includendo il
coordinamento e il controllo di behavior concomitanti e multipli.
• Per un dato sistema, progettare una tabella comportamentale che
specifichi i releaser, 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 o Robotech, 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
4
behavior ben progettati e testati, come si integrano in un sistema?
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 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 di
comportamenti,
che
funzionano
secondo
una
sequenza
riconoscibile.
5
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 macro-behavior, dove la struttura dello schema è usata
ricorsivamente per semplificare la programmazione del
programma di controllo.
Questa parte del corso tenta di aiutare il progettista a costruire un
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
7
ecologica per un robot reattivo.
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
nelle lezioni precedenti, che entrambe queste tecniche
sembreranno molto simili all’IRM di Tinbergen e Lorenz.
8
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
9
Il behaviour del nutrirsi può essere modificato come uno schema
comportamentale, o modalità come mostrato sotto.
Releaser
appearance of
small moving object
Toad’s vision
Sensory
Input
Perceptual
Schema
Motor
Schema
Get coordinates
of small, moving
object
Turn to coordinates
of small, moving
object
Toad’s legs
Pattern
of Motor
Action
Feeding Behavior
10
11
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.
12
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
13
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
dato sotto forma di vettore o di altra 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
14
l’hardware.
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.
15
Si ricordi che un behavior primitivo è composto solo di uno
schema percettivo e uno schema 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 assemblano 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.
16
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
17
visione del robot essendo di colore rosso e blu.
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 di programmazione.
18
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 userà un
campo attrattore chiamato pfields.attraction.extract_goal che usa
l'affordance del colore per estrarre dove è nell'immagine il goal,
per 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ù
19
velocemente si muove il robot.
Releaser
Sensory
Input
move_to_goal
Pattern
of Motor
Action
Schema
extract_goal
pfields.attraction.extract_goal
20
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
Data
percept
Methods
Identifier
goal_angle
goal_strength
perceptual_schema extract_goal(goal_color)
motor_schema
pfields.attraction(goal_angle,goal_strength)
21
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 di pfields su pfields.attraction() vuole dire che
quell'attrazione è un metodo all'interno di un altro oggetto
identificato come pfields.
I cinque campi di potenziale 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 di potenziali in PFields sono scritti
e
22
verificati, il 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.
23
LEZ. 17
24
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.
25
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 e 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
26
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
27
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.
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
28
DL
DR
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
29
DL
DR
Dove vanno a finire i releaser 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
è
30
"attaccato" al comportamento?
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 a meno che non abbia già nel gripper una lattina.
Il programma principale può stabilire che il releaser per il
behavior move_to_goal è stato o meno soddisfatto, e quindi
eventualmente instanziare move_to_goal() con goal = red.
31
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.
32
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 programmazione può limitare alcune risorse, ma è
un modo semplice ed efficace di programmare.
33
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.
34
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
cercare una Coca cola rossa e 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.
35
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 discussione sul processo di progettazione, poi si
esamineranno i vari passi.
La metodologia in fig. presume che a un progettista sia dato: il task
che il robot deve perseguire (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.
36
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 si comincia a capire che progettare
behavior è un'arte.
37
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.
38
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.
39
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 provare i behaviour
tutti insieme (7). Questo stile di test è consistente coi principi
dell’ingegneria del software, ed enfatizza i vantaggi pratici del
Paradigma Reattivo.
40
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.
41
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.
42
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
43
per prepararsi ed esaminare la pista del percorso; l’ordine
di
partenza era 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 determinati
dalla piattaforma del robot che hanno un impatto sulla relativa
progettazione.
44
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 on-board 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).
45
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 onboard 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’asta vicino al centro del veicolo
• un sonar panoramico montato sotto una grata sul davanti.
L’output della videocamera veniva digitalizzato in bianco e nero.
Il sonar era un Polaroid. L'apparecchiatura aveva una
panoramica di 180°.
Ogni codifica era fatta in C++.
46
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.
L’acquisizione in bianco e nero eliminò il problema del colore.
Inoltre, la velocità di aggiornamento del frame-grabber 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 47range
standard del sonar da 7.5mt a circa 3mt.
LEZ.18
48
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.
49
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.
50
Il sonar era capace di scoprire affidabilmente le balle coperte 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.
51
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.
52
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.
53
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
54 del
motore.
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
55
muoversi verso l'ultima ubicazione nota del goal.
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 uno schema motore, stayon-path(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 c_x, o ubicazione orizzontale, del
56
centroide veniva usata.
Step 5. Raffinare ogni behavior.
A questo punto, il progettista ha un'idea complessiva
dell'organizzazione del sistema reattivo e quali 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 quelle per le quali il behavior
fallisce.
1.
2.
3.
4.
5.
Descrivere il task
Descrivere il robot
Descrivere l’ambiente
Descrivere le reazioni del robot in risposta all’ambiente
Raffinare ogni behaviour
57
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
58
CSM si scambiò occhiate confuse.
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 59reagì
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 Pioneer,
vengono forniti di ottimi simulatori.
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.
1. Descrivere il task
2.
3.
4.
5.
6.
Descrivere il robot
Descrivere l’ambiente
Descrivere le reazioni del robot in risposta all’am
Raffinare ogni behaviour
60
Verificare ogni behaviour
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
1. Descrivere il task
balla, e seguiva il suo 2. Descrivere il robot
3. Descrivere l’ambiente
perimetro piuttosto
4. Descrivere le reazioni del robot in risposta all’ambiente
che la linea. Le balle 5. Raffinare ogni behaviour
6. Verificare ogni behaviour
erano viste come
61
7. Verificare i behaviour tutti insieme
"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.
62
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.
63
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
64
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 arrivo.
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.
65
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 attaccarli. 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
66
aggiornamento del frame-grabber 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
puramente reattivi di assegnare un sensore per behavior. 67
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 releaser che determinano
la sequenza. Il problema è come rappresentare formalmente i
releaser 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 la loro
68
sequenza logica in un modulo separato.
La stessa struttura a schema dell’OOP, usata per rappresentare
uno Schema Percettivo ed uno schema motore in un behavior, può
essere usata per rappresentare 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 i releaser per i behavior componenti.
69
Resta il problema di come rappresentare formalmente i releaser in
maniera che il robot li possa eseguire ed il progettista umano li
possa visualizzare e diagnosticare.
Ci sono tre maniere per rappresentare 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
70
nella 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
71
un modello interno di quello che il robot ha fatto recentemente.
72
LEZ.19
73
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.
74
http://www.dis.uniroma1.it/~terpa/sw/public_html/Lez2_tut3.htm
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/potrebbero 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.
, time
75
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, (Unmanned
Ground Vehicle) 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 releaser comportamentali, ed appaiono sotto la colonna
dove campeggia . La tavola del FSA considera quello che accade ad
ogni stato q per tutti i possibili input.
76
Come mostrato in Fig., ci sono solamente due releaser per
l'esempio di UGR, così la tavola non ha molte righe.
, time }
77
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 si trova. Questo è lo stesso dell’IRM, dove letteralmente
vengono ignorati i releaser che non sono rilevanti per lo stato
corrente.
, time}
78
Si ricordi anche che nella Lez. 3 nella implementazione del
programma seriale dell’IRMs l'agente "osservava“ i releaser 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 stato.
79
enum
Releaser={PRESENT, NOT_PRESENT};
Releaser
food, hungry, nursed, predator;
while (TRUE)
{ predator = sensePredator() ;
if (predator==PRESENT) flee() ;
food = senseFood();
hungry = checkStateHunger() ;
parent = checkStateParent() ;
if (hungry==PRESENT)
searchForFood() ;
if (hungry==PRESENT && food==PRESENT)
feed() ;
if(hungry== NOT_PRESENT && parent==PRESENT)
nurse() ;
if(nursed==PRESENT)
80
sleep() ; }
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.
, time }
81
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.
82
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 (Follow_line e Move_ahead) sono stati
finali.
Se il robot potesse riconoscere la linea di arrivo, allora potrebbe
aversi un stato finale.
Lo stato finale potrebbe essere 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 almeno 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
83
macchina a stati finiti (FSM) abbreviato M.
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 s=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 releaser per 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
84
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
85
implementazioni possono variare.
In fig. c’è una descrizione accurata dei cambi di stato all’inizio
dell’UGV. Il controllo per il behavior poteva essere implementato
come indicato dal FSA: se following-line è attivo 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 schematheory.
86
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 un bumper, per dire quando
il robot ha urtato qualche cosa, ed una telecamera. 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 gripper è 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
87
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 arriva alla
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
88
essere vista anche da lontano).
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 è:
5
89
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 è:
5
90
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. 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
91
robot è abbastanza vicino al 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 rappresentare graficamente
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
92
93
LEZ. 20
94
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 releaser differenti, e due
move-to-goal.
95
Molti progettisti progettano e interpretano gli FSA come estrattori
di releaser. 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 si trovi. Il concetto di stato interno è incompatibile con la
reattività.
96
Il FSA nasconde anche il ruolo del behavior di AVOID.
L' AVOID sta sempre in funzione, 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.
Il behavior AVOID 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.
97
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
98
potenziale, drop-trash non lo può.
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),
ha un releaser (il bidone delle lattine).
Mentre le implementazioni in termini di schema-theory usano
metodologie a campi di potenziale e vettori somma per il controllo
dell’effettore, non ogni behavior genererà un vettore basato su un
campo potenziale.
99
Un vantaggio degli FSA è che sono astratti, e possono essere
implementati in diversi modi.
La tavola dei behavior ha mostrato un modo con cui il FSA
potrebbe essere implementato con un meccanismo di schematheory. 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.
100
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.
101
Il behavior di move_to_trash continua finché la lattina è nel
gripper. Una volta che il gripper è pieno, il gripper si chiude e
stringe l'immondizia.
Solo ora il behavior di move_to_trash è inibito.
Questo impedisce a move_to_trash di fornire una direzione, e
quindi l’output è di nuovo la direzione di wandering.
102
Il successivo livello di competenza è depositare l’immondizia nel
bidone delle lattine.
Quando vede il bidone blu delle lattine, 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.
103
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.
104
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 un buon 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-can105
color, 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 "followpath".
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.
106
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 (in realtà si fa una
calibrazione del sensore).
Nella competizione del Pick up the Trash, molte squadre
letteralmente mostravano 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.
107
In terzo luogo, delle volte i robot falliscono nel loro compito;
questi eventi spesso sono chiamati eccezioni.
Una 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).
108
Gli script
I Behavior astratti spesso usano script o una struttura analoga
chiamata skills, per creare template (o modelli) 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, in quanto gli attori sono robot che leggono lo script.
Lo script lascia più spazio all’improvvisazione.
Se il robot incontra una condizione inaspettata (un'eccezione),
109
allora il 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.
110
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 per il lettore.
Supponiamo che il libro cominci con "John ordinò un’aragosta."
Questo è un indizio che serve per identificare l'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
111
stato detto esplicitamente.
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.
112
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 un
codice che permetta 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 grabtrash si attiva, è di guardare se c’è un 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.
113
Nel caso della Raccolta dell’immondizia, lo script apparirebbe
114
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 {
FULL=FALSE; EMPTY=TRUE;
115
}
\\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) ;
}
116