realsense-ros: setting align_depth causes misaligned coloured point cloud, similar but not the same issue as 2595

I’m running ROS Humble inside docker where I also apt install ros-humble-realsense2-* My setup:

When I run the ros2 launch realsense2_camera rs_launch.py with the following arguments:

enable_depth ==> true
pointcloud.enable ==> true
align_depth.enable ==> true

Note that there is a green colour silicon mat in real life, it is perfectly aligned to the edge of the table in real life(you can also see the urdf model of the table on rviz). However, on rviz where the pointcloud is displayed live, the points of the green mat is not aligned with the edge of the urdf table.

The purpose of me putting the brown box is to show that this problem is NOT related to issue #2595.

I notice that the pointcloud that is published is always misaligned by around 4-5cm to the right. Note that I am not referring to an issue where the depth information is not aligned to the rgb information that has been raised previously by issue #2595. This is a different problem. I know for a fact that this pointcloud is misaligned because I mount the D455 camera onto the robot end effector, and that the robot is mounted on a known position of the table.

Here we can see that the green mats’ points are now properly aligned to the edge of the urdf table.

Furthermore, once I change the argument align_depth.enable ==> false. The problem of the misaligned pointcloud disappears. Suggestions might include just leaving the align_depth.enable argument as false, but I desire the following topics:

1. depth image[that is aligned to the rgb image]
2. rgb image
3. pointcloud

Could someone please look into this? Thanks.

---

Required Info
Camera Model	D455
Firmware Version	5.15.1
Operating System & Version	Ubuntu 22
Platform	PC
Librealsense SDK Version	2.54.2
ROS Distro	Humble
RealSense ROS Wrapper Version	4.54.1-1jammy

Issue Description

The pointcloud that is published when using align_depth.enable==>true is misaligned to real physical space. This is NOT the same as issue #2595 although the title description is the same.