Sistemi per il Governo dei Robot
Silvia Rossi - Lezione 18
PROGETTAZIONE DI UN SISTEMA REATTIVO
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
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.
Primo, è presentato un approccio diretto alla programmazione a oggetti per i behavior.
Il caso di studio enfatizza l'importanza di stabilire
una nicchia ecologica per un robot reattivo.
Secondo, sono presentate due tecniche per
maneggiare sequenze di behavior: automi a stati finiti e script.
Tecniche sembreranno molto simili all’IRM di
Tinbergen e Lorenz.
Assemblaggio di behaviors
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 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.
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 Reazione-
Azione Packages (RAPs), in un "piano abbozzato" che può essere poi riempito man mano che il robot li esegue.
Coordinazione e controllo con behavior tipo FSA furono usati con successo dal team della Georgia che vinse nel 1994 la gara di
raccolta della spazzatura dell’AAAI, e dal team LOLA vincente nella
stessa competizione dell’JCAI nel 1995.
Gli Scripts furono usati dalla squadra della CSM nella competizione del 1995; essi dal punto di vista comportamentale funzionarono
come per le squadre vincenti ma la squadra non entrò in classifica a causa di una penale dovuta alla mancanza di un manipolatore.
Queste squadre usarono al massimo otto behavior, anche se LOLA aveva un gripper più sofisticato della squadra del Georgia Tech. Al contrario, CHIP la squadra che vinse il secondo posto nella
competizione dell’IJCAI, aveva 34 skill e 80 RAP per fare lo stesso task.
Poiché in generale gli skills portano ad una implementazione più complessa degli FSA e degli scripts, non li tratteremo.
Il punto più importante da ricordare nell'assemblaggio dei behavior
è di tentare di avere un sistema di trigger, o releaser, per decidere il
prossimo passo nella sequenza, piuttosto che contare su un
Georgia T.
LOLA
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.
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.
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.
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.
Si ricordi anche che in un esempio precedente 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.
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() ;
UGV competition
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.
Caso più generale
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 UGV 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.
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 .
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
FSA Summary
• “State” doesn’t mean “state of world” (bad); it means more “where the innate releasing
mechanism is currently at” (good)
• Advantages
– Formal mechanism
– Have to fill in the table, so a way of spotting unforseen effects
• Disadvantages
– Hard to keep up with implicit behaviors
• Ex. Avoid obstacle is often running throughout ALL states, gets tedious to express it formally
