ROS 2 Parameters Project Goals

[tylerjw]

There have been many different approaches taken to standardizing, making more declarative, and reducing the amount of boilerplate code that needs to be written to use ros2 parameters.

Before we can approach the trade-offs of various implementation ideas for how to accomplish this we should first lay out our goals for this project.

As I understand it these are the basic goals of the Parameters project:

• Standardize use of parameters in MoveIt / ros2_control / etc. to reduce mistakes and provide a consistent parameter interface for users
• Thread-safe dynamic parameter setting where appropriate
• Synchronized parameters (nodes can subscribe to and get their parameters from other node's parameters)
• Declare the type of parameter, description, default value, and validity checks in one place
• Support custom validity checks for parameters and groups of parameters. (ie quaternions)
• Compile linters for config packages
• Namespaced nodes and groups of parameters
• Reduce boilerplate that is copy and pasted from one project to another
• Recreating structured yaml files from nodes/configs including documentation from description

Please respond with any other goals you think this project should have or if you think any of the above goals should be revised or removed from the list.

[henningkayser]

I think this is already pretty spot on. The only thing missing here is "creating structured yaml files from nodes/configs including documentation from description" similar to or using an extension of ros2 param dump. With that, we wouldn't have to maintain template files for MSA.

[tylerjw]

Over the past week, I have been working with @pac48 to iterate on the approach of using code generation to generate parameter structs and code for declaring, getting, and handling dynamic updates of them.

https://github.com/pickNikRobotics/generate_parameter_library

Done

• Standardize use of parameters in MoveIt / ros2_control / etc. to reduce mistakes and provide a consistent parameter interface for users
  • As this approach uses code generation this is a DRY approach that would standardize the approach and interface of parameters
• Thread-safe dynamic parameter setting where appropriate
  • Current implementation does this by having a function you can call to detect when there is a new version of the parameters. This polling approach is inherently thread-safe.
• Declare the type of parameter, description, default value, and validity checks in one place
  • Declarative yaml file for all these things, Example: https://github.com/ros-controls/ros2_controllers/blob/c70563a4f27a6fc2ec920cf6cd1e99eba3dc74e4/joint_trajectory_controller/src/parameters.yaml
• Support custom validity checks for parameters and groups of parameters. (ie quaternions)
  • generate_parameter_library comes with some common validation methods
  • generate_parameter_library has an interface to write custom parameter validation functions. Example: https://github.com/ros-controls/ros2_controllers/blob/c70563a4f27a6fc2ec920cf6cd1e99eba3dc74e4/joint_trajectory_controller/include/joint_trajectory_controller/validate_parameters.hpp
• Namespaced nodes and groups of parameters
  • generated Params struct is placed in namespace at the top level of yaml. Example: https://github.com/PickNikRobotics/generate_parameter_library/blob/f1c3586f202b5093d7ec9ddddd8c4bbacfb7d7b1/example/src/parameters.yaml#L1
  • sub-namespaces can be created with just using keys that contain parameter entries in yaml. Example: https://github.com/PickNikRobotics/generate_parameter_library/blob/f1c3586f202b5093d7ec9ddddd8c4bbacfb7d7b1/example/src/parameters.yaml#L28
• Reduce boilerplate that is copy and pasted from one project to another
  • Generated code needed for declaring, getting, validating, and handling dynamic parameters

Planned Work

• Compile linters for config packages
  • Generate linter to check config packages PickNikRobotics/generate_parameter_library#7
• Recreating structured yaml files from nodes/configs including documentation from description
  • Generate yaml config files from config PickNikRobotics/generate_parameter_library#8
• Callback registraiton interface for dynamic parameters
  • Register async callback for updates PickNikRobotics/generate_parameter_library#6

Not solved by generate_parameter_server

• Synchronized parameters (nodes can subscribe to and get their parameters from other node's parameters)
  • Just as in ros1, global parameters and dynamic parameters were handled with a separate API a similar approach could be used for ros2 by using a global parameter server
  • https://github.com/fujitatomoya/ros2_persist_parameter_server

[tylerjw]

To prove this tooling (and to find our bad assumptions) we are going through the process of creating PRs that attempt to replace existing parameter usage with this tool.

• Generate Parameter Library for Joint Trajectory Controller ros-controls/ros2_controllers#384