CORSO SISTEMI DI GOVERNO DEI ROBOT Lezione n.5

Presentazione sul tema: "CORSO SISTEMI DI GOVERNO DEI ROBOT Lezione n.5"— Transcript della presentazione:

1 CORSO SISTEMI DI GOVERNO DEI ROBOT Lezione n.5
Progettazione di un sistema Reattivo prof. Ernesto Burattini

2 Proposta di progetto Sia assegnato un ambiente chiuso con ostacoli. Assegnata una tana, si vogliono raccogliere una serie di cubi accumulati in alcuni luoghi non noti all’interno dell’ambiente. Raccogliere un cubo alla volta e portarlo alla tana, evitando gli ostacoli e cercando il percorso migliore. Terminati i cubi accumulati in un posto cercare gli altri. Gli ostacoli sono di colore blu, i cubi di colore rosso, la tana di colore giallo. Dotare il robot di un sistema sensoriale facendo ricorso a sensori disponibili sul mercato (sonar, bumper, bussole, luminosità (colore), suoni, etc.). Può esserci una piccola memoria ma il paradigma di riferimento deve essere quello reattivo.

3 Obiettivi della lezione
Usare lo schema theory per progettare behavior usando la programmazione a oggetti. Progettare un sistema comportamentale completo, includendo il coordinamento e il controllo di behavior concomitanti e multipli. Per un dato sistema comportamentale, disegnare una tabella comportamentale che specifichi i releasers, 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.

4 Equipaggiamenti come Lego Mindstorms, 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 behavior bene progettati e testati, come si integrano in un sistema?

5 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 e 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.

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

7 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. Questo capitolo tenta di aiutare il progettista a costruire un sistema di 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 ecologica per un robot reattivo.

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.

9 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 nella Lez. 3, che entrambe queste tecniche sembreranno molto simili all’ IRM di Tinbergen e Lorenz.

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

11 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

12 Schema motore, Schema Percettivo e Behavior.
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 in un vettore o altra forma di 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.

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

14 Si ricordi che un behavior primitivo è composto solo di uno schema percettivo e uno schema a 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 sono assemblati da 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.

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

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

17 Behavior generici condividono anche la stessa filosofia come la fattorizzazione in matematica.
Si voglia semplificare l'equazione 45x2 + 90x Il primo passo è semplificare l'equazione trovando i fattori comuni. In questo caso, 45 può essere messo in evidenza e l'equazione riscritta come 45(x + 1)2. Il colore del goal, rosso o azzurro, è come il coefficiente comune 45; è importante, ma tende a nascondere che la chiave alla soluzione era la x in questo caso la direzione in move_to_goal.

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 usa un campo attrattore chiamato pfields.attraction.extract_goal che usa l'affordance del colore per estrarre dove è nell'immagine il goal, e 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.

19 Releaser Pattern Sensory of Motor Input Action Schema move_to_goal
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):

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 pfields su pfields. attraction() vuole dire che quell'attrazione è un metodo all'interno di un altro oggetto identificato come pfields. I cinque campi di potenziali 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 potenziali in PFields sono scritti e verificati, il progettista non deve più programmarli di nuovo.

22 3. I Behavior si possono riusare se scritti adeguamente
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 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.

24 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 in che modo è diretto, ecc. Questi campi sono sommati dal programma di controllo coordinato nello schema comportamentale per produrre un solo vettore di uscita. DL DR VL VR VF VF VR-L DL , DR VF+L+R VF VR-L VR VL

25 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. DL DR VL VR VF VF VR-L DL , DR VF+L+R VF VR-L VR VL

26 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. 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. VR VF VF+R DL VF+R VF+L VR VL DR VL VF+L VF+L+R VF+L VF+R DL DR VL VR VF

27 Dove vanno a finire i releasers 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 è "attaccato" al comportamento?

28 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. Il programma principale può stabilire che il releaser per il behavior move_to_goal è stato soddisfatto, e quindi instanziare move_to_goal() con goal = red.

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

30 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 programmare può limitare alcune risorse, ma è un modo semplice ed efficace di programmare.

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

32 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 perseguire una Coca cola rossa o 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.

33 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 ampia discussione sul processo di progettazione, poi si esamineranno i vari passi usando un approccio del 1994. La metodologia in fig. presume che a un progettista è dato: il task che il robot deve fare (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.

34 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 un novizio comincia a capire che progettare behavior è un'arte.

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

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

37 I passi 5-7 sono meno astratti
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 integrare tutti i comportamenti (7). Questo stile di test è consistente coi principi dell’ingegneria del software, ed enfatizza i vantaggi pratici del Paradigma Reattivo.

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

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

40 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 per prepararsi ed esaminare la pista del percorso; l’ordine di partenza fu sorteggiato.

41 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 fissi dalla piattaforma del robot che hanno un impatto sulla relativa progettazione.

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

43 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 albero vicino al centro del veicolo ed un sonar panoramico montato sotto una grata sul davanti. L’output della videocamera veniva digitalizzata da un sistema bianco e nero. Il sonar era un Polaroid. L'apparecchiatura aveva una panoramica di 180°. Ogni codifica era fatta in C++.

44 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. Una acquisizione in bianco e nero eliminò il problema del colore. Inoltre, la velocità di aggiornamento del framegrabber 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.

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

46 Il percorso era all’aperto su un campo erboso con piccoli pendii
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.

47 Il sonar era capace di scoprire affidabilmente le balle coperte e 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.

48 L'analisi dell'ambiente permise una semplificazione del compito
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.

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

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

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

52 Behavior Table Releaser Behavior Motor Schema Percept Perceptual schema always on follow-line() stay-on-path(c_x) c_x Compute-centroid(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 un 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 x, c_x, o ubicazione orizzontale, del centroide veniva usata.

53 Step 5. Raffinare ogni behavior.
A questo punto, il progettista ha un'idea complessiva dell'organizzazione del sistema reattivo e cosa 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 quando il behavior fallisce.

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

55 Cosa era accaduto da fare tornare Omnibot nei confini
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.

56 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 Nomads, vengono forniti con simulatori impressionanti. 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.

57 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."

58 Le balle fortunatamente erano relativamente piccole
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.

59 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. In fig. si vede questa inibizione, e la nuova Behavior Table.

60 Nuova Behavior Table Move_ahead Follow_line T sonar TV cam Releaser
Inhibited by Behavior Motor Schema Percept Perceptual schena always on Near=read_sonar() follow-line() stay-on-path(c_x) c_x Compute-centroid(image,white) Far=read_sonar() Move_ahead(dir) Uniform(dir) dir Dead_reckon(shaft-encoders) Move_ahead Follow_line T sonar TV cam

61 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 fine. 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.

62 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 collegarli. 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 framegrabber della visione.

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

64 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 releasers che determinano la sequenza. Il problema è come rappresentare formalmente i releasers 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.

65 La stessa struttura a schema dell’OOP, usata per raccogliere uno Schema Percettivo ed uno schema motore in un behavior, può essere usata per raccogliere 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 il releasers per i behavior componenti.

66 Resta il problema di come rappresentare formalmente i releasers in maniera che il robot li possa eseguire ed il progettista umano li possa visualizzare e diagnosticare. Ci sono tre maniere per compattare 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.

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

68

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

70 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 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. (Vedi fig.).

71 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, 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 releasers comportamentali, ed appaiono sotto la colonna dove capeggia . La tavola del FSM considera quello che accade ad ogni stato q per tutti i possibili input.

72 Come mostrato in Fig., ci sono solamente due releasers per l'esempio di UGR, così la tavola non ha molte righe.

73 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 è. Questo è lo stesso dell’IRM, dove l'animale letteralmente ignora i releasers che non sono rilevanti per il suo stato corrente. Si ricordi anche che nella Lez. 3 nella implementazione del programma seriale dell’IRMs l'agente "osservava“ i releasers 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.

74 Il codice C è implementato come una sequenza implicita, dove l’ordine di esecuzione dipende dal valore dei releasers. Una implementazione come sequenza esplicita potrebbe essere la seguente: Releaser food, hungry, nursed, predator; while (TRUE) { predator = sensePredator() ; if (predator==PRESENT) flee() ; food = senseFood(); hungry = checkStateHunger() ; parent = checkStateParent() ; if (hungry==PRESENT) searchForFood () ; feed() ; nurse() ; sleep() ; }

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

76 Un caso più generale è mostrato in Fig. 5
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.

77 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 sono stati finali. Se il robot potesse riconoscere la linea di arrivo, allora potrebbe avere un stato finale. Lo stato finale potrebbe essere giusto 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 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 macchina a stati finiti (FSM) abbreviato M.

78 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 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 releasers for 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

79 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 implementazioni possono variare.

80 In fig. c’è una descrizione accurata dei cambi di stato all’inizio dell’UGV. Il controllo per i behavior poteva essere implementato come indicato dal FSA: se following-line è attiva 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 schema-theory.

81 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 una telecamera ed un bumper per dire quando il robot ha urtato qualche cosa. 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 grippers è 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 portando una lattina o della immondizia la perde.

82 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 vede la 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 essere vista anche da lontano).

83 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 è:

84 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 (usando un NaT). 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 robot è abbastanza vicino al bidone e può gettare la lattina

85 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 mettere giù 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

86

87 L’FSA permette di esprimere la sequenza dei behavior
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 releasers differenti, e due move-to-goal. Molti progettisti disegnano e interpretano gli FSA come estrattori di releasers. 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à.

88 Il FSA nasconde anche il ruolo del behavior di AVOID.
L' AVOID behavior sta sempre funzionando, 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. L' AVOID behavior 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.

89 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 potenziale, drop-trash non lo può.

90 Drop-trash in realtà non è un behavior di navigazione
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), ed un releaser (il bidone delle lattine). Mentre le implementazioni in termini di schema-theory usano metodologie a campo di potenziali e vettori somma per il controllo dell’effettore, non ogni behavior genererà un vettore basato su un campo potenziale.

91 Un vantaggio degli FSA è che sono astratti, e possono essere implementato in diversi modi.
La tavola di behavior ha mostrato un modo con cui il FSA potrebbe essere implementato con un meccanismo di schema-theory. 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.

92 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. Il behavior di move_to_trash continua finché la lattina è nel gripper. Una volta che il gripper è pieno, il gripper si chiude ed stringe l'immondizia. Solo ora il behavior di move_to_trash è inibito. Questo impedisce a move_to_trash di fornire alcuna direzione, e quindi l’output è di nuovo la direzione di wandering.

93 Il successivo livello di competenza è depositare l’immondizia nel bidone delle lattine.
Quando vede bidone delle lattine blu, 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. 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.

94 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 uno buono 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-can-color, size-trash-can).

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

96 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. Nella competizione del Pick up the Trash, molte squadre letteralmente mostrarono 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.

97 In terzo luogo, delle volte i robot falliscono nel loro compito; questi eventi spesso sono chiamati eccezioni. Un'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).

98 Gli script I Behavior astratti spesso usano script o una struttura analoga chiamata skills, per creare template 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, dove gli attori sono robot che leggono lo script. Lo script ha più spazio per l’improvvisazione. Se il robot incontra una condizione inaspettata (un'eccezione), allora il robot comincia a seguire un sub-script.

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

100 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. Supponiamo che il libro cominci con "John ordinò un’aragosta." Questo è un indizio che serve come un indice rispetto all'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 stato detto esplicitamente.

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

102 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 che un codice che permette 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 grab-trash si attiva per guardare se è 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 segue:

103 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; FULL=FALSE; EMPTY=TRUE;

104 \\index into the correct step in the causal chain
if (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) ; }