D555 TF bug - flipped y on `camera_link` -> `camera_infra2_frame`

[kyle-the-voyant]

I am seeing an incorrect static transform when running the realsense2_camera_node with the new D555 camera.

It is documented (and shown) that camera_infra1_frame is the left stereo camera and aligns with the camera_link frame.

The camera_link -> camera_color_frame seems correct based on hand measurements of the RGB camera being ~6cm to the right of the left stereo camera. Below see: y: -0.05891134962439537

However, camera_link -> camera_infra2_frame is incorrect and seems to have a flipped sign. The magnitude is correct based on hand measurements of the right camera being ~10cm to the right of the left stereo camera. Below see: y: 0.09499085694551468. However, the positive sign puts this to the left of the left camera (and has the color camera frame outside of the two stereo camera frames, which is not how the camera is configured.)

$ ros2 topic echo /tf_static 
transforms:
- header:
    stamp:
      sec: 1758573838
      nanosec: 735626811
    frame_id: camera_link
  child_frame_id: camera_infra1_frame
  transform:
    translation:
      x: 0.0
      y: -0.0
      z: -0.0
    rotation:
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
- header:
    stamp:
      sec: 1758573838
      nanosec: 735626811
    frame_id: camera_aligned_depth_to_infra1_frame
  child_frame_id: camera_infra1_optical_frame
  transform:
    translation:
      x: 0.0
      y: -0.0
      z: -0.0
    rotation:
      x: -0.5
      y: 0.4999999999999999
      z: -0.5
      w: 0.5000000000000001
- header:
    stamp:
      sec: 1758573838
      nanosec: 735626811
    frame_id: camera_link
  child_frame_id: camera_aligned_depth_to_infra1_frame
  transform:
    translation:
      x: 0.0
      y: -0.0
      z: -0.0
    rotation:
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
- header:
    stamp:
      sec: 1758573838
      nanosec: 735666066
    frame_id: camera_link
  child_frame_id: camera_infra2_frame
  transform:
    translation:
      x: 0.0
      y: 0.09499085694551468
      z: -0.0
    rotation:
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
- header:
    stamp:
      sec: 1758573838
      nanosec: 735666066
    frame_id: camera_infra2_frame
  child_frame_id: camera_infra2_optical_frame
  transform:
    translation:
      x: 0.0
      y: -0.0
      z: -0.0
    rotation:
      x: -0.5
      y: 0.4999999999999999
      z: -0.5
      w: 0.5000000000000001
- header:
    stamp:
      sec: 1758573838
      nanosec: 755403300
    frame_id: camera_link
  child_frame_id: camera_color_frame
  transform:
    translation:
      x: -0.00039143903995864093
      y: -0.05891134962439537
      z: -3.5686345654539764e-05
    rotation:
      x: -0.0009801259730011225
      y: 0.0005495680379681289
      z: 0.0009980970062315464
      w: 0.9999988675117493
- header:
    stamp:
      sec: 1758573838
      nanosec: 755403300
    frame_id: camera_color_frame
  child_frame_id: camera_color_optical_frame
  transform:
    translation:
      x: 0.0
      y: -0.0
      z: -0.0
    rotation:
      x: -0.5
      y: 0.4999999999999999
      z: -0.5
      w: 0.5000000000000001
---

[MartyG-RealSense]

Hi @kyle-the-voyant Are you measuring on the front of the camera when measuring between the left and right IR sensors, please? If you are then the left sensor is actually on the right side of the camera when looking at it from the front.

This is because the left and right sensors are meant to be like a pair of eyes looking forwards. So when looking towards the sensors from the front of the camera, left and right are reversed.

[kyle-the-voyant]

Hi @MartyG-RealSense, yeah I am considering left and right from the camera's perspective and measuring in that way. What makes it clear is that the camera_color_frame should be between the camera_infra1_frame & camera_infra2_frame

(I should've included this screenshot in the initial post)

[MartyG-RealSense]

D555 has a D450 camera module inside it. So yes, the RGB color sensor should be inbetween the left and right infrared sensors.

The default position of camera_link is usually the left IR sensor, which is the origin point of depth, while base_link is the tripod screw-thread hole on the base of the camera.

The example image below is from a D435i, which has a similar sensor position layout.

In the RealSense coordinate system, the positive horizontal axis points to the right, towards the right IR sensor, when viewing the camera from the front.

Ignore that the above diagram has the horizontal axis labelled as X instead of Y. The RealSense coordinate system uses different orientations for XYZ than the ROS standard, and the RealSense ROS wrapper automatically converts RealSense axes to ROS standard axes.

[kyle-the-voyant]

Thanks @MartyG-RealSense , this is very thorough and clear!

I understand the difference between the ROS standard coordinate systems and the realsense optical frame (captured by the purely rotational transform between e.g., camera_infra2_frame & camera_infra2_optical_frame published by the realsense2_camera_node), but this is not relevant. The published TF has the color camera outside of the two stereo cameras, regardless of if we are considering in ROS standard or optical coordinate systems.

I am reporting this as I believe it is a bug in the TF produced by the realsense2_camera_node when connected to the new D555 sensor. The transforms I am echoing / displaying in the screenshot are coming from running the realsense2_camera_node with publish_tf: true and are incorrect based on what you have detailed.

[MartyG-RealSense]

I have highlighted this question to my RealSense colleagues to seek their input. Thanks very much for your patience.

[kyle-the-voyant]

Thanks @MartyG-RealSense !

[MartyG-RealSense]

My colleagues investigated this issue and confirmed that it does appear to be a bug that occurs when D555 is used.

An official internal ticket has been created to investigate the issue further, and I have added an Enhancement label to this GitHub issue to signify that it should be kept open whilst the internal ticket is active. Thanks very much for your report!