Difference between revisions of "Talk:Effects of Rates of Perception and Decision in Exploration"

From AIRWiki
Jump to: navigation, search
Line 41: Line 41:
 
----
 
----
 
'''Prime simulazioni con parametri di default''':
 
'''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 20KhZ, è 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.
 
dalle simulazioni con parametri di default emerge che la frequenza alla quale lavora il controllore delle ruote, pari a 20KhZ, è 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,
+
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 quindi 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 è invece interessante, e i dati corrispondenti non devono essere scartati. Visto perciò che un tempo alto di esplorazione non è un segnale univoco di errori indesiderati (ovvero le soste del robot) si è spostata l'attenzione sulla velocità di simulazione.

Revision as of 14:54, 19 August 2011

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:

  1. misura del tempo impiegato / distanza percorsa per completare l'esplorazione dell'ambiente
  2. 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 ≈ 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 20KhZ, è 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 quindi 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 è invece interessante, e i dati corrispondenti non devono essere scartati. Visto perciò che un tempo alto di esplorazione non è un segnale univoco di errori indesiderati (ovvero le soste del robot) si è spostata l'attenzione sulla velocità di simulazione.