Drone software

The stack is a hierarchy of deadlines

It is tempting to read the onboard software as layers of abstraction, the way a web application is read. It is more useful to read it as layers of how long each part may take. The flight controller runs a control loop at hundreds of hertz and has a hard deadline: miss it and the aircraft becomes unstable within a fraction of a second. Everything above it has progressively more slack, and the amount of slack decides what may live there.

• Flight controller

  Attitude and rate control on a real-time loop, reading the inertial sensors and driving the motors. Small, deterministic, no dynamic allocation, no network calls — and almost never where a new feature belongs.

• Autopilot

  Turns intent into setpoints: navigation, flight modes, mission sequencing, the state estimator that fuses inertial data with position sources. Slower loop, still safety-critical.

• Companion computer

  A normal computer running normal software: perception, planning, video, communications. It may be late and it may crash, and neither must reach the tiers below it.

The failsafe ladder is the specification

A mission plan describes what should happen. The failsafe configuration describes what will happen, and it is the part that decides whether a vehicle is flyable. Each entry answers one question — this condition has occurred, what now — and every answer is a trade with no free option.

Two properties of that table are worth extracting. First, every behaviour has to be enforced at the lowest tier that can enforce it — a boundary implemented in the ground station is a suggestion, because the ground station is exactly what disappears. Second, the failsafes interact, and the interactions are where the surprises live: link lost plus low battery plus a headwind is a different situation from any of the three alone, and a configuration that handles each individually can still produce an aircraft that flies confidently away from home.

Autonomy is a set of specific decisions, not a level

Autonomy is usually discussed as a scale from remote control to full independence, which is a useful summary and a poor engineering tool. The question a design actually has to answer is narrower and repeats for every capability: which decisions does this vehicle make alone, on what evidence, within what limits, and which ones does it hold and ask for. Answering that list is the design; the level is a label you can apply afterwards.

The right-hand column has a design consequence people miss: holding a decision requires the vehicle to be able to wait safely. A system that must ask a person but cannot loiter, cannot store the request, and cannot behave sensibly if no answer comes has not implemented the requirement — it has written it down. Waiting is a capability with its own energy budget, its own timeout behaviour and its own failsafe.

Simulation is the test environment, not a convenience

Every failure case that matters here is one you cannot reasonably produce on a real aircraft: losing the position fix at two hundred metres, a motor stopping in a turn, the link going at the far end of the route, a battery reporting a wrong value. Flying those tests is expensive, dangerous and slow, and the ones you survive you cannot repeat identically. So the primary test environment is a simulator, and the maturity of the simulation setup is a good proxy for the maturity of the team.

• Software in the loop: the real autopilot firmware runs on a workstation against a simulated airframe and simulated sensors. Fast enough to run on every commit, which is what makes it a regression suite rather than an experiment.
• Hardware in the loop: the real flight controller board runs the real firmware, wired to a simulator instead of to motors. This is where timing problems and driver bugs appear, and they are invisible to the previous tier.
• Fault injection as first-class test cases: cut the link, freeze a sensor, drift the clock, drop the battery reading, stall a motor. Each is a scripted case in the suite, not a manual experiment somebody ran once.
• Replay from real flights: every flight produces a log, and the log is a test input. A bug seen once in the air becomes a case that runs forever, which is the same rule as any regression suite.

Anti-patterns worth naming

• Putting new logic in the flight controller because it is "closer to the hardware", which trades the one deterministic component for a feature.
• Giving the companion computer authority instead of a request channel, so a crash in perception becomes a crash of the aircraft.
• Enforcing a boundary in the ground station, which is the component guaranteed to be absent when it matters.
• Testing only the mission and never the failsafes, so the first real link loss is the first execution of that code path.
• Treating the flight log as an artefact for incident review only, rather than as the input to a permanent test case.

When to use it

Related pages

• DeftechOverviewDefence technology software is ordinary engineering under four constraints the rest of this site assumes away: there is no reliable network, the attacker is funded and patient, a wrong output costs far more than a bad quarter, and the user is not at a desk with time to learn. Almost everything else on this site assumes the opposite of all four. Remove them and the engineering does not become exotic — it becomes strict. This page names the four constraints, shows what each one replaces, and covers the parts of the working environment that surprise people arriving from product engineering.
• DeftechComputer visionComputer vision is the practice of turning camera images into decisions a machine can act on, and the model is rarely the hard part of it. What makes vision hard here is that it runs on a device with a power budget and no network, on images that do not look like the ones it was trained on, and that its output feeds a decision where the two kinds of error are paid for by different people. This page covers the edge budget, the data problem that no amount of training fixes, the threshold as a policy decision, and what has to be recorded so a wrong answer can be investigated at all.
• DeftechC2 systemsA command and control (C2) system is software that turns reports from many sources into one shared picture people can act on, and it is usually pictured as a map. It is better understood as a correlation engine with a map attached: reports arrive from sources that disagree, arrive late, use different schemas and frequently describe the same object twice, and the system’s central job is deciding whether two reports are one thing or two. This page covers that decision, why time and confidence have to be fields rather than assumptions, what happens when two nodes lose contact, and why the interface is where the engineering ends up.