frame_id relative namespacing issue

[ethanholter]

Bug Description
When the diff_drive_controller is namespaced (for example /control/diff_drive_controller) The odom_frame_id and base_frame_id always use relative namespaces which can lead to TF frames with names such as /control//odom instead of the expected /odom

To Reproduce
Steps to reproduce the behavior:

# controller_config.yaml
/uirover/control/controller_manager:
  ros__parameters:
    update_rate: 100  # Hz

    ...

    diff_drive_controller:
      type: diff_drive_controller/DiffDriveController

    ...

/uirover/control/diff_drive_controller:
  ros__parameters:
   
    ...

    odom_frame_id: /odom
    base_frame_id: /base_link

# launch file
    ld.add_action(
        Node(
            package="controller_manager",
            executable="spawner",
            namespace="/uirover/control",
            arguments=[
                "diff_drive_controller",
                "-c",
                "controller_manager",
                "--switch-timeout",
                "15",
            ],
            # note: adding remappings had no effect
            remappings=[
                ("odom", "/odom"),
                ("base_link", "/base_link")
            ]
        )
    )

Expected behavior
published transforms should use a frame_id of /odom and /base_link

Screenshots

Environment:

• OS: Ubuntu 24.04.3 LTS
• Version Jazzy
• Binary installation

Additional context
I understand that the obvious fix is to simply not use namespacing for ros2 control nodes. In our use case we have 2 separate systems connected via rmw_zenoh and would prefer to keep the namespacing for more explicit seperation of the two

[ethanholter]

I was able to solve this issue doing the following

tf_frame_prefix: /
odom_frame_id: odom
base_frame_id: base_link

While this is technically (probably) intended behavior this is pretty inconsistent with how the rest of the ROS2 ecosystem typically behaves. I would suggest using my suggested behavior despite the existence of tf_frame_prefix

[christophfroehlich]

launch file

ld.add_action(
    Node(
        package="controller_manager",
        executable="spawner",
        namespace="/uirover/control",
        arguments=[
            "diff_drive_controller",
            "-c",
            "controller_manager",
            "--switch-timeout",
            "15",
        ],
        # note: adding remappings had no effect
        remappings=[
            ("odom", "/odom"),
            ("base_link", "/base_link")
        ]
    )
)

Remapping is for topics only, right? This can't effect the prefix.

Because this is not covered very well by unit tests, we are working in moving the tf_prefix logic to a common place and add specific tests. Do the tests in ros-controls/ros2_control#2803 meet your expectations?

[ethanholter]

My original intent was if the user explicitly prepends a / in a frame_id parameter it should be implied to use absolute name spacing even if tf_frame_prefix is unset.

for example

/ns/diff_drive_controller:
  ros__parameters:
    odom_frame_id: /odom

I would expect the frame_id of the resulting transform to be odom instead of ns/odom

My reasoning is that across other packages this has generally been a behavior which can be assumed. I was stuck on this issue for a while because I have yet to come across another package which has a separate namespace prefix parameter.

Generally speaking it has been safe to assume that any tf or node namespacing behaves similar to unix filepaths where a leading / means absolute namespace and no leading / or the usage of ~/ implies namespacing relative to the parent node.

I am not an expert in ROS so this might just be a skill issue, I just wanted to point out an area of friction that might be worth adjusting.

(also I think you're right, remapping is only for topics. I just included it as a shot in the dark. The remapping did literally nothing)

[christophfroehlich]

This is exactly what we will change with ros-controls/ros2_control#2803, you have to explicitly give ~/ to insert the node namespace, otherwise it just append nothing. Will this fit?

[ethanholter]

Oh I see. I must've misunderstood that conversation then. Seems good to me!