The symptom
The rover veered right. Not randomly — consistently, about 4° per metre, on every surface, in every direction of travel, with a fully charged pack and a cold IMU.
Consistency feels like a mechanical fault. That instinct cost four evenings.
What we replaced first
In order: both motors, the motor driver, the wheels, the chassis plate. Each swap was justified — a consistent mechanical bias is exactly what a weak motor or a dragging bearing produces.
- Motors swapped for a matched pair — no change
- Driver replaced with a known-good board — no change
- Wheels swapped left for right — veer stayed right
- Chassis re-shimmed and re-balanced — no change
That third test was the answer and we did not read it. Swapping the wheels left-for-right moves any mechanical asymmetry to the other side. The veer should have flipped. It didn’t, which means the cause was not mechanical at all.
The actual fault
The MPU6050’s gyroscope has a small zero-rate offset — a nonzero reading when the sensor is perfectly still. Ours was about 0.9 °/s. That is well within specification and not a defect.
The heading estimate integrates gyro rate over time. Integrating a constant 0.9 °/s produces a heading that rotates steadily even when the robot is stationary. The PID controller then dutifully steered to correct a rotation that was not happening.
// what the loop believed, per second
heading += (gyroZ) * dt; // gyroZ = 0.9 with robot still
// what it should have been
heading += (gyroZ - gyroBias) * dt;The fix
Sample the gyro 200 times at boot while the robot is stationary, average the result, and subtract that value from every subsequent reading. Eight lines.
void calibrateGyro() {
float sum = 0;
for (int i = 0; i gyroBias = sum / 200.0f;
}The measurement that would have ended it on night one
Put the robot on the bench. Don’t move it. Print the heading estimate for sixty seconds.
If the number changes while the robot is stationary, the fault is in the estimate, not the drivetrain. That test takes ninety seconds and needs no tools. It is now the first thing we run on any platform that holds a heading.
What to take from this
A repeatable physical symptom does not imply a physical cause. Control software translates a sensor error directly into mechanical behaviour, and it does so consistently, which is exactly what makes it look like hardware.
Before replacing a part, find the test whose result differs depending on which explanation is true. The wheel swap was that test. We ran it and ignored what it told us.