Static Parameters

Specifying Parameters in roslaunch Files

The preferred way of specifying static parameters for ROS-based programs is using roslaunch xml files which supply information to the ROS Parameter Server.

1. param vs rosparam

In roslaunch files, <param> tags are for setting a single parameter and <rosparam> tags are for setting groups or more complex structures of parameters.

The value set by the <param> tag may only be a string, int, bool, or double, which may be set through the xml attribute value, or by reading in from a text file, bin file, or the output of a command line command.

The <rosparam> tag enables users to define a batch of related parameters simultaneously. These can be read from a YAML string which can either be put inline in the launchfile or can be loaded from a file (the rosparam dump command generates YAML output). Unlike the <param> tag, the YAML specification allows nested structures of parameters and parameters with list values. While these data can be represented on the ROS parameter server, it is up to the various client libraries to support complex parameter access.

A good example of the <rosparam> tag use in practice is the move_base package, where there are many, many parameters to be set, it's less cumbersome to just use the YAML format.

Specifying Parameters in Command-Line Arguments

Static parameters can also be supplied directly to the node via command-line arguments. This is a good option for parameters which don't require introspection from outside of a given node, or for command-line utilities which are meant to be run manually.

Performance Considerations

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.

Parameters Which Are Subject to Change at Runtime

dynamic_reconfigure

• Reasonably nice GUI with minimal implementation effort
• Efficient updates
• Callbacks are triggered when parameters are updated
• Clean separation between nodes, making them easy to reuse

• Parameter updates are mirrored on the Parameter Server

dynamic_reconfigure and the Parameter Server (which getParam() uses) are designed to solve different problems. The parameter server is useful for situations where you know the value of parameters before a node starts, and know that those parameters are unlikely to change. dynamic_reconfigure is for situations where you might not know the values of parameters before a node starts, or those parameters might change while a node is running.

Dynamic reconfigure require a little extra development effort in creating the cfg file where all the parameters and their types are declared, and requires a callback in the reconfigurable node which is called when the configuration changes.

The choice between using the parameter server and dynamic reconfigure does not have to do with performance, it has to do with whether or not parameters will change while a node is running. Dynamic reconfigure may impose a slight performance penalty since it will need an extra thread for its callback, but it's probably not significant.

"Cached" Access to the Parameter Server

Using getParamCached() will cache changes from the Parameter Server so that when it's called, it will not block while sending a request and waiting for a response from the Parameter Server.

Service Call-Based Re-configuration

Service-calls with payloads can also be used for parameterizing a node at runtime.