flightdx

Deterministic ArduPilot flight-log anomaly detection. Layer 1 of the AI Log Analyzer portfolio project — see AI-LOG-ANALYZER-SPEC.md (in Rahul website/plans/) for the full 5-layer plan (this repo is Layer 1; RAG, agent orchestration, and eval land in later layers, likely as additions to this same repo).

Data policy: no operational/employer flight logs in this repo, ever. Use public ArduPilot sample logs or your own personal (non-defense) test flights only. See AI-LOG-ANALYZER-SPEC.md and FOCUS.md for why.

Why the LLM never sees the raw log

flightdx parses a .bin/.log dataflash file into a normalized ParsedLog, then runs pure-function detectors over it to produce a compact IncidentTimeline. That timeline — not the raw log — is what later layers hand to an LLM. Reasons: token cost, hallucination risk, and having a ground-truth layer that's independent of the model so the model can be measured against it in Layer 4.

Setup

python -m venv .venv
.venv\Scripts\activate
pip install -e .[dev]

Run

flightdx path\to\log.bin

Test

pytest

Detector tests use synthetic fixtures (plain dicts), not real log files — see tests/test_detectors.py. Real-log validation against the "10 real logs" done-when criteria in the spec is a separate, later step.

Layout

• src/flightdx/schema.py — Evidence / Incident / IncidentTimeline / ParsedLog. This is the stable contract every later layer builds on.
• src/flightdx/parsers/dataflash.py — pymavlink-based .bin parser → ParsedLog. ULog (.ulg, via pyulog) parser lands here too once dataflash is validated on real logs.
• src/flightdx/detectors/ — one pure function per failure mode, each unit-tested. Currently: vibration.py (VIBE + accel clipping), errors.py (ERR/EV decoding). Still to add: EKF innovations, GPS glitches, power/battery, motor asymmetry (RCOU saturation), attitude divergence, mode-change timeline.
• src/flightdx/cli.py — flightdx log.bin prints the incident timeline.

Known gaps (own these before calling Layer 1 done)

• Thresholds in vibration.py are placeholders — starting points from general ArduPilot guidance, not verified against current docs or tuned from field data. Fix before the Layer-4 eval numbers mean anything.
• SUBSYS_NAMES in errors.py is incomplete and may be stale — cross-check against the firmware version actually producing your test logs.
• No real logs tested yet. Next step: either source personal (non-defense) ArduPilot logs, or generate them via SITL (reproducible, and lets you construct known-failure scenarios on purpose — useful for the Layer-4 labeled eval set later, not just Layer 1).
• Detectors so far: vibration + errors only. EKF/GPS/power/motors/attitude/mode-timeline are in the spec but not yet built.