Engineering You're Hired

Decentralised, and why that was the argument

A pipe network is the worst possible place to put a robot that needs to be told what to do. It is enclosed, it is unmapped in the places that matter, and the moment one unit fails inside it you have both a broken robot and a blocked pipe.

So the design was a swarm with no central controller: cohesion and coverage rules that let the units spread out, cover the network without going over the same section twice, and carry on if one of them stops. My part of it was those rules and the visual inspection side, which is the half where the interesting failure modes live.

Designing for the failure first

The locomotion is caterpillar-like, grippers and motors, and the part I would point a reviewer at is that it extends by spring on power loss. A robot that loses power in a pipe should wedge itself and stay put, not slide back down it. That is a mechanical answer to a software problem and it was the right one.

The rest of the protocols are the same instinct: what happens at a corner, what happens when a unit disconnects, how one gets rescued. The concept spends most of its design budget on the situations where things have already gone wrong, which is the part of a system that decides whether it is deployable.

A robot that loses power in a pipe should wedge itself and stay put, not slide back down it.

Sensing, and the honest limits

Leak detection combines vision, LiDAR and ultrasonic, because no one of them is sufficient in a wet metal tube: vision gives you the crack you can see, ultrasonic gives you the wall thickness you cannot, and LiDAR gives you the geometry to know where either of them was pointing.

It is a concept and it is worth saying so plainly. Nothing was built. What was produced was a design, the mechanics, the protocols, the animations that made it legible to a panel, and a business case, judged third against everyone else in the year.