Skip to main content

ROS2-007-Communication Mechanisms: The Parameter Service

Jeacson She2/28/25...About 5 minComputerrobotROS

Introduction

Parameters are ROS2's key-value storage mechanism for the run-time dynamic configuration of a node. Parameters don't need a centralised repository to hold the information — they belong directly to the node itself. Parameters let you read and write a node's internal configuration through the service interface while it runs, without touching the code or restarting the node. Unlike topic communication (Topics) and service communication (Services), parameter interaction is essentially access to and control over the internal state of a node, not plain data flowing between nodes.

Concretely:

  • Parameters are stored directly inside the node; each node keeps its own parameter list, isolated by namespace (e.g. /control_node/max_speed).
  • Parameters are accessed through ROS2's built-in parameter service interfaces (such as /get_parameters and /set_parameters), and behind the scenes that access relies on ROS2 service communication (Services).
  • Parameters inside one node can be accessed by several external objects at once (the CLI tool, other nodes, the RQT interface and so on), giving a single server (the node) to many clients interaction pattern.

Parameters in a node are generally used to tune algorithm parameters (say the proportional gain of a PID controller), sensor thresholds (say a camera's exposure time) or operating modes (say a debug-mode switch). Of course, you can also batch-modify the parameters of several nodes with a script (say, setting the scan frequency of every lidar at once) to get some special behaviour. And in real deployments, saving parameters to a YAML file lets you quickly restore a node's configuration to the preset values in that file by loading it when the code is deployed.

Command-line access to the parameter service

While a ROS2 program is running, you can use commands in a terminal window to view, modify and so on the Parameters inside the running nodes.

    ros2 param <related command>

Viewing the Parameters a node has

While a ROS2 program is running, you can use list to see all the Parameters under all the nodes of that program.

    ros2 param list

In the output you'll see a structure like the following (taking the output of the turtlesim package while it runs as an example):

    /teleop_turtle:
        qos_overrides./parameter_events.publisher.depth
        qos_overrides./parameter_events.publisher.durability
        qos_overrides./parameter_events.publisher.history
        qos_overrides./parameter_events.publisher.reliability
        scale_angular
        scale_linear
        use_sim_time
    /turtlesim:
        background_b
        background_g
        background_r
        qos_overrides./parameter_events.publisher.depth
        qos_overrides./parameter_events.publisher.durability
        qos_overrides./parameter_events.publisher.history
        qos_overrides./parameter_events.publisher.reliability
        use_sim_time

Where:

  • /teleop_turtle is the node name
  • everything under a node name is a Parameter that node carries
  • among all the Parameters, use_sim_time is one that every node has.

Getting the value of a Parameter in a node

While a ROS2 program is running, you can use get to get the value of a Parameter inside one of the running program's nodes.

    ros2 param get <node_name> <parameter_name>

For example, when you want to find the value of the Parameter height in the node node_a:

    ros2 param get /node_a height

it returns:

Integer value is: 186

So you get to know the value of the data and its type at the same time.

Modifying the value of a Parameter in a node while the program runs

While a ROS2 program is running, you can use set to modify the value of a Parameter inside one of the running program's nodes.

    ros2 param set <node_name> <parameter_name> <value>

For example, when you want to change the value of the Parameter height in the node node_a to 168:

    ros2 param set /node_a height 168

When the change succeeds, it pops up:

Set parameter successful

Printing the values of all Parameters in a node while the program runs

While a ROS2 program is running, you can use dump to print the values of all the Parameters in a node.

    ros2 param dump <node_name>

For example, when you want to print the values of all the Parameters in the node node_a:

    ros2 param dump /node_a

it pops the following declarations up in the terminal window:

/node_a:
    ros__parameters:
        height: 168
        use_sim_time: false

That information is the Parameters data the node currently holds while running; if you modified anything earlier, it shows up here accordingly. Of course, if you'd rather save it to another file to browse, you can save it into a YAML file.

For example, when you want to output the values of all the Parameters in the node node_a to a YAML file, you can run:

    ros2 param dump /node_a > node_a.yaml

After that command runs, ROS2 generates a file called node_a.yaml in the folder the terminal is running in. It contains everything that was printed to the terminal window earlier.

Loading Parameters from a file into a running node

If you want to load a Parameters file you saved earlier into the corresponding node while it runs, you can use load when the node is re-run.

    ros2 param load <node_name> <parameter_file>

For example, when you want to load the Parameters of the node node_a:

    ros2 param load /node_a node_a.yaml

you should get a receipt like this:

    Set parameter height successful
    Set parameter use_sim_time successful

Later on you may run into receipts like this:

    Set parameter background_b successful
    Set parameter background_g successful
    Set parameter background_r successful
    Set parameter qos_overrides./parameter_events.publisher.depth failed: parameter 'qos_overrides./parameter_events.publisher.depth' cannot be set because it is read-only
    Set parameter qos_overrides./parameter_events.publisher.durability failed: parameter 'qos_overrides./parameter_events.publisher.durability' cannot be set because it is read-only
    Set parameter qos_overrides./parameter_events.publisher.history failed: parameter 'qos_overrides./parameter_events.publisher.history' cannot be set because it is read-only
    Set parameter qos_overrides./parameter_events.publisher.reliability failed: parameter 'qos_overrides./parameter_events.publisher.reliability' cannot be set because it is read-only
    Set parameter use_sim_time successful

That's because some of the Parameters in there are read-only: those can only be changed when the node starts, not after it has started — which is why the "qos_overrides" parameters throw warnings.

Loading Parameters from a file into a node at start-up

If you want to load the Parameters in a file when the program starts, you can use the two indicator variables --ros-args and --params-file when running the ros2 program, to tell ROS2 you want to use that file as the values of the Parameters inside the running node.

    ros2 run <package_name> <executable_name> --ros-args --params-file <file_name>

Note

When you update Parameters this way, all the relevant Parameters — read-only ones included — get updated.

A simple implementation of the parameter service

When you use custom nodes, you may well need Parameters. Now, to get a deeper understanding of the parameter service, we'll implement the following case separately in C++ and Python.

The case requirements & case analysis

Requirement: there are two nodes. Write a parameter service where the parameter server (node A) sets some parameters, so that the parameter client (node B) can view and modify those parameters by talking to the parameter server (node A), and the parameter server (node A) can itself do insert-delete-update-query on them.

Analysis: in the requirement above we need to care about three elements:

  1. the parameter server;
  2. the parameter client;
  3. the parameters themselves.

Workflow overview

Before implementing the case you need to understand the parameter APIs in ROS2 first — both the client and the server use parameters. The main steps for implementing the parameter service case are:

  1. Write the parameter server implementation;
  2. Write the parameter client implementation;
  3. Edit the configuration files;
  4. Build;
  5. Run.

The case will be implemented in C++ and in Python separately, and both follow the flow above.

Preparation

Create the workspace in a terminal:

mkdir -p ws01_plumbing/src
cd ws01_plumbing/src
colcon build

Go into the src directory of the workspace:

cd src/

Call the following two commands to create the C++ package, the Python package and the server node each of them needs:

C++:

ros2 pkg create cpp04_parameter --build-type ament_cmake --dependencies rclcpp --node-name demo01_parameter_server

Python:

 ros2 pkg create py04_parameter --build-type ament_python --dependencies rclpy --node-name demo01_parameter_server_py

Preparation is done.

Next you can go ahead and implement the parameter service in C++ and in Python respectively.

Summary

In this section we systematically set out the parameter service. Following the principles behind it and doing it ourselves, we got the creation and use of a node's parameter service working. With this chapter we've now briefly gone through all four communication methods — I hope it's of some use.

Important

This article was translated by Hermes Agent; the original text can be found at here. The translation is for reference only. Translation time: 2026-11-05

Last Updated:
Contributors: JeacsonSnake,Hermes-cRl1,Jeacson_Snake