* Progetto Robot Autonomo - Cardillone *

Luigi Zappa (lz562575@silab.dsi.unimi.it)

1. Introduzione:

Il progetto consiste nella costruzione di un agente (un robot) che esibisca un comportamento autonomo "delivery-like".

· Hardware: a nostra disposizione, per la costruzione del robot, avevamo una confezione "Lego Mindstorm" ed una di "Lego Tecnics" contenenti, oltre ai vari mattoncini:

A. Blocco RCX (Robotic Command Explorer), la tecnologia RCX consiste in un dispositivo indipendente, un processore Hitachi H8/3297 montato all'interno di un blocco Lego che dispone di:

· tre input sensoriali

· tre output cui e’ possibile collegare motori

· una porta di I/O ad infrarossi

· una memoria capace di contenere fino a cinque programmi

· un display LCD multifunzione

· un altoparlante per produrre output di controllo.

B. Una serie di sensori per fornire input all'RCX, come sensori di contatto, di luminosita’, di rotazione e termici.

C. Tre motori ed una sorgente luminosa, da collegare agli output dello RCX.

D. Un Beacon, cioe’ un ricetrasmettitore di impulsi all' infrarosso che interfaccia l'RCX al PC (va collegato alla porta seriale).

· Software:

A. NQC (Not Quite C), un linguaggio di programmazione C-like che permette di definire procedure sincrone e task asincroni per il monitoraggio dei sensori.

B. Legolog, un sistema di trasmissione avanzato che permette di comunicare, tramite interi di dimensione variabile, con l'RCX.

C. Golog, un meta-interprete ProLog basato sul Situation Calculus di McHarty, che supporta flussi di controllo, scelte non deterministiche, priorita’, concorrenza, interrupts, azioni esogene e sensing.

2. Descrizione Del Dominio:

Di tipo controllato, ma aperto. Consta di un tavolo, una pista, il robot ed infine un oggetto:

A. La pista, realizzata con nastro adesivo scuro, che puo’ essere di forma qualsiasi, sulla quale sono presenti sei stazioni, piu’ o meno equidistanti, costruite con carta stagnola di colore argenteo.

B. Il tavolo, di color beige con dei bordi marrone scuro (i colori sono importanti per il sensore di luminosita’).

C. Il robot, e’ un cingolato, monta tre motori: due per i cingoli ed uno per il meccanismo di acquisizione dell'oggetto che e’ di tipo "tenaglie", simili a quelle descritte sul manuale (differiscono per la vite infinita da noi utilizzata) poste sulla parte anteriore del robot. Sono utilizzati inoltre un sensore di luminosita’, posizionato sotto le tenaglie, ed infine uno di contatto in mezzo alle tenaglie. Siccome il sensore di contatto e’ risultato di ridotte dimensioni e poco sensibile, abbiamo ideato un meccanismo scorrevole che poggia sullo stesso (in caso di avvenuto contatto ovviamente) premendolo perfettamente e che aumenta la superficie di contatto.

D. L'oggetto, rappresenta l'ente su cui effettuare la delivery, e’ costruito anch'esso soltanto con pezzi presenti nel kit Lego Mindstorm & Tecnics. E' stato studiato appositamente pensando alla struttura fisica del nostro robot: ha una struttura a “spaventapasseri" che permette una facile e sicura presa alle tenaglie del robot. Tale forma fa in modo che una volta afferrato l'oggetto si sollevi leggermente dalla superficie del tavolo in modo che non venga trascinato provocando cosi’ impedimenti al regolare incedere del robot. Alla base dello stesso vi sono delle ruote in posizione orizzontale che fanno attrito con il suolo conferendo stabilita’ all'oggetto, in modo che il robot lo possa afferrare senza che scivoli via.

3. Goal:

Rispetto alla versione realizzata da Pagnucco, Reiter e Levesque, noi abbiamo reso l'esecuzione della delivery piu’ robusta assumendo dominio parzialmente aperto. Tale compito consiste nella ricerca di un blocco, l'acquisizione, ed il trasporto a destinazione; dopodiche’ il robot ritorna "a casa" ossia alla prima stazione. La situazione iniziale rimane pressoche’invariata cioe’ il robot si trova alla stazione numero tre orientato verso la parte piu’ lunga della pista. L'oggetto puo’ essere posizionato in un punto qualsiasi del tavolo oppure puo’ non essere presente sullo stesso. Il nostro obiettivo e’ quello di cercare sulla pista e nei suoi dintorni l'oggetto per portarlo alla stazione che l'utente indica mediante una query fatta con l'interprete Prolog. Se il robot, dopo una esplorazione completa della pista, non trova nulla la percorre nuovamente pero’seguendola con un andamento irregolare, simile ad uno zig-zag, per cercare l'oggetto nelle prossimita’ della stessa. Se anche dopo questa seconda ricerca non si ha successo, il robot ritorna alla stazione numero uno in attesa di nuove query dall'utente (si e’ assunto che l'oggetto non e’presente nel dominio). Durante l'ultima esplorazione (quella con andamento a zig-zag) e’ possibile che il robot si imbatta con il limitare del tavolo, allora ci si arresta e si arretra un po' per evitare un macabro epilogo. Nel caso il robot trovi l'oggetto, lo afferra e lo trasporta alla stazione desiderata emettendo due tonalita’sonore differenti al momento della acquisizione e del rilascio dell'oggetto.

4. Autonomia e Comportamenti Intelligenti:

Come gia’ scritto nella sezione "goal" ci siamo proposti di rendere il compito della delivery piu’ sicuro e adattivo. L'oggetto da trasportare puo’ essere sito in un qualsiasi locazione sul tavolo (in un intorno definito della pista), viene raccolto autonomamente dal robot senza bisogno dell'intervento umano. Inoltre, il robot, sa riconoscere i confini del dominio (i bordi del tavolo) evitando cosi’ di danneggiarsi. Abbiamo inserito nel dominio anche il robot stesso perche’ la sua stessa stazza va considerata come parametro. Infatti, per esempio, quando si rilascia l'oggetto alla stazione di destinazione spesso e’ necessaria una azione di "turnAround" (ovvero il robot ruota su di se’ di 180 gradi) per ritornare alla prima stazione. Questo comportamento potrebbe causare l'urto del robot con l'oggetto appena consegnato con conseguente rovesciamneto dello stesso. Per evitare questo fenomeno indesiderato si rende utile una piccola "retromarcia" prima di girarsi e di tornare alla stazione "home". Nella nostra implementazione le query vengono effettuate nella medesima maniera della versione originale, anche se il primo parametro risulta essere non necessario, in quanto il blocco da trasportare verrebbe comunque ricercato nel dominio.

5. Programma:

Il programma utilizzato come canovaccio per il nostro progetto e’ il delivery (.pl e .nqc) del dott. Pagnucco. Date le modifiche necessarie al raggiungimento del goal propostoci, abbiamo deciso di rielaborare quasi completamente il file originale, riordinandolo secondo il nostro gusto ed eliminando tutto cio’ che non abbiamo ritenuto essenziale. Le query hanno lo stesso schema del delivery originale, ma il primo paramentro, ovvero la stazione di partenza, risulta nel nostro caso inutile. Inoltre sono stati inseriti dei nuovi fluenti:

· where_to_deliver, il quale indica la stazione alla quale deve essere consegnato l’oggetto;

· bot_state, necessario per tenere traccia dello stato in cui si trova il robottino (ulteriori spiegazioni di seguito);

· cargo, che indica se il robot ha con se l’oggetto oppure no (empty e full);

· motion, che indica il tipo di movimento del robot, e puo’ assumere i valori moving, stopped e retreating.

Il valore iniziale del fluente bot_state e’ “tranquillo”.Una volta richiesta una delivery al robot, esso parte alla ricerca di un oggetto sulla pista. Percorre esaustivamente la pista nella direzione in cui si trova, e nel caso non riesca a trovarlo, passa dallo stato “tranquillo” allo stato “preoccupato”. A questo punto ripercorre nuovamente la pista in direzione opposta per assicurarsi di aver controllato tutte le stazioni. Se la sua ricerca fallisce nuovamente, il robot diventa “isterico”. Il comportamento dell’agente subisce allora una mutazione sostanziale: percorre la pista in modo piu’ accurato controllando anche un intorno della pista, muovendosi alla sua sinistra ed alla sua destra per una decina di centimetri ad ogni piccolo avanzamento. Se finalmente riesce a trovare un oggetto, torna ad essere tranquillo e lo porta alla stazione desiderata, altrimenti torna sconsolato alla base.
Per quanto riguarda le azioni che l’agente puo’ compiere, l’unica variazione sostanziale e’ l’introduzione delle azioni take_object e release_object. Per quanto riguarda invece il file .nqc, sono stati aggiunti dei controlli per rilevare il bordo del tavolo, e sono state modificati i task e le procedure originali per soddisfare le caratteristiche dell’ambiente nel quale si muove il nostro robot.

6. Problemi:

La comunicazione e’ certamente la parte piu’ problematica e cio’ che crea problemi e' il sistema a raggi infrarossi, notoriamente imprecisi e soggetti a problemi di direzionalita’. Quello che si puo’ fare e’ cercare di piazzare il dispositivo di trasmissione seriale nella posizione e nella direzione giusta, ma questo ovviamente dipende dall'ambiente di lavoro. E' inoltre importante sapere che le batterie dell'RCX devono sempre essere cariche; sotto i 7.5 Volt i problemi di comunicazione si fanno troppo frequenti. In ogni caso, e’ bene tenere presente che il sistema di comunicazione puo’ cadere in ogni momento: spesso appare un messaggio che indica la perdita di contatto fra l'RCX ed il Golog con richiesta di premere un tasto per continuare. Spesso premendo l'esecuzione continua normalmente, ma altre volte occorre reinizializzare il tutto.

Ulteriori problemi sono nati nella manipolazione del file NQC:

· limitato numeri di variabili “int”, superato convertendo in variabili globali alcune di esse;

· limitata memoria a disposizione nell’RCX, che impedisce la definizione di troppe procedure e ne limita l’estensione. A questo proposito abbiamo notato che convertendo una procedura in “task” lo spazio risultava bastevole; infatti i task hanno un porzione di memoria dedicata;

· necessita’ di assicurarsi che i task non interferissero, a volte il fatto che il robot non esibisse il comportamento desiderato dipende dalla presenza in background di task differenti che sovrascrivono il comportamento desiderato.