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 » 20.Dagli Automi a Stati Finiti agli Script


Dagli automi a stati finiti agli script

Proseguendo il caso mostrato nella lezione 19, il programmatore dovrebbe implementare due behavior di wander, ciascuno istanziato da releaser differenti, e due move-to-goal.
Molti progettisti progettano e interpretano gli FSA come estrattori di releaser. Per esempio la transizione corretta da RACCOGLI_SPAZZATURA a CERCA_BIDONE_LATTINE (cerca il bidone per le lattine) è PIENO 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 PIENO.
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à.

EVITA

Il FSA nasconde anche il ruolo del behavior di EVITA.

L’ EVITA 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, usate in ingegneria del software, non sono usate comunemente in robotica.

Il behavior EVITA non è un problema in questo caso.
Esso è sempre attivo e l’output del vettore di campo potenziale dell’EVITA può essere sommato con l’output di un altro qualunque behavior attivo.

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 CocaCola, 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 sia su dove va messo il FSA, è utile guardare un momento la realizzazione complessiva.

Mentre i behavior di cerca_goal e di vai_verso_goal possono essere implementati facilmente con una metodologia a campi potenziale, rilascia_spazzatura non può esserlo.

rilascia_spazzatura

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

FSA

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 schema-theory.
La figura, invece, mostra un modo con cui potrebbe essere implementato tramite la sussunzione. Questo esempio mostra il potere dell’inibizione e soppressione che non sono ben rappresentate dai diagrammi di stato degli FSA.

Schema a sussunzione problema spazzino

Schema a sussunzione problema spazzino


FSA (segue)

Nell’idea della modularità e delle aggiunte incrementali di behavior, 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 vai_verso_spazzatura sopprime vai_in_giro e sostituisce l’heading con la direzione verso l’immondizia.
Il behavior di vai_verso_spazzatura 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 vai_verso_spazzatura è inibito.
Questo impedisce a vai_verso_spazzatura di fornire una direzione, e quindi l’output è di nuovo la direzione di wandering.

Schema a sussunzione problema spazzino

Schema a sussunzione problema spazzino


FSA (segue)

Il successivo livello di competenza è depositare l’immondizia nel bidone delle lattine.
Quando vede il bidone blu delle lattine, vai_verso_spazzatura sopprime wander e dirige il robot verso il bidone delle lattine.
Se il gripper è vuoto, l’output di vai_verso_spazzatura è inibito.
Il robot sta cercando simultaneamente macchie rosse e blu, ma finché il gripper è vuoto, risponde solamente a macchie rosse.

Schema a sussunzione problema spazzino

Schema a sussunzione problema spazzino


FSA (segue)

Anche vai_verso_spazzatura 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 vai_verso_spazzatura can.
Ma il robot non aprirà il suo gripper e non girerà attorno se il gripper è vuoto, perché vuoto inibisce l’intera linea.
L’esempio con la sussunzione produce un sistema meno complesso di quello fatto con un FSA.

Schema a sussunzione problema spazzino

Schema a sussunzione problema spazzino


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: raccogli-la-spazzatura (colore-spazzatura, colore-bidone-spazzatura, size-bidone-spazzatura).

Behavior astratti (segue)

In secondo luogo, i templates hanno bisogno di gestire condizioni di inizializzazione diverse.

L’inizializzazione non è un grande problema per Pic-up-the-trash, ma lo può essere per le altre applicazioni.

Per esempio, il behavior emergente del robot descritto precedentemente per la competizione di Unmanned Ground Vehicle potrebbe essere descritto come un behavior astratto di “follow-path”.
Si ricordi che il programma del robot presumeva che esso partisse con la telecamera rivolta verso la linea bianca.

Per gestire una più ampia gamma di condizioni iniziali sarebbe necessario un general purpose behavior di follow-path riutilizzabile come, ad esempio, partire di fronte ad una balla di fieno o non essere perfettamente allineato alla linea bianca.

Behavior astratti (segue)

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.

Behavior astratti (segue)

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

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 (segue)

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), allora il robot comincia a seguire un sub-script.

Gli script (segue)

La figura 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.

Confronto tra script e behavior

Confronto tra script e behavior


Gli script (segue)

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 (segue)

Gli script concentrano inoltre l’attenzione del sistema sul prossimo evento più probabile (cerca una frase che indica che John ha fatto una ordinazione), così il computer può instanziare la funzione che cerca questo evento.

Se la prossima frase è “Armand servì l’aragosta e versò di nuovo il vino bianco”, il computer può inferire che Armand è il cameriere e che John prima aveva ordinato ed aveva ricevuto del vino bianco, senza che questo fosse stato detto esplicitamente.

Gli script (segue)

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 va oltre lo scopo di questo corso.

Esempio

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 si accorge che questo behavior potrebbe generare una direzione casuale e facendo muovere il robot, perde 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 vai-verso-goal (rosso).

Esempio (segue)

Il progettista sa anche che il prossimo releaser, dopo che grab-trash 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.
Nel caso della Raccolta dell’immondizia, lo script apparirebbe come descritto nelle prossime slide.

Esempio (segue)


Esempio (segue)


Proposte di progetti

Hardware

Cataglyphis. Simulare il comportamento di due formiche.

Cataglyphis. Entrambe partono dalla tana e in maniera casuale vanno a cercare il cibo. Quando una delle due lo trova, accende una luce si fa raggiungere dall’altra e poi va direttamente alla tana. La stessa cosa farà la seconda formica.

  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.

Proposte di progetti (segue)

Simulazione

Operai – Dato un ambiente con ostacoli fissi di colore blu, contenenente un certo numero di oggetti gialli. Progettare un team di robot (da due a 5 a scelta) che individuano gli oggetti gialli e li spingono (o trasportano insieme) in una prefissata posizione di accumulo.

  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.
  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
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