Build a Line Maze Solver Robot With LSRB Route Memory

A line follower follows. A line maze solver decides. That is the whole jump this project makes, and it is a bigger one than it looks: the robot stops being a control loop with wheels and becomes something that explores an environment it has never seen, remembers what it found, and acts on that memory.

The trick is that none of it replaces the line follower—it sits on top of one. Underneath, the same reflectance array and the same PID loop keep the robot centred on the tape, knowing nothing about mazes. Above it, a thin decision layer watches for the moments when the line branches, classifies what kind of junction it hit, picks a direction, and writes down one character. That separation is what makes the project tractable, and it is the same two-layer split real robots use everywhere.

So the build order matters more than usual. You get plain line following genuinely stable first—tuned in the simulator, then on a large oval of real tape—and only then add junctions. Skip that discipline and every mechanical problem, every calibration drift, every wheel that is 2 mm out of alignment will show up disguised as a maze-solving bug.

Follow the tech tree below top to bottom. Each node opens once its prerequisites are done, and your progress is saved on this device, so you can build the robot over a weekend without losing your place.

Bill of materials

Total: roughly $35–45. The 8-channel array is the one part not to economise on, and the reason is specific: a robot detects a left branch by noticing that the outermost left sensors have gone dark while the centre is still on the line. An array barely wider than the tape physically cannot see that, so junction detection becomes guesswork no matter how good the code is.

Why the array must be wider than the line

   left branch                    array (8 channels, ~60 mm wide)
   ────────────────┐          [ x x x . . . . . ]   outer left dark -> a branch
                   │
   ════════════════╪═══════   [ . . . x x . . . ]   centre still on the line
                   │

Rule of thumb: the array should be at least three times the tape width. For 19 mm tape that is around 60 mm, which an 8-channel array at 8 mm spacing gives you exactly. Narrower and the robot cannot distinguish “the line curved sharply” from “the line branched”, which is the central decision the whole project rests on.

Build it in milestones

The build order here matters more than in any other project on this site. A maze solver is a line follower with a decision layer, and every mechanical or calibration fault in the follower reappears disguised as a maze-solving bug.

Milestone 1 is not negotiable. “Mostly follows the line” becomes “occasionally invents a junction”, and you will spend an evening debugging path simplification for a fault that is really a wheel 2 mm out of alignment.

Milestone 2 is the one people skip. A maze solver executes hundreds of turns per run, and a turn that is consistently 5° short accumulates until the robot leaves the line entirely. This is exactly where gearbox backlash shows up — error that changes sign with direction is mechanical, not a tuning fault.

The two-layer split, in code

The separation that makes this project tractable is worth seeing explicitly:

             ┌─────────────────────────────────────┐
   decision  │  classify junction -> choose turn   │   runs only at junctions
     layer   │  record a character -> simplify     │   knows nothing about PWM
             └──────────────────┬──────────────────┘
                                │ "turn left" / "keep going"
             ┌──────────────────▼──────────────────┐
   following │  read array -> position -> PID      │   runs every loop, ~200 Hz
     layer   │  -> left and right wheel speeds     │   knows nothing about mazes
             └─────────────────────────────────────┘

The lower layer never learns what a maze is. The upper layer never touches a motor. When something goes wrong, that boundary tells you which half to look in — and if you cannot say which half a bug lives in, the layers are not properly separated.

What good looks like

Junction accuracy is genuinely all-or-nothing, and that surprises people. One misread junction corrupts the recorded string, the simplifier then produces a valid-looking but wrong path, and the return run confidently drives into a wall. There is no partial credit — which is why exploration runs slowly and the return run is where you gain the time back.

Troubleshooting

Where to take it next

Add encoders and turn by distance rather than by time. Timed turns are the largest source of unreliability in a first maze solver, because the time needed changes with battery voltage and surface. Encoder-based turns do not.

Move to a walled maze — the micromouse — which replaces the tape with walls and the LSRB rule with flood fill. That is the genuinely bigger step: LSRB is a wall-following heuristic that finds a path, while flood fill computes the shortest one and replans as new walls are discovered.

Optimise the return run. Once the path is known, there are no decisions left to make, so the robot can accelerate on straights and slow only for turns. A motion profile over the known route is where the dramatic time improvements come from — often halving the return run.