Identifying .ulg message type parameter descriptions

PX4 Autopilot
1

I’m working on python scripts that report on data in PX4 and ArduPilot log files.

I’m distributing these scripts on GitHub and make them available live on my website. I’ve only got a few so far - GitHub - CopterCamTech/flight-tools: Modular UAV log analysis suite for ArduPilot and PX4 formats

I’ve found a way to identify parameters on .ulg message types. But I haven’t found documentation on the meaning of these fields.

I assume that since PX4 parameters are “self-documenting” from the codebase itself, that there might be something similar for .ulg message type parameters.

If someone could suggest places to look, I’d appreciate the guidance - it could be a real time saver.

As an example of parameters by message type, Here’s a report that details some:

PX4 Range vs Signal Diagnostic.pdf (174.3 KB)

Thanks!

2

Is this something that is not covered by these docs?

3

Thanks for this reference.

This document explains how a .ulg file is structured, but I can’t find an explanation of individual fields or parameters.

What I’m looking for is something like what ArduPilot documents here: Onboard Message Log Messages — Copter documentation

4

I don’t think we produce anything special for the logs, and I’m not really too familiar with ArduPilot, but here’s a link to our parameter reference

5

Thank you - yes, I’m familiar with the PX4 Parameter Reference.

As I understand it, this document is auto generated using comments embedded in the PX4 firmware itself.

In the link to the “ULog File Format | PX4 Guide (main)” you provided, there is a list of “Known Parser Implementations” at the bottom of the document.

How did the programmers of these “Known Parser Implementations” tools get the detail about what’s being “parsed” from a .ulg file?

Maybe it’s in the PX4 firmware itself - perhaps where the code causes data to be recorded in a .ulg file, the code also describes what the data element is that’s being saved.

I appreciate that what I’m looking for might not exist. But for anyone wanting to do their own parsing of .ulg log files, (like me) this information is essential.

Seems to me that making this information available is consistent with the notion of “open source.”

6

Maybe I’m missing something here, but as far as I understand, those parsers are going by the ulog spec, and don’t know anything about the contents of those files other than how to parse them. Check out the pyulog implementation below. I can also suggest looking into the git history to get a sense of how it’s developed.