Ouster Frames TF error

[tmalechka]

System Configuration:

OS: Ubuntu 24.04
ROS2 Distro: Jazzy
Package version: last
Real Robot Platform: Husky A200
Sensor: Ouster OS-1-32U

In our lab, we are currently working on implementing a mapping pipeline using our physical system (real robot A200). We are able to initiate the mapping process and successfully generate and save maps.

However, during the mapping (all other too) operation, we consistently encounter a TF errors related to our LiDAR sensor (lidar3d_0). This same error also appears when we simply launch RViz using the following command:

ros2 launch clearpath_viz view_robot.launch.py namespace:=a200_0000

❗ Error message:

TF_SELF_TRANSFORM: Ignoring transform from authority "Authority undetectable"
with frame_id and child_frame_id "lidar3d_0_sensor_link" because they are the same

Relevant section of robot.yaml:

sensors:
lidar3d:
- model: ouster_os1
urdf_enabled: true
launch_enabled: true
parent: default_mount
xyz: [0.2, 0.0, 0.4]
rpy: [0.0, 0.0, 0.0]
ros_parameters:
ouster_driver:
sensor_hostname: 192.168.132.1
lidar_port: 7502
imu_port: 7503
scan_ring: 15
proc_mask: IMU|PCL|SCAN|IMG|RAW|TLM
use_system_default_qos: false
cap_type: halo # either halo or fins
lidar_mode: 512x10

While many of its parameters originate from robot.yaml, the purpose and origin of some fields—particularly the following frame IDs—are unclear to me:

sensor_frame
lidar_frame
imu_frame
point_cloud_frame

All of these frames are currently set to lidar3d_0_sensor_link.
Is this correct?
From my understanding, sensor_frame should probably be lidar3d_0_link, but I’m unsure how to change that properly. I’ve already tried editing it via the robot.yaml file, but unfortunately, this does not seem to have any effect.

Questions:
Are these frame IDs being set elsewhere?
Where should I correctly define sensor_frame if changing robot.yaml has no effect?

[tonybaltovski]

Thanks for reporting this! It is indeed a bug. We are looking to get you a fix shortly.