A preflight log check a drone hobbyist can run on their own laptop

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Drone Flight-Log Explainer reads an ArduCopter / Pixhawk .BIN flight log and turns it into a plain-English preflight report.

The person who would pay is a hobbyist who just had a rough flight and does not want to learn a log browser before they fly again. They want a yes-or-no on four things: did the battery sag, did the airframe vibrate hard enough to clip the sensors, did GPS lose a 3D fix, and did the autopilot throw a failsafe. A small repair bench or a club instructor would pay for the same check, so a pilot shows up with a written list instead of a raw file.

The report covers battery voltage, current, and drain; vibration and accelerometer clipping; satellite count and HDOP; autopilot messages, error codes, and mode changes; then a short "inspect before the next flight" list. Every number comes from the log. The wording is not allowed to invent a voltage, a time, or a cause.

A club could charge a few dollars per log, or a shop could include the report with a pack test. The check itself runs locally, so the cost of one report is not an API bill.

Demo

Run it from the project folder:

pip install -r requirements.txt
uvicorn app.main:app --reload

Open http://localhost:8000 and click Try demo flight. That flight is synthetic and already contains a battery sag, a vibration spike, a GPS fix loss, and a battery failsafe that ends in RTL. Uploading a real .BIN uses the same pipeline. No account and no API key are required.

Code

AyushyaRanjan / drone-log-explainer

Drone Flight-Log Explainer

A small web app for hobbyist ArduCopter / Pixhawk pilots. Upload a dataflash .BIN log, or run a built-in demo flight, and get a plain-English diagnostic report covering battery, vibration, GPS, and autopilot warnings.

The analyzer produces every number in the report. The language model only explains those findings. If ANTHROPIC_API_KEY is missing or the call fails, a template writes the same sections so the app still works offline.

Architecture

browser (index.html + Chart.js)
    |  POST /api/analyze  or  POST /api/demo
    v
FastAPI (app/main.py)
    |-- parser.py      pymavlink DF reader -> pandas DataFrame per message
    |-- analyzers/     battery, vibration, GPS, warnings, summary
    |-- report.py      verdict, checklist, downsampled timeseries
    |-- explainer.py   Claude, or the template fallback
    v
in-memory report store, plus JSON under data/reports/

No database. Reports are kept in process memory and written as JSON when the disk is writable.

Run it

pip install -r requirements.txt
uvicorn app.main:app --reload

…

View on GitHub

The app is a small Python service:

• app/parser.py reads the dataflash log with pymavlink and builds one pandas table per message type.
• app/analyzers/ applies fixed thresholds for battery, vibration, GPS, and warnings.
• app/explainer.py writes the English report from those findings. If ANTHROPIC_API_KEY is unset, a template does it.
• app/static/index.html draws the charts with Chart.js.

pytest -q covers the demo anomalies, a clean flight, a missing message type, a hand-built .BIN, and the HTTP routes.

How I Built It

The part that makes the product work is open and local. pymavlink decodes the .BIN. pandas and numpy compute the sag fit, the vibration runs, and the GPS fractions. FastAPI serves one static page. Those libraries are what turn a flight log into findings. A closed chat API cannot read a dataflash file, and it should not be the thing deciding that a cell hit 3.28 V.

The English layer is a template filled from the analyzer JSON, so the app works with no model and no key. An optional Claude call can rephrase that same JSON. It receives the summary, findings, and checklist, never the raw log, and the prompt forbids numbers that are not in the data. If the call fails, the template is what the pilot sees.

I used a coding agent in Cursor to build the pipeline. The agent is not in the product. The product a pilot runs is the parser, the rules, and the template.

Why Does Open Innovation Matter?

A flight log is a map of where someone flew, how long they were up, and how the aircraft failed. Uploading that file to a hosted model is a bad default for a hobby tool. Running the parser and the rules on the laptop means the log never leaves the machine, and a useful report does not depend on someone else's per-token price.

The thresholds are in the repo. A pilot can see that "critical" means a cell under 3.3 V, vibration above 60 m/s² for more than two seconds, or a failsafe subsystem. A closed model that summarizes a log in one paragraph can sound confident and still invent a cause. Here the open code produces the findings, and the words are only allowed to explain them.

pymavlink is also the reason this can exist as a side tool at all. ArduPilot's log format is documented and readable because the autopilot stack is open. A closed vendor log would have made the same preflight check a paid black box.