PX4/MavLink Logging#
Thanks to Chris Lovett for developing various tools for PX4/MavLink logging mentioned on this page!
Logging MavLink Messages#
AutonomySim
can capture mavlink log files if you add the following to the PX4 section of your settings.json
file:
{
"SettingsVersion": 1.2,
"SimMode": "Multirotor",
"Vehicles": {
"PX4": {
...,
"Logs": "c:/temp/mavlink"
}
}
}
AutonomySim
will create a time-stamped log file in this folder for each "armed/disarmed" flight session.
You will then see log files organized by date in [DRIVE]:\temp\logs
, specifically *input.mavlink
and *output.mavlink
files.
MavLink LogViewer#
For MavLink enabled drones, you can also use our Log Viewer to visualize the streams of data. If you enable this form of realtime logging you should not use the "Logs" setting above, these two forms of logging are mutually exclusive.
PX4 Log in SITL Mode#
In SITL mode, please a log file is produced when drone is armed. The software-in-the-loop (SITL) terminal will contain the path to the log file, it should look something like this
PX4 Log in HITL Mode#
If you are using Pixhawk hardware in hardware-in-the-loop (HITL) mode, then set parameter SYS_LOGGER=1
using QGroundControl
. PX4 will write log file on device which you can download at later date using QGroundControl.
Debugging a bad flight#
You can use these *.mavlink
log files to debug a bad flight using the LogViewer. For example, AutonomySim/PX4 flight may misbehave if you run it on an under powered computer. The following shows what might happen in that situation.
In this flight, we ran a simple commander takeoff
test as performed by PythonClient/multirotor/stability_test.py
and the flight started off fine, but then went crazy at the end and the drone crashed. So why is that? What can the log file show?
Here we've plotted the following 5 metrics:
hil_gps.alt
- the simulated altitude sent from AutonomySim to PX4.telemetry.update_rate
- the rate AutonomySim is performing the critical drone update loop in updates per second.telemetry.update_time
- the average time taken inside AutonomySim performing the critical drone update loop.telemetry.actuation_delay
- this is a very interesting metric measuring how long it takes PX4 to send back updated actuator controls message (motor power).actuator_controls.0
- the actuator controls signal from PX4 for the first rotor.
What we see then with these metrics is that things started off nicely, with nice flat altitude, high update rate in the 275 to 300 fps range, and a nice low update time inside AutonomySim
around 113 microseconds, and a nice low actuation delay in the round trip from PX4. The actuator controls also stabilize quickly to a nice flat line.
But then the update_time
starts to climb, at the same time the actuation_delay
climbs and we see a little tip in actuator_controls
. This dip should not happen, the PX4 is panicking over loss of update rate but it recovers.
But then we see actuator controls go crazy, a huge spike in actuation delay, and around this time we see a message from AutonomySim saying lockstep disabled
. A delay over 100 millisecond triggers AutonomySim into jumping out of lockstep mode and the PX4 goes nuts and the drone crashes.
The button line is that if a simple takeoff
cannot maintain steady smooth flight and you see these kinds of spikes and uneven update rates then it means you are running AutonomySim on a computer that does not have enough horsepower.
This is what a simple takeoff, hover, and land (THL) should look like:
Here, you see the update_rate
sticking the target of 333 updates per second. You also see the update_time
a nice flat 39 microseconds and the actuator_delay
somewhere between 1.1 and 1.7 milliseconds, and the resulting actuator_controls
a lovely flat line.