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 » 16.Progettazione di un sistema Reattivo - 1


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

Lego Mindstorms

Equipaggiamenti come Lego Mindstorms, con accoppiamento rapido di sensori ed attuatori, rendono facile per gli utenti 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 problemi.

  • Il primo, progettare behavior è più un’arte che una scienza. Spesso i giovani robotici sono incerti su come iniziare il processo di progettazione, e 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?

Il paradigma reattivo

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.

Il paradigma reattivo (segue)

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 in un unico behavior.

(C’è certamente la possibilità di concorrenza, per esempio quando evita gli ostacoli mentre si muove verso la lattina o il bidone.)

Il paradigma reattivo (segue)

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.

Iniziamo con il presentare un approccio diretto alla programmazione a oggetti per i behavior.
Questo approccio è basato sullo schema theory presentato nella lez. 11.

Il caso di studio enfatizza l’importanza di stabilire una nicchia ecologica per un robot reattivo.

Behaviors e Schema Theory

Nella applicazione fatta da Arbib dello schema theory rivolto ad 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.

Schema di un behavior

Schema di un behavior


Behaviors e Schema Theory (segue)

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

Behavior del sistema visivo della rana

Behavior del sistema visivo della rana


Schema Theory di una rana che vuole afferrare due mosche equidistanti

Behavior del sistema visivo della rana

Behavior del sistema visivo della rana


Automi a stati finiti e script

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

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

Behavior come Oggetti in OOP (segue)

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.

Schema in programmazione a oggetti

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

Classi: a) schema b) behavior

Classi: a) schema b) behavior


La Classe Schema

Tre classi sono derivate dalla Classe Schema:

  • Schema motore;
  • Schema Percettivo;
  • 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.

L’UML

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.

Classi: a) schema b) behavior

Classi: a) schema b) behavior


Behavior primitivo

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

Esempio: Un behavior primitivo di move_to_goal

L’esempio che segue 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 di mettere un robot 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.

Esempio: Un behavior primitivo di move_to_goal (segue)

L’esempio che segue 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 di mettere un robot 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.

Esempio: Un behavior primitivo di move_to_goal (segue)

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 è una possibilità per introdurre bug di programmazione.

Codice modulare

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

Il behavior move_to_goal consisterà di uno schema percettivo che sarà chiamato estrai_goal ed uno schema motore che userà un campo attrattore chiamato pfields.attrattivo.estrai_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.

Schema

Schema per move_to_gol

Schema per move_to_gol


Schema (segue)

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.


Programmazione con i behavior

La tabella contiene alcuni aspetti 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.

Programmazione con i behavior (segue)

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.

  • 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