Glossary

Fictionlab > Glossary > ROS 2 parameter

ROS 2 parameter

ROS 2 parameter – definition

A ROS 2 parameter is a named, typed value owned by a specific ROS 2 node. Parameters configure node behaviour without changing source code. A node can use parameters for sensor frame names, navigation limits, controller gains, map paths, update rates, or algorithm thresholds.

ROS 2 parameters are node-local. ROS 2 does not use the ROS 1 global Parameter Server architecture. A node normally exposes its own parameter interface through ROS services and publishes parameter changes through the /parameter_events topic. This design reduces reliance on a central ROS master and makes parameter ownership explicit.

On a mobile UGV, parameters are commonly used to configure localisation, sensor drivers, velocity control, obstacle detection, and navigation nodes. On Leo Rover, which can be integrated with ROS 2 and uses differential drive, parameters can define wheel geometry, velocity limits, LiDAR topic names, coordinate frames, and Nav2 planner settings. On Raph Rover, the same mechanism can configure payload integrations such as multi-camera systems, RTK GNSS receivers, or higher-capacity compute units.

How ROS 2 parameters work

A parameter belongs to one node and is addressed by the node name and parameter name. For example, /localization/use_sim_time belongs to the /localization node. A ROS 2 node normally declares parameters before reading them. Declaring a parameter can define its type, default value, and descriptor metadata such as a description or allowed ranges.

ROS 2 supports the following parameter value types, defined in the rcl_interfaces/msg/ParameterValue message:

  • bool
  • int64
  • float64
  • string
  • byte[]
  • bool[]
  • int64[]
  • float64[]
  • string[]

Parameters are accessed through ROS 2 service interfaces, including GetParameters, SetParameters, SetParametersAtomically, ListParameters, and DescribeParameters. Nodes can validate proposed changes before accepting them. A navigation node, for example, can reject a negative robot footprint radius or an unsupported sensor frame name.

Parameter declaration and type safety

In standard ROS 2 node configuration, undeclared parameters are not accepted by default. A node can explicitly allow undeclared parameters or automatically declare parameters supplied through overrides. This differs from many ROS 1 workflows, where parameters could be added to the central parameter server without node-side declaration.

ROS 2 parameters are statically typed by default. If a parameter is declared as a floating-point value, a later attempt to assign a string will fail. A node may enable dynamic typing through its parameter descriptor, but this should be reserved for cases where the accepted data type genuinely needs to change.

Parameter descriptors can define metadata that nodes and tools can use for validation. Useful descriptor fields include:

  • description – human-readable explanation of the parameter.
  • read_only – prevents runtime modification after declaration.
  • integer_range – describes an allowed range for an integer value.
  • floating_point_range – describes an allowed range for a floating-point value.
  • dynamic_typing – permits changing the parameter type.

Range metadata does not replace node-side validation. Validation is important in UGV deployments. A change to a maximum velocity, inflation radius, or IMU covariance parameter can directly affect navigation behaviour. Runtime changes should therefore be logged, tested, and restricted to values that the node can safely apply.

ROS 2 parameter files

Parameters are usually stored in YAML files and loaded when a node starts. The key ros__parameters is required by the ROS 2 parameter-file format. The following example configures a hypothetical localisation node for a Leo Rover sensor stack.

/leo_rover/localization:
  ros__parameters:
    use_sim_time: false
    base_frame: base_link
    odom_frame: odom
    lidar_frame: laser
    scan_timeout_s: 0.25
    publish_tf: true

The value 0.25 in this example is application-specific. It is not a hardware specification. Its acceptable range depends on LiDAR scan frequency, transport latency, and the timeout handling implemented by the localisation node.

A launch file can load the YAML file when starting a node. This keeps robot configuration separate from executable code and allows different files for indoor mapping, outdoor inspection, simulation, or sensor-calibration workflows.

ros2 run my_robot_localization localization_node \
  --ros-args \
  --params-file config/leo_rover_localization.yaml

Inspecting and changing parameters from the ROS 2 CLI

The ros2 param command-line interface is used to inspect parameters on a running ROS graph. A parameter can be read or changed only if the target node exposes it and accepts the requested value.

ros2 param list /leo_rover/localization

ros2 param get /leo_rover/localization lidar_frame

ros2 param set /leo_rover/localization scan_timeout_s 0.30

ros2 param dump /leo_rover/localization

A successful CLI command does not guarantee that a configuration change is safe during motion. For example, changing a controller gain or obstacle-layer threshold while Leo Rover is moving can alter command output immediately if the relevant node supports dynamic updates. Test such changes with the robot lifted, in simulation, or inside a controlled operating area.

Parameters in Leo Rover and Raph Rover integrations

For differential-drive UGVs, parameter sets should reflect the actual mechanical and sensor configuration. Leo Rover requires a separately integrated autonomy stack. ROS 2 parameters are one of the mechanisms used to connect its base driver, odometry source, LiDAR or depth camera driver, localisation node, and Nav2 nodes into a reproducible configuration.

Typical parameter groups for a Leo Rover deployment include:

  • Base parameters – wheel separation, wheel radius, odometry topic, command velocity topic, and velocity limits.
  • Sensor parameters – serial device path, baud rate, frame ID, scan topic, IMU orientation, and camera optical frame.
  • Navigation parameters – robot footprint, costmap layers, obstacle ranges, planner configuration, and recovery behaviour.
  • Localisation parameters – map frame, odometry frame, base frame, sensor covariance, transform timeout, and initial pose settings.

Raph Rover can use the same ROS 2 parameter model when integrating sensor payloads or more complex perception stacks. Its hardware configuration does not change ROS 2 parameter semantics. Each node still owns, declares, validates, and exposes its own parameters.

Parameter events and runtime observability

When parameter-event publishing is enabled, ROS 2 nodes publish parameter creation, deletion, and modification events on the /parameter_events topic using the rcl_interfaces/msg/ParameterEvent message. Monitoring this topic helps operators record configuration changes during field tests, mapping runs, and navigation debugging.

ros2 topic echo /parameter_events

Parameter events are useful for traceability, but they are not a replacement for version-controlled YAML configuration. A reproducible UGV deployment should store parameter files with the robot software repository, record the ROS 2 distribution, and document sensor firmware and calibration data separately.

References and official documentation

The ROS 2 parameter model is described in ROS 2 design documentation and implemented through the ROS client libraries and rcl_interfaces package. Distribution support policies are maintained through ROS Enhancement Proposals.

See also