Four ultrasonics and a rotation

The maze is a grid of 12-inch tiles. What the robot can measure about the tile it is standing on is exactly four booleans — wall or no wall, on each side — so a tile is a number from 0 to 15. The map of the whole maze is 32 such numbers, hardcoded.

The design decision that makes the rest work is the order of those four bits. They are assigned going around the tile — north, west, south, east — rather than in any arbitrary order:

Because the bits go around the tile, turning the robot 90° is a cyclic rotation of the four bits. A robot facing an unknown direction does not have to enumerate four different geometries; it reads one number, and the four hypotheses are that number rotated 0, 1, 2 or 3 places. In MATLAB that is one call to bitror. The whole orientation problem collapses into a rotate instruction.

Localization is then a set intersection, and nothing more. Start with all 96 states — 24 free tiles × 4 headings. Keep the ones whose rotated code matches the reading. Drive one tile, push every surviving candidate along the same body-relative move, drop the ones that would have hit a wall, and intersect with the new reading. Repeat until one survives.

What makes this a real problem rather than a formality is how little a four-bit reading tells you.

All of the above assumes the robot can move exactly one tile and end up square in the next one. It cannot, and the report's stated design principle is unusually blunt about it: distrust the physical robot and increase trust as needed. Assume the motors desync, assume friction is asymmetric, assume nothing is straight.

The team considered closing a PID loop on heading and rejected it as too complex for the schedule. What they built instead is geometric and open-loop-per-step: a tile crossing is broken into three-inch increments, and each increment corrects one error.

Before each increment, the side ultrasonics give the distance to the reference wall — the shorter of the two readings, because ultrasonic error grows with range, or both together in a corridor. Comparing that to the ideal centre-lane distance gives a lateral offset, and the robot turns by θ, drives the increment diagonally, and turns back by −θ, so it arrives forward by the step and sideways by the correction.

After the increment, it measures the side distance again. If the heading error α were zero, the lateral offset would now be zero. It is not, and the discrepancy is exactly what α produces — so α is recovered from the residual and corrected by rotating.

It is a dead-reckoning-free controller: nothing accumulates, because every three inches the walls tell it the truth again. The report's own summary is that the robot "perfectly travels without hitting any object", and the measured outcome — a clean maze run on the first attempt at milestone two — supports it.

The failure mode is where the reference disappears. Around some corners, and in the middle of the run between (1, 4) and (2, 4), the guiding wall switches sides mid-step, and wall-following faithfully follows it around the corner. The fix is not a better controller: it is a hardcoded list of positions where wall-following is switched off for part of a movement. Which means the geometry module depends on the localization module, while localization depends on the robot being able to drive straight — a circular dependency the report calls out explicitly as the thing that made integration delicate.

The electronics ceiling was pin count, not compute

The first build put every ultrasonic on a shared echo pin to save I/O on an Arduino Uno. Sharing serialised the readings and let the echoes interfere; a diode per pin did not fix it. The Uno also had no room for the MOSFETs the speakers and high-voltage LEDs needed, each of which costs another digital pin.

The fix was to stop economising: an Arduino Mega, one trigger and one echo pin per sensor, and the decorative outputs deleted. The wiring then fitted on a single breadboard and needed no further modification for the rest of the project. It is the same ceiling the LED cube ran into — I/O and interrupt budget, not clock speed.

Two halves that barely know about each other

The Arduino is deliberately stupid. It accepts primitives over Bluetooth — read the left ultrasonic, turn this many degrees — and answers when done. Everything above that lives in MATLAB on a laptop: wall-following, localization, navigation, block handling.

The payoff is that the simulator speaks the same primitives, so the same MATLAB runs in simulation and on the robot with nothing swapped. That is why weeks of untested code worked on contact with hardware, and it is the same sim-and-real-share-the-logic split I have used on every project since.