ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

rosparams vs. command line arguments for initialization

asked 2012-12-06 09:45:27 -0500

thebyohazard gravatar image

In my understanding, nodes can get initialization arguments in two ways:

  1. rosrun or roslaunch xml files can pass command line arguments straight to the main method
  2. the node can use the ros parameter server to get parameters that have been loaded by rosparam or roslaunch loading a yaml config file.

Are there any benefits to one over the other? Perhaps in terms of performance (I plan to use ROS on embedded devices), flexibility, or some other way I'm not thinking of? Or is there a best practice?

I see a clear case for yaml in the case of things like motor parameters, since you may want to tweak them while the node is running and save the value you ended up with for subsequent runs.

But what about a parameter that will not change during execution such as a parameter that specifies whether a node is left or right handed?

Or what about parameters that are not always used? For example, a node type could be 'tcp' or 'serial.' It then either needs an IP address or a port, but not both.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2012-12-06 10:25:26 -0500

joq gravatar image

updated 2012-12-06 10:28:40 -0500

For parameters that are only processed once at initialization, performance is not an issue. If there are a lot of them to set, YAML files are a good choice. They are easy to read and easy to edit. You can conveniently store them in packages. For a node with only a few parameters, it may be easier to set them in a launch file. The rosrun command line is mostly good when running a node separately for testing or debugging.

Sensible default values help keep things simple. Unused parameters can default to something like an empty string, where appropriate.

The only performance issue is when parameters need to be updated while the node is operating. Use getParamCached() instead of getParam() in that case, to avoid bogging down the parameter server. Or, use the excellent dynamic_reconfigure package, which will invoke a callback in your node whenever a parameter changes.

edit flag offensive delete link more

Question Tools


Asked: 2012-12-06 09:45:27 -0500

Seen: 2,354 times

Last updated: Dec 06 '12