Four loops, two links: the architecture that keeps flying

The demo version of any drone system quietly assumes three things: that GPS works, that the radio link holds, and that the drone is smart enough to fly itself. A real fight grants you none of those. GPS gets jammed. The link drops. Half the airframes are cheap things with no brain on board.

So the interesting engineering question for DomeCommand isn't "how well does it work on a good day." It's "what happens on the bad day, and the worse one after that." This post is about how the system is built to degrade: to keep doing something useful as each assumption gets taken away.

One loop, living in different places

Underneath everything, DomeCommand runs the same shape: fuse the sensor picture, plan against it, execute the plan, coordinate so nobody collides or double-targets. What changes under pressure is where each part of that loop runs.

There are two radio links that can independently fail:

• the uplink: from the edge command node up to the drones (low rate, tolerant of dropouts),
• the peer mesh: drone-to-drone (a self-forming, self-healing MANET where every node is also a relay).

Cross those two links, each either up or down, and you get four operating modes. The system doesn't switch between them with a "degraded mode" toggle. It's a set-membership test run every tick: given what's actually connected right now, what can I still do?

Read that picture left-to-right, best case to worst:

• Hybrid: both links up. This is the design point. The edge pushes one mission per group (intent, not micro-control); the drones self-organize over the mesh; telemetry flows back. Every maneuver is available.
• Central: the mesh is down but the uplink holds. The edge substitutes for the mesh: it computes lanes centrally and pushes per-drone waypoints at a higher rate. Works, but only for small groups, since you're paying comms for what the swarm used to do itself.
• Autonomous: the uplink is gone and the edge is blind. An elected leader holds the last mission and re-tasks the group over the mesh. A degraded planning loop, now running on the swarm itself.
• Solo: both links dead. Each drone flies its last mission alone and vision-flocks just to avoid hitting its neighbors. No new orders, no target-sharing, but still flying, still on task.

The point of drawing it this way is that there's no cliff. Capability falls off in steps, and at every step the system is honest about what it can and can't still do.

GPS-denied is a signal, not a mode

The instinct is to build a "GPS-denied mode." We deliberately didn't. GPS health is just another live input the loop reads every tick, sitting alongside the two link states. When it's good, the drone uses it. When it's jammed, self-positioning falls back: to visual-inertial odometry, to ultra-wideband ranging between drones, to plain vision of its neighbors. The swarm holds formation on relative position instead of absolute.

Because it's a signal and not a special case, degradation gets authored the same way everything else does, as an ordinary guard in the policy:

saturation_strike:                        # one policy, deployed once
  when neighbors_alive == 0:      pursue(asset)       # alone → press the attack
  when contacts_within(250m):     evade(nearest)      # threat close → break
  otherwise:                      pursue(asset)       # ingress on the mesh lane

The drone doesn't pick a "rung." Its behavior tree branches on the live signals, and a collision-avoidance floor sits underneath any policy regardless. That's the whole trick: the hard cases aren't bolted on, they're the same machinery reading worse inputs.

"Flying solo" is the actual autonomy

Here's the part I care most about. The execution loop runs on the drone, at about 20 Hz, link or no link. That's not a fallback. That is the autonomy. The mission coming down the uplink only selects which pre-deployed policy to run, against which target, with which rules of engagement. The decision logic already lives on the aircraft before the fight starts.

Which means when the uplink dies, nothing about the drone's inner loop stops. It keeps sensing, keeps deciding, keeps flying. Two safety floors are wired in beneath every policy and can't be authored away: an always-on collision-avoid, and a solo vision-flock fallback for when even the mesh is gone. The worst case isn't a crash. It's a drone quietly finishing its last assignment.

Smart drones and dumb drones, same loop

The last assumption to kill is that the drone has a brain at all. Most don't. So a drone's control profile carries two facts:

• the link it speaks: MAVLink, DJI's PSDK, Crazyflie's CRTP, or none at all, and
• where its execution loop runs: OnDevice or Offboard.

A capable drone flashed with our firmware is OnDevice: it runs the loop itself and flies solo when cut off. A primitive drone, no compute, just a flight controller, is Offboard: the runtime hosts the exact same loop on a companion computer (think a Raspberry Pi zip-tied to the airframe) and streams setpoints down over MAVLink. Same policy, same decisions; only the transport differs. A stock Crazyflie is Offboard; the same Crazyflie flashed with the firmware becomes OnDevice. (Genuinely hostile platforms resolve to link: none, observed, never tasked.)

That symmetry matters because it means the fleet doesn't have to be homogeneous or expensive. You can put a smart loop behind a dumb airframe and it behaves like the smart one, right up until the companion computer loses its own link, at which point a dumb airframe is exactly as blind as it should be.

What we're building

Here's where the work sits right now.

In place: the loop architecture, the policy DSL with its comms-degradation predicates (mesh_down, link_lost, neighbors_alive), the vehicle-adapter layer that makes MAVLink/PSDK/CRTP interchangeable, and, importantly, a fully deterministic simulator where a whole engagement replays byte-for-byte from a seed. The plan → policy → execute path is closed end-to-end, under a human approve/reject gate.

Building next: contested-RF mesh networking on real radios, GPS-denied VIO, monocular vision-flocking, on-device target recognition. The near-term proof we're driving toward is a companion computer plus a PX4 drone plus one mesh radio, with the harder swarm-survivability behaviours maturing in simulation first, then moving onto hardware.

So "built to survive" is first a statement about architecture. The design assumes the bad day from the start: one loop that keeps running as GPS, then the uplink, then the mesh, then everything gets taken away. Bringing that all the way onto hardware is the work ahead, and I'll write it up as it happens.