Sistemi per il Governo dei Robot
Silvia Rossi - Lezione 17
PROGETTAZIONE DI UN SISTEMA REATTIVO
Obiettivi
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 diagramma di stato o con uno pseudocodice in script.
1
Designing a Reactive Implementation
• List the steps involved in designing a reactive behavioral system.
• Use schema theory to program behaviors using object-oriented programming principles.
• Design a complete behavioral system, including coordinating and controlling multiple concurrent behaviors.
• Describe the two methods for assembling primitive behaviors into abstract behaviors: finite state
machines and scripts.
PROGETTAZIONE DI UN SISTEMA REATTIVO
COMPORTAMENTI E SCHEMA THEORY
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.
Il behaviour del nutrirsi può essere modificato come uno schema comportamentale, o modalità come
mostrato sotto.
Sensory Input
Pattern of Motor
Action
Releaser
appearance of small moving object
Toad’s legs
Feeding Behavior Toad’s vision Perceptual
Schema
Get coordinates of small, moving
object
Motor Schema
Turn to coordinates of small, moving
object
Frog snapping a fly
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.
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.
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.
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
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.
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.
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.
move_to_goal(color)
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.
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ù velocemente si muove il robot.
20
SENSORY
INPUT MOVE_TO_GOAL
PATTERN OF MOTOR
ACTION
PFIELDS.ATTRACTION(EXTRACT_GOAL)
SCHEMA
EXTRACT_GOAL
RELEASER
Il behavior move_to_goal 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):
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 librerie 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 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.
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 consisteva di due campi
primitivi:
due istanze di perpendicular ai muri ed una di uniform parallela ai muri.
In qualche maniera, ognuno dei campi primitivi può essere uno schema motore separato.
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.
VL
VR DL DR
VL VR
VF VF
VF+L+R VR-L
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.
VL
VR DL DR
VL VR
VF VF
VF+L+R VR-L
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.
VL
VF+L
DL DR
VL VR
VF VR
VF VF+R
VF+L+R
VF+L VF+R
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.
VL
VF+L
DL DR
VL VR
VF VR
VF VF+R
VF+L+R
VF+L VF+R
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.
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?
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.
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.
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.
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.
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.
PROGETTAZIONE DI UN SISTEMA REATTIVO
DESIGN DI UNA ARCHITETTURA REATTIVA
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.
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.
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.
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.
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 (6)
Prova i behaviour tutti insieme (7).
Questo stile di test è consistente coi principi dell’ingegneria del software, ed enfatizza i
vantaggi pratici del Paradigma Reattivo.
Steps in Designing a Reactive Behavioral System
L'elenco dei passi per implementare un sistema
reattivo può essere fuorviante. Nonostante le frecce di ritorno, il processo complessivo 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.
PROGETTAZIONE DI UN SISTEMA REATTIVO
ESEMPIO
3
CSM 1994 UGV Competition
FROM 1996
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.
Step 1: Descrivere il task
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 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.
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), essere in grado di trasportare un peso di 9 Kg.
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’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++.
4
CAMCORDER ON A
PANNING MAST, GOING TO A FRAMEGRABBER
SONAR ON A PANNING MAST
33MHZ 486 PC RUNNING
LYNX (COMMERCIAL UNIX)
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 range standard del sonar da 7.5mt a circa 3mt.
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.
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.
Il percorso era all’aperto su un campo erboso con piccoli pendii.
Consisteva di una corsia larga 3 mt marcata con vernice bianca.
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.
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.
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.
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.
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.
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.
Behavior table
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, stay-on-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 centroide veniva usata.
Releaser Behavior Motor Schema Percept Perceptual schema always on follow-line() stay-on-path(c_x) c_x Compute-
centroid(image,white)
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.
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.
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ì
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. Descrivere il robot 3. Descrivere l’ambiente
4. Descrivere le reazioni del robot in risposta all’ambiente 5. Raffinare ogni behaviour
6. 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 balla, e seguiva il suo perimetro piuttosto che la linea. Le balle erano viste come "distrazioni visuali."
1. Descrivere il task 2. Descrivere il robot 3. Descrivere l’ambiente
4. Descrivere le reazioni del robot in risposta all’ambiente 5. Raffinare ogni behaviour
6. Verificare ogni behaviour
7. Verificare i behaviour tutti insieme
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.
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.
Behavior Table
Move_ahead
Follow_line T
sonar
TV cam
Releaser Inhibited by Behavior Motor Schema Perc ept
Perceptual schena
always on Near=read_sonar(
)
follow-line() stay-on- path(c_x)
c_x Compute-
centroid(image,white always on Far=read_sonar() Move_ahead(dir )
)
Uniform(dir) dir Dead_reckon(shaft- encoders)
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.
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 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.
8
Final System
• Round 1
– OOPS: sonar connection off so it hit the bale
• Round 2
– White shoes and dandelions
• Demo round
– Hill vs. implicit flat earth assumption
• Round 3
– Trapped by sand, but $5K richer!
9
Main Points
• Let the WORLD BE ITS OWN BEST
REPRESENTATION and CONTROL STRUCTURE
– “line” wasn’t a “line” just centroid of brightest pixels in the image – Pick up trash: if can is in gripper, then go to the recycle bin
• Design process was iterative; rarely get a workable emergent behavior on the first try
• There is no single right answer
• Could have been done with subsumption, pfields, rules, whatever
10
Other Lessons Learned
• Don’t count on getting much work done in the field!
“A RIVER RUNS THROUGH IT…”
11
Case Study and Field Trip:
Polar Robotics
• Existing robots
– Nomad
14
Nomad
• Task
– search for and analyze metorities
• Environment
– Antarctica
• Robot
– hybrid mobility, LADAR, omnivision, sample sensors
• Behaviors
– search an area using GPS, avoid negative/positive obstacles, stop at
possible metorities and alert user. Can be controlled by human
• Refine and Test
• Test with other behaviors
– 1999
– 2000 success
INTRODUCTION TO AI ROBOTICS (MIT CHAPTER 5: DESIGNING A REACTIVE 15
Nomad Omnivision
27
Additional Case Studies:
Commercial Products
• Robomow
– cutting grass in residential areas
• My Real Baby
– toy dolls
30
Commercial Case Studies
• Purely reactive
• May not need subsumption or pfields, very straightforward
• State of practice is much less complicated than state of art!
31
Design Tool: Behavior Table
AN AGENT IS ATTRACTED TO LIGHT. IF IT SEES LIGHT, IT HEADS IN THAT DIRECTION.
IF IT ENCOUNTERS AN OBSTACLE, IT TURNS EITHER LEFT OR RIGHT, FAVORING THE DIRECTION OF THE LIGHT. IF THERE IS NO LIGHT, IT SITS AND WAITS. BUT IF AN
OBSTACLE APPEARS, THE AGENT RUNS AWAY.
1. PHOTROPISM
2. OBSTACLE AVOIDANCE
32
Behavior Table
Releaser Behavior Motor
Schema Percept Perceptual Schema
Light phototropism move2Light():
Attraction
Light:
direction &
strength
Brightest(dir), atLight()
Range
<tasked level>
Obstacle avoidance
avoid(): turn left or right;
runaway()
proximity Obstacle()
AN AGENT IS ATTRACTED TO LIGHT. IF IT SEES LIGHT, IT HEADS IN THAT DIRECTION.
IF IT ENCOUNTERS AN OBSTACLE, IT TURNS EITHER LEFT OR RIGHT, FAVORING THE DIRECTION OF THE LIGHT. IF THERE IS NO LIGHT, IT SITS AND WAITS. BUT IF AN
OBSTACLE APPEARS, THE AGENT RUNS AWAY.
