ROS 2 Parameter Management: Safely Tuning Robot Behavior at Runtime

The Problem: Hard-Coded Robot Behavior

When a robot's maximum speed is hard-coded as a constant, you can't adjust it without recompiling and redeploying the entire node. This becomes critical when you need to adapt to different environments—a delivery robot might need to slow down in crowded hallways but speed up in empty corridors.

Thesis: ROS 2 Parameters Enable Dynamic, Type-Safe Configuration

ROS 2 provides a built-in parameter system that lets you modify node behavior at runtime without restarting. Parameters are declared with type-safe defaults and can be changed via command-line tools or programmatically, with optional callbacks to react to changes.

Declaring and Using Parameters

Every ROS 2 node must declare its parameters before use. The declaration includes the parameter name and a default value with type information:

rclcpp::Node::declare_parameter("max_speed", 1.0);  // default 1.0 m/s
rclcpp::Node::declare_parameter("safety_margin", 0.5);  // default 0.5 meters
rclcpp::Node::declare_parameter("enabled", true);  // default boolean

Retrieving values uses the get_parameter() method:

double speed = this->get_parameter("max_speed").as_double();
double margin = this->get_parameter("safety_margin").as_double();
bool enabled = this->get_parameter("enabled").as_bool();

Modifying Parameters at Runtime

You can change parameters while the node is running using the ros2 param set command:

ros2 param set /controller_node max_speed 0.8
ros2 param set /controller_node enabled false

Alternatively, use the C++ API within your node:

rclcpp::Parameter param("max_speed", 0.8);
this->set_parameter(param);

Reacting to Parameter Changes with Callbacks

For immediate reaction to parameter changes, implement an on_parameter_event callback:

using ParamEventCallback = std::function<void(const rcl_interfaces::msg::ParameterEvent::SharedPtr)>;

Working Example: Adjustable Navigation Controller

Consider a simple controller node that adjusts motor commands based on distance to obstacles. First, declare parameters in your node header:

#include <rclcpp/rclcpp.hpp>

class NavigationController : public rclcpp::Node {
public:
  NavigationController() : Node("navigation_controller") {
    this->declare_parameter("max_speed", 1.0);
    this->declare_parameter("min_distance", 0.5);
    this->set_on_parameter_event_callback(
      std::bind(&NavigationController::parameter_event_callback, this, std::placeholders::_1));
  }

private:
  void parameter_event_callback(const rcl_interfaces::msg::ParameterEvent::SharedPtr event) {
    for (const auto& param : event->changed_parameters) {
      if (param.name == "max_speed") {
        max_speed_ = param.value.as_double();
      } else if (param.name == "min_distance") {
        min_distance_ = param.value.as_double();
      }
    }
  }

  double max_speed_{1.0};
  double min_distance_{0.5};
};
_value

Run the node, then from another terminal:

ros2 run my_package navigation_controller
ros2 param set /navigation_controller max_speed 0.6
ros2 param set /navigation_controller min_distance 0.3

Trade-offs and Limitations

Type Safety: Parameter types must match exactly between declaration and retrieval. Calling .as_int() on a double parameter throws an exception at runtime. Always verify types before conversion.

No Immediate Propagation: Parameter changes don't automatically propagate to all components. If a subscriber is processing messages, it may continue using old values until the next update cycle.

Validation Required: Setting negative values for distances or speeds can cause unsafe robot behavior. Always validate parameter ranges in your callback logic.

Verification Checklist

1. Declaration: Run ros2 param list /node_name to verify parameters are declared
2. Modification: Use ros2 param get /node_name param_name before and after changes to confirm updates
3. Callback: Add logging in your parameter event callback and verify it triggers when parameters change

Actionable Next Steps

Start by declaring all configurable values as parameters in your existing nodes. Add validation logic in parameter callbacks to reject unsafe values. Test parameter changes during simulation before deploying to physical robots. For team environments, consider loading parameters from YAML files to maintain consistent configurations across different robot instances.