inconsistent declare/undeclare parameter behaviour
@fujitatomoya is already working on this.
Since Feb 20, 2025.
- Dominant language
- C++
- Stars
- 805
- Forks
- 564
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 27
Description
current behaviour
A ROS node can:
- explicitly declare a parameter via
declare_parameterand explicitly undeclare it viaundeclare_parameter - implicitly declare a parameter by setting the option
allow_undeclared_parameters(true)and then just setting the parameter viaset_parameterand implicitly undeclare a dynamic parameter by changing its type toPARAMETER_NOT_SET
It is also possible to mix these modes and implicitly undeclare an explicitly declared parameter by not allowing undeclared parameters, using dynamic parameter types and then setting its type to PARAMETER_NOT_SET. In such a situation, it will not be possible to "reactivate" the parameter again, without the node explicitly declaring the parameter again.
This mix of explicit creating and implicit deletion of parameters is inconsistent.
expected behaviour
If an explicitly declared dynamic parameters type is changed to PARAMETER_NOT_SET, it should result into the same behaviour as declaring the parameter with PARAMETER_NOT_SET in the first place. That means, after changing the type to PARAMETER_NOT_SET, has_parameter must return true and ros2 param get should return Parameter not set. and ros2 param dump should show the value as null.
Additionally, it would be useful if this would still work with static types, such that a parameter has a static type and its value is either be set or unset (null), comparable to a NULL pointer in C.
The current implicitly undeclare behaviour should only apply when allow_undeclared_parameters is true and parameters are declared implicitly via set_parameter.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.