[GSoC 2026] An automated log diagnosis engine

Google Summer of Code
1

Hey everyone,

As part of my preparation for GSoC 2026, I’ve been working on a new tool to help automate [.BIN](cci:7://file:///c:/log%20anyalysis/ardupilot-log-diagnosis/test_cascade.BIN:0:0-0:0) dataflash log triage. I know maintainers spend a huge amount of time pulling up MAVExplorer just to tell a pilot their crash was caused by vibration clipping or compass EMI, so I wanted to see if we could automate the initial root-cause analysis.

I’ve built a hybrid diagnostic engine at [BeastAyyG/ardupilot-log-diagnosis](GitHub - BeastAyyG/ardupilot-log-diagnosis · GitHub).

**How it works right now:**

  1. It parses the [.BIN](cci:7://file:///c:/log%20anyalysis/ardupilot-log-diagnosis/test_cascade.BIN:0:0-0:0) file and extracts about 60+ key telemetry features (vibration std dev, EKF variance, mag field ranges, etc.).
  2. It passes these through a normal deterministic rule engine first (checking against known ArduPilot default thresholds).
  3. It also passes them through an XGBoost model I trained on a mix of the BASiC dataset and expert labels mined from this forum (~140 logs total).
  4. A causal arbiter decides the root cause (e.g., if vibration spiked *before* the EKF lane switch, it flags vibration as the root cause, not navigation).

It outputs a confidence score and generates an interactive 3D Plotly replay of the trajectory so you can explicitly see where the anomalies occurred on the flight path. Right now it’s catching compass interference, high vibration, and standard RC/EKF failsafes pretty reliably.

I’m planning to formally submit this for GSoC to expand the training dataset and potentially port the inference engine to run on companion computers via MAVLink.

If anyone has time to throw a few weird [.BIN](cci:7://file:///c:/log%20anyalysis/ardupilot-log-diagnosis/test_cascade.BIN:0:0-0:0) files at the web UI or the CLI, I would really appreciate any feedback on the false-positive rate.

Thanks,
Agastya

2 Likes
2

Hey everyone,

I’ve spent the last week completely rewriting the core of the engine based on the recent discussions and feedback happening across the GSoC threads.

I realized the tool was acting too much like a “magic 8-ball” (just spitting out a single label), so I rebuilt the output to be what @NDev described in another thread: scaffolding to help users build a hypothesis.

Here is what I just pushed to the repo based on mentor feedback:

1. Hypothesis Scaffolding & CITA (Fixing the Compass Hallucination) Instead of just printing “Root Cause: X”, the engine now prints its internal reasoning trace. Using Crash-Immune Temporal Arbitration (CITA), it tracks the exact tanomaly (first threshold breach) for every subsystem. If a motor fails at T+12s and the compass freaks out at T+15s (during the crash), it explicitly shows:

Selected: Motor Imbalance (Onset: T+12s) Suppressed: Compass Interference (Onset: T+15s — filtered as downstream/post-crash)

2. True Thrust-Loss Detection (@dkemxr) Previously the engine missed Thrust Loss because it relied on generic percentages. Based on Dave’s feedback, I added a dedicated RCOU state tracker. It now scans for windows where all active motors are pegged (≥ 1900 PWM) for >3 seconds while GPS/CTUN altitude is actively dropping, giving a hard onset timestamp for thrust loss.

3. Vehicle-Aware Branching (@Nate) The pipeline no longer assumes everything is a Copter. It dynamically reads FRAME_CLASS or boot strings at ingestion. If the log is a Rover or Sub, it completely disables Copter-centric extractors (like Hover Thrust or Roll/Pitch oscillation checks) so it doesn’t feed garbage zero-data into the ML layer.

4. Pre-Flight Parameter Checking (@amilcarlucas) Before the ML layer even runs, there is now a Parameter Validation stage. If it sees stock Copter default PIDs (ATC_RAT_RLL_P = 0.135) combined with heavy VIBE data or attitude standard deviation > 8°, it explicitly warns the user that bad tuning likely caused the mechanical issue, reinforcing the “prevention is better than cure” approach.

I’ve got the full test suite (176 tests) passing with these structural changes. If anyone has a spare minute to critique the new hypothesis scaffolding output (or run a weird log through the CLI), I’d really value the reality check before I finalize my GSoC proposal!

Repo: GitHub - BeastAyyG/ardupilot-log-diagnosis · GitHub

3

Hey everyone! :waving_hand:

I just pushed a massive update to my ArduPilot AI Log Diagnosis project, and I’m super excited to share where it’s at. Over the last few days, I had to stop building new features and just focus on making the engine rock-solid and usable for everyone.

Here’s a quick rundown of what I’ve been working on:

First off, I finally crushed a nasty dependency bug that was breaking my entire test suite. Getting all 176 tests passing again felt amazing. I also spent time fixing some annoying Windows-specific crashing issues with mavlogdump—so now the whole telemetry extraction pipeline runs seamlessly whether you’re on Windows, macOS, or Linux.

On the logic side, I’ve updated the API schema and added Pre-Flight Parameter Validation. Now, instead of just telling you a component failed, the system actually looks back at your PIDs and other parameters to see if bad tuning is what put mechanical strain on your drone in the first place.

But honestly, my favorite part of this update is the UI. I wrapped up the interactive web dashboard! You can literally just drag and drop a .BIN crash log into your browser, and it will give you a root-cause diagnosis in less than a second. It even includes a 3D Flight Replay that drops markers at the exact GPS coordinates where the anomalies started.

Finally, I completely rewrote the GitHub README with all the new performance benchmarks (the ML model is sitting at a 1.00 Macro F1 score right now!), architectural diagrams, and screenshots of the new UI.

All of this is polishing up my proposal for Google Summer of Code 2026. My ultimate goal is to get this 350-millisecond automated crash analysis directly into the hands of the ArduPilot community so nobody has to spend hours staring at vibration graphs ever again. :grinning_face_with_smiling_eyes:

If you have a mystery crash log lying around, I’d love for you to clone the repo, drop it in the dashboard, and see what the engine thinks!

:link: Check it out here: https://github.com/BeastAyyG/ardupilot-log-diagnosis

4

Nice work, glad to hear you’re having fun with it.

1 Like
5

my discord got hacked …BEASTAYYG is not mine now i apologise if any message or inconvenience happened (MommyChorr) aka BeastAyyG