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 » 23.Sistemi ibridi - 3


Stili di architetture ibride

Gli stili architetturali si possono dividere in tre categorie.

Stile manageriale: divide la parte deliberativa in strati basati sullo scopo del controllo o sulle responsabilità manageriali di ciascuna funzione deliberativa. Un modulo di mission planning dovrebbe essere capace di dirigere altri moduli come la navigazione (dove andare) perché è più astratto del path planning (come arrivarci).

Stili di architetture ibride (segue)

Gerarchie di stato: usano la conoscenza dello stato del robot per distinguere fra attività reattive e deliberative.

I behavior reattivi sono visti come non avere uno stato, non avere auto-coscienza e funzionare solo nel presente.

Le funzioni deliberative possono essere divise in quelle che richiedono conoscenza dello stato passato del robot (cioè di una sequenza di comandi) e del futuro (pianificazione della missione e del percorso).

Stili di architetture ibride (segue)

Modelli orientati agli stili: sono più nebulose.

Esse sono caratterizzate da behavior che hanno accesso a parti del modello del mondo, spesso ad un punto tale che sembra di ritornare al modello globale del mondo gerarchico.

Architetture manageriali

Gli stili manageriali di architetture ibride sono riconoscibili dalla loro scomposizione di responsabilità simile alla gestione d’affari.

In cima ci sono agenti che fanno pianificazione a alto livello, quindi passano il piano ai subordinati, che rifiniscono il piano e procurano le risorse e passano il tutto ai lavoratori di livello più basso i behavior reattivi.

Architetture manageriali (segue)

Gli agenti di livello più alto possono vedere i risultati degli agenti subordinati di livello più basso e possono dare indicazioni.

Come nella sussunzione un livello può influire sul livello sottostante.

Nello stile manageriale ciascun livello cerca di eseguire le proprie direttive, di identificare i problemi, di correggerli localmente. Solo quando un agente non può risolvere un suo problema chiede aiuto a un agente superiore.

AUtonomous Robot Architecture

AURA è uno dei robot ibridi più antichi.

Esso è stato progettato è realizzato da Arkin nello stesso periodo in cui Brooks iniziava a pubblicare il suo lavoro sulla sussunzione.

Aura è basato sullo schema theory e consiste di cinque sottosistemi equivalenti, a classi orientate agli oggetti.

Due sottosistemi comprendono la parte deliberativa: il pianificatore e il cartografo.

AUtonomous Robot Architecture (segue)

Il pianificatore è responsabile della pianificazione della missione e del task.

Il cartografo contiene tutte le funzioni per leggere le mappe necessarie per la navigazione. Il cartografo può anche avere una mappa a priori.

Le tre componenti del pianificatore possono interagire con il cartografo attraverso metodi per ottenere un cammino da seguire suddiviso in segmenti.

Layout di AuRA con i cinque sottosistemi

Layout di AuRA con i cinque sottosistemi.

Layout di AuRA con i cinque sottosistemi.


Sottosistema pianificatore

Il sottosistema pianificatore è diviso in:

  • pianificatore di missione,
  • navigatore,
  • pilota.

Il pianificatore di missione serve da interfaccia con l’uomo e, l’attuale implementazione di
Aura, ha una delle più amichevoli interfacce disponibili sul mercato.

Il navigatore lavora con il cartografo per elaborare un cammino per il robot e dividerlo in sub-task
(es. se sei sulla montagna segui la strada lungo il fiume).

Schema generale

Schema generale


Sottosistema pianificatore (segue)

Il pilota prende il primo sub-task e procura le informazioni necessarie (terreno, tipo di foglie etc.) per generare il comportamento. La parte pilota del sottosistema di pianificazione interagisce con il manager dello schema motore nel sottosistema motore dandogli la lista dei behavior di cui ha bisogno per realizzare il task corrente.

Il manager dello schema motore compone ogni behavior esaminando le librerie degli schemi percettivi nel sottosistema percettivo e gli schemi motori nel sottosistema motore. Lo schema motore rappresenta le azioni con i campi di potenziale e il behavior finale emerge dalla somma dei vettori.

Schema generale

Schema generale


Sottosistemi motore e i sensori

I sottosistemi motore e i sensori rappresentano la parte reattiva dell’architettura.

Queste classi contengono librerie di schemi percettivi e motori, e formano gli schemi dei comportamenti. Gli schemi stessi possono consistere di assemblaggi di schemi primitivi, coordinati da macchine a stati finiti.

Gli schemi possono condividere informazioni, se necessario, attraverso collegamenti del manager
dello schema motore. I behavior non sono costretti ad essere puramente riflessivi. Behavior con una conoscenza specifica e rappresentazioni in memoria sono permessi all’interno dello schema.
Gli schemi motori, comunque, sono ristretti ai campi di potenziale.

Schema generale

Schema generale


Controllo omeostatico

Il quinto sottosistema, controllo omeostatico, ricade nell’area grigia fra deliberativo e reattivo.
Lo scopo del controllo omeostatico e di modificare le relazioni fra i behavior cambiando il guadagno in funzione della “salute” del robot o di altri vincoli.

Controllo omeostatico (segue)

Ad esempio si consideri una macchina planetaria che opera su un pianeta roccioso. Il robot deve fisicamente prendere pietre in giro sul pianeta e portarle al veicolo madre. La data per il ritorno del veicolo sulla terra è fissata indipendentemente da quello che accade. Ora il veicolo può essere fornito di un behavior di conservazione. Esso prevede che il robot deve stare sempre lontano due metri da ogni ostacolo.

Controllo omeostatico (segue)

All’inizio della missione questo behavior di conservazione appare ragionevole.
Ora si consideri cosa accade quando il tempo per il ritorno del veicolo si avvicina.
Se il robot è vicino al veicolo di ritorno egli potrebbe voler sfiorare gli angoli e ridurre il margine per il quale evita gli ostacoli per consegnare in tempo il suo carico.
Il robot potrebbe voler fare l’equivalente di un sacrificio della propria vita per il bene della missione.

Controllo omeostatico (segue)

Il problema diventa come renderlo omeostatico.
Molti aspetti di Aura sono ispirati dalla biologia e il controllo omeostatico non è un’eccezione.
Piuttosto che immettere un modulo nella parte deliberativa per esplicitare il ragionamento su come cambiare il behavior complessivo del robot, la biologia suggerisce che gli animali cambiano inconsciamente i loro behavior tutte le volte che è necessario sulla base di necessità interne.
Per esempio un animale che ha bisogno di mangiare aumenta man mano la sua attenzione a cercare cibo.

Controllo omeostatico (segue)

Ad esempio il behavior umano cambia in risposta all’insulina.

Fortunatamente il cambio del behavior emergente è possibile nella rappresentazione dei behavior a campi di potenziale, poiché il vettore di uscita prodotto da ogni behavior può essere scalato con un termine di guadagno.

Ritornando al caso del veicolo planetario che corre per fare l’ultima consegna, il guadagno del behavior vai-verso-goal che attrae il veicolo verso la casa madre dovrebbe aumentare mentre il guadagno del behavior evita-ostacolo dovrebbe diminuire in funzione del tempo di lancio.

Componenti di AURA

La tabella riassume le componenti di AURA.

La tabella riassume le componenti di AURA.


  • 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