Add support for parameters

[nnmm]

This likely depends, in part, on the service/client functionality to be added soon.

The relevant functions are in https://github.com/ros2/rcl/blob/master/rcl/include/rcl/arguments.h

[nnmm]

@esteve @jhdcs What do you think, should we support the parameter semantics rclcpp had before Dashing, i.e. allow_undeclared_parameters and automatically_declare_initial_parameters? https://github.com/ros2/ros2_documentation/pull/187/files

These flags seem to be there mostly for backwards compatibility (though the the blackboard parameter server is cited as an example use-case). I'd find it nice if we could avoid the complexity incurred by these options.

[nnmm]

I noticed that implementing parameter services will cause a dependency on rcl_interfaces. That means we'd need to release that package onto crates.io as well.

[ashquarky]

Is there any movement on this? I'm making a driver and would like to have ~cmd_vel_timeout. I saw _parameter_map is in Node now but not used or exported?

[nnmm]

Hi @ashquarky – development from my side happens in bursts and I must say I have not made progress with parameters since last year. But I've now picked it up again (partly thanks to your comment :P), so there's a good chance you'll see progress on this in the coming week or so. Your use case seems to be a simple parameter set through the command line or yaml, right? Not through parameter services.

[texhnolyze]

Hey @nnmm have you started with this yet? I'd be happy to try implement it (but might need some pointers), as I've already had a look at adding a get_parameter_value method for local parameters, which I use a lot by combination of yaml config and launch files.

Concerning allow_undeclared_parameters and automatically_declare_parameters_from_overrides I feel, that it is reasonable to require all parameters to be predefined, however when utilizing a yaml config file I think it is tedious to require predeclaration of all those (especially if there are quite a few).
Because of that I would support allowing the automatically_declare_parameters_from_overrides.

To clarify what would this issue entail:

• allow accessing local Node parameters, which already exist
• add flag of start_parameter_services to node creation, starting already existing ParameterService
• add parameter events publisher for /parameter_events sending ParameterEvents when changing a Parameter
• add flag of automatically_declare_parameters_from_overrides and prevent setting undeclared params from overrides, when set to false
  Am I missing something else?

[nnmm]

@texhnolyze Yes, I've started, although at a slower pace than I had planned. Parameters are just complex, the difficulty lies not so much in translating from C++, but in deciding which subset of parameters functionality is suitable for a first version in Rust, and how to do adapt things to be maybe less ugly than in C++. I plan to focus on that a bit more in the time ahead.

[ashquarky]

Sorry I'm late to the party, I'm just getting back into my project now. I'd be happy with just commandline stuff, yeah! Just to tweak some of the constants in the driver.

[nnmm]

I clarified my thinking on parameters today a little bit (by reading up on & drawing a state diagram of rclcpp's parameters). I think we can probably give direct (read-only) access to the parameter overrides (the command line stuff) for now. I think it is conceptually simple to do so, and rclcpp seems to be leaning in that direction too with ros2/rclcpp#2090, though they only expose the names, not the values.

[mxgrey]

We have support for node parameters and even parameter services are implemented, so I think we can consider closing this issue, unless there's some other aspect of parameters that's still missing.

[maspe36]

Agreed, if there are missing features in our parameters implementation lets open a new issue that is specific.