You're reading the documentation for an older, but still supported, version of ROS 2. For information on the latest version, please have a look at Iron.
In ROS 1, parameters are associated with a central server that allowed retrieving parameters at runtime through the use of the network APIs. In ROS 2, parameters are associated per node and are configurable at runtime with ROS services.
See ROS 2 Parameter design document for more details about the system model.
See ROS 2 CLI usage for a better understanding of how the CLI tools work and its differences with ROS 1 tooling.
This guide describes how to adapt ROS 1 parameters files for ROS 2.
YAML is used to write parameters files in both ROS 1 and ROS 2. The main difference in ROS 2 is that node names must be used to address parameters. In addition to the fully qualified node name, we use the key “ros__parameters” to signal the start of parameters for the node.
For example, here is a parameters file in ROS 1:
lidar_name: foo lidar_id: 10 ports: [11312, 11311, 21311] debug: true
Let’s assume that the first two parameters are for a node named
/lidar_ns/lidar_node_name, the next parameter is for a node named
/imu, and the last parameter we want to set on both nodes.
We would construct our ROS 2 parameters file as follows:
/lidar_ns: lidar_node_name: ros__parameters: lidar_name: foo id: 10 imu: ros__parameters: ports: [2438, 2439, 2440] /**: ros__parameters: debug: true
Note the use of wildcards (
/**) to indicate that the parameter
debug should be set on any node in any namespace.
Some features of ROS 1 parameters files do not exist in ROS 2:
Mixed types in a list is not supported yet (related issue)
radsubstitutions are not supported