Eagle
"Il progetto di un'aquila che non ha mai volato"
Il progetto eagle nasce dall'idea di ricostruire e migliorare il progetto sviluppato all'universita' di Toronto per la robotica con meccanica Lego controllata da logica di alto livello.
Il progetto prevede la gestione di oggetti elettro-meccanici, come i robot della Lego, con sistemi e teorie logiche di alto livello con l'obiettivo di valutare quanto queste teorie si prestino alla gestione di componenti reali in domini reali.
L' hardware con cui il progetto e' stato sviluppato si basa sul kit Midstorm™ della Lego®, un prodotto che, grazie a doti di espandibilita', e' stato addottato dalle maggiori universita' per studi in vari settori applicativi. Nel nostro specifico caso il robot viene pilotato da un software fortemente orientato alla logica come il golog supportato da alcune procedure software di livello intermedio scritte in NQC™.
Il progetto parte dal lavoro di Maurice Pagnucco dell'universita' di Toronto che ha realizzato la base software, il framework e la gestione della comunicazione. Il problema fondamentale che Maurice ha dovuto affrontare e' stata la sincronizzazione e l'unione di due settori diversi, da un lato la programmazione in NQC™ dall'altra l'implementazione di programmi logici che generalmente mal si prestano ad essere 'portati' su strutture fisiche. I risultati raggiunti da Maurice sono molto promettenti, nel suo progetto e' riuscito a realizzare tutte le componenti logiche e le relative interfacce con i moduli sottostanti. Eagle, dopo una prima fase di 'ambientazione', eredita l'ottimo lavoro di Maurice e si pone l'obiettivo di studiarlo e ampliarlo.
Il progetto Eagle
| Prima fase: | Estendere l'idea di Maurice per far muovere il robot su una pista disegnata sopra una griglia. Inizialmente il mondo chiuso e'gia conosciuto dal programma e l'automa deve muoversi a comando dell'utente che inserisce la posizione di destinazione. Come esempio +(7,3) manda il robot nella posizione illustrata in figura per afferarre un oggetto. Un secondo comando come +(4,3) permettera'di mandare il robot in posizione indicata e rilasciare l'oggetto. |  |
| Seconda fase: | Eliminare la conoscenza a priori del mondo chiuso e, inizialmente, far muovere il robot lungo tutti i rami della pista in modo che realizzi autonomamente la propria mappa. Per semplificare il lavoro supponiamo la pista priva di anelli chiusi o ramificazioni annidate. | |
Suddivideremo la prima fase nella gestione della direzione, il controllo sul moto e il conseguimento del goal descrivendo a grandi linee ognuna delle parti.
La direzione:
Due azioni primitive: Turnright e TurnLeft azioni che faranno ruotare il robot di 90 gradi rispettivamente a destra e a sinistra.
Due i fluenti che rappresentano la direzione del robot rispetto all'asse X e all'asse Y ognuno dei quali potra'assumere valor -1, 0, +1. L'idea viene ereditata dal programma di Maurice con l'inevitabile introduzione di un possibile 'stato' 0 che rappresentera il non spostamento sull'asse rispettivo. Direct_x e Direc_y modificano il proprio stato mediante quattro clausole causes_val associate alle action di tipo Turn right o left.
causes_val(Turnright, direct_x, D, D is ..............).
causes_val(Turnleft, direct_x, D, D is ..............).
causes_val(Turnright, direct_y, D, D is ..............).
causes_val(Turnleft, direct_y, D, D is ..............).
Il moto:
Azione primitiva: start_to_next_station che muove il robot fino alla prossima stazione.
Sempre due i fluenti, location_x e location_y rappresentano le coordinate di posizione all'interno della pista, legate (come nell'idea originale) ai fluenti direct_x e direct_y e all'evento esogeno arrive_at_station
causes_val(arrive_at_station, location_x, N, N is location_x + direct_x).
causes_val(arrive_at_station, location_y, N, N is location_y + direct_y).
Naturalmente la possibilita'di movimento dipende al mondo chiuso in cui il robot si muove, vincolando i possibili valori delle causes. Allo stesso modo l'evento che muove il robot e'vincolato all'esistenza di una stazione successiva.
poss(start_to_next_station, <<<< se esiste la stazione successiva lungo il percorso>>>).
Il goal:
Azioni primitive: Pick_up e Put_down che rispettivamente chiudono la pinza afferrando l'oggetto e la riaprono; l'una legata implicitamente alla pressione di un micro interruttore posto sul fronte del robot l'altra all'evento put_down.
Il fluente is_pick rappresenta lo stato della pinza -1 se aperta e +1 se chiusa, la modifica e' affidata all'evento di arrivare alla stazione (arrive_at_station) indicata [dest(locate_x,locate_y)] dall' utente e dall'evento esogeno Pick_up. Nel caso in cui l'evento pick_up si verificasse in un punto diverso dalla stazione il robot passa in uno stato di incertezza.
causes_val(pick_up, is_pick, D, D is (-1) * is_pick). % cambio di stato di is_pick
causes_val(pick_up, incerto, (1), non dest(locate_x, locate_y)). % se non e'in destinazione e riceve il messaggio pick_up lo stato diventa incerto.
poss(Put_down(N,M), and(dest(N, M), is_pick) ). % La put_down rilascia l'oggetto precedentemente preso se e'arrivato a destinazione e se esiste un oggetto
Alcune considerazioni pratiche
Prima di affrontare le tappe evolutive del progetto facciamo alcune considerazioni pratiche riguardanti il sensore che permettera' di seguire la pista. Considerazioni che potranno essere utili per ulteriori estensioni del progetto. Il sensore rileva, a distanze di pochi millimetri, l'intensita' luminosa di una sorgente di luce rossa. Vista la scarsa scala di valori campionati dal sensore si e' reso necessario realizzare una tabella campione per determinare quanti colori potevano essere usati contemporaneamente in una singola pista. Tenuto conto delle oscillazioni dei valori durante il moto del robot e dell' impossibilita' di stampare a colori sono stai individuati circa 6 tonalita' di grigio complessive che potranno essere utilizzate contemporaneamente. La tabella sotto riportata mostra i livelli di grigio con i relativi valori campionati.
La distanza numerica di ogni valore campionato e' sperimentalmente sufficiente per controllare gli errori duvuti al moto e all livello di illuminazione ambientale.
Un ulteriore suggerimento per i futuri progetti riguarda l'impostazione della velocita'dei robot e l'utilizzo di cingoli per il moto che influiscono negativamente sulla stabilita'. L' utilizzo di cingoli, benche' piu' adatti a terreni non piani, apesantisce il robot diminuendone la mobilita'. Nel caso di Eagle la pista, piana, rendeva superflua, benche'possibile, la scelta dei cingoli.
La realizzazione del progetto
Il piano di realizzazione del progetto nel suo complesso, suddiviso in sottoparti, si sviluppa con una struttura a grafo con radice la personalizzazione e la realizzazione di un robot che metta in evidanza una primitiva intelligenza.
Non e' questa la sede per puntualizzare l'idea di primitiva intelligenza, fondamentalmente si puo'pensare a questa come a una qualche sorta di forma autonoma di comportamento.
Formalmente le tappe del progetto sono state definite nel modo sotto indicato.
Realizzazione
del robot
Test
con ambiente di sviluppo grafico Lego
Analisi
e Test del programma di Maurice Pagnucco sull'automa
Personalizzazione
del programma
La realizzazione
Diversi sono stati i problemi realizzativi che sono stati superati piu' o meno con successo. Tra questi l'assoluta inesperienza di tipo meccanico ha portato a ricostruire piu' volte le diverse parti del robot che, di volta in volta, presentavano i piu' svariati difetti. In particolare ricordiamo la difficolta' nel realizzare le pinze del robot e come riuscire a determinare la loro posizione (aperte o chiuse); problema alla fine risolto utilizzando delle frizioni e mantenendo in rotazione il motore delle pinze.
Un ulteriore problema riguarda la stabilita' del robot stesso che, inizialmente, si presentava troppo alto e sbilanciato rispetto alla dimensione. Dopo svariati tentativi spesso conclusi con l'auto distruzione del robot stesso dopo qualche metro, l'utilizzo di 3 ruote, il ribassamento della pinza e il decentramento del corpo principale hanno risolto almeno parzialmente questo problema.
Complessivamente questo punto del progetto ha fornito uno spunto per analizzare il funzionamento di alcune parti meccaniche, viti senza fini, frizioni e altre componenti. La necessita' di trovare soluzioni a problemi pratici di stabilita' e cinematica ha permesso di aprire una parentesi pratica oltre alle teorie del settore informatico.
I primi passi
Il passo successivo aveva come obiettivo la verifica del funzionamento e un primo approccio alla programmazione con l'ambiente visuale fornito in bundle con il kit di Lego®. La prima applicazione sviluppata permetteva di seguire una pista nera con sfondo chiaro.
Di particolare interesse, la gestione dei dispositivi sensoriali, in particolar modo i sensori di prossimita' e rotazione: il primo consente di rilevare diverse tonalita'di grigio e il secondo di misurare una rotazioni di un albero.
Test
La prima vera sfida di Eagle e' stato lo studio del progetto originale, di come era stato sviluppato e come poteva essere modificato per poter sviluppare il punto successivo. Nel progetto originale di Maurice il robot segue una pista nera con delle stazioni di colore argento in cui fermarsi a richiesta dell'utente. Purtroppo il lavoro di Maurice, benche' molto commentato, e' carente di spiegazioni introduttive in particolare dei frame di progettazione e sviluppo. Grazie pero' alla particolare pulizia del codice e alla suddivisione in file del progetto originale l'analisi si riduce allo studio di due soli file delivery.nqc, la componente di medio livello da inserire nel cuore del robot, e delivery.pl il programma vero e proprio.
La personalizzazione e il comportamento intelligente
Considerazioni finali
Il parziale fallimento del progetto
Difficile fare un'analisi critica dei motivi che hanno portato al parziale fallimento dell'ultimo punto del progetto (personalizzazione) ma una delle prime riflessioni da fare e' sulla dimensione teorica del progetto di Maurice. Il progetto prevede un vasto assortimento di conoscenze di base che, partendo dalla programmazione di C arrivano fino alla padronanza, almeno a grandi linee, di Golog. Passiamo quindi da uno stile di programmazione funzionale tipico dei linguazzi like C ad uno stile nuovo come quello del Golog. Certamente Golog presenta funzionalita' innovative rispetto ad altri linguaggi tanto da meritare un approfondimento ulteriore. Benche' il Golog non aumenti il numero delle funzioni calcolabili presenza una potenza espressiva nuova con un diverso tipo di approccio alla programmazione. Il nuovo aspetto logico della programmazione e' stato di sicuro un elemento di difficolta per il gruppo che proviene da un'esperienza di programmazione funzionale/algoritmica.
Un ulteriore elemento di analisi e' il tipo di progetto scelto che troppo si discosta da quello originale di Maurice aumentando cosi' i tempi di sviluppo e analisi del nuovo programma. In particolare il problema delle ramificazioni della pista e la decisione da parte nostra di permettere all'utente di indirizzare il robot in una delle possibili ramificazioni. Certo si poteva ridurre il problema delle ramificazioni a delle scelte casuali ma la dimostrazione di un comportamento intelligente parte dalla consapevolezza, almeno parziale, della propria posizione nel mondo chiuso. Potevamo anche restringere il dominio ad una sola pista rettilinea ma in questo caso avremmo semplicemente ricopiato con abbellimenti il programma originale.
L'ultima considerazione riguarda, purtroppo, i tempi strettissimi di studio e sviluppo non di meno ad una certa ansia nel termine di consegna che certo non hanno influito positivamente durante la realizzazione del progetto. Il problema del tempo, in parte dovuto alla poca organizzazione del gruppo, si e' riflesso sull'andamento generale ritardando lo sviluppo.
