Slippage correction

There are two kinds of slippage in our robots: constant and spontaneous slippage. This wiki page discusses the measures that we have taken in order to counter these kinds of wheel slippage.

When the robot drives around, it never has complete traction with the flooring that it is moving on. This results into the robot thinking it drives faster than that it is actually driving. This problem has been present since at least 2018-2019 (see velocity_measurement_world_state_vs._wheel_encoders.pdf).

In order to counter this problem the robot has correction factors for each DOF (forward, sideways and rotation). These correction values are dependent on the material of the wheels (the rubber sub-wheels) and the flooring itself. In the testing report that can be found here encoder_analysis.pdf it is demonstrated that the measurement error, caused by slippage, is constant; allowing us to indeed use correction factors.

So in order to reliably determine the needed correction factors for any robot the following calibration procedure has been set-up. One robot is set to drive forward while logging the (uncalibrated) speed reported by the robot. At the same time the vision camera system will also be logging the speed of this robot. This procedure is repeated 2 - 3 times; for forward, sideways and rotational velocities. Next, the error between the vision and reported robot speeds can be determined. In the gif below you can see the proposed procedure:

In order to determine the difference between the robot reported speeds and the ones from SSL Vision, you need to determine the reported velocities from SSL vision and from the robot. The first one can be done with the help of roboteam_observer and this script (you'll need the script track_vision.py). For the robot speeds you can log these with the help of the -d flag in testRobot.py in the Basestation/python_utils folder.

On overage the delay between sending and executing a command and receiving feedback from it is about 50 ms, so you will most likely want to compensate with it. (Vision is even slower, but if you work with step responses, then it should be fine).

In order to come to the conclusion of having constant slippage a lot of things in the robot have been validated:

1. Re-validation of the omnidirectional kinematics The equations that translate the instructed velocities into wheel speeds and vice-versa have been rewritten and checked. These were correct, but inconsistent with the existing documentation with regards to conventions, like the symbols being used. More information about these equations can be found at Omnidirectional Control.
2. Thorough check of constants used Next to the equations, all of the constants have been re-checked. Examples are the wheel radius, robot radius and the gear-ratio between each motor and the wheel.
3. Influence of kalman filter A kalman filter in the state estimation of the robot is used in order to fuse the accelerometer and encoder data. Disabling this sensor fusion functionality (only relying on encoders) did not give better results.
4. Production error on wheel angles In the line of checking constants, the angles of each wheel have been rechecked. In the following document it is proven that the angles cannot be the reason: encoder_angle_check.pdf.
5. Measure accuracy of reported wheel speed With the help of a tachometer it was proven that the encoders reported correct rotational velocities, when the wheels were not making any contact with the ground (see again encoder_angle_check.pdf.
6. Validate reference point The camera system, which is assumed to be true. Has been validated by driving a robot with a constant speed over a defined length, while timing the amount of time needed. This showed that the reported speeds by the cameras are correct.