Which way is it facing?
The last post ended with one false alarm left: a fence that "moved" because the robot thought it was facing 7° away from where it really was. 7° doesn't sound like much. At 5 m it moves a fence 60 cm, and that's enough to look like something walking. This post fixes the heading, and on the way found that the simulator had been flattering us.
Where the heading comes from
The robot has no compass. It knows which way it's facing from three things:
- the gyro, which measures how fast it's turning, very precisely, but only changes in heading;
- the wheels, which do the same, less precisely;
- RTK GPS, 5 times a second, which gives position to 1–2 cm but no direction at all. Direction comes from watching the position move: drive forward, and the line between fixes says which way is forward.
A filter (an EKF, from the standard ROS robot_localization package) blends them. It has a setting for how much the
heading may drift on its own, with nothing measuring it. Ours was the package default: about 14° per second. That
told the filter "the gyro could be wildly wrong", so every GPS fix was allowed to pull the heading around. When the
robot moves slowly or turns on the spot, position says almost nothing about direction, and the pulls are noise:
spikes up to 7.6°, each lasting one GPS fix.
A replay instead of a mow
Each setting would need a 50-minute mow to try. Instead we recorded the raw sensor messages of one back-yard mow and built a tool that plays them through the real filter nodes with any settings, then compares the heading with the simulator's ground truth. Ten minutes of mowing replays in five. First, it had to give the same answer as the real run: 1.04° average error replayed, 1.07° recorded. Good enough to trust.
Turning the drift setting down from 0.06 to 0.001 took the error from 1.04° to 0.28°. Done? No.
The simulator was flattering us
The simulated gyro had noise but no bias. A real cheap gyro reads a small turn rate when nothing is turning, a few tenths of a degree per second, and it changes with temperature. The replay tool can add one. With a bias of 0.01 rad/s (0.6°/s), the setting that looked best was the worst:
| Heading drift setting | Perfect gyro | Gyro with a 0.6°/s bias |
|---|---|---|
| 0.06 (the old default) | 1.03° | 3.7° |
| 0.001 | 0.28° | 13.8° |
Of course: we'd told the filter to trust the gyro almost completely, and the gyro was lying.
So, two changes:
- Learn the bias standing still. Whenever the wheels say the robot isn't moving, the true turn rate is zero, so whatever the gyro reads is its bias. A small new node averages it and subtracts it before the filter sees the gyro. The robot stands on its dock for hours and stops often while mowing, so it gets plenty of chances.
- A middle setting, 0.01, chosen against the hard case: bias that hasn't been learned yet. It beat the old default in every replay, with and without a bias:
| Setting | Bias learned and removed | 0.11°/s of bias left in |
|---|---|---|
| 0.06 (old) | 1.03° (worst 7.0°) | 1.14° (worst 6.5°) |
| 0.01 (new) | 0.53° (worst 3.4°) | 1.06° (worst 4.2°) |
And the simulated gyro now drifts, so every run from here on tests this.
Live
| Run | Heading error | Worst | Back yard result |
|---|---|---|---|
| Before (perfect gyro) | 1.19° | 7.6° | 1 false "something moves" alarm; failed to dock |
| After (drifting gyro) | 0.71° | 4.35° | 98.0% mowed, docked, 0 false stops, 0 alarms |
The walk, dog and child scenarios still pass (the dog seen at 4.07 m), and so does the obstacle course.
The first live try had a gyro that drifted far more than intended, swinging by 0.6°/s over a few minutes: a setting that sets the size of each wobble, not of the whole wander. The robot passed that too, with a 1.4° heading error.
Not covered yet
- A real gyro. How much a real one drifts, and how fast, depends on the part and the weather. The numbers here are a guess at a cheap MEMS gyro, on the pessimistic side.
- Learning while driving. The bias is only learned standing still. A long mow with no stops would rely on the setting above, which copes with 0.1°/s left over.
- The bumpy-lawn grass stop from the last post is still on the list.
- Next: the camera. Labelled pictures of what the robot sees, at the speed a Raspberry Pi 5 really manages, not the speed of the laptop the simulator runs on.