RotorLab logo RotorLabDocs

Crash Analyzer

The Crash Analyzer at https://rotorlab.app/crash is RotorLab's post-incident forensics tool. Upload a flight log and it reconstructs what happened: it finds the crash, builds the event timeline, reads the seconds leading up to the event, and rules common causes in or out in plain language. Reach for it after a crash, a hard landing, or any flight that ended in a way you cannot explain.

It accepts the same formats as the Log Analyzer — ArduPilot dataflash (.bin), MAVLink telemetry (.tlog), PX4 ULog (.ulg), DJI flight records (.txt), Parrot FreeFlight and GUTMA JSON, and Litchi/Airdata/DJI GO CSV — up to 64 MB, with the format detected from the file's bytes rather than its name. Multirotor, plane and rover logs are all supported.

What you need#

The Crash Analyzer requires an account, and your plan must include it. It is available as an add-on with a one-time, monthly, or annual purchase, or on a plan that includes it. If it is not enabled on your account, the page shows a Crash Analyzer not enabled notice with a Go to add-ons button that takes you to the Add-ons section of My account. With the add-on enabled there is no daily limit on analyses.

Running an analysis#

  1. Open https://rotorlab.app/crash.
  2. Drop a .bin, .tlog, .ulg, DJI .txt, .json or .csv file onto the upload area, or click to browse.
  3. If Fleet Manager is on and you have aircraft registered, a File this flight to selector appears. Pick an aircraft to file the flight to its record, or leave it on "nothing - just analyze it".
  4. Press Analyze log.

Analysis runs within your account; nothing is shared.

The verdict#

The result opens with a verdict card. When a crash is found it reads "Crash detected at T+..." with the time into the flight, the reason, and a detector confidence of high, medium or low. The detector works down a priority chain:

  1. The autopilot's own crash check (an ArduPilot CRASH_CHECK error, or a disarm by the crash detector). Confidence: high.
  2. On fixed wings, the autopilot's crash or hard-landing status message, because ArduPlane announces a crash as text rather than an error record. Confidence: high.
  3. A thrust-loss or vibration failsafe firing. Confidence: medium.
  4. An attitude departure heuristic: the aircraft holding a large tracking error against its commanded attitude while armed and airborne. When the log carries no attitude target, only a near-inverted absolute attitude counts, and confidence drops to low.

When nothing matches, the verdict says "No crash signature detected" and shows the full-flight overview instead, because a clean log is a result too.

What the data says#

Below the verdict, a metrics grid shows the preconditions in the seconds before the event: altitude at departure, descent rate, horizontal speed, throttle against hover throttle, minimum airspeed on fixed wings, peak roll and pitch, battery voltage and its minimum, peak vibration, and whether the motor mixer saturated.

The findings under What the data says rule specific failure signatures in or out:

  • Mixer saturation: at least one motor pinned at the idle floor right before departure, meaning the controller had no authority left.
  • Thrust loss: a motor output pinned at full throttle, the classic signature of a failed motor or ESC, or a lost prop on the opposing arm.
  • Vortex ring / settling with power: a near-vertical descent with almost no horizontal speed.
  • Low control authority: throttle well below hover, so the motors were near idle.
  • Stall on fixed wings: airspeed below the configured minimum, or a finding that the wing stayed clear of it.
  • Battery: either a sag under load that may have starved the motors, or an explicit "NOT a battery/brownout event" when the pack held steady.
  • No brownout: the flight controller kept logging past the event, so the board did not reset.
  • Vibration ruled out when measured vibration stayed low up to the departure.

Deeper diagnostics#

A second set of sections reads pilot input, battery internal resistance, estimator innovation ratios, compass interference, GPS quality, accelerometer clipping, ESC and motor telemetry, the IMU cross-check, airspeed, configuration changes since the last flight on that aircraft, weather at the time, and auxiliary sensors (rangefinder, optical flow, terrain data, board power, harmonic notch).

Every section states whether this log could support it. A section the log cannot support is listed under Not available in this log with the reason, so "no magnetometer in this log" never looks the same as "the compass was fine". Weather figures are shown separately from the log-derived measurements, with the observing station named, because density altitude is looked up afterwards rather than recorded by the aircraft.

Vehicle-specific rules#

The vehicle type is resolved from the log first, and the analysis adapts to it. Mode names are decoded per vehicle, because the same mode number means different things on a copter, a plane and a rover. Hover-throttle and mixer-idle checks apply only to aircraft that hover. Attitude-departure limits are loosened for planes, which legitimately bank hard, and skipped for ground vehicles. A VTOL quadplane's telemetry log is judged as a plane, and hover-phase checks are not applied to it, because the plane throttle in the log is not its hover throttle.

Filing to an aircraft#

If you selected an aircraft, the flight is filed to that aircraft's record and the result shows the flight number with a link to the aircraft's health page. The log file itself is kept with the flight, exactly as one filed by a ground station would be. A crash verdict on a filed flight can also raise a work order and send a notification. Filing requires the aircraft to be covered by Fleet Manager on your account.

Downloading the report#

Two downloads sit under the results:

  • Download report (HTML) produces a single self-contained file with the verdict, findings, key metrics, charts and the full event timeline. It has no external assets, so it opens from disk years later, and it is print-ready.
  • Download PDF produces the same analysis as a document, which is the form you attach to an insurance claim or hand to an investigator.

Warning

Detection is heuristic and windowed around the detected event. Always confirm the findings against the raw log before acting on them.