Top 5 ArduPilot Crash Causes (Ranked Against What Logs Actually Show)

TL;DR: Across the publicly searchable ArduPilot Discourse incident threads and ArduPilot's own failsafe taxonomy, five failure classes account for the bulk of avoidable crashes: battery-induced power loss, GPS-driven position errors, EKF and compass failsafe chains, configuration and parameter errors, and mechanical failures (ESC desync, motor mounts, propellers). Each leaves a distinct signature in the dataflash log and each has a different prevention recipe. This post walks through them with the exact ERR Subsys values, log fields, and the parameters that most often need a second look.

Methodology — how this list was built

This is not an opinion ranking. We surveyed:

• The publicly searchable ArduPilot Discourse incident threads from the last two years — the threads where the reporting pilot shared a .bin log and the community converged on a root cause.
• ArduPilot's own Crash Check documentation, which describes the firmware-side detectors that the autopilot itself trusts.
• Cross-references against the failsafe parameter set in ArduCopter 4.6 and the LogErrorSubsystem enum in libraries/AP_Logger/AP_Logger.h.

This is an evidence-shaped ranking. Where we can, we link to a representative Discourse thread or the ArduPilot wiki page so you can read the original material. The order is not a leaderboard — any of these five can be the cause that ends a flight.

Cause 1 — Battery failsafe and brown-out

Underrated and the most preventable. Two sub-cases:

• Voltage sag below failsafe threshold. Logs show BAT.Volt dropping below BATT_LOW_VOLT for the duration BATT_LOW_TIMER, followed by ERR Subsys=6 ECode=1 (battery failsafe occurred) and a MODE change to RTL or LAND with Rsn=4.
• Power module brown-out. The log ends abruptly mid-flight while BARO.Alt still indicates altitude. The flight controller lost rail voltage. Look at POWR.Vcc — dips below 4.7 V are usually the trigger.

Prevention: Set BATT_LOW_VOLT to the chemistry-appropriate cutoff (3.5 V per cell is conservative for LiPo), enable BATT_CRT_VOLT as the harder failsafe, and verify a healthy BATT_LOW_TIMER (default 10 s). For brown-outs, use a power module rated above the FC's draw plus servo rail plus video, and re-test under sustained current load before flying. BATT_FS_LOW_ACT = 2 triggers RTL; = 3 triggers SmartRTL.

Cause 2 — GPS-driven position error

The largest failure family on Discourse. ArduPilot logs the moment a GPS glitch is detected as ERR Subsys=11 ECode=2, but the downstream effects vary by mode — in Loiter you get position drift; in Auto the mission planner can chase a phantom position; in RTL the drone can fly off in the wrong direction.

Look for: GPS.NSats dropping below 8, GPS.HDop climbing above 2, GPS.Status demoting from 3 (3D fix) to 2 (2D fix) or worse.

Prevention: Multi-constellation (GPS_GNSS_MODE = 65), elevated antenna mast, dual-GPS with GPS_AUTO_SWITCH = 1, and an arming gate that doesn't allow takeoff under HDop > 1.2 (GPS_HDOP_GOOD). For the full receiver-side analysis, see our GPS glitch deep-dive.

Cause 3 — EKF and compass failsafe

The EKF (Extended Kalman Filter) is the navigation brain. When it loses confidence, it triggers ERR Subsys=16 ECode=2 (EKFCHECK bad variance) and, if persistent, Subsys=17 ECode=1 (EKF failsafe), which forces the vehicle into Land or AltHold. The cause is rarely the EKF itself — it's almost always one of:

• Magnetometer interference. Heavy current peaks from a payload or ESC routing too close to the compass bias the heading. COMPASSMOT calibration helps, but physical separation is the durable fix.
• Vibration corrupting the IMU. VIBE.VibeX/Y/Z above 30 m/s² for sustained windows. The EKF can't integrate accelerometer data correctly when the noise floor is that high.
• Persistent GPS disagreement. See Cause 2.

Prevention: Read our EKF innovation post for the diagnostic chain, our VIBE message guide for the vibration side, and ArduPilot's advanced compass setup for the magnetometer side.

Cause 4 — Configuration and parameter errors

The cause with the widest blast radius and the hardest to detect after the fact, because the log records what the firmware did with the parameters you gave it, not the parameters you should have given it. The most common variants:

• Wrong FRAME_CLASS or FRAME_TYPE. Tells the firmware "you're a Quad X" when you're actually a Quad +; motor mixing is reversed; aircraft flips on takeoff. Pair with our takeoff-flip post.
• Untuned PIDs. Default rate gains on a heavy or stiff airframe cause oscillations that progress until the EKF gives up. RATE.RPOut vs RATE.R diverging is the signature.
• Failsafe not configured. FS_THR_ENABLE = 0 means the autopilot does nothing when the receiver drops out. BATT_FS_LOW_ACT = 0 means voltage failsafe is logged but not acted on.
• Wrong sensor source. EK3_SRC1_POSXY = 0 means no horizontal position source; the EKF will refuse to enter autonomous modes. Easy to misconfigure when migrating from EKF2 to EKF3.

Prevention: Run the Methodic Configurator workflow on every new airframe. Do not skip the bench arming/disarming dry run. Always export your parameter list to a file and check it into version control so a bad change is traceable to a date and a reason.

Cause 5 — Mechanical failures

ESCs that desync at high throttle, motor mounts that vibrate loose, propellers that delaminate or strike obstacles. The autopilot can detect some of these:

• ESC desync on Copter — ERR Subsys=25 ECode=2 (THRUST_LOSS_CHECK). RCOU.Cn drops to minimum while attitude rate begins to spin uncontrollably about one axis.
• Motor not responding — RCOU.Cn at maximum while the airframe rolls toward that corner. The autopilot is commanding more thrust from a motor that's already saturated.
• Prop strike — sudden VIBE spike, attitude rate disturbance, and on Copter a possible Subsys=12 ECode=2 (CRASH_CHECK_LOSS_OF_CONTROL) once the airframe departs.

Prevention: Hover-stand test new builds before flight; calibrate ESC range with the ESC-calibration sequence in Mission Planner; balance props (a basic prop balancer pays for itself the first time); inspect motor mounts after every hard landing.

What didn't make the top 5 (and why)

Three causes that are real but less common than people assume:

• Firmware bugs. They exist (the Internal Error reporting page tracks them), but they're a small fraction of Discourse incident threads and are usually caught in beta cycles.
• RC range loss. Modern receivers (ELRS, CRSF) have failsafe behaviour that hands off cleanly to the autopilot when configured. Outdated PWM receivers are still around, but when they cause a crash the root cause is "failsafe wasn't configured", which falls under Cause 4.
• Weather. Wind beyond the airframe's authority shows up as Cause 3 (EKF disagreement from sensor noise) or Cause 4 (untuned PIDs unable to handle the disturbance). Categorising weather separately doesn't usually change the fix.

A pre-flight checklist anchored to these five causes

1. Battery: confirm BATT_LOW_VOLT, BATT_CRT_VOLT, and BATT_FS_LOW_ACT match the chemistry and operation. Cycle the battery on a load and watch the sag, then set thresholds for the worst case.
2. GPS: wait for NSats ≥ 12 and HDop < 1.2 before arming. If you have dual-GPS, both must reach those thresholds.
3. EKF and compass: arm, then read the XKF4.SP trace from the first 30 seconds of hover. SP should sit below 0.3. If it doesn't, do not start a mission.
4. Configuration: diff today's parameter file against the last known-good. Any change touching FS_*, EK3_*, SERVO*_FUNCTION, FRAME_*, or BATT_* needs an explicit reason and a bench arm test.
5. Mechanical: hand-spin every motor with the prop attached, listen for bearing noise; confirm prop balance on the balancer; check motor mount screw torque; visual prop inspection for chips and delamination.

How LogHat helps for each cause

Drop the .bin into LogHat and the Root Cause Hypotheses section ranks the five families above against your log's actual event timeline, with the specific ERR Subsys/ECode values that triggered each hypothesis. The 3D replay lets you scrub to the failure moment and watch sensor readings cascade. Where the cause is in the parameter set, we surface the relevant ARMING_CHECK, FS_*, EK3_*, BATT_*, and SERVO*_FUNCTION values directly in the report.

Where we can't help: anything that requires you to know the physical airframe state. The log can't tell us whether the motor mount was finger-tight or whether the prop was nicked — those belong in your post-flight inspection notes.