Underground and in-tunnel robotics.

The mission

A drainage gallery under an old mine needs inspecting before anyone signs the entry permit. The crawler goes in with cameras and gas sensors; the crew stays at the portal. The gallery runs straight for two hundred metres, then bends, drops a level, and bends again — and somewhere past that second bend is the collapse the survey exists to find. The machine can drive it. The question is whether anyone on the surface will still be in contact when it gets there, because the alternative to a working link is the one thing the permit process is trying to avoid: sending people in after the machine.

What breaks

Underground radio is a corridor problem. A tunnel guides a signal surprisingly well along a straight run — and kills it at the first serious bend, because rock does not reflect politely and nothing usable diffracts around ninety degrees of it. Two bends in, the surface is simply another planet: no cellular, no Wi-Fi from the portal, no long-range radio, whatever the transmit power. The classical answers all disappoint. Tethers give a reliable link and a hard limit — they snag on inverts, halve the speed, and dictate the route. Leaky feeder installations are excellent and permanent, priced and scheduled accordingly; they do not exist in the gallery you are surveying precisely because it has not been maintained. And a “come home on link loss” autonomy fallback quietly converts every radio shadow into an aborted survey.

There is a second failure inside the first: even when the link merely flickers at a bend, a conventional streaming architecture treats it as a disconnection. The gas reading spike the sensors caught in the gap was never recorded anywhere the surface can see.

The architecture on this mission

The pattern turns the tunnel itself into the network plan. The robot carries a magazine of small relay nodes — a single-board computer, a radio and a battery each — and drops one at every bend as it advances, or a crew emplaces them on the walk-in section. Each node runs the same Atlas software as the robot and the portal station: it authenticates by key, joins the mesh, and starts relaying. No controller, no surface infrastructure, no configuration at the bend — the chain assembles itself as it is laid, hop by hop, up to 8 hops deep, with every leg its own measured, encrypted link and relays unable to read the traffic they carry.

Control rides the chain inward on a reserved class floor; inspection video rides outward, elastic, shedding quality when a marginal hop narrows rather than stalling the drive. And when the chain breaks anyway — a relay knocked over, a battery gone, the robot pushing one bend past its last node — store-carry-forward takes over: sensor events, gas readings and flagged frames queue on the robot in priority order and drain automatically the moment it backtracks into contact. A break in the chain costs latency, not data.

How the run unfolds

1. Staging at the portal. The crew powers the portal station and the robot; the two nodes form the first link of the mesh. The relay magazine is loaded and each node’s key is already enrolled.
2. The straight run. The robot advances two hundred metres on the direct link, video flowing, every probe logged. As the first bend approaches, the link’s measurements begin to sag on schedule.
3. First drop. At the bend, the robot releases a relay. It joins the mesh in seconds and traffic re-routes through it — two short hops replacing one dying long one. The drive continues without a pause command ever being sent.
4. Deeper. A second bend, a second relay. Control now rides three encrypted hops; the video is coarser than at the portal and the command channel, a few kilobits on its reserved floor, is untouched.
5. The break. Past the collapse, the robot pushes beyond its last relay to finish the sensor sweep. The chain is broken by choice; readings and imagery queue on the robot, and on the backtrack they drain in priority order — gas alarms first, bulk video last.
6. The debrief. Relays are collected on the way out. The journal holds a per-hop record of the whole run — where each link held, where it sagged, what queued and when it delivered — which is both the survey’s evidence and the layout plan for the next gallery.

What each mechanism contributes

• Self-forming mesh — dropped nodes authenticate and join with no configuration at the bend; the chain assembles as it is laid. Shipped.
• Relay routing with per-hop encryption — up to 8 hops, each leg its own measured session; relays cannot read what they carry. Shipped.
• Class floors — control inward before video outward on every narrow hop. Shipped, opt-in.
• Store-carry-forward — data queued through any break and delivered on re-contact, priority first. Shipped, opt-in.
• External to Atlas — the droppable relay hardware itself: enclosure, battery, release mechanism and emplacement mechanics are the operator’s or an integration partner’s engineering.

The honest boundary: this is a pattern, not an off-the-shelf capability, and the reason is hardware. Atlas’s share — mesh joining, relay routing, queueing and the journal — is shipped software; the droppable node itself, how it is carried, released, powered and survives a tunnel floor, is external engineering that does not exist as a product here. Atlas also cannot see through rock: a robot beyond its last relay is genuinely out of contact, and what the pattern guarantees there is that the data survives to delivery, not that the link does.

What a pilot should prove

• A working chain through at least two real bends: control inward and usable video outward, with per-hop measurements from the journal.
• Chain assembly time per relay — from drop to routed traffic — repeated enough to be boring.
• A deliberate mid-chain kill: traffic queuing at the break and draining completely, in priority order, on re-contact.
• Throughput versus hop count on the candidate relay hardware, measured in the actual tunnel rather than assumed.

One gallery, one robot, one crate of prototype relays. The evaluation format covers the structure.