ROS 2 Parameter Event

Parameter events are asynchronously published as standard ROS 2 messages on a dedicated, system-managed topic (e.g., /parameter_events). This decouples the parameter service from the reacting nodes, allowing multiple subscribers to be notified of changes without blocking the setter. The event message contains a list of changed parameters, their new values, and the type of change (e.g., PARAMETER_CHANGED, PARAMETER_DELETED). This pub-sub model is central to ROS 2's reactive architecture.

Nodes can register callback functions that are automatically invoked by the ROS 2 client library (RCL) when a parameter event affects one of the node's own declared parameters. This is the most common and robust pattern for handling changes. The callback receives a std::vector<rclcpp::Parameter> containing the new values, allowing the node to validate and apply the updates, then return a result indicating success or failure. This declarative approach localizes configuration logic within the node.

A ROS 2 Parameter is a configuration variable stored on a node's local parameter server. Unlike ROS 1's global parameter server, parameters in ROS 2 are node-specific, providing better encapsulation and lifecycle management. Parameters are defined with a name, type (e.g., integer, string, double array), and a value. They are the primary unit of configuration that a Parameter Event monitors for changes.

• Dynamic Reconfiguration: Nodes can declare parameters as dynamic, allowing their values to be changed at runtime without restarting the node.
• Descriptors: Parameters can include a descriptor with a description, read-only constraints, and allowable ranges.
• Access: Other nodes can get, set, and list a node's parameters via service calls.

A ROS 2 Node is a fundamental executable process that performs computation. Every node that declares parameters acts as its own parameter server. The Parameter Event system is intrinsically tied to nodes, as events are generated per-node when its local parameters change.

• Modularity: A robotic system is composed of many nodes (e.g., a perception node, a planning node, a control node).
• Lifecycle: Nodes can be Lifecycle Nodes, following a strict state machine (Unconfigured, Inactive, Active). Parameters are typically set during the configuring transition.
• Communication: Nodes communicate via topics, services, actions, and the parameter server.

A ROS 2 Service is a synchronous, request-response communication mechanism. The parameter system uses several built-in services for remote interaction. The get_parameters, set_parameters, and list_parameters services allow external nodes to query and modify a node's parameters, which in turn may trigger a Parameter Event.

• Service Clients: Tools like ros2 param use these services under the hood.
• Atomic Operations: The set_parameters service can set multiple parameters atomically; a single Parameter Event will be published describing all changes.
• Contrast with Topics: Services are blocking and one-to-one, whereas Parameter Events are published asynchronously on a topic for any interested subscriber.

A ROS 2 Topic is a named channel for asynchronous, many-to-many message exchange using a publish-subscribe model. The Parameter Event is itself published on a topic. Each node with parameters automatically publishes to the /parameter_events topic (by default), and can subscribe to it to monitor other nodes' parameter changes.

• Decoupled Communication: Subscribers to /parameter_events are notified of changes without directly calling a service.
• Quality of Service (QoS): The Parameter Event topic uses VOLATILE durability and RELIABLE reliability by default, ensuring new subscribers only get future events but receive them reliably.
• System-wide View: By subscribing to the global /parameter_events topic, a monitoring or diagnostics node can track configuration changes across the entire system.

The ROS 2 Launch System is a Python-based framework for orchestrating the startup of multiple nodes, setting parameters, and remapping topics. It is the primary tool for initializing the parameter state that Parameter Events later monitor. Launch files can set node parameters at startup, defining the initial configuration from which runtime changes diverge.

• Parameter Declaration: Launch files can push parameter values (from YAML files or directly) to nodes as they are spawned.
• Lifecycle Management: Launch can sequence node startup, ensuring parameter servers are active before dependent nodes try to access them.
• Overrides: Parameters set via launch can later be overridden at runtime using ros2 param set, triggering a Parameter Event.