Inconsistences when using real sensors and components.yaml

Software
1

There are inconsistencies in TF frame names when using real sensors with Husarion official docker containers and components.yaml.

When starting “rplidar.launch.yaml” you can set a parameter “name” which puts the lidar measurement in frame “_link” or it defaults to just “laser” if name is not specified. However if you define a rplidar in components.yaml you can specify “device_namespace“ which generates frame: “<robot_namespace>/<device_namespace>_laser“ and the default is “<robot_namespace>/laser“

So let’s say we have a Lynx robot, the default option is:

  • rplidar scan topic which uses frame “laser“
  • tf_static topic with frame “lynx/laser

If we change the rplidar node to have a prefix i.e. “name:=lynx/“ then the following is generated:

  • rplidar scan topic with frame “lynx/laser_link“
  • tf_static topic with measurement frame “lynx/laser”

If we try to change components.yaml by adding “device_namespace” parameter we would only have it add a prefix to laser e.g. if device_namespace:=lidar then we get frame “lynx/lidar_laser”.

Therefore we could never achieve the same frame referenced in the lidar measurement (“scan” topic) and in “tf_static” topic generated by components.

Another issue is with Realsense, the latest Husarion docker image doesn’t support “tf_prefix“ since it is in the version 4.56.4 while the tf_prefix for ros2 was officially added in version 4.57.2:

Releases · realsenseai/realsense-ros

Support TF Prefixing by pondersome · Pull Request #3332 · realsenseai/realsense-ros

When we create a Realsense camera in components.yaml it generates camera all frames in “tf_static“ with e.g. “lynx” prefixes which cannot be achieved with current camera node in latest Husarion docker container for Realsense cameras.

The Husarion components system apparently has a property “use_tf_prefix“ could possibly be set to False so it doesn’t put <robot_namespace> prefix to “tf_static“ frames but unfortunately that property cannot be set in components.yaml.

Kind regards

2

Hi @ddff1,

Thank you for pointing this out.

RPlidar

I rebuilt the Docker image and added a dedicated frame_id argument, so now you can freely configure the exact TF frame name and keep it consistent between the scan topic and tf_static.

You can test it with:

docker pull husarion/rplidar:humble-1.0.1-20260522

Example integration and demonstration are available in:

Realsense

I’ll try to address this in the future. For now, you can remove realsens from components.yaml and add the transformation using static_transform_publisher

3

Thank you.

Also, if I can make another suggestion.

Since the robot’s computer runs a dockized husarion-ugv, how can we add new arbitrary component to its description without rebuilding container image? Components.yaml only supports adding components that you have previously added to your repository: husarion/husarion_components_description: URDF models for sensors and hardware components used with Husarion mobile robots.

Is that right?

If that is the case, I have a suggestion that you add additional configuration file beside components.yaml for example user_components.urdf.xacro that would at the start be “empty” (similar logic to components.yaml). You than reference that file in your robot description when you dockerize and users can than attach any component on the real robot and have it easily integrate with its prebuilt description of considered components without the need to rebuild the ugv container image.

Is this possible or is there a more simple solution for robot expansion and component integration?

4

Realsense
I’ve been looking through the realsense repo and I see that we’re not adding any layer above the default ros driver. And since the fix is ​​on the official branch, rebuilding should be sufficient.

Custom components
Regarding the feature, it’s an interesting idea; we’ll consider adding this option. It’s certainly not trivial, as mesh issues also need to be addressed.