ROS Graph Concepts: Nodes | Topics | Services | Messages | Bags | Master | Parameter Server

A parameter server is a shared, multi-variate dictionary that is accessible via network APIs. Nodes use this server to store and retrieve parameters at runtime. As it is not designed for high-performance, it is best used for static, non-binary data such as configuration parameters. It is meant to be globally viewable so that tools can easily inspect the configuration state of the system and modify if necessary.

The Parameter Server is implemented using XMLRPC and runs inside of the ROS Master, which means that its API is accessible via normal XMLRPC libraries.

Parameters

Parameters are named using the normal ROS naming convention. This means that ROS parameters have a hierarchy that matches the namespaces used for topics and nodes. This hierarchy is meant to protect parameter names from colliding. The hierarchical scheme also allows parameters to be accessed individually or as a tree. For example, for the following parameters:

/camera/left/name: leftcamera
/camera/left/exposure: 1
/camera/right/name: rightcamera
/camera/right/exposure: 1.1

The parameter /camera/left/name has the value leftcamera. You can also get the value for /camera/left, which is the dictionary

name: leftcamera
exposure: 1

And you can also get the value for /camera, which has a dictionary of dictionaries representation of the parameter tree:

left: { name: leftcamera, exposure: 1 }
right: { name: rightcamera, exposure: 1.1 }

NOTE: The current implementation does not enforce the naming conventions of parameter names. However in the future they may be so you should follow them.

Parameter Types

The Parameter Server uses XMLRPC data types for parameter values, which include:

  • 32-bit integers
  • booleans
  • strings
  • doubles
  • iso8601 dates
  • lists
  • base64-encoded binary data

You can also store dictionaries (i.e. structs) on the Parameter Server, though they have special meaning. The Parameter Server represents ROS namespaces as dictionaries. For example, imagine you set the following three parameters:

/gains/P = 10.0
/gains/I = 1.0
/gains/D = 0.1

You can either read them back separately, i.e. retrieving /gains/P would return 10.0, or you can retrieving /gains, which would return a dictionary:

{ 'P': 10.0, 'I': 1.0, 'D' : 0.1 }

Just like the ROS naming hierarchy, you can nest dictionaries within dictionaries to represent child namespaces.

Private Parameters

The ROS naming convention refers to ~name as a private name. These private names primarily are for parameters specific to a single Node. The ~ prefix prepends the Node's name to use it as a semi-private namespace -- they are still accessible from other parts of the system, but they are generally protected from accidental name collisions.

You can use remapping arguments to specify node parameters on the command line by changing the tilde ~ to an underscore _, e.g.:

rosrun rospy_tutorials talker _param:=1.0

Parameter Tools

The rosparam command-line tool enables you to query and set parameters on the Parameter Server using YAML syntax.

Client Library Support

Python

See the rospy overview.

C++

See the roscpp overview.

Wiki: Parameter Server (last edited 2013-08-07 01:15:31 by DirkThomas)