Why are the axes swapped when publishing static tf?

[schmidtp1]

https://github.com/IntelRealSense/realsense-ros/blob/development/realsense2_camera/src/base_realsense_node.cpp#L1991 ff. seems like it shouldn't be there/necessary if the transformations are done correctly. can anyone provide insight why this is currently required? thanks

[MartyG-RealSense]

Hi @schmidtp1 Looking at that section of code, it may be taking account of ROS using X-forward, Y-left, Z-up as its standard frame_id, whilst in the RealSense coordinate system Z is forward and Y is up. This subject is discussed at https://github.com/IntelRealSense/realsense-ros/issues/1099

[schmidtp1]

Hi @schmidtp1 Looking at that section of code, it may be taking account of ROS using X-forward, Y-left, Z-up as its standard frame_id, whilst in the RealSense coordinate system Z is forward and Y is up. This subject is discussed at #1099

but as it looks this is happening for all the static/internal transformations (that should be given by the CAD model /calibration) and not just for the reference frame. also why is the orientation (quaternion) not rotated then? also doesn't it seem the wrong place to do this (or at least unexpected) when one would just expect "publishing" (based on the function name)?

[MartyG-RealSense]

I will discuss this section of base_realsense_node.cpp code with my Intel RealSense colleagues. Thanks very much for your patience!

[schmidtp1]

I will discuss this section of base_realsense_node.cpp code with my Intel RealSense colleagues. Thanks very much for your patience!

thank you for your quick response, your insight and for following up on this

[schmidtp1]

I will discuss this section of base_realsense_node.cpp code with my Intel RealSense colleagues. Thanks very much for your patience!

to provide a bit more context, i suspect a bug in the transformation(s) there as well as in this function: https://github.com/IntelRealSense/realsense-ros/blob/development/realsense2_camera/src/t265_realsense_node.cpp#L94 based on that when i'm getting the transformation between the sensors from ROS, it is (slightly) different than what I'm getting from LRS, see below.

if it is agreed that this is not the expected behavior, can this issue be promoted to a bug? (@MartyG-RealSense) i think it can affect anyone who uses the transformations between the sensors, e.g. for sensor fusion /slam, e.g. between depth/rgb and imu. (it shouldn't affect rgb-d because it is aligned within LRS.) it is rather subtle because the differences can be pretty small, sub mm/degree, basically the manufacturing tolerances, for this special case with the sensors mostly aligned on 1 axis, and mostly aligned or 180 degree rotated sensor frames.

i'm working on a fix for it...

(i'm using ros2-beta but pointed at the functions above because i don't think it is ROS2-specific, i.e. the same on the main branch.)

actually since the latest merge in ros2-beta a couple of days ago, it seems another issue was introduced and the trafo looks closer to the inverse... (@SamerKhshiboun)

[MartyG-RealSense]

Thanks very much @schmidtp1 for your detailed feedback. A decision regarding whether or not there is a bug would be taken as part of the internal discussions about this case.

[MartyG-RealSense]

Hi @schmidtp1 After discussing your case with the RealSense ROS team, they said that they would look into it. In the meantime they suggested that https://github.com/IntelRealSense/realsense-ros/issues/305 may be related to your question.

[MartyG-RealSense]

Hi @schmidtp1 Was https://github.com/IntelRealSense/realsense-ros/issues/305 a helpful reference for your question, please? Thanks!

[schmidtp1]

@MartyG-RealSense, yes, #305 is related (thanks for finding it!) but the issue is stated there: "My initial guess was that flipping axes is a trick applying rotation, however if it was actually rotation the quaternion should also be rotated." i don't think the reply (https://github.com/IntelRealSense/realsense-ros/issues/305#issuecomment-365867286) addresses it. also i don't think it is logically done in the right place, in the publisher, and a possible transformation should be applied somewhere else to avoid other issues.

[MartyG-RealSense]

The RealSense ROS team has created an internal Intel report to further investigate why axes are swapped when publishing a static TF.

[MartyG-RealSense]

I have added an Enhancement label to this case as a reminder that it should be kept open whilst Intel's internal report is active.

[schmidtp1]

thanks, @MartyG-RealSense. please note that i still think there is a bug as pointed out in the results above. i hope this will be recognized and approved as a bug to increase the priority. i think it can affect any kind of sensor fusion with RS (and is rather subtle).

[MartyG-RealSense]

A fix has been merged into the RealSense ROS wrapper - see https://github.com/IntelRealSense/realsense-ros/pull/2684 - and so this case can now be closed.