ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Dynamic Reconfigure porting

Hello everyone,

Has anybody picked up “Dynamic Reconfigure” migration work on ROS2?
If not , I would be interested in doing so.
Please let me know if anybody has any concern or any update for the same.

Thanks,
Poonam Deoghare

Hi Poonam,

I’ve been working with the team on the Navigation2 stack for ROS2 (https://github.com/ros-planning/navigation2). Dynamic Reconfigure is very prevalent throughout this code, so I opened an issue about what we would need to accomplish to replace it in our stack (https://github.com/ros-planning/navigation2/issues/177). I’ve been working in my own fork on an intermediate replacement for Dynamic Reconfigure functionality using the supported ROS2 parameter events and callbacks. I’ll be submitting a PR to our Nav2 repo soon. As I see this as a more temporary replacement, I welcome any contribution and feedback you have to migrating the essential Dynamic Reconfigure features to ROS2.

Thanks,
Brian Wilcox

Dynamic reconfigure does intentionally not existing in ROS 2 and its features have been rolled into the ROS 2 parameters. So dynamic reconfigure should not be ported to ROS 2. If any functionality is missing it should be added to the existing ROS 2 parameters.

2 Likes

@dirk-thomas - We’ve been having some discussion on this while working on Navigation2. Is there a proposed way for:

  1. Developers to easily validate the values of their parameters (type, value, range, etc.)
  2. Users to ‘tune’ their robot parameters dynamically? The GUI tool before was a convenient / user friendly way of doing that.

The existing parameters implementation enables each note to “review” incoming parameter change request and either accept or reject them base on an arbitrary policy.

As a difference to dynamic reconfigure parameters don’t have an introspectable range.

There is no UI at the moment but in the future an rqt plugin would be one way to provide that functionality.

Right now… We always intended to have that functionality at some point, see:

See here for the method and here for a sample (I think).

Thanks everyone for your comments.
I am looking into pcl_ros(under perception_pcl) porting and there I came across dynamic reconfigure dependency.
But now it is clear that dynamic reconfigure should not be ported on ROS2.
I will look into how Dynamic Reconfigure functionality can be replaced in pcl_ros using ROS2 parameters.
Please let me know if anybody has any information on this.

Thanks,
Poonam

Two questions on this:

  1. What is the default behavior if no callback is registered – all parameters update with any value?

  2. Is there a design doc for parameters somewhere? And, in particular, was their any design doc or other documentation for thoughts on introspectable range?

Thanks,

-Fergs

Yes.

http://design.ros2.org/articles/ros_parameters.html

No, that idea is only captured in the comment William cited above.

@wjwood - a couple questions. When you say introspectable range, do you mean for example for an integer you could specify range 0-100 and that would be enforced by the node itself? And if so, what would it take to implement this?

I can’t help at all with implementation aspects - but yes, introspectable range means you can tell the client (that is changing the parameter) what the acceptable range is. That might be an integer range, or it might be an enumeration of settings (for instance, camera modes are often done this way). The main use of this introspectable range is for a visual client (in ROS1 this was the rqt_reconfigure GUI), can show set the values of slider bars or drop down menus.

I think we’d want the introspect-able range for parameter validation to be an automatic operation as opposed to redundant custom validation checks written in code. My goal was to achieve this in the interim through a parameter validator class with optional upper/lower bound arguments passed for parameters. I do think having this as optional meta-info on the parameters as @wjwwood mentioned as TODO is a better option going forward with perhaps a validation function written in the ROS2 parameters code to protect from parameter changes that violate.

1 Like

I’m not sure it solves any of our issues directly, but on the web side of things we have been using schematics and Transmute to do input validation via Function Annotations.

Hey there,

Any update on this topic ? Was any design document, centralized discussion or such started ?

Just to mention that introducing some parameter validation scheme will also call for a mean to define the validation rules from the user side, think .cfg files in ROS 1.

While at it, I’d like to mention a ROS 1 package which has a few features that could be interesting to consider here. The package is rosparam_handler and is meant as an easy/user-friendly manner to handle parameters. The features to be considered imho are,

  • a .params file similar to .cfg for the user to declare/define parameters and rules
  • an auto-generated struct that holds the parameters with helper functions (e.g. to/fromParamServer, to/fromConfig)
  • a tool to generate a YAML file from the .params file
  • The possibility to compose .params files through inheritance

Notice that the last mentioned feature never quite got merged to the main branch tho.

1 Like