I’ve been working on a Python tool for analysing ArduPilot DataFlash logs and have now put the project on GitHub.
The project started because I wanted a better way of examining my ArduPlane automatic landings. UAV Log Viewer is very useful for visually exploring a flight, but I kept running into limitations for this particular job: MAVLink messages/events aren’t exposed alongside the plotted data, and once I had more than about three parameters on a plot it became increasingly difficult to correlate what was happening.
Landing analysis often meant comparing approach, preflare and flare events with altitude, airspeed, groundspeed, sink rate, rangefinder behaviour and position relative to the mission landing point. I found myself repeatedly digging through the same logs and manually piecing that evidence together.
ArduPilotTools grew out of wanting those relationships extracted automatically and presented as a compact description of each landing attempt, while still keeping the underlying logged evidence visible rather than turning it immediately into a score or judgement.
It has since grown into a more general flight-analysis framework, although Landing Analysis is currently the first analysis producing useful data for my own flying and analysis use case.
Along the way, the work needed to support landing analysis also produced an ArduPilot event timeline and a battery analysis module. These use the same underlying flight-log framework and have been useful in their own right, although landing analysis remains the main focus at present.
The basic approach is deliberately evidence-based. The tool tries to report what is actually present in the log without deciding whether a landing was “good” or “bad”, or automatically attributing unusual data to the pilot, aircraft or ArduPilot.
For each detected landing attempt it currently reports:
-
approach altitude and glide slope
-
preflare time, height, airspeed, groundspeed and sink rate
-
flare time, height, airspeed, groundspeed and sink rate
-
distance from the mission LAND target at flare
-
rangefinder acquisition and continuity
-
rollout/GPS stop
-
final distance from the LAND target
-
how the landing attempt terminated
It handles multiple flights within a BIN log and multiple landing attempts within a flight, including aborted approaches. You can give it one BIN file or an entire directory of BIN files.
For example, part of the output from one of my flights looks like:
Landing 1 Attempt 1
----------------------------------------------------------------------
Landing window 11:57.705 -> 12:23.104
Landing duration 25.4 s
APPROACH
Approach altitude 20.5 m
Glide slope 3.9 deg
PREFLARE
Time 12:15.904
Preflare height 4.9 m
Airspeed 11.0 m/s
GPS groundspeed 11.1 m/s
Sink rate 1.5 m/s
FLARE
Time 12:16.404
Flare-timing height 4.6 m
Sink rate 1.6 m/s
Airspeed 11.5 m/s
GPS groundspeed 11.5 m/s
Flare distance to target 45.8 m
RANGEFINDER
First non-zero 12:08.925
First distance 11.7 m
First in range 12:09.023
In-range distance 5.8 m
Continuous from 12:12.184
LANDING / ROLLOUT COMPLETION
GPS stop 12:23.104
Flare -> stop 6.7 s
Distance from target 19.1 m
End reason GPS stop
One reason I wanted the analysis to retain the underlying evidence is that it can expose oddities without trying to explain them away. For example, some of my logs contain interesting rangefinder behaviour around acquisition. The analyzer reports the first non-zero reading, first in-range reading and when readings become continuous. Interpretation remains separate from measurement.
The architecture is intended to support other analyses using the same decoded flight data. TECS/cruise behaviour, RTL, power-system analysis and autotune review are on the roadmap, but those are development directions rather than finished features.
I’ve regression-tested the landing analysis against my development log set, covering multiple flights, multiple attempts, aborted landings, missing flare events, optional airspeed/rangefinder data and different landing termination cases. The regression suite is included in the repository, although the actual development BIN logs and parameter files are private because the logs contain GPS location data.
The project is here:
nflyernz/ArduPilotTools on GitHub
This is my first public GitHub project. At this stage I’m particularly interested in feedback from people familiar with ArduPlane logs:
-
assumptions I’ve made that won’t generalise to other aircraft or firmware versions
-
landing/event semantics I’ve misunderstood
-
useful landing evidence that I’m not extracting
-
unusual landing sequences I haven’t accounted for
-
logs that simply break the analysis
I’m deliberately holding off on adding lots more metrics, scoring or graphical presentation until the underlying landing analysis has had some exposure to logs other than my own.
If anyone is willing to try it against their own ArduPlane BIN logs, I’d be interested to see what it gets right — and, more importantly at this stage, what it gets wrong.
i started this project knowing nothing lol. just finished the first merge pr into amc and am using the excelent bin parser there. dropped a lot of my code but that’s all good.