Diff_Drive controller odometry drift
Hi, I've been using the default DiffDrive controller (https://github.com/ros-controls/ros2_...) with my robot (4 wheel drive, 2 each side), on ubuntu 20.04 (galactic distro). The defined command interface is velocity and the state interfaces include velocity and position.
When commanding the robot to move forward, it moves in a satisfing straight line. In the odometry ouput though (which is currently recieved by the motor's encoders only), there is a significant drift to the right.
The error is pretty linear, up to a point when commanding the robot to drive forward and turn left shows odometry of driving straight forward.
2 wheel drive: When defining the diff_drive to use the front two wheels only, the odometry output seems great - as well as when I unplug only the REAR LEFT motor. Even more weird- when I load the code to 2-wheel-drive (1 each side) AFTER the odometry output was bad, the RVIZ fixes the existing odometry (with no new inputs) up to that point (before any new movement is being commanded)!
Hardware: I assumed it was a hardware problem, but when switching the motors (with each other, or using completely new ones) the odometry ouput stays the same.
Encoder differences: I built a script to monitor the differences between the average encoder values received when driving straight forward, and the difference was insignificant (and similar between the 4-wheel-drive mode and the 2-wheel-drive mode, in which the odometry output was okay).
I'm pretty clueless at this point, so any help or suggestions would be highly aprreciated. Also, if someone has an idea for more tests I could run, I would be happy to.
Thanks for you time,
Matan.
How does the signal get from your encoder to the SW? I'm guessing looks like this: power supply -> extension cable -> encoder cable -> encoder -> encoder cable -> extension cable -> some HW that counts pulses -> network connection -> ros
It does sound like HW to me with the little info provided, so you should consider the rest of the HW that is unique to that encoder, and if that other HW is subject to a unique environment like vibration or close to motor-driver(electrical interference) etc.
Thanks for the reply Billy, I followed your advice and focused on the hardware- eventually it turned out to be a communication problem- some of the position feedback messages from one of the motos got ran over by other messages so eventually the robot thought it was drifting sideways. The hardware interface (and communication with the hardware) is better now, so the odometry looks fine :)