[Showcase] PAMIR — Offline PX4 ULog Incident Reconstruction and Root-Cause Analysis

Spotlight
1

Hi everyone,

I’m building PAMIR, an offline forensic analysis engine for PX4 ULogs.

The goal is not simply to flag anomalies, but to reconstruct an incident timeline and identify the earliest material root event, together with timestamped evidence showing what happened next.

PAMIR v0.1 has now passed a reproducible validation gate using:

  • 5 public PX4 incident logs
  • 3 healthy/control logs
  • timestamp-based causal validation
  • SHA256-pinned benchmark inputs
  • no material root detections on the control set

The current focus is on:

  • root-event detection
  • causal ordering
  • false-positive control
  • evidence-backed incident reconstruction

One important part of the validation work was deliberately rejecting a case that initially looked like a motor-output failure, because closer inspection showed that the output change could be expected controller behaviour rather than a true failure. We chose not to tune the detector just to make the benchmark pass.

I’d really value feedback from the PX4 community on the methodology, especially around root-event detection, causal ordering, and additional public ULogs that could strengthen the validation set.

GitHub: https://github.com/yigitcan-ozturk/pamir

Feedback, criticism, and additional test cases are very welcome.

2

Hi Yigitcan,

I took a look at PAMIR, cool project! A few questions came to mind:

  • Is multivariate time-series anomaly detection on the roadmap?
  • Have you thought about building a labelled dataset from PX4 logs, maybe as a separate tool, for training anomaly detection models? I see that PX4 Flight Review already lets people rate a flight and attach error labels. It would be cool if we could flag anomalies at specific times in Flight Review itself, so they could be used for training.
3

Thanks Rado both are very relevant questions.

Multivariate time-series anomaly detection is on the roadmap, but I want to keep an important boundary in PAMIR:

anomaly detection should help us find where to investigate; it should not become the explanation itself.

The direction I’m interested in is:

multivariate anomaly candidate → earliest observable divergence → affected signals → downstream propagation → causal hypotheses → evidence

So an ML/statistical detector could surface candidate regions in a large ULog, while the final incident reconstruction remains deterministic, inspectable and reproducible.

Your labelled-dataset idea is particularly interesting. I agree that flight-level labels such as “good/bad flight” are probably too coarse for this purpose. I think the useful unit would be a time-bounded event annotation.

For example:

log_id
t_start / t_end
affected_topics/signals
anomaly_class
flight_mode / estimator state
confidence
suspected_root_cause
confirmed_root_cause
upstream_event
downstream_effects

That would allow one flight to contain multiple labelled events and, importantly, distinguish the first relevant divergence from later symptoms such as estimator failure, failsafe activation or termination.

I also like your Flight Review idea. Being able to select a time interval directly on a plot and attach a structured annotation would make creation of such a corpus much more practical.

I would probably keep the dataset/tool separate from PAMIR initially, define a small open annotation schema, and validate it manually against a handful of real PX4 incidents before using the labels for model training.

If you’re interested, I’d be happy to sketch a minimal v0.1 annotation schema and test it against a few existing ULogs. That could tell us fairly quickly whether the idea is useful before building anything larger.