Project: GSoC | Mentors: Amilcar Lucas & Jaime Machuca | Duration: May to August
1. Introduction
Hello ArduPilot community,
I’m Omkar Sarkar, a 2nd year undergraduate studying Computer Science and Engineering at the Institute of Technical Education and Research (SOA), India.
I’ve been exploring robotics and autonomous systems for a while now, and recently I’ve been doing some research on UAVs, control systems, and flight behaviour. I’ve also been contributing to ArduPilot, especially working on AMC, over the past few months.
I’m really excited to be working on this project as part of GSoC.
2. Problem Statement
Analyzing flight logs in ArduPilot is still a largely manual process. Often when a user shares a crash log, the expectation is a clear answer. In practice, identifying the root cause requires going through multiple signals, correlating them, and validating against configuration.
Tools like Mission Planner and existing log viewers provide access to raw data, but understanding what went wrong and why is difficult for many newer users. This often leads to a guess approach when tuning parameters or diagnosing issues.
At the same time, ArduPilot Methodic Configurator (AMC) provides a structured way to configure parameters using metadata and predefined workflows, but it does not currently take into account actual flight behaviour captured in logs.
There is a gap, as there is no reliable integrated system that takes a flight log, analyses it in context, and provides actionable feedback on configuration or system behaviour.
Users do not need an existing AMC project to use the tool. AMC can import a .bin log and automatically create a vehicle project from the information stored in the log. This allows the diagnostic system to work with both the flight log and the generated AMC project, enabling configuration aware analysis even for first time AMC users.
2.1 Solution Workflow
A detailed flow is in my Github
3. Solution Overview
3.1 Step 1: Flight Log Validation & Feature Extraction
Responsible for translating raw flight data into physical understanding and checks the quality of the log.
-
The system ingests a .bin log using pymavlink and loads firmware metadata from
apm.pdef.xml. Since different messages are logged at different rates, the data is synchronized before analysis.The log quality check module determines which analyses can be performed reliably. It checks for missing messages, insufficient logging rates, processor load indicators(when available) etc. and reports which diagnostic modules can run reliably and which require additional logging.
For Example. if a user requests vibration analysis but the log does not contain sufficiently IMU data, the report will say, vibration analysis cannot be performed reliably and recommend recording a short validation flight with the appropriate logging settings enabled.
-
After validation, physical features such as battery behaviour, vibration metrics, and IMU frequency content are extracted.
Feature extraction will use techniques like variance measurements to identify unstable signals and increasing vibration levels, derivative (delta) calculations to detect sudden events such as voltage drops, etc.
Fast Fourier Transform (FFT) analysis, similar to the ArduPilot Filter Review Tool, will be used to identify vibration peaks, motor harmonics, and possible resonance sources automatically.
Fig. 2: IMU Spectrum Visualization
- These extracted features are then evaluated using two parallel approaches. Physics based checks and, later in the project, a Hidden Markov Model (HMM) trained using real flight logs.
I would like to thank Patrick Hinchey for providing access to a large collection of ArduPilot Copter logs. (These logs will be used for developing and validating, and later for training and evaluating the HMM model.)
3.2 Step 2: Root Cause Detection
Root Cause Detection links detected events using their temporal relationships to identify the most likely root cause.
For Example. A voltage drop followed by motor saturation and frame vibration is treated as a single chain of events, not three isolated warnings.
Hardware and operational issues are reported together with supporting evidence and corrective actions.
For Example. persistent vibration peaks at motor harmonics may indicate propeller imbalance, motor damage, or frame resonance.*
If the issue is configuration based, it will validate the current parameters against firmware definitions, checking for range limits and conflicting settings. It then maps the root cause to the appropriate AMC tuning step and generates the required parameter adjustments.
Fig. 3: AMC Configuration Steps
3.3 Step 3: Execution
If a configuration issue is detected, parameter changes are suggested. It presents the analysis, explains the recommended AMC step, and asks the user for approval. If approved, the parameter updates are sent directly to the flight controller through the AMC interface.
After the changes are applied, we will recommend a short validation flight (for required and updated steps). The user uploads the new .bin log, and compares it against the previous log to verify that the cause was successfully fixed.
3.4 LLM Layer
A local LLM sits above this analysis pipeline and acts as the user interface with the system and does not perform the analysis itself, only interprets diagnostic outputs, explains detected issues, highlights supporting evidence, and presents recommendations.
4. Expected Midterm Milestones
- Implement log quality checks.
- Extract an initial set of physical features including battery behaviour, vibration metrics etc.
- Develop initial physics based diagnostic modules for a set of common issues.
- Build the first version of the AMC integration and validation workflow.
5. Closing
The goal of this project is to develop a log analysis and diagnostic system that works alongside AMC.
By the end of GSoC, I am aiming to deliver a working foundation consisting of log quality analysis, feature extraction, initial physics based diagnostics, AMC workflow integration, and a validation workflow.
Since reliable flight log diagnosis requires testing against real world logs and hardware, development and validation will continue beyond GSoC.
I would appreciate any feedback from the community, especially from those who regularly work with flight logs. Any suggestions or real world cases would be super helpful.
Thank You!