Problem​

A cheap drone now forces a response that can cost a thousand times more. Send a hundred at once and the hard part is no longer the hardware. It is the decision: what to send, at what, and when, faster than a person can make it.

And the person making that call is already overloaded. Sensors pour feeds at the operator, but the data points that actually decide the outcome, a clean track, a confident classification, stay scarce. Too much signal, not enough of it good.

What holds the decision together in production today is, honestly, thousands of hardcoded rules. That is what a lot of "decision support" really amounts to: hand-written logic, brittle at the edges, and almost impossible to keep current with how fast the threat is changing.

So the problem is three things at once. A decision that has to be made faster than a human can make it. An operator drowning in feeds but starved of good data. And a status quo held up by rules nobody can maintain. DomeCommand is being built to take all three on. This blog is the log, in the open, from the start.

How it started​

Years ago at Yojee I worked on route optimization, assigning vehicles to jobs under messy real-world constraints. Later I dabbled a little with programming my own flight controller using a Crazyflie. And for a while now I have been building Distri, an open-source agentic harness.

Applying a solver brain on top of an agentic brain sounded like a great fit for a counter-UAS proposition. So I built a demo.

The first demo​

The first demo was a Space Invaders style planning screen, built on Distri and focused on C-UAS: waves of drones come down the screen at Singapore, and the screen models the cost of defending against them.

It runs two things at once. A solver continuously re-allocates the effectors you have against the threats that are inbound, under the constraints and the cost of each intercept. An agent reasons around the solver as the picture changes, deciding what to ask it next and what to recommend. Traditional planning algorithms and an agentic brain might be a good mix. This was the cheapest way to find out.

▶ Watch the demo

The solver does the maths. The agent does the small amount of reasoning around it, and that small amount is what changes the answer.

DomeCommand has since been invited to submit a proposal for a three-month project at the Singapore Defence Tech Hackathon.

After a number of conversations with defence consultants, military experts, and people who have spent years close to this, the idea has evolved and deepened a lot. The backdrop is hard to miss too: drones changed the fight in Ukraine, they are cheap and numerous and hard to stop, and the hardware is years ahead of the software that has to command a response to it.

Autonomous continuous planning, and decision support​

What we aim to build is an autonomous decision support system that really aids an operator: one that can move the sensors to where they are needed, a fleet that auto adjusts, and an agentic brain aiding the traditional AI and ML approaches.

Rules are still in there. They are necessary. They just cannot all be hardcoded, because the threat moves faster than anyone can maintain them. We wrote our own DSL for how policy and instructions are expressed, and I will cover it in a later post.

Three bets follow from this.

01 · Dynamic aerial sensor fusion​

Radar, RF, EO/IR and acoustic each see a different slice of the world, and they have to agree on one track. Most systems treat the sensors as fixed points on a map. Ours does not. When identity is uncertain, the system sends a flying sensor to go earn a better look. Fusion stops being passive.

02 · Dynamic, multi-purpose drone swarm​

One fleet you can task on demand. It defends, and it also watches, patrols, and scouts. Drones self-organize, reassign themselves mid-flight, and keep flying as links drop. Defence is the hard edge that forces the system to be fast and trustworthy. The everyday jobs are what make a fleet worth owning.

03 · Agentic and solver decision brains​

The solver carries the math, allocating assets under hard constraints of cost, coverage, and reach. The agent reasons around it: what changed, what matters now, what to re-solve, and briefs the trade-offs in plain language. Two kinds of intelligence in one loop, and a human approves the call.

Where this goes​

That is where DomeCommand starts. A solver, an agentic harness, a hackathon proposal, and a problem that turned out to be very real.

I am building it in the open, and writing up each piece as it comes together. If this is your kind of problem, follow along. Hello, world.

Inturai builds sensors that read the radio environment instead of looking at it, so they can pick up people and movement through a wall with no camera and no line of sight. That is a genuinely different way to sense a space, and it is useful well beyond defence: search and rescue, site monitoring, aged care. We have been building the other half of that loop, which is what to do once you know something is there.

Extending dynamic sensor fusion​

The part worth paying attention to is that these sensors can be carried. In late June Inturai said their sensors now talk directly to each other with no internet, and that they are testing one mounted on a drone. A sensor that needs no fixed install, no network, and no line of sight is a sensor you can fly. Coverage stops being a property of the building and becomes something you task: instead of wiring a village to see inside it, you fly a few drones over it and stitch what they heard into one picture. That is the bet DomeCommand was built on, from the first post here. Fusing sensors that hold still is largely solved. Fusing sensors that move is not, because each reading arrives with the platform's own motion in it, and two drones passing the same wall from different angles have to be resolved into one contact rather than two. That is the dynamic sensor fusion problem, now with a sensor that sees through the wall instead of down the street. Inturai senses what you cannot see, DomeCommand acts on it beyond line of sight, and the pilot the two teams are running closes that loop with a person approving each step. It is a letter of intent, a step and not a finish line, and I will share more as it firms up.

Let me start with the honest version of the problem, because most descriptions skip it.

The picture is usually bad​

"Sensor fusion" sounds like addition. You have radar, RF, electro-optical, infrared, acoustic. Add them up, get one clean track. If only.

In reality each sensor lies in its own way. Radar gives you a position but not a name. RF tells you something is transmitting but not exactly where. A camera confirms what a thing is, but only once it is pointed at it and close enough to see. Coverage has holes. The contacts you care about are often the ones sitting in a hole, or the ones two sensors disagree about.

So the failure mode of a naive system is not that it misses things. It is that it is confidently wrong. Every blip becomes a track with a threat level attached the instant it appears. The operator ends up staring at a screen full of certainty that the system has not earned. Fuse bad inputs faster and all you have done is reach a wrong answer sooner.

Three questions, not one​

The mistake underneath the bad picture is that it collapses three different questions into a single answer. When we started modelling this properly, the first move was to pull them apart. A fused entity is not one number. It is three separate channels, each answering its own question:

• Existence, "is it real?" A running score that goes up when a sensor corroborates the contact and down when it does not. It has a status you can read: tentative, confirmed, coasting, deleted. A single radar return is not a track. It is a suspicion that has to earn its way up.
• Identity, "what is it?" A belief spread across the possible classes rather than a hard label, with a measure of how uncertain that belief is. Radar alone leaves it near "unknown." An RF match narrows it toward a commercial quad. A close visual look collapses it to a specific model.
• Affiliation, "whose is it?" Friend, neutral, suspect, hostile, on a proper ladder, tagged with whether a machine inferred it or a human declared it.

Keeping these apart lets the console show something it never could before: the honest state of "we know something is there, but not what it is or whose it is." That is a real, common situation in this domain, and pretending otherwise is how you get a fabricated picture.

It also lets us hold one rule that matters more than any other:

Kinematics alone can never make something hostile.

A fast contact heading for a protected asset can reach suspect on its own. It cannot reach hostile without positive identification, a hostile RF signature, or a human making the call. Speed is not intent. Baking that into the type system, not the training material, is the point.

The part I actually care about: making it move​

Here is where the "dynamic" in the title comes in.

There is a well-worn idea in this field called cross-cueing, or slew-to-cue: one sensor's output tasks another. A radar hit slews an electro-optical camera to go look. It is production-proven and it works. But notice the quiet assumption. The camera is bolted to a mast. The cue can only ever point the sensors you already happen to have, wherever they already happen to be.

So the question I keep coming back to: what if the cue could task a sensor that flies?

When identity is uncertain and the contact is near something you care about, the system does not just sit there and average its confusion. It raises a request: this contact is ambiguous, the thing that would resolve it is a closer visual look, and here is the drone that can get there, with an estimated time to do it. The operator sees a plain-English recommendation. Unidentified contact 1.2 km from the site. Send a drone to identify? ETA 40 seconds. They approve. The drone repositions, gets eyes on, and a picture comes back that firms the identity from "unknown" to a named model, and the affiliation off "unknown" to a real call.

That is the whole thesis in one motion. A fixed sensor sees what it sees. A moving one can be sent to the gap in coverage, to the ambiguous contact, to the one angle you do not have. It turns fusion from "combine what you were given" into "go get a better look, then combine." Harder to build. Also, I think, where the real advantage is.

And it changes what certainty even means on the screen. Instead of a made-up "87% confident," a contact reads as its evidence: radar plus RF, two sensors, seen three seconds ago, identity still open. The operator instantly sees which modality is missing, and therefore what would fix it. The system is not hiding its ignorance. It is showing you the shortest path out of it.

What we are building​

We are building this in layers, and the foundation is in place: the three-channel model, the existence scoring, the identity belief and the affiliation ladder with the kinematics-never-hostile rule enforced. The association math that keeps two crossing targets from swapping identities. Sensor models honest enough that RF and acoustic come in as bearings without a magic position attached, so fusion has to triangulate the way it would anywhere else.

On top of that we are building the collection loop end to end: the recommendation, the human approval gate, the drone repositioning, and the look coming back to firm the picture. In the simulator the closer look is a range-degraded capture, blurry far out and sharpening as the drone nears, so we can build and exercise the whole loop deterministically. The architecture is shaped so that as we bring the loop onto real optics and real airframes, the machinery is already there to receive it.

That is the through-line of everything here: build the honest picture first, then build the loop that goes and improves it.

Why this is the first bet​

Fusion is where most of C2 quietly gives up and hardcodes its way to a confident guess. Making it honest about uncertainty is worth something on its own. Making it active, letting the picture task the fleet to go improve itself, is the part I think is genuinely new, and it only works because the same drones that defend can also go collect. Which is the second bet, and the subject of another post.

If a picture that argues with itself and then goes and settles the argument sounds like your kind of problem, follow along.

It is worth slowing down on what that word actually means, because the naive version of it is the source of most bad pictures. So here is sensor fusion explained the way I think about it, with a concrete example you can follow tick by tick.

The naive idea, and why it breaks​

The comfortable mental model is addition. Each sensor gives you a piece, you sum the pieces, and the total is the truth.

The problem is that the pieces are not the same kind of thing. Radar gives you a position and a velocity but has no idea what the object is. A camera can tell you it is a DJI quadrotor, but only once it is pointed at it and close enough to resolve it. RF tells you something is transmitting. Acoustic hears rotors. Each one answers a different question, at a different range, with a different error.

Sum them naively and you get the classic failure: a screen full of confident tracks the instant anything appears, each with a threat label it has not earned. The system looks decisive and is quietly guessing.

A concrete walkthrough​

Let me make it real. This is a scenario straight out of our simulator: one drone closing on a protected asset at 25 m/s from 400 m out, seen by four sensors that come online in the order they realistically would.

Radar picks it up first. Acoustic corroborates. Then RF. And only at the end, once it is close, does the camera get a good enough look to say what it is. Here is what the fused picture does, tick by tick:

One object stays one track the whole way through, no matter how many sensors see it. The identity resolves on that same track. It does not spawn a second one.

The one distinction that matters​

Read those five rows again and the whole idea falls out of them.

Existence and identity are two different questions, answered by two different kinds of evidence.

By t4 the system is very confident something is really there. Three independent sensors, three different physics, all agree on a real, closing object 350 m from the asset. The existence score has climbed past the confirmation threshold. And yet the class is still "unknown," because not one of those three sensors can say what it is. Radar, acoustic, and RF all abstain on identity. They are honest about it.

This is the part the naive "just add them up" model gets wrong. More corroboration buys you more existence. It does not buy you identity. You can stack ten radars and still not know whether you are looking at a quadrotor or a large bird. Identity only arrives at t5, when a sensor that can actually see gets close enough to resolve it.

So a good fusion engine tracks these as separate channels:

• Existence, is it real? Earned by corroboration, scored, and allowed to say "not sure yet."
• Identity, what is it? Earned only by a sensor that carries identity, and left honestly "unknown" until then.

Keeping them apart is what lets the console show the true state at t4: confirmed, corroborated, closing, and we still do not know what it is. That is a real situation, it happens constantly, and pretending otherwise is exactly how you end up with a fabricated picture.

Where this points next​

Sit with the t4 state for a second, because it is the interesting one. You have a confirmed object bearing down on something you care about, and no amount of more of the same sensing will identify it. Every fixed sensor that can see it already is.

That is precisely the moment the system should say: go look at it. Send something with a camera to close the range and earn the identity. Which is only possible if your sensors can move, and that is the idea I dig into in dynamic sensor fusion.

What we are building​

The picture above is not a mockup. It is generated from a test in our fusion engine that regenerates the numbers from the running code and fails if they drift, so the walkthrough cannot quietly disagree with what the system actually does. The existence channel and the cross-modality association that keeps one drone as one track are what we are building on right now.

From there we are building the identity belief that measures how unsure we are, the affiliation logic that decides friend from foe under strict rules, and the collection loop that turns a high-uncertainty contact into a tasked "go identify it" mission. Each piece is a post of its own as it comes together.

If a picture that is honest about what it does not yet know sounds more useful than one that is confidently wrong, that is the whole bet. Follow along.

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.

You cannot go and film that. Real saturation attacks are rare, expensive to stage, and impossible to repeat on demand, and the whole point of testing is repetition. This is the quiet problem at the center of building anything like DomeCommand: the data you most need is the data you can never collect. So you generate it instead.

We are putting a lot of time into the simulation engine for exactly this reason. It is where the synthetic data gets exercised in full, across combinations we could never stage: fleet laydowns against threat patterns, run and re-run until the failure modes show themselves.

Scenarios you can generate, not just author​

If you cannot get real fights, you have to be able to generate them, precisely and repeatably. A scenario in DomeCommand is three things bundled together:

• a theater: where it happens, over real satellite imagery,
• a laydown: the fleet, what you are defending with, and where your sensors and effectors sit,
• a threat package: what is coming, how many, of what type, from where, in what waves.

Both halves come out of catalogs, so scenarios combine rather than get hand-built one at a time. On the fleet side: sensor types and their coverage, effector tiers (long-range area defence, short-range gun and missile, point defence at the high-value assets), the number of defender posts and where they sit. On the threat side: airframe types, wave sizes, attack vectors, timing, and faults injected mid-fight. Pick from each and you have a scenario, which means the interesting space is a product of the catalogs and not a list somebody wrote down.

A few from the current library, to make it concrete:

And you can author a new one in plain language. You describe the fight the way you would say it out loud, "a saturation swarm of 60 FPV drones from the north-west, with a two-minute radar blackout halfway through", and the engine parses it into the same structured parameters the catalog scenarios use: threat type, count, attack vectors, defender posts, difficulty, duration, faults. You get to review and correct the parameters before it runs.

That plain-language front door matters more than it looks. It is the difference between a simulator only its authors can drive and one an operator can use to ask "what if it came from the other direction?" and get an answer in seconds.

Then you run it, and watch the whole engagement play out: the threat tally, the rules of engagement in force, the priority queue, the plans the system is proposing, and what each one is predicted to cost you.

Determinism is the whole game​

Here's the part I'd defend hardest. A simulator is only useful for learning from if it's deterministic: if the same setup plays out identically every single time.

We put real engineering into this. Every source of randomness in the sim funnels through one seam: a virtual clock, a seeded random-number generator per agent, and an event-logged command stream. The consequence is that a whole engagement becomes a pure function of the seed plus the ordered list of commands. Replay it and you get a byte-for-byte identical fight, even with reactive drones and even with an operator making live decisions in the middle, because those decisions get recorded as events too.

(If that sounds familiar, we borrowed the idea openly from deterministic-simulation testing in databases like TigerBeetle and FoundationDB. Funnel all nondeterminism through one place, and your entire system becomes reproducible.)

Why care so much? Because it turns the simulator into an instrument. Run a scenario, make one different decision partway through, run it again, and because nothing else could have changed, the difference in outcome is attributable to your decision and not to luck. That's the precondition for learning anything real from a simulation. Without it you're just watching fireworks.

Threats that behave, not dots that fly straight​

The first version of any sim has threats that follow scripted paths: fly from A to B, ignore everything. That's useless the moment your defense does something, because a real adversary reacts.

So the threats are little agents with intent. A kamikaze drone terminates on its target; a payload-drop runs in, drops, and egresses; a recon drone loiters and watches. Each one senses only what it could actually see: an attacker notices an interceptor when it comes into camera range, and can feel a GPS jammer by the way its satellite fix diverges from its inertial one. Then it reacts: press the attack, break evasively, dead-reckon through the jam zone.

None of this is hand-waved. The maneuvers are grounded in the real guidance literature: proportional navigation (how missiles have pursued targets for decades), Dubins paths (the tightest turn a fixed-wing can make), vector fields for orbiting. The goal is an adversary that's hard for honest reasons.

One detail I find clarifying: the simulator holds two versions of the world. There's ground truth, exactly where everything is and what it intends, which only the sim knows. And there's the deduced picture, noisy observations run through sensor fusion into tracks, which is all the operator is allowed to see. Same data structure, opposite provenance. The gap between them is the fog of war, and being able to measure that gap is a large part of why you simulate at all.

Learning from the history​

Every run leaves a record: the scenario, the picture the operator saw, the plans on offer, which one was approved, and what it cost. That history is a training set, and we are experimenting with two ways of using it.

The first is fine-tuning. Take the engagements that went well, and the human approvals and rejections attached to them, and tune a model on that trace so its next plan looks more like the ones that worked and less like the ones a person threw out. This is the cheaper, more direct path, and it learns the taste of an operator as much as the physics of the fight.

The second is reinforcement learning against the simulator itself. That is the more ambitious one, and it only works because of the determinism above: an episode you cannot reproduce is an episode you cannot learn from.

The AlphaZero-shaped bet​

Now the part I'm most excited about building toward: this is a direction we're heading, and the groundwork for it is what we've been putting in place.

Think about how AlphaZero learned Go. It wasn't fed human games. It was given the rules (a closed, deterministic world where every move has a defined outcome) and it played itself, millions of times, getting better by grinding against its own improving opponent. The rules never changed, so every game was a clean experiment, and self-play could squeeze signal out of it indefinitely.

Look back at what we just built. A deterministic environment with fixed rules. Threats and defenders that are agents taking actions and getting outcomes. A reproducible result for any given setup. That is exactly the shape a self-play system needs. The simulator isn't just a test harness. It's a candidate training environment.

The experiment we're circling: wrap the deterministic sim as a reinforcement-learning environment. A scenario becomes an episode. The action space is a plan, the same structured mission format the system already emits. The reward is the outcome the sim already scores: leakers stopped, cost spent, coordination quality, rules-of-engagement compliance, robustness to comms loss. Then let a planner learn against that reward the way AlphaZero learned against a win. The adversary gets harder over iterations in ways grounded in real simulated outcomes, not hand-tuned difficulty knobs, and a human stays in the loop on what gets promoted.

Here's how the work stacks: the deterministic engine, the behavior model, the plain-English scenarios, and the replay-and-compare loop are the foundation we've built. The self-play / RL layer is what we're building toward on top of it. I'm writing it down now because the interesting thing about the architecture is that it was designed to make that possible. You build the fixed-rule world first. What you do with it is the next chapter.

The scenario-authoring screenshots are from the DomeCommand console. The determinism approach draws on publicly documented deterministic-simulation testing (TigerBeetle's VOPR, FoundationDB); the threat maneuvers on standard guidance literature. Nothing here reflects a specific site or operator.

My first real flight-controller project was Udacity's Flying Car and Autonomous Flight Engineer Nanodegree. The course is four projects, and they are more or less the four things an autonomous aircraft has to do: fly a shape (backyard flyer), plan a route through a city (3D motion planning), control the vehicle along that route (build a controller), and work out where it is in the first place (estimation and sensor fusion). I wrote mine in Python and the code is still on GitHub. It is a basic implementation, which is exactly what makes it a good way to explain this.

Underneath, it comes down to two jobs. Know where you are. Decide what to do about it. Everything else is detail.

State estimation: where am I?​

You would think you could just read the sensors. You cannot, and the reason is worth sitting with.

A gyroscope measures how fast the drone is rotating. To get an actual angle you integrate that rate over time, and any small constant error in the measurement integrates too, piling up forever. Integrate the gyro alone and your sense of which way is up slowly rots, even sitting still on a desk. That is drift, and it is fatal.

An accelerometer feels gravity, which is an absolute, drift-free reference for which way is down. It also feels vibration and every movement the drone makes, so in the short term it is noisy and untrustworthy.

They fail in opposite directions: the gyro is smooth but drifts, the accelerometer is stable but noisy. So you fuse them, trusting the gyro moment to moment and letting the accelerometer pull the long-run drift back towards level. Add GPS and a magnetometer and you can do the same for position and heading, which is what the course's estimation project builds: an Extended Kalman Filter that holds a belief about the full state along with how uncertain it is, predicts that state forward with the physics on every tick, then corrects it against whatever measurements arrived, weighting each by how much it deserves to be trusted.

The cheap version is worth knowing too. A complementary filter does a smaller version of the job with almost no machinery: trust the gyro at high frequency, the accelerometer at low frequency, blend. It gives you attitude and not much more, and for "just stay level" that is plenty. The Crazyflie I later kept on my desk ships with both, and choosing between them is a neat summary of the trade: complementary filter to hold it level, EKF the moment you want it to know where it is in a room.

Whichever filter you run, the output is the same: one clean belief about position, velocity and attitude. That belief is the only thing the next job gets to see.

The control loop: what do I do about it?​

The controller's question is narrower. Given where I am, and where I am supposed to be, what should the motors do?

The trick is that you never answer "be at that point in space" in one shot. You build a cascade: a stack of small controllers, each turning a goal into a goal for the next one down. My implementation is five functions, and reading them in order is the whole idea.

• lateral_position_control turns the horizontal position error into a desired acceleration.
• altitude_control does the vertical half, turning altitude error into a thrust, accounting for the tilt of the craft (a tilted drone spends part of its thrust sideways).
• roll_pitch_controller turns that desired acceleration into a desired attitude. To accelerate forward, tilt forward. A quadcopter has no other way to move.
• body_rate_control turns the desired attitude into the moments the motors have to produce. This is the innermost loop, fed straight from the gyro.
• yaw_control handles heading on its own, since where the craft points is decoupled from where it is going.

Two things make the cascade work. The first is that each loop is little more than a gain on an error, which keeps tuning tractable: in my controller the inner rate loops are stiff (Kp_p = Kp_q = 20) and the outer position loop is soft (Kp_pos = 6). The inner loop has to be fast, because rotational dynamics are twitchy and a quadcopter that loses its attitude flips. The outer loop can afford to be slow, because moving through space is comparatively sluggish. Fast and reflexive on the inside, slow and strategic on the outside.

The second is saturation. Every command is clamped before it leaves: a maximum tilt, a maximum ascent and descent rate, a maximum speed. Without those, the position loop cheerfully asks for a ninety-degree bank and the drone falls out of the sky doing exactly what it was told.

Production firmware is this, tuned harder. The Crazyflie runs the same cascade with a PID at each stage, the inner rate loop at 500 Hz and the outer position loop at 100 Hz, and there are fancier controllers again (Mellinger's geometric controller, INDI) once you want aggressive flight. The shape does not change.

Why I am telling you this​

Squint at the two jobs and you get: sense, estimate, decide, act, and then do it again, forever. That is the shape DomeCommand runs, one level up. Where the quadcopter fuses a gyro and an accelerometer into which way is up, DomeCommand fuses radar and RF and cameras into what is out there. Where the cascade turns a setpoint into motor commands, the planner turns a commander's intent into tasks for a fleet.

The instinct that a hard autonomy problem is really a clean estimation problem stacked on a clean control problem came from a course assignment and a small quadcopter I could not stop tinkering with. It scales further than I expected.

The two diagrams above are from Bitcraze's open crazyflie-firmware documentation, a genuinely good place to learn this hands-on.