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):
- Bad configuration
gazebo_ros2_controlros2_controllers/diff_drive_controllerros2_controlgazebo_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.
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.
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.
Thanks! I had been assuming the controller would use the
effortlimits in thejointtag 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 theros2_controltag inros2_control.xacro. I won't have a chance to test that for another ~10 hours, but I'll report back with the result.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.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