Strips & Shankey
Per far muovere Shankey (circa 1970) fu necessario utilizzare un pianificatore derivato da STRIPS che permetteva di dimostrare teoremi, cioè di risolvere, e operare su una serie di predicati attraverso i quali veniva rappresentato il mondo di Shankey.
Strips & Shankey (segue)
Shankey è il primo robot mobile in AI che ha usato un algoritmo generalizzato per pianificare lo svolgimento dei suoi compiti.
Il metodo applicato era una variante del GPS.
Questo programma usa un approccio detto analisi means-ends dove se il robot non può svolgere un compito o raggiungere il goal in un solo movimento prende in considerazione una azione che possa ridurre la differenza fra lo stato in cui si trova e quello verso cui vuole andare.
GPS – General Problem Solver
Newell & Simon 1972
- Divide-and-conquer: usa sottopiani per raggiungere sub-gol che permettono il raggiungimento del goal finale.
- Means-end analysis: cerca gli operatori significativi
Means-end analysis del GPS
Means-end analysis del GPS: definizione del problema
Supponiamo di voler programmare un robot che deve andare da Milano a Napoli.
A meno che il robot non sia già nel punto di arrivo, rappresentato come una variabile goal, allora il viaggio deve essere organizzato.
Supponiamo che il robot si trovi a Milano (stato iniziale).
Il robot può rappresentare il processo di decisione di come raggiungere un nuovo luogo con una funzione detta operatore che prende in considerazione ad esempio la
Means-end analysis del GPS: soluzione del problema
Obiettivo del robot è annullare la differenza, cioè la distanza tra se stesso e Napoli. Se il robot vuole prendere l’aereo bisogna tenere conto che l’ aeroporto di Milano è lontano dalla città 50 chilometri. Allora in questo caso il robot ha una nuova differenza da minimizzare. Dalla tavola si ricava che potrebbe andare in auto. La scelta si fa mediante una lista di precondizioni che devono essere soddisfatte prima di eseguire un certo operatore.
Quando il robot prende l’aereo da Milano e giunge a Napoli allora il suo stato cambia. Il suo stato iniziale ora è aeroporto di Napoli e non più quello di Milano.
Quindi ogni qualvolta il robot esegue un’operazione vi è quasi sempre qualche cosa che deve essere aggiunta alla sua conoscenza dello stato del mondo.
Aggiungiamo allora due colonne nella tabella una per le aggiunte e un’altra per le cancellazioni. In questa maniera quando un robot applica un operatore può facilmente modificare il suo mondo.
Esempio di soluzione con il GPS
Altro esempio
Esempio di soluzione con il GPS
Altro esempio (segue)
Supponiamo di avere un robot ET che si trova in una stanza R1 e deve andare nella stanza R2 dove si trova lo scatolo B1. Le due stanze sono separate da una porta D1.
Dobbiamo ora, secondo il paradigma gerarchico, descrivere il mondo del robot. Lo facciamo attraverso dei predicati. Usiamo nella definizione dei predicati, nomi con lettere maiuscole per indicare fatti VERI, e nomi con lettere minuscole per indicare variabili che possono essere VERE o FALSE.
Nel mondo del robot ci sono solo tre tipi di cose: movable_object, room, door.
La conoscenza può essere così rappresentata:
- INROOM(x,r): l’oggetto x (di tipo movable_object) si trova nella stanza r (di tipo room)
- NEXTTO(x,t): l’oggetto x (di tipo movable_object) si trova vicino a t che è un tipo door o movable_object
- STATUS(d,s): d è di tipo door e s può essere OPEN o CLOSED
- CONNECT(d,rx,ry): d è di tipo door e rx,ry sono di tipo room
Esempio di applicazione del paradigma gerarchico
Altro esempio (segue)
Con questi predicati che descrivono il mondo, in maniera a priori noi inizializziamo Strips (il pianificatore) come segue:
Initial state
INROOM(ET,R1)
INROOM(B1,R2)
CONNECT(D1,R1,R2)
CONNECT(D1,R2,R1)
STATUS(D1, OPEN)
NEXTTO(x,y)
Si noti che per ora il predicato NEXTTO(x,y) non è utilizzato perché non c’è nessun oggetto vicino a una porta o ad un altro oggetto.
Le sue variabili quindi rimangono non istanziate.
Il pianificatore lavora sulla base di una tabella che contiene dei possibili operatori che il robot può applicare, le precondizioni purché siano applicabili, i predicati che si aggiungono o modificano rispetto allo stato iniziale o precedente e quelli che si eliminano perché non più veri.
Esempio di applicazione del paradigma gerarchico
Altro esempio (segue)
Dalla tabella a lato si ha che il robot è programmato per eseguire due sole operazioni: andare verso una porta, passare attraverso una porta.
Poiché il goal da raggiungere è nella stanza R2 allora la differenza logica da annullare è il non essere nella stanza R2.
Per annullarla il predicato INROOM(ET,R2) che inizialmente risulta FALSE deve diventare TRUE.
Altro esempio (segue)
Se guardiamo tra gli operatori troviamo che l’unico che ha nella sua add-list un predicato che potrebbe annullare la differenza INROOM(ET,R2)=FALSE, è OP2 con INROOM(ET,rm). Allora in OP2 istanziamo rm=R2. Le precondizioni che devono essere soddisfatte affinché OP2 sia applicabile sono:
CONNECT(dx,rk,rm)
NEXTO(ET,dx)
STATUS(dx, OPEN)
INROOM(ET,rk)
Di queste solo CONNECT(dx,rk,rm) contiene rm che quindi sostituiamo con R2. Ora STRIPS cerca nella base dati se vi sono istanze di CONNECT(dx,rk,R2). L’unica che trova è CONNECT(D1,R1,R2), (l’altra ha al posto di rm R1). Quindi da qui in poi STRIPS pone dx=D1, rk=R1, rm=R2.
Con questi valori si va a vedere se le altre precondizioni sono soddisfatte, cioè sostituendo le variabili istanziate si verifica se i predicati appartengono al closed world.
Nel verificare NEXTO(ET,dx) ci si accorge che NEXTO(ET,D1) non appartiene al data base.
Tabelle di applicazione del paradigma gerarchico
Altro esempio (segue)
In maniera ricorsiva ora STRIPS si pone NEXTO(ET,D1) come obiettivo da perseguire e quindi come differenza da colmare ← NEXTO(ET,D1). Pertanto pone nello stack della ricorsione il primo goal, diciamo G0, non ancora soddisfatto, a cui aggiunge il nuovo G1. Cerca ora se tra gli operatori rimasti ce n’è uno nella cui add-list c’è un predicato che annulli la differenza, cioè se c’è NEXTO(ET,D1). Non appena lo trova, nel nostro caso si tratta di OP1, ripete il procedimento di verifica delle precondizioni con il nuovo vincolo di dx=D1.
Le precondizioni sono in questo caso
INROOM(ET,rk)
CONNECT(dx,rk,rm)
instanziando rk=R1, e rm=R2 troviamo che nel data base CONNECT(D1,R1,R2) è vera così come INROOM(ET,r1).
A questo punto STRIPS pone OP1 nello stack e prova a risolvere il problema.
Tabelle di applicazione del paradigma gerarchico
Altro esempio (segue)
Dopo l’applicazione di OP1 (GOTODOOR(ET,D1)) lo stato del mondo è il seguente:
INROOM(ET,R1)
INROOM(B1,R2)
CONNECT(D1,R1,R2)
CONNECT(D1,R2,R1)
STATUS(D1, OPEN)
NEXTO(ET,D1)
E il robot si trova vicino alla porta D1.
A questo punto dallo stack emerge OP2 che può essere applicato perché tutte le sue precondizioni sono soddisfatte.
Tabelle di applicazione del paradigma gerarchico
Altro esempio (segue)
Dopo l’applicazione di OP2 GOTHRUDOOR(ET,D1) lo stato del mondo è il seguente: (vedi figura).
La differenza prevista per OP2 è ora annullata dato che ora INROOM(ET,R2) è vera e quindi STRIPS si ferma, avendo raggiunto il suo scopo, e l’azione, così come previsto dai due operatori GOTHRUDOOR(ET,D1) e GOTODOOR(ET,D1) può essere eseguita (solo ora!).
Tabelle di applicazione del paradigma gerarchico
Altro esempio (segue)
Pianificazione
Differenza(startstate, goalstate)
- INROOM(ET,R2) è FALSE
Confronto (Matching)
- Confronta la ADD-LIST con la differenza
- Op2: IF rm=R2 allora applicando OP2 si potrebbe eliminare la differenza
Applicazione
- Controlla le precondizioni dello stato attuale
- CONNECT(D1, R1, R2)
- NEXTTO(ET,D1) è FALSE
Tabelle di applicazione del paradigma gerarchico
Ricorsione
- Crea un nuovo sub-goal G1:NEXTTO(ET,D1)
- Push G1 nello stack dei goal
- Controlla e confronta la Add-list con G1
- Op1: NEXTTO(ET,dx), dx=D1
- Riassegna i valori
- es. (dx,rk,rm)=(D1,R1,R2)
- Tutte le precondizioni di Op1 sono soddisfatte
- Applica OP1 e fai il pop sullo stack
Ricorsione nel GPS
Modello del mondo
Dopo l’applicazione di OP1
INROOM(ET,R1)
INROOM(B1,R1)
STATUS(D1, OPEN)
CONNECT(D1,R1,R2)
CONNECT(D1,R2,R1)
NEXTTO(ET,D1)
- G1
- G0
- G1 fatto
- Considera G0
- Op2 è un operatore ancora valido
- Verifica le precondizioni di OP2
- Applica OP2
- Aggiorna il modello del mondo
- Elimina G0 dallo stack
- Se lo stack dei goal è vuoto STRIPS manda il piano a Shakey
Ricorsione nel GPS
STRIPS
STRIPS quindi lavora in maniera ricorsiva. Se non può raggiungere direttamente un goal identifica il problema che glielo impedisce nelle precondizioni che falliscono. Si propone queste come sub-goal e ricomincia. Quando tutti i sub goal sono soddisfatti, fa il pop dello stack cercando di risalire al goal di partenza.
STRIPS pianifica più che agire, in effetti crea una lista di operatori che si possono applicare per raggiungere lo scopo.
STRIPS (segue)
Per lavorare con STRIPS il progettista deve produrre:
- una rappresentazione del mondo;
- una tavola delle differenze con operatori, precondizioni, add e delete list;
- un valutatore delle differenze.
STRIPS (segue)
I passi che STRIPS compie sono:
- calcolo della differenza tra stato iniziale e stato finale (quello del goal) usando la funzione di valutazione delle differenze;
- se vi è qualche differenza la riduce cercando tra gli operatori il primo che presenta nella ADD-LIST un predicato che neghi la differenza;
- esamina quindi le precondizioni per vedere se esiste un insieme di possibili instanziazioni per tutte le variabili non instanziate. Se così non è, prende la
- prima precondizione non verificata, se la propone come nuovo goal e memorizza il goal originale in uno stack. Ricorsivamente quindi riduce la differenza ripetendo i passi precedenti;
- quando tutte le precondizioni per un operatore sono soddisfatte, inserisce l’operatore nello stack e aggiorna il suo modello del mondo con le nuove asserzioni; passa poi all’operatore che segue nello stack e ripete il procedimento ricorsivo.
Closed World Assumption e Frame problem
L’ipotesi di Closed World impone che il modello del mondo costruito dal progettista contenga tutto quanto serve al robot. Non ci possono essere sorprese. Se questa ipotesi è violata il robot potrebbe non funzionare più bene. Questo è un primo problema.
L’opposto dell’ipotesi di Closed World è detta ipotesi di Open World.
Closed World Assumption e Frame problem (segue)
Un secondo problema sorge dalla considerazione che solo per due stanze, nell’esempio fatto, abbiamo scritto molti predicati ai quali se ne aggiungeranno altri se le stanze sono più di due, se ci sono ostacoli e così via.
In effetti risulta evidente che il numero di fatti (o assiomi) che il problema deve maneggiare, ordinandoli e ricercandoli, ad ogni passo attraverso la tavola delle differenze diventa rapidamente intrattabile, dal punto di vista computazionale, per applicazioni reali.
Il problema di rappresentare una situazione di un mondo reale in maniera computazionalmente trattabile è noto come frame problem.
Closed World Assumption e Frame problem (segue)
Si noti ancora che sotto l’ipotesi di Closed World se qualcosa di nuovo viene introdotto dall’esterno allora bisogna rivedere tutto l’apparato degli assiomi.
Con questo e con il problema che lo stack ricorsivo può alla fine andare in overflow si capisce quanto questa via non sia troppo praticabile.
Si cercò negli anni ‘80 di affrontare questo aspetto suddividendo il problema in tante parti sempre più astratte.
Di qui emersero due distinte linee di ricerca: una sulla pianificazione e una detta di robotica in cui si studiava prevalentemente la sensoristica.
Relazione/Seminario
Introdurre, scrivere e commentare usando STRIPS un algoritmo che risolva il problema dei cubi:
Dati 5 cubi, collocati o a terra o sovrapposti tra loro produrre un piano che permetta lo spostamento di un qualunque cubo su un qualunque altro, spostando gli eventuali ostacoli.
In alternativa
Introdurre, scrivere e commentare usando STRIPS un algoritmo che risolva il problema del robot spazzino come illustrato precedentemente (ricordando la soluzione adottata in Prolog)
Descrivere in termini GPS la soluzione individuata.
Relazione/Seminario (segue)
Descrivere nei dettagli almeno tre veicoli di Braitenberg rappresentandoli con STRIPS e riportando e discutendo le implicazioni psicologiche proposte dallo stesso Braitenberg.
Descrivere nei dettagli la tartaruga di Grey Walter rappresentandola con STRIPS e e discuterne il funzionamento in termini di GPS.
Alcune architetture gerarchiche
Il Nested Hierarchical Controller (NHC) è una delle più note architetture gerarchiche sviluppata da Meystel (1990).
In essa le tre componenti PERCEPISCI-PIANIFICA-AGISCI sono ben visibili.
Architettura NHC
Alcune architetture gerarchiche (segue)
Il robot inizia con il raccogliere i dati dai suoi sensori (PERCEPISCI) per costruire il suo modello del mondo (Modello del mondo /Base di conoscenza). Per altro il suo Modello del mondo può anche avere una conoscenza a priori fornita dal progettista (ad esempio una mappa dell’ambiente, regole di comportamento, etc.).
Aggiornato il Modello del mondo con l’attività sensoriale, il modulo PIANIFICA interviene per decidere cosa fare.
Architettura NHC
Alcune architetture gerarchiche (segue)
Questo modulo ha tre sotto moduli ognuno dei quali interagisce con il Modello del Mondo e con quello che lo precede.
Pianificatore di missione.
- Riceve dall’uomo o genera da solo una missione da compiere (esempio prendi lo scatolo nella camera accanto), instanziando una serie di variabili (es. box=B1; rm=R2). Ciò fatto il Pianificatore di missione accede al Modello del Mondo per determinare dove si trova il robot ET e dove il goal B1.
Navigatore
- A partire dalla localizzazione di ET e B1 determina un percorso dalla postazione di ET a B1.
Pilota
- Riceve il percorso da Navigatore. Prende il primo segmento retto o pezzo di percorso e determina quali azioni ET deve fare per seguire quel percorso.
Architettura NHC
Alcune architetture gerarchiche (segue)
Cosa accade se il percorso è molto lungo o un ostacolo improvviso si para davanti a ET? Contrariamente a Shakey questo robot non va in giro necessariamente con gli occhi chiusi. Non appena infatti Pilota manda gli opportuni comandi ai controller degli attuatori, ET2 riattiva i suoi sensori.
Architettura NHC
Alcune architetture gerarchiche (segue)
Il Modello del Mondo è aggiornato. Però non si ripete il ciclo precedente, perché ora ET ha il suo goal e il suo percorso. Il Pilota semplicemente, sulla base delle nuove informazioni verifica se e a quale punto del percorso previsto si trova ET e se per caso non ci sono ostacoli. Se il Pilota verifica che ha raggiunto l’estremità del segmento di cammino assegnatogli dal Navigatore informa quest’ultimo e riceve il nuovo segmento da seguire. Se ha raggiunto il goal allora il Navigatore informa il Pianificatore di missione che decide cosa fare (fermare il tutto, programmare un nuovo goal, etc.).
Architettura NHC
Alcune architetture gerarchiche (segue)
Se il Pilota trova un ostacolo ne informa il Navigatore che gli fornisce un nuovo percorso da seguire per raggiungere il goal. Il tutto avviene con una costante interazione tra i moduli, in maniera gerarchica e con il Modello del Mondo aggiornato di volta in volta.
Architettura NHC
Alcune architetture gerarchiche (segue)
I vantaggi di NHC consistono nell’alternare pianificazione e azione.
L’attività inizia a eseguire una pianificazione.
Se il mondo nel frattempo cambia allora anche NHC cambia i suoi piani.
Si noti che i tre livelli gerarchici lo sono non solo in termini temporali ma anche dal punto di vista della “intelligenza”, nel senso che Pianificatore di Missione è più intelligente e opera ad un livello più astratto di Navigatore e lo stesso avviene rispetto a Pilot.
Questa organizzazione la ritroveremo anche in altre architetture.
Lo svantaggio dell’architettura NHC è che essa sembra adatta a problemi di navigazione ma meno adeguata per problemi tipo prendi l’oggetto o ruota una manopola e così via.
NHC è stato fondamentalmente testato solo in simulazione.
Architettura NHC
Architetture RCS & NASREM
Jim Albus (1996) ai fini di applicazioni industriali nell’ambito dei manipolatori sviluppò un’architettura detta Real-Time Control System (RCS) per aggiungere, usando la NHC, più intelligenza ai robot industriali.
Architettura RCS
Architetture RCS & NASREM (segue)
Le attività percettive sono raggruppate in una serie di moduli denominati Percezione Sensoriale.
L’output dei sensori è inviato al Modello del mondo che costruisce una mappa globale usando anche le informazioni già presenti nella sua Base di conoscenza. Questa organizzazione è simile a quella del NHC. La principale differenza consiste nel fatto che il modulo sensoriale effettua un preprocessing delle informazioni percepite (feature extraction).
Architettura RCS
Architetture RCS & Nasrem (segue)
Queste informazioni vengono elaborate dal modulo Valutazione del piano che fornisce la maggior parte delle funzionalità necessarie per l’attività di PIANIFICAZIONE. In altre parole pianifica e simula i piani per assicurarsi che tutto funzioni. Dopo di che invia i piani al modulo Generazione del Behavior che converte i piani in azioni che il robot può realmente eseguire (AZIONE). A questi moduli se ne aggiunge un altro non mostrato che permette il debug all’osservatore umano
Architettura RCS
Architetture RCS & NASREM (segue)
Questi tipi di architettura hanno fornito una serie di indicazioni sulla opportunità di introdurre modularità nel progetto di un robot.
Questa modularità però non consente molta portabilità poiché in genere le due architetture prima viste sono state realizzate e, si pensa lo siano sempre, per ristrette nicchie di applicazioni.
NHC è prevalentemente utilizzata per problemi di navigazione mentre RCS è stata utilizzata per controllo di strumentazioni in sottomarini e scavi in miniera. Il vero problema rimane quello del tempo di reazione all’evento quando questo può essere catastrofico. Infatti i moduli di pianificazione, prevedendo una simulazione, sono in genere molto time-expensive. In realtà in queste architetture i moduli PERCEZIONE e AZIONE sono sempre disconnessi impedendo così una immediata reazione ad un evento pericoloso.
Questo standard è stato adottato dalla NASA e dal US Bureau of Mines.
Architetture RCS & NASREM (segue)
Queste architetture, NHC e RCS sembrano molto utili per un controllo semiautonomo. L’operatore umano può fornire il Modello del Mondo, decidere la missione, decomporla in piani e quindi in azioni.
A livello inferiore il robot esegue le azioni. Ovviamente man mano che si eleva l’intelligenza del robot questo può occuparsi dei moduli di livello superiore al Pilota nella gerarchia prima vista. Sulla base di queste considerazioni Albus ha sviluppato una architettura chiamata NASREM per teleguidare le braccia di un robot nello spazio, che è ancora oggi utilizzata.
Architetture RCS & NASREM (segue)
La dipendenza da un global Modello del Mondo, e cioè del frame problem, fa sì che queste architetture non siano molto generali ma risentano delle applicazioni per le quali sono state pensate.
Altro problema non risolto è quello dell’incertezza che può essere semantica (NEXTTO che significa veramente?) e dovuta all’imprecisione dei sensori e degli attuatori.
Inoltre non è sempre chiaro quando si può considerare completata l’azione del robot e come questo si può rilevare.
Architetture RCS & NASREM (segue)
Dal punto di vista dei linguaggi di programmazione data la presenza della ricorsione e della logica dei predicati STRIPS favorisce linguaggi come il Lisp e il PROLOG.
Il paradigma gerarchico incoraggia una programmazione monolitica piuttosto che una orientata agli oggetti.
Sebbene NHC decomponga la pianificazione in più parti, questa divisione è però strettamente funzionale (di qui l’uso prevalente del Lisp).
Architetture RCS & NASREM (segue)
Le architetture NHC e RCS/NASREM sono ragionevoli per sistemi semi-autonomi dove:
L’operatore umano potrebbe:
- Fornire il modello del mondo;
- Decidere la missione;
- Decomporre la missione in piani;
- Decomporre i piani in azioni.
Il robot potrebbe:
- Eseguire azioni.
Far diventare il robot più intelligente significa trasferirgli alcune delle funzioni dell’operatore umano seguendo a salire la gerarchia precedente.
Le lezioni del Corso
1. Introduzione
4. Esempi di applicazione del paradigma gerarchico
11. Schema Theory
13. Architetture Reattive a Sussunzione
14. Architetture a Campi di Potenziale
15. Architetture a Campi di Potenziale e Sussunzione
16. Progettazione di un sistema Reattivo - 1
17. Progettazione di un sistema Reattivo - 2
18. Progettazione di un sistema Reattivo - 3
