1

2

LEZ. 16

3

Obiettivi della lezione

• Usare lo schema theory per progettare behavior con la programmazione a oggetti.

• Progettare un sistema comportamentale completo, includendo il coordinamento e il controllo di behavior concomitanti e multipli.

• Per un dato sistema, progettare una tabella comportamentale che specifichi i releaser, gli schemi percettivi e motori per ogni comportamento.

• Descrivere due metodi per assemblare e coordinare behavior primitivi all'interno di un behavior astratto: automi a stati finiti e script.

•Essere capaci di rappresentare una sequenza di behavior con un diagramma di stato o con uno pseudocodice in script.

4

Equipaggiamenti come Lego Mindstorms o Robotech, 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 ben 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 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.

Questa parte del corso tenta di aiutare il progettista a costruire un 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

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 nelle lezioni precedenti, che entrambe queste tecniche sembreranno molto simili all’IRM di Tinbergen e Lorenz.

9

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.

SensoryInput

BEHAVIORPattern of MotorAction

Schemamotorio

Schemapercettivo

Releaser

10

Il behaviour del nutrirsi può essere modificato come uno schema comportamentale, o modalità come mostrato sotto.

SensoryInput

Pattern of MotorAction

Releaserappearance of

small moving object

Toad’s legs

Feeding Behavior

Toad’s visionPerceptual

Schema

Get coordinatesof small, moving

object

MotorSchema

Turn to coordinatesof small, moving

object

11

12

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.

13

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

14

Tre classi sono derivate dalla Classe Schema: Schema motore, Schema Percettivo e Behavior.

I Behavior sono composti da almeno uno Schema Percettivo ed uno Schema Motore; questi schemi si comportano come metodi per la classe Behavior.

Lo Schema Percettivo ha almeno un metodo; tale metodo prende in input il sensore e lo trasforma in una struttura dati detta percetto.

Lo Schema motore ha almeno un metodo che trasforma il percetto dato sotto forma di vettore o di altra rappresentazione in un'azione.

Lo Schema Percettivo è collegato ai sensori, mentre lo Schema motore è collegato agli attuatori del robot. I sensori e gli attuatori possono essere rappresentati se necessario dalle loro proprie classi software; questo è utile quando si usano driver software per l’hardware.

15

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.

16

Si ricordi che un behavior primitivo è composto solo di uno schema percettivo e uno schema motore; non c'è nessun bisogno di avere alcun programma di controllo per il coordinamento.

Si può pensare che i Behavior primitivi siano monolitici, in quanto essi fanno solo una cosa. Poiché di solito essi sono un semplice mapping tra lo stimolo e la risposta, sono spesso programmati come un solo metodo, non composti da metodi multipli od oggetti.

I Behavior che assemblano altri behavior o hanno schemi percettivi multipli e schemi motore li chiameremo “behavior astratti”, perché, rispetto a un behavior primitivo, sono alquanto lontani dai sensori e dagli attuatori.

L'uso del termine “behavior astratto" non deve essere confuso con una classe astratta in OOP.

17

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.

18

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.

19

Un codice modulare, generico può essere ben gestito dagli schemi.

Il behavior move_to_goal consisterà di uno schema percettivo che sarà chiamato extract_goal ed uno schema motore che userà un campo attrattore chiamato pfields.attraction.extract_goal che usa l'affordance del colore per estrarre dove è nell'immagine il goal, per poi calcolare l'angolo al centro della regione colorata e la grandezza della regione.

Queste informazioni formano il percetto del goal; l’affordance della lattina di Coca cola può essere il colore, mentre le informazioni estratte dalla percezione sono l'angolo e la grandezza. Lo schema motore attrattivo riceve il percetto ed è responsabile di far girare il robot verso il centro della regione rossa e muoverlo in avanti. Questo si può fare facilmente usando un campo attrattivo, in cui più grande è la regione, più forte è l'attrazione e più velocemente si muove il robot.

20

SensoryInput

move_to_goalPattern of MotorAction

pfields.attraction.extract_goal

Schema

extract_goal

Releaser

21

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

Object Behavioral Analog Identifier

Data percept goal_angle goal_strength

Methods perceptual_schema motor_schema

extract_goal(goal_color) pfields.attraction(goal_angle,goal_strength)

22

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 di pfields su pfields.attraction() vuole dire che quell'attrazione è un metodo all'interno di un altro oggetto identificato come pfields. I cinque campi di potenziale primitivi, visti precedentemente, potrebbero essere incapsulati in una classe chiamato PFields che ogni schema motore potrebbe usare. PFields servirebbe come una libreria. Una volta che i campi di potenziali in PFields sono scritti e verificati, il progettista non deve più programmarli di nuovo.

23

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.

24

LEZ. 17

25

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.

26

Lo schema motore di follow_corridor consiste di tre primitive e di un programma di controllo coordinato. Il programma di controllo coordinato è la funzione che sa che un campo è perpendicolare al muro sinistro e va verso il centro del corridoio e in che modo è diretto, ecc. Questi campi sono sommati dal programma di controllo coordinato nello schema comportamentale per produrre un solo vettore di uscita.

VL

VR

DLDR

VL VR

VF

VF

VF+L+R

VR-L

VFVR-L

DL, DR

27

Lo Schema Percettivo di follow_corridor esamina il diagramma

polare del sonar ed estrae l'ubicazione relativa dei muri del

corridoio. Lo Schema Percettivo ritorna la distanza dal muro

sinistro e dal muro destro.

VL

VR

DLDR

VL VR

VF

VF

VF+L+R

VR-L

VFVR-L

DL, DR

28

Un altro modo per realizzare lo stesso behavior complessivo è avere follow_wall composto di due istanze di un behavior segui il muro: follow_wall (sinistro) e follow_wall (destro). Ogni istanza di segui il muro riceve il plot polare del sonar ed estrae il muro corrispondente.

VL

VF+L

DLDR

VL VR

VF

VR

VFVF+R

VF+L+R

VF+LVF+R

DL

VF+RVF+L

VRVLDR

29

In entrambe le realizzazioni, gli schemi motore funzionano continuamente, ed i vettori sono sommati internamente per produrre un solo vettore di output. Poiché ci sono schemi motore multipli, il programma di controllo coordinato per follow_corridor non è nullo come era per move_to_goal. La sommatoria vettoriale e la concorrenza formano in questo caso il programma concettuale di controllo coordinato.

VL

VF+L

DLDR

VL VR

VF

VR

VFVF+R

VF+L+R

VF+LVF+R

DL

VF+RVF+L

VRVLDR

30

Dove vanno a finire i releaser in OOP?

Gli esempi precedenti mostrano come i behavior possono essere implementati usando costrutti OOP, come le classi.

Un'altra importante aspetto di un behavior è come esso è attivato. 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?

31

La risposta alla prima parte della domanda è che il releaser è

esso stesso uno schema percettivo.

Può funzionare indipendentemente da tutto quello che sta

accadendo al robot; è uno Schema Percettivo non limitato da

uno schema motore.

Supponiamo per esempio, che il robot sta cercando lattine di

Coca cola rosse con lo schema percettivo di extract_color.

Un modo di implementare questo è: quando lo schema vede

rosso, allora può segnalare al programma principale che c'è

rosso a meno che non abbia già nel gripper una lattina.

Il programma principale può stabilire che il releaser per il

behavior move_to_goal è stato o meno soddisfatto, e quindi

eventualmente instanziare move_to_goal() con goal = red.

32

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.

33

Un altro approccio più comune di programmare è quello che il releaser è parte del behavior: in questo caso il singolo Schema Percettivo svolge un doppio compito.

Questo stile di programmazione richiede un programma di controllo coordinato. Il behavior è sempre attivo, ma se il releaser non è soddisfatto, il programma di controllo coordinato cortocircuita l’elaborazione.

Il behavior ritorna una funzione identità, cioè un vettore (0,0) nel caso di campi di potenziale, il che equivale ad un behavior non attivo.

Questo stile di programmazione può limitare alcune risorse, ma è un modo semplice ed efficace di programmare.

34

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.

35

In seguito si mostrerà che i releaser devono essere progettati per sostenere una sequenza corretta.

A seconda di dove il robot si trova nella sequenza delle attività, il robot usa move_to_goal per andare verso una lattina di Coca cola rossa o un bidone di riciclaggio blu. Altrimenti, il robot potrebbe cercare una Coca cola rossa e un bidone di riciclaggio blu simultaneamente.

In questa situazione, dovrebbero esserci due oggetti move_to_goal, uno instanziato con goal "rosso" e l'altro con goal "blu."

Si noti che il behavior move_to_goal può usare qualunque Schema Percettivo che può produrre un angolo e una forza per il goal.

Se il robot avesse bisogno di muoversi verso una luce brillante (fototropismo), si dovrebbe cambiare solo lo schema percettivo. Questo è un esempio di riusabilità del software.

36

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 discussione sul processo di progettazione, poi si esamineranno i vari passi.La metodologia in fig. presume che a un progettista sia dato: il task che il robot deve perseguire (1), una piattaforma robotica (2) (o dei vincoli, in genere economici). Il goal è progettare un robot come un agente situato (3). Perciò, i primi tre passi servono a ricordare al progettista di specificare la nicchia ecologica del robot.

37

Al quarto passo comincia un processo iterativo in cui si fa l’identificazione e il raffinamento del set di behavior per il task. Viene posta la domanda: cosa farà il robot (4)? Definire la nicchia ecologica determina i vincoli e le opportunità ma non presenta necessariamente altri suggerimenti nella situatedness del robot: come esso agisce e reagisce alla variabilità nella sua nicchia ecologica. Questo passo è dove si comincia a capire che progettare behavior è un'arte.

38

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.

39

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.

40

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 provare i behaviour tutti insieme (7). Questo stile di test è consistente coi principi dell’ingegneria del software, ed enfatizza i vantaggi pratici del Paradigma Reattivo.

41

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.

42

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 1994. L'obiettivo della competizione era avere un piccolo veicolo non controllato (non più grande di un carrello da golf) che autonomamente navigasse in uno spazio aperto seguendo linee bianche dipinte sull'erba.

Il CSM vinse il primo posto ed un premio di $5,000.

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.

43

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 era sorteggiato.

44

Step 2: Descrizione del robot.

Lo scopo di questo passo è determinare le abilità fisiche e di base del robot e le sue limitazioni. In teoria, ci si aspetta, che il progettista voglia avere il controllo sul robot (costruirlo lui stesso), decidere quello che può fare, di quali sensori essere dotato ecc. In pratica, la maggior parte dei robotici opera con piattaforme commerciali che possono avere limitazioni su hardware e sui sensori che possono essere aggiunti, o sulle piattaforme sotto forma di kit con equipaggiamento poco costoso ma dove ci sono vincoli sulla potenza. Al progettista di solito sono perciò imposti dei vincoli determinati dalla piattaforma del robot che hanno un impatto sulla relativa progettazione.

45

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

46

Il veicolo di base era una jeep con ruote motorizzate acquistata in un negozio di giocattoli. La base soddisfaceva esattamente le richieste minime per le dimensioni. Venne usato uno sterzo Ackerman (come nelle auto) per il governo, un motore per muovere le ruote posteriori ed un motore per le ruote anteriori. Il veicolo aveva un angolo di rotazione di 22°. Il calcolatore on-board era un PC 486 a 33MHz. L’insieme dei sensori consisteva di tre apparecchiature: •shaft encoders sui motori di movimento e rotazione, •una videocamera montata su un’asta vicino al centro del veicolo• un sonar panoramico montato sotto una grata sul davanti. L’output della videocamera veniva digitalizzato in bianco e nero. Il sonar era un Polaroid. L'apparecchiatura aveva una panoramica di 180°.

Ogni codifica era fatta in C++.

47

A causa del sistema di motori e di rotazione, Omnibot poteva andare solo a 1.5 mph.

Questa limitazione implicava che avrebbe potuto vincere solamente se fosse andato più lontano con un minor numero di penalità. Questo significava anche che bisognava aggiornare la lettura dei sensori almeno ogni 150ms o il robot sarebbe potuto andare fuori dei limiti senza accorgersi che lasciava il percorso previsto. L’acquisizione in bianco e nero eliminò il problema del colore.

Inoltre, la velocità di aggiornamento del frame-grabber era di circa 150ms; l’algoritmo che tratta la visione deve essere molto veloce altrimenti il robot si muove prima di un nuovo aggiornamento.

Le riflessioni dovute all’erba disuguale ridussero il range standard del sonar da 7.5mt a circa 3mt.

48

LEZ.18

49

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.

50

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.

51

Il sonar era capace di scoprire affidabilmente le balle coperte di plastica da più angoli di approccio da una distanza massima di 2,4 mt. I veicoli dovevano correre tra le 9 e le 17 del 22 maggio, anche con tempo coperto. Oltre ai problemi di visione dovuti al cambiare dell’illuminazione causata dalle nubi, le balle proiettavano ombre sulle linee bianche tra le 9 e le 11 e tra le 15 e le 17. La buca di sabbia era lunga solo 1,2 mt e messa su una parte diritta del percorso.

52

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.

53

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.

54

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.

55

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.

56

Come si vede dalla tavola dei behavior, la squadra del CSM propose inizialmente solamente un behavior: follow-line . Il behavior di follow-line consisteva di uno schema motore, stay-on-path(centroid) che era riflessivo (stimolo-risposta) e taxonomico (orientava il robot in funzione dello stimolo). Lo Schema Percettivo, compute-centroid(image,white), estraeva un affordance del centroide del bianco dall'immagine come se fosse la linea. Solamente la componente c_x, o ubicazione orizzontale, del centroide veniva usata.

Releaser Behavior Motor Schema Percept Perceptual schema

always on follow-line() stay-on-path(c_x) c_x Compute-centroid(image,white)

Behavior Table

57

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.

1. Descrivere il task2. Descrivere il robot3. Descrivere l’ambiente4. Descrivere le reazioni del robot in risposta all’ambiente5. Raffinare ogni behaviour

58

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.

59

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.

60

Step 6: Verifica ogni behavior indipendentemente.

Come in ogni progetto di ingegneria del software, moduli o behavior sono esaminati individualmente. Idealmente, il test si fa in simulazione prima di esaminare il robot immerso nell’ambiente. Molti robot commerciali disponibili, come Khepera e Pioneer, vengono forniti di ottimi simulatori. Comunque, è importante ricordare che i simulatori spesso imitano solo le meccaniche del robot, non le capacità percettive. Essi sono utili per verificare che il codice dello schema motore è corretto, ma spesso l'unico modo di verificare lo Schema Percettivo è quello di provarlo nel mondo reale. 1. Descrivere il task

2. Descrivere il robot3. Descrivere l’ambiente4. Descrivere le reazioni del robot in risposta all’ambiente5. Raffinare ogni behaviour6. Verificare ogni behaviour

61

Step 7: Test con gli altri behavior. Il passo finale del progetto e dell’implementazione del sistema reattivo è fare un test sull’integrazione quando cioè i behavior sono combinati insieme. Questo include anche il collaudo dei behavior nell'ambiente reale. Anche se il behavior di follow_line funzionò bene quando fu fatto il test con le linee bianche, non funzionò però bene quando fu fatto con linee bianche ed ostacoli. Gli ostacoli, balle di fieno avvolte di plastica luccicante poste vicino alla linea, erano spesso più brillanti dell'erba. Perciò lo schema percettivo di follow_line nel calcolare il centroide teneva conto di pixels che facevano parte della balla. Invariabilmente il robot si fissava sulla balla, e seguiva il suo perimetro piuttosto che la linea. Le balle erano viste come "distrazioni visuali."

1. Descrivere il task2. Descrivere il robot3. Descrivere l’ambiente4. Descrivere le reazioni del robot in risposta all’ambiente5. Raffinare ogni behaviour6. Verificare ogni behaviour7. Verificare i behaviour tutti insieme

62

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.

63

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.

64

Nuova Behavior TableReleaser Inhibited by Behavior Motor Schema Perc

eptPerceptual schena

always on Near=read_sonar() follow-line() stay-on-path(c_x) c_x Compute-centroid(image,white)

always on Far=read_sonar() Move_ahead(dir) Uniform(dir) dir Dead_reckon(shaft-encoders)

Move_ahead

Follow_line T

sonar

TV cam

65

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.

66

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.

67

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.

68

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

69

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.

70

Resta il problema di come rappresentare formalmente i releaser

in maniera che il robot li possa eseguire ed il progettista umano li

possa visualizzare e diagnosticare.

Ci sono tre maniere per rappresentare una sequenza di behavior:

automi a stati finiti, scripts e skills.

Gli automi a stati finiti (FSA) e gli scripts sono logicamente

equivalenti, ma danno luogo a modi lievemente diversi di

implementazione.

Gli skills raccolgono i tipo-behavior primitivi, chiamati Reazione-

Azione Packages (RAPs), in un "piano abbozzato" che può essere

poi riempito man mano che il robot li esegue.

Coordinazione e controllo con behavior tipo FSA furono usati con

successo dal team della Georgia che vinse nel 1994 la gara di

raccolta della spazzatura dell’AAAI, e dal team LOLA vincente

nella stessa competizione dell’JCAI nel 1995.

71

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.

72

73

LEZ.19

74

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.

http://www.dis.uniroma1.it/~terpa/sw/public_html/Lez2_tut3.htm

75

Per cominciare, il progettista deve essere capace di specificare un numero limitato di stati distinti nei quali il robot potrebbe trovarsi. Il set di stati è rappresentato da K, e ogni stato q K è una lista dei behavior che dovrebbero/potrebbero essere attivi contemporaneamente. Nel caso della competizione precedente, c’erano solamente due stati: seguire la linea e muoversi in avanti. Gli stati sono rappresentati in una tavola sotto l'intestazione q, e da cerchi in un grafico.

, time

76

Per convenzione, vi è sempre un stato di Start, ed il robot dovrebbe partire sempre di là. Lo stato di Start è spesso scritto come s o q0 e disegnato con un doppio cerchio. Nel caso dell'UGR, (Unmanned

Ground Vehicle) lo stato di following-line era sempre lo stato di inizio poichè il robot cominciava col behavior di follow-line attivo. La successiva parte del FSA è l’input (anche detto alfabeto). Gli input sono i releaser comportamentali, ed appaiono sotto la colonna dove campeggia . La tavola del FSA considera quello che accade ad ogni stato q per tutti i possibili input.

77

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

, time }

78

La terza parte del FSM è la funzione di transizione, detta che specifica in che stato va il robot dato uno stimolo in input. Il set di stimoli o affordances che può essere riconosciuto dal robot è rappresentato da . Questi stimoli sono rappresentati da frecce. Ogni freccia rappresenta il releaser per un behavior. Il nuovo behavior triggerato dal releaser dipende dallo stato nel quale il robot si trova. Questo è lo stesso dell’IRM, dove letteralmente vengono ignorati i releaser che non sono rilevanti per lo stato corrente.

, time}

79

Si ricordi anche che nella Lez. 3 nella implementazione del programma seriale dell’IRMs l'agente "osservava“ i releaser ogni secondo. Ad ogni iterazione, l’agente avrebbe potuto avere fame e “sarebbe entrato" nello stato di alimentarsi. Nella successiva iterazione, ancora avrebbe potuto avere fame e sarebbe rientrato nello stato di alimentarsi. Questo può essere rappresentato avendo frecce che partono dallo stato di alimentarsi e puntano di nuovo allo stesso stato.

80

enum Releaser={PRESENT, NOT_PRESENT};Releaser food, hungry, nursed, predator;while (TRUE) { predator = sensePredator() ;if (predator==PRESENT) flee() ;food = senseFood();hungry = checkStateHunger() ;parent = checkStateParent() ;if (hungry==PRESENT)

searchForFood() ;if (hungry==PRESENT && food==PRESENT)

feed() ;if(hungry== NOT_PRESENT && parent==PRESENT)

nurse() ;if(nursed==PRESENT)sleep() ; }

81

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.

, time }

82

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.

83

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 (Follow_line e Move_ahead) sono stati finali. Se il robot potesse riconoscere la linea di arrivo, allora potrebbe aversi un stato finale. Lo stato finale potrebbe essere 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 almeno 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.

84

La notazioneM = K, , , s, Fè usata per ricordare che per usare un FSA il progettista deve sapere tutti i q stati (K), gli input le transizioni tra gli stati , lo stato iniziale speciale s=q0 e lo stato/i finale (F). Ci deve essere una freccia nel diagramma di stato per ogni riga nella tabella . La tabella sotto compendia le relazioni tra gli FSA e i behavior:

FSA Behavior

K Tutti i behaviors per un task

I releaser per ciascun behavior in K

La funzione che calcola il nuovo stato

s Behavior di start per il robot

F Behavior che il robot deve eseguire per smettere

85

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.

86

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

87

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 un bumper, per dire quando il robot ha urtato qualche cosa, ed una telecamera. 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 gripper è 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.

88

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

89

5

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

90

5

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

91

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

92

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 rappresentare graficamente 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

93

94

LEZ. 20

95

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 releaser differenti, e

due move-to-goal.

96

Molti progettisti progettano e interpretano gli FSA come estrattori

di releaser. 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à.

97

Il FSA nasconde anche il ruolo del behavior di AVOID.

L' AVOID 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 sono usate in

ingegneria del software ma non sono usate comunemente in

robotica.

Il behavior AVOID 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.

98

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

99

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

100

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

101

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.

102

Il behavior di move_to_trash 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 move_to_trash è inibito.

Questo impedisce a move_to_trash di fornire una direzione, e

quindi l’output è di nuovo la direzione di wandering.

103

Il successivo livello di competenza è depositare l’immondizia nel

bidone delle lattine.

Quando vede il bidone blu delle lattine, 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.

104

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.

105

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: pick-up-the-trash (trash-color, trash-can-color, size-trash-can).

106

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.

107

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.

108

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

109

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

110

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.

111

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

112

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.

113

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 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 wander-for-goal(red).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 segue:

114

115

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 bluegStatus=gripper_status(); \\ stato del gripperif (gStatus==TRUE) {

FULL=TRUE; EMPTY=FALSE; } else {FULL=FALSE; EMPTY=TRUE;}

116

\\index into the correct step in the causal chain

if (EMPTY){

if (SEE_RED){move_to_goal(red);

elsewander ();

} else{grab_trash(); if (NO_BLUE)

wander(); else if (AT_BLUE)

drop_trash(); else if (SEE_BLUE)move_to__goal (blue) ;

}