ROS Parameter

A ROS Parameter is stored on a centralized parameter server, a network-accessible key-value store. This server acts as a single source of truth for configuration data, decoupling configuration from node logic. Nodes can retrieve, set, and monitor parameters from this server at runtime.

• Decouples configuration: Node behavior can be altered without restarting the node or recompiling code.
• Hierarchical namespaces: Parameters are organized in a tree structure (e.g., /camera/driver/exposure) for logical grouping and to prevent naming collisions.

Parameters are designed for runtime mutability. A node can change a parameter's value on the server, and other nodes can be notified of this change via parameter events. This enables:

• Online tuning: Adjust control gains, perception thresholds, or operational modes while the system is running.
• Adaptive behavior: Nodes can subscribe to parameter changes and reconfigure internal algorithms (e.g., updating a filter's cutoff frequency) without service interruptions.
• Tool integration: GUI tools like rqt_reconfigure dynamically generate interfaces for live parameter adjustment.

ROS Parameters support a defined set of primitive and compound data types, ensuring data integrity across the distributed system. Supported types include:

• Primitives: Integers, floating-point numbers, strings, booleans.
• Compound: Lists (arrays) and dictionaries (maps) of the primitive types.
• Type enforcement: The parameter server and client libraries enforce type checking, preventing a node from setting a string value for an integer parameter.

Example: A parameter max_velocity would be declared as a double, while joint_names would be a string[] list.

Nodes declare the parameters they use, optionally providing default values and descriptors. This declaration serves as a contract and enables automatic tooling.

• Default Values: Provide a fallback if a parameter is not set on the server, ensuring the node has a valid configuration at startup.
• Descriptors: Include a human-readable description, type constraints (e.g., integer range {from: 0, to: 100, step: 1}), and read-only flags. These are used by dynamic reconfigure tools.
• Initialization: At node startup, declared parameters are automatically fetched from the server, merging with defaults.

Parameters exist within a node's namespace, which is part of its fully qualified name. This scoping allows for parameter overrides at multiple levels, providing flexible configuration strategies.

• Node-level: Parameters are typically accessed relative to the node's namespace (e.g., ~/gain).
• Global-level: Parameters can be set in the global namespace (/global_setting).
• Launch File Overrides: The most powerful feature. Launch files can set, remap, or load parameters from YAML files, allowing environment-specific configurations (e.g., simulation.yaml vs physical_robot.yaml).

ROS Parameters are deeply integrated with the launch system, enabling complex, reproducible system configurations defined in static files.

• YAML Files: The standard format for bulk parameter definition. A YAML file maps parameter namespaces to their values.
• Launch File Loading: A launch file can load a YAML file onto the parameter server for a specific node or a group of nodes.
• Example YAML:

yamlCopy
camera_driver:
  ros__parameters:
    exposure_time: 0.1
    resolution: [1920, 1080]
    auto_white_balance: true

This allows version-controlled, environment-specific configurations to be applied at startup.

A ROS Node is the fundamental executable process within a ROS graph that performs computation. Nodes are the entities that retrieve, set, and monitor parameters. They communicate with the centralized parameter server to access configuration values that dictate their runtime behavior, such as control gains, sensor thresholds, or operational modes.

The ROS Launch System is a tool for configuring and starting multiple ROS nodes from XML or Python launch files. It is the primary mechanism for setting initial parameter values at system startup. Launch files can:

• Load parameter files (YAML)
• Set parameters directly on nodes
• Use arguments to conditionally assign values This ensures a reproducible and declarative system configuration.

A ROS 2 Parameter Event is a notification published by the parameter service whenever a parameter's value is changed on the server. This allows nodes to dynamically reconfigure their behavior at runtime without restarting. Nodes can subscribe to these events to receive callbacks for changes to specific parameters or entire parameter namespaces, enabling live tuning and adaptive control.

ROS 2 Quality of Service (QoS) is a set of configurable policies that govern communication reliability and timing between nodes. While parameters are typically retrieved via services (which have their own QoS), the underlying parameter server interactions are influenced by system-wide QoS settings. For critical parameters, engineers must ensure the QoS profile for the parameter client/server interaction meets latency and reliability requirements.

YAML files are the standard format for declaratively defining parameter names and values outside of code. These files are loaded by launch systems or via command-line tools (ros2 param load). They support:

• Scalar values (integers, floats, strings, booleans)
• Lists and dictionaries
• Nested namespaces using the / separator This separates configuration from logic, adhering to the Twelve-Factor App methodology for configurable services.

In ROS 1, dynamic_reconfigure was a separate but related pattern for providing a runtime graphical interface to adjust a subset of a node's parameters. It allowed for real-time tuning via a GUI. In ROS 2, this functionality is largely superseded by the native parameter event system and tools like rqt_reconfigure, which provide a unified interface for interacting with the core parameter server.