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

Ernesto Burattini » 17.Progettazione di un sistema Reattivo - 2


Un behavior astratto di segui_il_corridoio

Esempio

Nell’esempio vai_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.

Nel caso di un corridoio, il segui_il_corridoio a campo di potenziale visto nelle lezioni precedenti consisteva di due campi primitivi:

  • due istanze di perpendicolare ai muri ed
  • una di uniforme parallela ai muri.

Il campo segui_il_corridoio 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.

Un behavior astratto di segui_il_corridoio (segue)

I campi di potenziale per follow_corridor

I campi di potenziale per follow_corridor


Schema motore

Lo schema motore di segui_il_corridoio 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.

Controllo coordinato: esempio di segui_il_corridoio

Controllo coordinato: esempio di segui_il_corridoio


Schema Percettivo

Lo Schema Percettivo di segui_il_corridoio 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.

Controllo coordinato: esempio di segui_il_corridoio

Controllo coordinato: esempio di segui_il_corridoio


Segui_muro

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

Controllo coordinato: esempio di segui_il_muro

Controllo coordinato: esempio di segui_il_muro


Schema motore (segue)

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 segui_il_corridoio non è nullo come era per vai_goal. La sommatoria vettoriale e la concorrenza formano in questo caso il programma concettuale di controllo coordinato.

Controllo coordinato: esempio di segui_il_muro

Controllo coordinato: esempio di segui_il_muro


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 nelle lezioni precedenti, 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?

Dove vanno a finire i releaser in OOP? (segue)

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 Cocacola rosse con lo schema percettivo di estrai_colore.
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 vai_goal è stato o meno soddisfatto, e quindi eventualmente instanziare vai_goal() con goal = rosso.

Dove vanno a finire i releaser in OOP? (segue)

  • vai_goal può instanziare una nuova istanza di estrai_colore o il programma principale può passare un puntatore all’estrai_colore attualmente attivo.
  • vai_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.

Dove vanno a finire i releaser in OOP? (segue)

Un altro approccio è quello di intendere il releaser come 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.

Dove vanno a finire i releaser in OOP? (segue)

In entrambi i casi, una volta che il robot vede rosso, l’aspetto osservabile di vai_goal (cioè muoversi direttamente verso il goal) comincia.

Gli schemi estrai_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.

Dove vanno a finire i releaser in OOP? (segue)

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 vai_goal per andare verso una lattina di Coca cola rossa o un bidone di riciclaggio blu. Altrimenti, il robot potrebbe cercare una CocaCola rossa e un bidone di riciclaggio blu simultaneamente.

In questa situazione, dovrebbero esserci due oggetti vai_goal, uno instanziato con goal “rosso” e l’altro con goal “blu.”

Si noti che il behavior vai_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.

Passi per progettare un Sistema Reattivo

Nella figura successiva si mostrano quali passi bisogna fare per progettare un sistema con behavior reattivi.

Essa è ripresa da un articolo di Murphy.

La metodologia in figura presume che a un progettista sia dato:
il task che il robot deve perseguire (1), e 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.

Passi per progettare un Sistema Reattivo (segue)


Passi per progettare un Sistema Reattivo (segue)

“I tre passi precedentemente indicati si possono rappresentare come nella figura in cui viene richiesto di:

  • 1. Descrivere il task
  • 2. Descrivere il robot
  • 3. Descrivere l’ambiente

Passi per progettare un Sistema Reattivo (segue)

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.


Passi per progettare un Sistema Reattivo (segue)

Qualche volta, una decomposizione in behavior appare ovvia al progettista 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.

Passi per progettare un Sistema Reattivo (segue)

I progettisti 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 progettisti di robotica fanno a capire a quale classe di compiti animali può essere simile il compito del robot.

In pratica, i progettisti che usano suggerimenti biologici e cognitivi tendono a leggere e a rimanere al corrente della letteratura etologica così da poter poi trovare qualche collegamento.

Passi per progettare un Sistema Reattivo (segue)

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, ad esempio, 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. Prima prova il behavior da solo (6) e poi i behaviour tutti insieme (7). Questo stile di test è consistente coi principi dell’ingegneria del software, ed enfatizza i vantaggi pratici del Paradigma Reattivo.


Passi per progettare un Sistema Reattivo (segue)

L’elenco dei passi per implementare un sistema reattivo può essere fuorviante. Nonostante le frecce di ritorno, il processo complessivo in figura 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.


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.

Tracciato del percorso

Tracciato del percorso


Un caso Studio: Unmanned Ground Robotics Competition (segue)

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.

Tracciato del percorso

Tracciato del percorso


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.

Tracciato del percorso

Tracciato del percorso


Step 1: Descrivere il task (segue)

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

Tracciato del percorso

Tracciato del percorso


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.


Step 2: Descrizione del robot (segue)

In pratica, la maggior parte dei progettisti robotici opera con piattaforme commerciali che possono avere limitazioni sul 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.

Step 2: Descrizione del robot (segue)

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.

Step 2: Descrizione del robot (segue)

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

Step 2: Descrizione del robot (segue)

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.

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.


Step 3: Descrizione dell’Ambiente (segue)

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 figura. 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 60×120 cm e non occupavano mai più di 90 cm nella corsia.

Tracciato del percorso

Tracciato del percorso


Step 3: Descrizione dell’Ambiente (segue)

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.

Tracciato del percorso

Tracciato del percorso


Step 3: Descrizione dell’Ambiente (segue)

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.

Tracciato del percorso

Tracciato del percorso


Step 3: Descrizione dell’Ambiente (segue)

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.

I materiali di supporto della lezione

Murphy R.R. 1995 - An Artificial Intelligence Approach to the 1994 AUVS Unmanned Ground Vehicle Competition, 1995 IEEE Intern. Conf. on Systems, Man and cybernetics, oct. 1995, Vancouver, BC pp. 1723-1728

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

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