Failure Analysis — What Drone Teams Can Learn from Space Programs

Failure analysis was one of the most instructive parts of working in a space programme. When something misbehaves on a launch vehicle, the response is never a shrug. Every anomaly is investigated to its root, documented, and fed back into design and process. The organisation learns, permanently, and the next vehicle is built by people who know what the last one did.

What drone teams do instead

A drone crashes. The team recovers what it can, orders a new airframe, and flies again next week. The pilot has a theory, usually interference, and the theory is never tested because the evidence went into the bin with the airframe.

The cost of that shrug is invisible until the same failure takes out the next aircraft, or the one after that, in front of a customer. Then it is a programme problem, and the programme has no record to learn from.

How a space programme does it

Three habits, none of them expensive.

Every anomaly gets a ticket, including the ones that resolved themselves. A sensor that glitched and recovered is a data point, not a non-event.

Every ticket gets a root cause, or an explicit “could not determine” with the evidence attached. “Probably the GPS” is not a root cause.

Every root cause changes something: a design, a procedure, a check in the pre-flight list, a threshold in the monitoring. The loop is closed in writing.

The failure-mode database

The habit worth stealing first is the catalogue. Every incident gets a signature: what the telemetry looked like in the minutes before, what failed, what the root cause was, what was changed. Over time that becomes a failure-mode database, and the fleet starts learning collectively instead of one pilot at a time.

It does not need to be large to be useful. Twenty entries cover most of what a small fleet will see: the ESC desync at high throttle, the compass that lost its calibration after a payload change, the link that drops when the aircraft turns its antenna away from the mast, the pack that sags at take-off on cold mornings.

Parameter change history: every change to an aircraft, with time, old and new value and who made it.

From post-mortem to pre-mortem

Once failure signatures exist, they become detection rules. Live telemetry and every landed log can be matched against the known precursors: vibration trending up on one arm, current per rpm creeping away from the other motors, estimator variance rising, link quality decaying, cell spread widening. Flagged before the flight that fails, not explained after it.

This is what the health digital twin in AutrikOS does with the logs that Skyclient records and uploads from every flight. Each log is reduced to per-component figures, judged nightly against the component’s own history and the limits the autopilot’s maker publishes, and the warnings that result stay open until someone resolves them, with the flight replayable from the warning. The failure-mode database is no longer a spreadsheet; it is the set of rules the fleet is judged by. The details are on the Fleet Health page.

Where to start

Log everything from day one: telemetry, events, parameter changes, maintenance actions. The console keeps the parameter change history of every aircraft, who changed what and when, because the change nobody remembers is the root cause nobody finds.

Write down every anomaly, even the ones that went away. Give each one a number. Read the list before each campaign.

The database is cheap to keep and expensive to reconstruct, and the first time it tells you that today’s odd reading is last year’s crash, it has paid for itself.

More on the mindset in From Rocket Science to Drone Tech. Building a reliability culture around your fleet? Talk to us.