-

hey viewer, we're moving!

We are currently transitioning to a new web system, so we are not updating this wikisite anymore.

The public part of the new web system is available at http://www.ira.disco.unimib.it


ROS Tips and Tricks

From Irawiki

Jump to: navigation, search

Pagina per raccogliere le nozioni acquisite su ROS. Per aggiungere qualcosa bisogna averci sbattuto la testa almeno un'ora..

Contents

Mailing list e Ros Answers

Mailing list principale ROS_USERS http://code.ros.org/lurker/list/ros-users.html

Archivio della mailing list su Nabble http://ros-users.122217.n3.nabble.com/ (non inoltrare messaggi da Nabble in quanto non vengono inoltrati sulla mailing-list!)

Sito domande/risposte http://answers.ros.org/questions/


ROS distribuito: Impostazione degli hostname su setup.sh

Questo file, se l'installazione di ROS è stata effettuata con i binari (e non con la ricompilazione dei sorgenti) dovrebbe trovarsi su /opt/ros/{ROS_RELEASE}/setup.sh

Come macchina principale si intende la macchina che esegue roscore

if [ ! "$ROS_MASTER_URI" ] ; then export ROS_MASTER_URI=http://_INDIRIZZO_MACCHINA_PRINCIPALE_:11311 ; fi

if [ ! "$ROS_IP" ] ; then export ROS_IP=_INDIRIZZO_MACCHINA_ATTUALE_ ; fi Oppure: if [ ! "$ROS_HOSTNAME" ] ; then export ROS_HOSTNAME=_HOSTNAME_MACCHINA_ATTUALE_O_IP ; fi

NB: bisogna modificare i setup di tutti i computer che si vogliono utilizzare, anche quello su cui gira roscore. Attenzione perchè si potrebbero avere problemi di certificato se più computer lo condividono. Una volta che si imposta l'ip del master, tale indirizzo deve essere disponibile. Se imposto l'indirizzo ip della rete unimib-U14 e non è effettivamente collegato darà un errore dicendo che non riesce a pingare il master.

Running roscore on another machine

The ROS Master provides naming and registration services to the rest of the nodes in the ROS system. It tracks publishers and subscribers to topics as well as services. The role of the Master is to enable individual ROS nodes to locate one another. Once these nodes have located each other they communicate with each other peer-to-peer. http://www.ros.org/wiki/Master

To run roscore through ssh type "roscore &": the master will stay active also after disconnect. to kill the master on reconnect type "ps aux | grep roscore" and then "sudo kill RoscorePID"


References

Costmap global planner

Un comportamento anomalo riscontrato è il seguente: se si aggiorna la costmap del global planner con i dati del laserscanner questi vengono considerati per generare il global plan. Si verifica però che anche ostacoli mobili vengono considerati e se questi non vengono correttamente rimossi (ad es se il robot li supera e questi si spostano), il plan generato non è quello desiderato perchè cerca di evitare tali presunti ostacoli. Per risolvere questo problema si è deciso di non includere i dati del laser per aggiornare la global costmap che resterà sostanzialmente la mappa statica.

Per implementare questa soluzione bisogna spostare la source list dal file costmap_common_params al solo local_costmap verificando che sia nel namespace locale

Reference frame conventions

Udite udite, dopo innumerevoli ore di imprecazione è saltato fuori per caso questo report sulle naming conventions usate con relativo significato semantico (c'è anche odom).. http://www.ros.org/reps/rep-0105.html; inoltre ecco la descrizione di come AMCL interviene per modificare il frame odom AMCL_ROS

Unit and coordinate conventions: http://www.ros.org/reps/rep-0103.html

Nodelet e più in generale i "Plugins"

Nel repository USAD è presente un progetto NODELETTE, tutorial autocostruito per fare i primi passi con i nodelet (e quindi con i plugin, in quanto i nodelet sono plugin che si caricano dinamicamente su un nodelet manager). Ulteriori spiegazioni http://www.ros.org/wiki/nodelet

Multicore ROS

Using "export ROS_PARALLEL_JOBS=-jX" with X being the number of your cpu cors at maximum, will speed the compilation up by a factor of X, but will need huge amounts of memory (~ 1GB per core). http://www.ros.org/wiki/rgbdslam

CMakeLists tweaks

cmake_minimum_required(VERSION 2.4.6)
include($ENV{ROS_ROOT}/core/rosbuild/rosbuild.cmake)

set(ROS_BUILD_TYPE Release)
#set(ROS_BUILD_TYPE Debug)

rosbuild_init()

if (ROS_BUILD_TYPE STREQUAL Release)
	#release mode, optimizations enabled
	add_definitions (-Wno-missing-field-initializers -O4 -DNDEBUG -mfpmath=sse -msse4 -fopenmp )
else()
	#debug mode, optimizations disabled
	add_definitions (-Wno-missing-field-initializers -O0 -DNDEBUG -mfpmath=sse -msse4 -fopenmp )
endif()

Parameter server and dynamic reconfigure

Although they can look very similar, they are different because of their purpose.

  • the parameter server is to be used for initialization of values
  • the dynamic reconfigure is to be used for changing parameters

The reason lay in the fact that a query to the parameter server is a tcp request, while a query to the internal node configuration is a memory access, i.e. faster.

Example

One could say: I want to change the particle set dimension at will!

Wrong solution:

'
while(ros::ok())
	for (int i = 0; i < nodeHandle.getParam("NumberOfParticles"); ++i)
	{
		//generate particles and do stuff
	}
}

this is wrong since every loop includes a call to the parameter server. A little fix could be to call paramCached (or similar) to avoid tcp requests but it is not a solution.

Right solution

while(ros::ok())
	for (int i = 0; i < dynConf.NumberOfParticles); ++i)
	{
		//generate particles and do stuff
	}
}

each loop only checks a local variable, but that variable can be changed at will with dynparam/reconfigure_gui.

Do right, get more

Using the dynamic reconfigure you will get two bonuses:

  • the reconfigure gui, which allows for a quick reconfigure, and a cool zero-effort gui
  • the possibility to set defaults in the launchfile since for each parameter dynamically reconfigured, at first the parameter server will be queried to retreive, if available, a default value, which will overload the default wrote in the gen file
Personal tools