ros2 / ros2/rclcpp

inconsistent declare/undeclare parameter behaviour

Open
#2,736 4 comments 0 reactions 1 assignee View on GitHub

@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:

  1. explicitly declare a parameter via declare_parameter and explicitly undeclare it viaundeclare_parameter
  2. implicitly declare a parameter by setting the option allow_undeclared_parameters(true) and then just setting the parameter via set_parameter and implicitly undeclare a dynamic parameter by changing its type to PARAMETER_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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.