View source for Talk:Effects of Rates of Perception and Decision in Exploration

installazione di ROS Diamondback precompilato su ubuntu 10.04

creazione directory per l'installazione di nuovi package

aggiunta alle variabili di ambiente del path di ROS e della cartella per i package personalizzati

aggiunta della var di ambiente ''ROS_HOSTNAME=localhost'' per far sì che il tutto funzioni anche offline

scaricamento e compilazione dei sorgenti del package explore_stage e di tutte le sue dipendenze

correzione del parametro ''pose'' (aggiunta del 4° elemento: orientamento) all'interno dei file di configurazione nel package ''bosh_worlds''

sempre all'interno degli stessi file, modifica dei parametri riguardanti l'immagine della mappa (bitmap, size)

lancio della simulazione col comando ''roslaunch explore_stage explore_slam.launch''. Con questa configurazione il robot per stimare la sua posizione utilizza l'odometria. Inoltre viene introdotto forzatamente un errore sui dati dei sensori, in modo da simulare il comportamento di un robot "reale", ad esempio lo scivolamento delle ruote. Per compensare gli errori di localizzazione durante il processo di SLAM (Simultaneous Localization and Mapping) il robot utilizza un algoritmo di loop closure.
::se si vuole eseguire una simulazione "esatta" (posizionamento gps) occorre eseguire il comando ''roslaunch explore_stage explore.launch''

strumenti utilizzati: '''rviz''' (dati dei sensori, mappa costruita, traiettorie calcolate), '''xgraph''' (nodi coinvolti nella simulazione e loro collegamenti), '''rxconsole''' (visualizzazione log), '''rostopic''' (informazioni sui topic pubblicati), '''rosmsg''' (informazioni sul tipo dei messaggi spediti sui topic)

----
'''Parametri importanti:'''
*explore_stage/explore/explore_costmap.yaml: ''update_frequency'' (default 1.0)
::frequenza con la quale il robot aggiorna la mappa dell'ambiente
*explore_stage/explore_slam.xml: ''planner_frequency'' (default 1.0)
::frequenza con la quale il robot calcola il nuovo goal da raggiungere
----
'''Valutazione delle prestazioni:'''
# misura del tempo impiegato / distanza percorsa per completare l'esplorazione dell'ambiente
# fissato il tempo, misurazione della percentuale di completamento della mappa
----

creazione del package ''explore_test'' con le varie dipendenze (fare attenzione ai tipi dei messaggi pubblicati sui topic da ascoltare)

creazione di un nodo in ascolto su due topic:
* ''explore/map'' dove viene pubblicata la mappa esplorata. Messaggio del tipo ''nav_msgs/OccupancyGrid''. La mappa completa è una matrice 300x300, nella quale gli elementi con valore ''-1'' corrispondono a posizione dell'ambiente non ancora esplorate. Con la mappa di prova, il robot termina di esplorare con copertura &asymp; 10100.
* ''move_base/feedback'' dove viene pubblicata la posizione attuale del robot (con frequenza 10 Hz). Viene calcolata la distanza totale percorsa sommando le distanze euclidee tra punti successivi.

modifica del package ''explorer'' al fine di implementare la scelta "random" per il next goal. L'uso di random serve come bottom-line per confrontare le altre strategie. Ci si aspetta che nessuna faccia peggio di random. Random potrebbe avere senso se il tempo di aggiornamento della decisione è alto (= la frequenza è bassa), in caso contrario il robot non riesce ad esplorare poiché cambia goal in continuazione e quindi non riesce a raggiungerne nessuno.
::per forzare il comportamento random, occorre impostare correttamente i parametri ''potential_scale'', ''orientation_scale'', ''gain_scale'' e ''random_scale'', all'interno del file ''explore_slam.xml''. In particolare i primi tre vanno settati a 0.0 e l'ultimo a 1.0

----
'''Prime simulazioni con parametri di default''':

dalle simulazioni con parametri di default emerge che la frequenza alla quale lavora il controllore delle ruote, pari a 20Hz, è troppo alta per l'architettura sulla quale gira il simulatore. Questo causa frequenti errori che rallentano il robot e contribuiscono ad aumentare il tempo di esplorazione. Dimezzando la frequenza (parametro ''move_base/controller_frequency'' settato a 10.0) si nota un evidente miglioramento delle prestazioni e la contestuale scomparsa di errori e warnings da parte del controllore. D'ora in poi questo parametro sarà mantenuto tale.

Un altro fenomeno indesiderato che si verifica durante l'esplorazione sono gli stop del robot: a volte il robot si ferma sul posto (in media dai 30 ai 120 secondi) per poi riprendere la marcia. Dopo un'attenta analisi è emersa la causa di queste soste indesiderate: durante la scansione del laser, a causa degli inevitabili errori di percezione, è possibile che siano memorizzati dei punti di frontiera "irraggiungibili", poiché alle spalle di muri o comunque al di fuori della zona esplorabile dal robot. Questi punti teoricamente non dovrebbero nemmeno essere rilevati dal laser, ma come detto questo è inevitabile a causa della superficie suddivisa in pixel. Questo non sarebbe un gran danno se l'algoritmo di esplorazione non mettesse dei punti di frontiera proprio su quei pixel della mappa: ciò provoca il blocco del robot, il quale tenta invano di creare un path per raggiungere quella destinazione fino a far scadere il timeout, per passare quindi alla frontiera successiva. Questo causa quindi una perdita di tempo indesiderata.
La soluzione migliore sarebbe quella di correggere l'algoritmo di ricerca dei punti della frontiera, in modo che escluda queste frontiere "sporche" e irraggiungibili. Questo esula però dallo scopo di questo progetto, quindi è stato deciso di mantenere questo comportamento ma di scartare le prove in cui il robot si comporta in questa maniera, analizzando a posteriori i file di log per eliminare gli outliers, che si presentano con una frequenza di circa il 25%.

Per poter riconoscere questi errori dall'osservazione del log e ripetere in maniera automatica le corrispondenti prove, non è sufficiente osservare il tempo totale di simulazione. Se è vero infatti che un tempo decisamente superiore alla media può indicare delle soste effettuate dal robot, è anche vero che un tempo alto potrebbe essere dovuto anche a scelte scorrette da parte dell'algoritmo di selezione delle frontiere, il quale fa compiere al robot un'esplorazione poco "intelligente" che lo riporta spesso sui suoi passi, facendogli percorrere diverso spazio senza esplorare nuova area. Questo tipo di comportamento è però interessante, quindi i dati corrispondenti non devono essere scartati.

Visto perciò che un tempo alto di esplorazione non è un segnale univoco di comportamenti indesiderati (ovvero le soste del robot) si è spostata l'attenzione sulla velocità del robot, intesa come distanza percorsa diviso tempo totale. Individuata una velocità media, calcolata su prove senza interruzioni, è possibile scartare i dati che presentano una velocità inferiore alla soglia prefissata, poiché le soste del robot fanno diminuire sicuramente la velocità media, mentre scelte errate dell'esploratore comportano magari più strada da percorrere e quindi più tempo dedicato all'esplorazione, ma non interruzioni del moto del robot e quindi un decremento della velocità media.

In maniera automatica sono scartate anche le rare prove nelle quali si verifica una copertura insufficiente della mappa (sempre a causa di frontiere piazzate in punti irraggiungibili) o in cui il robot si blocca a causa di un errore nel controllore delle ruote. Non è ancora stato compreso il motivo per il quale si verifica questo tipo di errore, che causa un blocco indefinito del robot, ma si presenta raramente (nell'ordine dell'1%) e quindi le corrispondenti prove sono automaticamente scartate e ripetute.

----
'''Primi risultati:'''

Sono state eseguite 10 batterie di simulazioni, ognuna da 10 esperimenti ciascuno. Ad ogni esperimento è stato fatto variare il punto di partenza del robot, ripetendo poi gli stessi punti per le batterie successive. Dai dati rilevati, scartati gli outliers, emerge un comportamento abbastanza costante, nel senso che la deviazione standard dei tempi di esplorazione è nell'ordine del 10% della media. Calcolando la deviazione standard tra le prove con stessi punti di partenza, piuttosto che tra prove della stessa batteria, si trovano valori inferiori: questo significa che il tempo di esplorazione dipende anche dal punto di partenza del robot

PARAMETRI DI DEFAULT<br>
esplorazione con rumore sui sensori, SLAM con loop closure<br>
strategia di scelta del goal di default (pesata)<br>
frequenza di aggiornamento della mappa dell'ambiente: 1Hz<br>
frequenza per il calcolo del nuovo goal: 1Hz<br>
dieci punti di partenza differenti sparsi sulla mappa<br>

STATISTICHE
* Medie totali (100 prove)
:''tempo'' 326.3  ''area'' 10084 ''distanza'' 146.75 ''velocità'' 0.45086
* Media delle 10 deviazioni standard tra prove della stessa batteria
:''tempo'' 39.683 ''area'' 74.133 ''distanza'' 16.593 ''velocità'' 0.023669
* Media delle 10 deviazioni standard tra prove con lo stesso punto di partenza 
:''tempo'' 28.696 ''area'' 66.928 ''distanza'' 9.2028 ''velocità'' 0.020479


[TODO] inserire risultati per ogni punto di partenza e per ogni batteria