Parameters documentation incomplete or misleading

I’m trying to track down some clear design rules the parameter system that replaced dynamic_reconfigure. All the parts seem to be fully implemented in all client libraries, but I can’t find any examples of a correct usage.

The most common issue I see in public code (including tutorials) is that add_on_set_parameters_callback should not be used to update anything on the node.
see rclcpp docs and rclpy docs. Instead, there is a separate event (a specialisation of a subscription) that passes the values that were accepted by the on_set_parameters_callback of all nodes.

This design pattern seems to go back at least as far as Dashing, but the APIs have changed a lot since.

There’s no all-in-one demo, and the ros2 design document still says validation callbacks are unimplemented

The API in rclcpp is a little cumbersome (maybe misleading?); it’s easy to set a validation callback on the node, but the parameter event comes back on a ParametersClient that you create separately. I can’t figure out how to make the same calls in rclpy.
This also doesn’t combine well with the executors and callback groups for a multi-threaded node.

Am I missing some info? or should I make a tutorial and send PRs to the relevant docs?

3 Likes

I believe the best use cases of dynamic parameters in ros2 are in the nav2 stack, check it out: GitHub - ros-planning/navigation2: ROS2 Navigation Framework and System