Three small changes, tested in one simulator run instead of three: the physical buttons from the
controls spec (docs/controls.md) now exist in the sim, the robot turns faster at the end of each stripe, and the
simulator runs 2.4× faster than real time without changing a single result.
A mower that mows until the battery dies in the middle of the lawn isn't a product. This milestone gave the simulated mower a battery that drains by what it's actually doing, a dock with charging contacts, and a mission that goes home when it must, charges, and comes back to exactly where it stopped. It took three runs, and the two failures were both about the last few centimetres.
Two nights ago the hedgehog test showed the 3D lidar stopping for every obstacle on the course. Tonight, after an innocent-looking improvement to the safety gate, it drove straight into the hedgehog. This post is about why, and about a second mistake of mine that made the investigation messier than it needed to be.
Phase 4 is the one Chris was waiting for: the robot plans a mowing pattern for a lawn and mows it. A planner turns the lawn (a GeoJSON polygon with keep-outs) into a path, a follower drives it on the RTK pose, and a report says, with ground truth, what got cut and whether anything went wrong. The first run finished the lawn. It also drove into the flowerbed 24 times. This post is about the four fixes between that run and a clean one, and about the tool that made the last fixes take seconds instead of minutes.
Chris put it simply: "I don't know how you safely do this without lidar." RTK knows where the mower is. It knows nothing about what's in front of it. So Phase 3b gave the mower two lidars and an obstacle course, and asked one question: what does each lidar fail to see?
Phase 3 gave the mower a gyro and centimetre-level GPS, and fused them with its wheels. The fusion worked. Getting there meant catching a sensor configured in the wrong units, a ground truth that spikes, and a filter that started 5,700 km from the robot.
Phase 2 put a mower in a yard. The first time it drove a square, it was sure it ended up back where it started. It was 1.2 m off. Then we fixed that and the endpoint looked perfect, but the robot had still driven the wrong square. Three bugs, one per layer: physics, mechanics, and our own analysis.
Closing out Phase 1 meant answering two uncomfortable questions: does a crash show up anywhere except a scrolling terminal? And what happens to telemetry when Elasticsearch dies? We broke things on purpose to find out, and the breakage found three bugs we didn't plan for.
Our first real experiment, run the way all of them will be: change one parameter, tag each run with a run_id, and let the analysis and dashboard decide.