# Sensor synchronisation bug between Gazebo and ros2_control with diff_drive_controller

For the past few months I have been tackling this issue on-and-off and getting nowhere.

When using the ros2_control diff_drive_controller with Gazebo, there appears to be a discrepancy between the simulated sensor data and the reported odom TF. For comparison, using the built-in Gazebo-ROS differential drive controller has no issue.

The best way to understand the issue is to watch this video (desired behaviour 1:07, actual 2:29): https://www.youtube.com/watch?v=D3tFc...

And then check out this minimum working example: https://github.com/joshnewans/mwe_dif...

The issue is most obvious when rotating on the spot. The lidar data "springs" in and out, and is at a constant(ish) offset while in constant motion. When viewed in RViz, one would expect the lidar data to remain aligned to the grid - barring wheel slip. I do not believe the issue is due to wheel slip, the symptoms are too consistent and indicative of a timing issue, and I can't visually observe any slip when using the wireframe view in gazebo.

(I'd upload screenshots but my level is too low)

Have I done something wrong, or is there a bug?

I think the source of the issue could be (in order from most to least suspicious):

• gazebo_ros2_control
• ros2_controllers/diff_drive_controller
• ros2_control
• gazebo_ros_plugins
• Somewhere else

All example files are available in the linked github repo.

At the end of the video I show another observed issue, which may or may not be related, where the depth data and RGB data from a simulated depth camera are also out of sync, however this occurs with both control methods.

Tested on ROS2 Foxy with the apt versions of all the ros2_control stuff, as well as the foxy branches from source.

edit retag close merge delete

Your question is awesome! Thank you for the video and the code to better understand. I will start digging to see what I can find, but at this moment I am not sure what is causing it either. I suspect if it's happening with rotations more than with linear motions, perhaps the accuracy of the calculations with doing the transformations as the error will accumulate. Very interesting question.

( 2021-10-06 08:51:02 -0500 )edit

Just for curiosity, I see that for ROS 2, you don't specify the max torque, but you do for ROS 1. I don't think this has to do with the problem you raised, but just trying to understand when I compared side to side. Also In ROS 1, you allow for acceleration but not in ROS 2.

( 2021-10-06 09:50:01 -0500 )edit

Thanks! I had been assuming the controller would use the effort limits in the joint tag of the URDF (which is admittedly 1000 at the moment, I forget if I tested a lower value). However I've only just realised that I may also need to set it in the ros2_control tag in ros2_control.xacro. I won't have a chance to test that for another ~10 hours, but I'll report back with the result.

( 2021-10-06 16:18:10 -0500 )edit

Your comment sent me down a different line of thinking, to check if there are acceleration limits in the diff_drive_controlleritself. I eventually figured out that this was broken and that someone else had already submitted an issue https://github.com/ros-controls/ros2_.... I'll keep poking around to see what I can find.

( 2021-10-07 14:59:05 -0500 )edit

I’m glad it helped. Let me know when you find the answer. It’s very interesting. I’m just started with ROS 2.0 so I don’t have a lot of experience

( 2021-10-07 15:29:16 -0500 )edit