Odometry twist is erroneously reported in odom frame

[peci1]

According to Odometry message docs, twist should be expressed in the child frame, which is body.

According to Bodsdyn API docs, velocity_of_body_in_odom is expressed in odom frame.

Thus the twist published by the driver is invalid for downstream nodes that expect it to be in body frame.

https://github.com/heuristicus/spot_ros/blob/e71e726ee48328985a6015f634acd531e3935e92/spot_driver/src/spot_driver/ros_helpers.py#L290-L296

Note that fixing this bug could break downstream code that has already adapted to this deviation from the standard, so care has to be taken.

[heuristicus]

A temporary fix for this might be to transform the values we get from getOdomTwistFromState into the body frame and publish it to a new topic like /spot/odometry_corrected and encourage use of that.

[peci1]

That's exactly what I've implemented in our helper library: https://github.com/tpet/nav_utils/pull/9/files#diff-738e7609319b75d0ccfebeebf1176d7eeed21562fd45dadc0c2b8c179b8c6a83 .

[julianraheema]

So I have question: I have /spot/odometry and /spot/odometry/twist, and my understanding @peci1 is your node subscribe to /spot/odometry and publish /spot/odometry_corrected then how I can use the /spot/odometry_corrected to gmapping or rtabmapping? Or do you suggest to use the corrected topic at planning level, and "go to point" function in rviz? Thank you so much for sharing this.

[peci1]

You can do whatever you need with odometry_corrected, as that is a standard ROS-compliant odometry topic. If you don't mind minor drifting, you can use it for the go-to-point function. Generally, the odometry is quite good.

[Jannkar]

Is there any progress on this or decisions made what is the appropriate way to fix it? This issue led into days of debugging to us and anybody using the odometry data will most likely face the same issue.

[heuristicus]

There is now a topic /spot/odometry_corrected which should fix this issue.