Build a Micromouse: A Flood-Fill Maze-Solving Robot

What you are building

A robot that is dropped into a maze it has never seen, finds the centre, and then drives back through the shortest route it can prove exists.

That second half is what makes a micromouse different from every other robot on this site. A line follower reacts. An obstacle avoider reacts. A micromouse remembers — it builds a map while driving, and then plans across cells it has not visited. It is the smallest complete robotics problem: sensing, motion, mapping and planning, all of which must work at once.

The two-run strategy

Competition mice get several runs and are scored on the fastest. That produces a strategy worth copying even when nobody is timing you:

Run one — explore. Drive carefully, record which cells have which walls, and reach the centre. Speed is irrelevant; the map is the product.

Run two — exploit. Flood fill the finished map, compute the shortest route, and drive it without stopping to sense anything you already know.

The split matters because the two runs want opposite things. Exploring wants slow, cautious motion and constant sensing. Speed-running wants commitment. Trying to do both at once produces a robot that is bad at each.

Why the algorithm is not the hard part

Flood fill is genuinely simple: give the goal cell distance 0, give every neighbour 1 more than the lowest neighbour it can reach, and then always step to a lower number. It is a few dozen lines and it is provably shortest on a grid.

The hard part is that it assumes the robot knows which cell it is in.

Miscount one cell, or turn 88° instead of 90° a few times, and the planner is now solving the maze for a robot that is somewhere else. The symptom is maddening: the algorithm is perfect, the wiring is fine, and the robot confidently drives into a wall.

So the build order below spends most of its effort on motion, and adds the planner last. You can prove the planner separately in the maze solver simulator, where position is exact by construction — which is precisely why simulating it first is worth the time.

Build order

1 — Get three clean distance readings. Front, left, right, using VL53L0X time-of-flight sensors. They share one I²C bus and boot at the same address, so bring them up one at a time by holding the others in reset and reassigning addresses at startup. Confirm each reads a wall at a known distance before mounting anything.

2 — Make it drive straight and turn square. This is the real project. Follow wall following and precise turns: a PID loop on the side sensors to stay centred, gyro-integrated turns instead of encoder counts, and re-squaring against a front wall whenever one is available. Do not move on until the robot can do ten turns and still face the right way.

3 — Count cells reliably. Encoders predict where a boundary should be; the falling edge of a side wall confirms where it actually is. When they disagree, believe the wall — it is a physical landmark, not an accumulated estimate.

4 — Record walls into a map. Two bits per cell for four walls, and a 16 × 16 maze fits in a few hundred bytes. Record what you see as you see it.

5 — Add flood fill. Now the planner has honest data. Recompute the distances whenever a newly discovered wall invalidates the current plan — that replanning is the whole reason flood fill is used rather than a one-shot search.

Hardware notes that matter

Small beats fast. The robot must turn within a cell. A tight chassis with the wheels near the centre of rotation pivots cleanly; a long one clips walls on every turn, and no amount of tuning fixes geometry.

Backlash is heading error. Every pivot turn reverses the motors, and a loose gearbox loses the first few degrees. N20 metal-gearbox motors exist for this reason.

Mount the side sensors slightly forward and angled. Pointing them straight out means they see a wall only when perfectly beside it, so the robot learns about the wall late. A small forward angle gives the control loop a preview.

Give the sensors a stable supply. A VL53L0X returns plausible-looking wrong numbers on a sagging rail rather than obviously failing — the worst kind of fault, because the map fills with walls that are not there.

When it goes wrong

Symptom	Usually
Drives into a wall confidently	Cell count is off — position, not planning
Ends up diagonal after several turns	Gyro bias not subtracted, or turns not re-squared
Lurches into side openings	Wall-presence check missing from the following loop
Maps walls that do not exist	Sensor supply sagging, or crosstalk between modules
Solves it slowly, crashes fast	Speed run too quick for the motion layer — slow it, then raise

Almost every entry in that table is a motion or sensing fault rather than an algorithm one. That distribution is the single most useful thing to know before starting, because it tells you where to spend your weekends.

If you want the mapping and planning ideas without the hardware, the maze solver simulator runs the same two-phase strategy in the browser, and the path planning and mapping roadmap carries it forward into A* and SLAM. For a much cheaper first maze robot, the line maze solver uses tape instead of walls and needs no distance sensors at all.