You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create a subnode with a subnamespace, use it declare and set a parameter, and then try to get the parameter using the different overloads of the get_parameter() method.
Example:
All the overrides of the method get_parameter() and get_parameter_or() should behave consistently, and not sometimes try to prepend the subnode namespace and sometimes not.
and both variants of get_parameter_or() call the extend_name_with_sub_namespace() function that modifies the name of the parameter. The rest of the methods (including set_parameter() and declare_parameter()) do not. This behavior is not documented, it is inconsistent, and it cost me a lot of debugging time.
Additional information
I think the root of the problem is that the implementation of subnodes is only half finished, leading to bugs and unexpected behavior like this. It's as if somebody simply committed and pushed his WIP code when in the middle of implementing subnodes. Subnode parameters in ROS2 are almost never namespaced, which makes it hard to solve conflicting parameter names.
The short-term solution is to remove the call to extend_name_with_sub_namespace() (which btw. seems to be broken or at the least not behaving as in ROS1 w.r.t. the /, . and ~ special symbols).
I think the correct solution however would be to finish implementing subnodes also for parameters... and finish writing the documentation...
The text was updated successfully, but these errors were encountered:
this is obviously bug and inconsistent behavior that confuses user application.
IMO, it should never call extend_name_with_sub_namespace on subordinate node either, because all the parameters belong the node instance, even with subordinate node. on the other hand, all the endponts such as publisher, subscription, service server/client, action server/client should extended with extend_name_with_sub_namespace on the creation. (as far as i check, create_generic_client is missing to call extend_name_with_sub_namespace.)
fujitatomoya
added a commit
to fujitatomoya/ros2_test_prover
that referenced
this issue
Apr 21, 2025
Operating System:
Ubuntu 24.04
ROS version or commit hash:
jazzy (from apt)
RMW implementation (if applicable):
No response
RMW Configuration (if applicable):
No response
Client library (if applicable):
rclcpp
'ros2 doctor --report' output
ros2 doc --report
Steps to reproduce issue
Create a subnode with a subnamespace, use it declare and set a parameter, and then try to get the parameter using the different overloads of the
get_parameter()
method.Example:
Expected output:
Actual output:
:'(
Expected behavior
All the overrides of the method
get_parameter()
andget_parameter_or()
should behave consistently, and not sometimes try to prepend the subnode namespace and sometimes not.Actual behavior
The override
and both variants of
get_parameter_or()
call theextend_name_with_sub_namespace()
function that modifies the name of the parameter. The rest of the methods (includingset_parameter()
anddeclare_parameter()
) do not. This behavior is not documented, it is inconsistent, and it cost me a lot of debugging time.Additional information
I think the root of the problem is that the implementation of subnodes is only half finished, leading to bugs and unexpected behavior like this. It's as if somebody simply committed and pushed his WIP code when in the middle of implementing subnodes. Subnode parameters in ROS2 are almost never namespaced, which makes it hard to solve conflicting parameter names.
The short-term solution is to remove the call to
extend_name_with_sub_namespace()
(which btw. seems to be broken or at the least not behaving as in ROS1 w.r.t. the/
,.
and~
special symbols).I think the correct solution however would be to finish implementing subnodes also for parameters... and finish writing the documentation...
The text was updated successfully, but these errors were encountered: