A Beginner's Guide to PX4 ULog Analysis (.ulg Files)

TL;DR: PX4 flight logs are ULog (.ulg) files. The diagnostic content lives across roughly ten messages: vehicle_status (mode, arming, failsafe), sensor_combined (IMU), estimator_status (EKF state and innovations), vehicle_attitude + vehicle_attitude_setpoint (control loop), actuator_outputs (motor commands), and battery_status. The fastest viewer is PX4’s Flight Review for a hosted GUI; pyulog for scripting. If you’re coming from ArduPilot, the message names differ but the diagnostic logic maps cleanly — estimator_status.innovations is the PX4 equivalent of XKF3.IVN/IVE/IVD.

The ULog format in two paragraphs

ULog is PX4’s binary log format. Each message is a defined structure with a name (like vehicle_status) and fields. Unlike ArduPilot’s DataFlash, ULog records continuously at the rate each publisher emits, so a fast-rate message like sensor_combined writes at 250 Hz while vehicle_status writes only on state change.

The file format is fully self-describing: every message type carries its own field schema at the top of the log, so a viewer doesn’t need an external dictionary to decode the file. That makes ULog future-proof against PX4 version changes and easy to parse from third-party tools.

The ten messages you actually read

• vehicle_status — nav_state (mode), arming_state, failsafe bit. State-change driven, perfect for finding the moment a failsafe fired.
• vehicle_command — commands received over MAVLink. Shows operator actions.
• estimator_status — the EKF’s self-reported health. innovations, innovation_test_ratios, and states are the most-watched fields. Equivalent to ArduPilot’s XKF3/XKF4.
• sensor_combined — consolidated IMU output (accelerometer + gyro). Vibration diagnosis lives here.
• vehicle_attitude + vehicle_attitude_setpoint — achieved versus desired attitude. PX4 equivalent of ATT.
• vehicle_rates_setpoint — rate-loop setpoints. PX4 equivalent of RATE.RDes/RATE.PDes/RATE.YDes.
• actuator_outputs — motor and servo commands. Equivalent of RCOU.
• vehicle_global_position — latitude, longitude, altitude estimate.
• battery_status — voltage, current, remaining capacity. Equivalent of BAT.
• vehicle_local_position — NED-frame position from the EKF.

Reading a ULog — three options ranked by friction

1. Flight Review. Drop a .ulg file into the browser and the PX4 team’s hosted viewer renders a full standard report: maps, attitude tracking, EKF status, vibration, motor outputs. Zero setup. Good for one-off diagnosis.
2. pyulog. Python library for programmatic access. ulog2csv my_flight.ulg exports every message to CSV; ulog_info my_flight.ulg dumps a structured summary. Use this when you want to grep, plot, or integrate ULog data into your own dashboard.
3. LogHat. Same upload flow as ArduPilot: drop the .ulg, get the same forensic PDF and 3D replay. The internal pipeline normalises ULog into the same event schema as DataFlash, so the analysis runs through identical logic to your ArduPilot logs.

The ArduPilot ↔ PX4 equivalence table

If you read ArduPilot logs daily, this map saves an hour the first time you hit a PX4 ULog:

• BARO.Alt ↔ vehicle_air_data.baro_alt_meter
• GPS.NSats ↔ vehicle_gps_position.satellites_used
• GPS.HDop ↔ vehicle_gps_position.hdop
• VIBE.VibeX/Y/Z ↔ computed from sensor_combined RMS over a window
• XKF3.IVN/IVE/IVD ↔ estimator_status.velocity_innovation
• XKF3.IPN/IPE/IPD ↔ estimator_status.position_innovation
• XKF4.SP ↔ estimator_status.position_innovation_test_ratio
• XKF4.SS ↔ estimator_status.solution_status_flags
• MODE.Mode ↔ vehicle_status.nav_state
• RCOU.C1-C4 ↔ actuator_outputs.output[0..3]
• BAT.Volt ↔ battery_status.voltage_v
• RATE.RDes ↔ vehicle_rates_setpoint.roll
• RATE.R ↔ vehicle_attitude derived rate (or vehicle_local_position fields)

Diagnosing common PX4 problems

1. EKF disagreement. Plot estimator_status.innovation_test_ratios. Values above 1 indicate a measurement was rejected. The PX4 equivalent of our EKF Innovation post — same logic, different field names.
2. Vibration. Flight Review shows vibration in the "Acceleration" section directly. For deeper analysis, compute RMS of sensor_combined.accelerometer_m_s2 over 1-second windows.
3. Failsafe trigger. Plot vehicle_status.nav_state on a state-change timeline. The transition from a navigation mode to LAND, RTL, or POSCTL with failsafe == 1 tells you a failsafe fired.
4. Battery problems. battery_status.voltage_v versus battery_status.current_a at the failure timestamp.

When PX4 logs are easier than ArduPilot

• The estimator self-reports test ratios in a single named field (position_innovation_test_ratio) instead of the XKF4.SP shorthand.
• Failsafe state has a dedicated bit in vehicle_status.failsafe — no need to cross-reference an enum.
• The format is fully self-describing — a third-party parser doesn’t need a field dictionary.

When ArduPilot logs are easier than PX4

• The ERR/MSG system gives one canonical line per failsafe event with subsystem and code. Easier to grep than PX4’s state-change pattern.
• The dataflash format is denser — a long-mission .bin is typically smaller than the equivalent ULog.
• Mission Planner’s log browser is more polished than QGC’s for routine post-flight review.

When LogHat helps — and when it doesn’t

LogHat normalises ULog into the same event schema as DataFlash so the forensic PDF and 3D replay run identical analysis on both. The Root Cause Hypotheses section names the PX4 message and field that triggered each hypothesis. What we don’t replace: Flight Review is the canonical PX4 viewer and we recommend it for one-off detailed exploration alongside our own analysis.