A drone comes back from a job with a cracked arm and a pilot who says it "just fell out of the sky." Without a flight log, that sentence is the entire investigation. With one, an engineer can usually name the failure inside an hour: motor 3 saturated its output while the others stayed level, the pack sagged below the cutoff under a gust, or the estimator lost GPS lock and the aircraft drifted until the pilot fought it. The log is the difference between guessing and knowing, and on a commercial program it is the difference between a fix and a recall.

What a flight log actually records

Modern autopilot firmware writes a binary log to onboard flash or a microSD card every time the vehicle arms. PX4 writes .ulg files, ArduPilot writes dataflash .bin files, and small FPV builds running Betaflight write a blackbox stream — the formats differ but the content overlaps heavily. A typical log contains:

  • Raw IMU data: accelerometer and gyro on all axes, often at 200 Hz to 1 kHz
  • Attitude estimate and setpoint, so you can see commanded versus achieved
  • Individual motor outputs and ESC telemetry (RPM, current, temperature) where the ESCs support it
  • Battery voltage, current draw, and consumed capacity
  • GPS fix type, satellite count, HDOP, and position
  • Barometer, magnetometer, rangefinder, and any optical flow sensor
  • Mode changes, arming events, failsafe triggers, and every parameter value at boot

That last item matters more than people expect. Half of "the drone behaved strangely" reports resolve into a parameter someone changed and forgot. The log carries the full parameter set, so you can diff the aircraft's configuration against your released baseline. Which firmware stack you standardize on shapes all of this, which is why the choice between PX4 and ArduPilot is worth making deliberately rather than inheriting from whatever the first prototype used.

Onboard log versus telemetry downlink

Two different streams get confused constantly. The telemetry downlink is a low-rate summary sent to the ground station over a radio link — position, battery, mode, a few health flags, maybe 1 to 10 Hz. It exists so a human can supervise the flight. The onboard log is high-rate, complete, and never leaves the aircraft until you pull the card.

You need both, and you need to design for the case where the aircraft does not come back. If the drone lands in a lake or burns, the card is gone. Programs that fly over water, over long distances, or in fire environments usually add a low-rate summary log that streams to the cloud during flight so at least the last known state survives. That is the same architecture used for remote diagnostics on any deployed device: a full local record plus a compressed heartbeat you can afford to transmit.

Reading a log after a failure

The workflow is more disciplined than opening a plotter and scrolling. A repeatable order that works:

  1. Confirm the timeline. Find arm, takeoff, the anomaly, and touchdown. Everything gets referenced to that anomaly timestamp.
  2. Check power first. Plot pack voltage against current. A sag that crosses the ESC undervoltage threshold explains a surprising share of sudden descents, and it points at pack sizing and cell health rather than the airframe.
  3. Compare motor outputs. In level hover all outputs should sit in a tight band. One motor pinned high while its diagonal opposite sits low means lost thrust on that arm — a prop, a bearing, a bent shaft, or a desync.
  4. Compare setpoint to actual attitude. Persistent lag or oscillation is a tuning problem, and log traces are the raw material for PID tuning work.
  5. Check the estimator. GPS fix drops, magnetometer disturbance near steel structures, and barometer jumps from prop wash all show up as innovation spikes before the aircraft misbehaves.
  6. Check vibration. High-frequency energy on the accelerometers corrupts the estimator and mimics almost every other fault.

Sizing the logging subsystem

Logging is a design decision with real cost. Full-rate logs on a mid-size multirotor run roughly 1 to 5 MB per minute depending on how many topics you enable; a 30-minute mission at high rate can approach 150 MB. A 32 GB industrial-grade card holds a season of flights, but consumer cards fail under vibration and heat, and a corrupted card discovered after a crash is worse than no card. Specify an industrial SLC or pSLC card, verify write performance at temperature, and make log integrity part of preflight. The flight controller you pick sets the ceiling on log rate and buffer size, so read those specs during flight controller selection rather than after.

Logs during development, not just after crashes

The teams that get real value from logging use it during structured testing, not only forensics. Every run in a flight test plan should produce a labeled log with the configuration, payload, wind, and temperature recorded alongside it. That archive becomes your regression baseline: when a firmware change makes the aircraft feel different, you compare traces instead of arguing about feel. Endurance claims, hover current, and thrust margin all come out of the same files.

Fleet scale changes the problem

One aircraft means a card reader. Fifty aircraft means an ingestion pipeline. At fleet scale you want automatic upload after landing, automatic parsing into flight summaries, and alert rules that flag anomalies nobody looked for — a motor whose average output has crept 8% above its peers over 40 flights, or a pack whose sag is deepening. That predictive-maintenance layer normally lives inside fleet management software, and it is what turns logging from an after-the-fact tool into a way to ground an aircraft before it fails.

One caution: logs contain flight paths, and flight paths can be sensitive to a customer. Decide up front who owns the data, how long you retain it, and what gets shared with an insurer or an investigator after an incident. Write that into the customer agreement rather than improvising it during a bad week.

Projects House designs drone platforms with logging, diagnostics, and fault analysis built in from the first airframe rather than bolted on after the first crash. If you are developing an aircraft and want the instrumentation right the first time, tell us about the program through our contact form.