After the line follower: what to build next, and what to learn with it

A first working robot is a genuine achievement and it is followed, very reliably, by a stall. The pattern is consistent enough to be worth naming: the next project is chosen for ambition rather than for what it teaches, it involves four or five unfamiliar things at once, and it is abandoned at the point where a fault could be any of them.

The underlying problem is diagnostic rather than technical. Debugging works by elimination, and elimination requires that most of the system is known-good. A project where the mechanics, the electronics, the sensing and the control are all new has nothing known-good in it, so a fault cannot be localised and progress becomes guessing.

So the productive rule is one new thing per project. Keep the drivetrain you understand and add a new sensor; or keep the sensing and change the mechanics. It feels slower and it is dramatically faster, because every project finishes.

• Better control — build a balancing robot — Two wheels, an inertial measurement unit, and a control loop that has to run properly or the thing falls over. The canonical next project, because the mechanics are trivial and the entire difficulty is in the loop — which means when it misbehaves you know where to look. It is also where tuning stops being folklore and starts being something you can reason about.
• Better mechanics — build something that walks — A hexapod or quadruped. Servo-heavy, mechanically demanding, and the point at which a 3D printer stops being optional. What it teaches is that geometry and rigidity are engineering problems in their own right, and that a frame that flexes makes correct code look broken.
• Better autonomy — make it map something — A rover that builds a representation of a space rather than reacting moment to moment. This is where hobby robotics meets the professional field, where sensor fusion and path planning become real, and where the software becomes the hard part for the first time.
• Better under pressure — enter a competition — A deadline, a ruleset and other people’s machines to compare against. Competition teaches reliability above all, which is the engineering virtue hobby projects never demand — a robot that works on the bench and not in the third round has taught you something no amount of solo building would.

• Version control from the first line — The commonest way a working robot stops working is an undocumented change. Costs nothing to start and is the cheapest debugging tool available.
• Instrument before you optimise — Log what the sensors report and what the outputs did. A surprising proportion of "the algorithm is wrong" is a sensor that was never reading correctly, and you cannot see that without looking.
• Build test rigs — A way to run the drivetrain off the ground, or to exercise a sensor without the whole robot. People who progress quickly nearly all built something like this early.
• Finish things, even badly — A finished mediocre robot teaches more than three abandoned ambitious ones, because the last ten per cent is where reliability lives and it is the part hobby projects skip.
• Learn one thing properly rather than five superficially — Depth in one branch transfers; a shallow pass over all of them does not. The people worth asking questions of are nearly always specialists.
• On the big frameworks: later, and only with a reason — The professional robotics middleware is genuinely powerful and genuinely heavy, and adopting it because it seems like the serious choice usually adds a large unfamiliar system to a project that did not need one. Reach for it when you have a problem it solves — typically multiple sensors and processes that must be coordinated — rather than as a rite of passage.