Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Ernesto Burattini » 18.Progettazione di un sistema Reattivo - 3


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.

Step 4: Descrizione delle reazioni del robot in risposta all’ambiente (segue)

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, resta_nel_sentiero(centroide) che era riflessivo (stimolo-risposta) e taxonomico (orientava il robot in funzione dello stimolo).
Lo Schema Percettivo, Calcola_centroide(immagine,bianco), 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.


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

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.

Il behavior di follow-line (segue)

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.


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.”


Step 7: Test con gli altri behavior (segue)

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 muovi_in_avanti.
L’approccio al problema di quando ignorare la visione era di usare il sonar come un releaser per muovi_in_avanti. Il sonar era puntato sulla linea ed ogni qualvolta faceva una lettura, muovi_in_avanti interveniva per due secondi.

Step 7: Test con gli altri behavior (segue)

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 muovi_in_avanti essenzialmente interdivano follow_line, mentre la mancanza di un releaser del sonar interdiva muovi_in_avanti.
Entrambi i behavior funzionavano continuamente, ma solo uno aveva qualche influenza su quello che il robot faceva.

Nuova Behavior Table

Tavola dei behavior

Tavola dei behavior


Nuova Behavior Table (segue)


Versione finale

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.

Versione finale (segue)

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.

Versione finale (segue)

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 muovi_in_avanti 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.

Assemblaggio 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 sequenza logica in un modulo separato.

Assemblaggi di Behavior (segue)

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.

Struttura OOP dei behavior

Struttura OOP dei behavior


Assemblaggi di Behavior (segue)

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;
  • script;
  • 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.

Assemblaggi di Behavior (segue)

Gli Scripts furono usati dalla squadra della CSM nella competizione del 1995; essi dal punto di vista comportamentale funzionarono come per le squadre vincenti ma la squadra non entrò in classifica a causa di una penale dovuta alla mancanza di un manipolatore. Queste squadre usarono al massimo otto behavior, anche se LOLA aveva un gripper più sofisticato della squadra del Georgia Tech. Al contrario, CHIP la squadra che vinse il secondo posto nella competizione dell’IJCAI, aveva 34 skill e 80 RAP per fare lo stesso task.
Poiché in generale gli skills portano ad una implementazione più complessa degli FSA e degli scripts, non li tratteremo.
Il punto più importante da ricordare nell’assemblaggio dei behavior è di tentare di avere un sistema di trigger, o releaser, per decidere il prossimo passo nella sequenza, piuttosto che contare su un modello interno di quello che il robot ha fatto recentemente.

Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93