I’m Dijo, a CS student applying for GSoC 2026 on the AI-Assisted Log Diagnosis & Root-Cause Detection project. I’ve been building ALDA (ArduPilot Log Diagnosis Assistant).
What ALDA does
ALDA (v0.1) parses ArduPilot .bin DataFlash logs using pymavlink, extracts features from VIBE, EKF4, ATT, GPS, BAT, COMPASS, RCOU, ESC, MODE and ERR message streams, and runs a hybrid rule-based classifier + causal arbiter to identify the root cause of failures.
The key design decision I made after reading this community’s feedback on similar tools: ALDA only analyses the 30-second pre-event window before any ERR or EV message and not the crash sequence itself. This directly prevents the compass hallucination problem where magnetic noise from the physical impact gets misread as the cause of the crash ( let me know if this is the right approach )
Results on real forum logs
used this as a test .bin file - https://discuss.ardupilot.org/t/crash-help-with-bin-analysis/42329
I appreciate that you’ve called out a key design decision for focused consideration by reviewers. Every applicant should be doing that as much as reasonable.
However, I’m also surprised at this particular decision (only consider 30 sec before the first ERR or EV message). Would you consider providing links to the feedback you have in mind in order to justify your choice? That would help me, who is not actually familiar with this problem, understand your solution to it better.
It’s probably an incorrect mitigation to a problem that should be addressed directly. If the AI is so prone to such specific hallucination, it’s either a poor model choice or poorly trained.
Many crash events are only diagnosable within seconds or milliseconds of the actual event, though others are the result of stacked error from systemic issues that could be diagnosed even before a catastrophic flight occurs at all.
the thread which gave me idea of using an 30s pre-window: Introducing an AI-Assisted Log Diagnosis Engine: Tracing Root Causes in .BIN files
community feedback in that thread flagged the engine for hallucinating compass_interference in many logs, where the actual root causes were motor imbalance, thrust loss, and EKF failures. That’s what led me to use a pre-event window to reduce post-crash noise before classification.
I should have linked it directly rather than referencing it vaguely — apologies for that.
The 30-second window was a rough heuristic in v0.1’s rule-based classifier — not the principled solution to the hallucination problem. As you pointed out, restricting the time window doesn’t fix a model that’s poorly weighting noisy magnitude-based features. The right fix is a classifier that’s robust to post-crash artifacts by design, not one that simply avoids looking at them.
For the GSoC implementation, the causal arbiter is meant to handle this more correctly. Rather than relying on feature magnitudes (which are easily contaminated by impact noise), it looks at threshold-crossing timestamps in the pre-event window to establish which signal deviated first — designating that as the root cause and flagging everything after as downstream symptoms. That approach is more robust to the compass hallucination problem than a hard time cutoff.
Your second point about different failure classes needing different temporal scopes is something I’ve been thinking about too. An acute GPS glitch or sudden EKF divergence needs millisecond-resolution just before the ERR message. A systemic failure like motor wear or gradual battery sag has signatures that appear minutes before any ERR fires, a 30-second window cuts off most of that diagnostic signal entirely.
In my gsoc proposal I had proposed a solution with per-class adaptive windows, which I will implement in the project.
