Talk:Effects of Rates of Perception and Decision in Exploration

From AIRWiki
Revision as of 14:22, 19 August 2011 by SimonePignatelli (Talk | contribs)

Jump to: navigation, search

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,