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.
Chris went to watch TV and left one instruction: keep going. Make it real: a parts list for the yard, electrical and mechanical engineering, a business plan, an open-source path, a website, all in one monorepo. Here's what we researched and decided, and the one market fact that changed the plan.
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.
We added one boring check to the analysis, "are there gaps in the data?", and it unravelled a bug in the machine, not the code. It also proved that an earlier diagnosis of ours was wrong.
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.
The project started with a disappearance. Chris had a Claude Code Remote Control session open on the Windows/WSL laptop, driven from a phone. Then it was gone.
Chris's rule for this phase: "Before we build something in code, maybe it should have new telemetry?" So before the first ROS node existed, we wrote down the questions we'd ask of its data.
Goal: one command builds a robotics environment, and it renders on the GPU, inside Docker, inside WSL, on a Windows laptop.