PX4/MavLink Protokollierung#

Vielen Dank an Chris Lovett für die Entwicklung verschiedener Tools zur PX4/MavLink-Protokollierung, die auf dieser Seite erwähnt werden!

MavLink-Nachrichten protokollieren#

AirSim kann MavLink-Protokolldateien erfassen, wenn Sie Folgendes zum PX4-Abschnitt Ihrer settings.json-Datei hinzufügen

{
    "SettingsVersion": 1.2,
    "SimMode": "Multirotor",
    "Vehicles": {
        "PX4": {
            ...,
            "Logs": "c:/temp/mavlink"
        }
    }
}

AirSim erstellt für jede "bewaffnete/entwaffnete" Flugsession eine zeitgestempelte Protokolldatei in diesem Ordner.

Sie sehen dann Protokolldateien, die nach Datum in d:\temp\logs organisiert sind, insbesondere *input.mavlink- und *output.mavlink-Dateien.

MavLink LogViewer#

Für MavLink-fähige Drohnen können Sie auch unseren Log Viewer verwenden, um die Datenströme zu visualisieren. Wenn Sie diese Form der Echtzeitprotokollierung aktivieren, sollten Sie die obige "Logs"-Einstellung nicht verwenden, da diese beiden Protokollierungsformen sich gegenseitig ausschließen.

PX4-Protokoll im SITL-Modus#

Im SITL-Modus wird eine Protokolldatei erstellt, wenn die Drohne bewaffnet ist. Das SITL-Terminal enthält den Pfad zur Protokolldatei, der ungefähr so aussehen sollte:

INFO  [logger] Opened log file: rootfs/fs/microsd/log/2017-03-27/20_02_49.ulg

PX4-Protokoll im HITL-Modus#

Wenn Sie Pixhawk-Hardware im HIL-Modus verwenden, setzen Sie den Parameter SYS_LOGGER=1 mit QGroundControl. PX4 schreibt eine Protokolldatei auf das Gerät, die Sie später mit QGroundControl herunterladen können.

Einen schlechten Flug debuggen#

Sie können diese *.mavlink-Protokolldateien verwenden, um einen schlechten Flug mit dem LogViewer zu debuggen. Zum Beispiel kann ein AirSim/PX4-Flug sich schlecht verhalten, wenn Sie ihn auf einem leistungsschwachen Computer ausführen. Das Folgende zeigt, was in dieser Situation passieren könnte.

In diesem Flug haben wir einen einfachen commander takeoff-Test durchgeführt, wie er von PythonClient/multirotor/stability_test.py ausgeführt wird, und der Flug begann gut, wurde dann aber am Ende verrückt und die Drohne stürzte ab. Warum ist das so? Was kann die Protokolldatei zeigen?

Hier haben wir die folgenden 5 Metriken geplottet: - hil_gps.alt - die simulierte Höhe, die von AirSim an PX4 gesendet wird - telemetry.update_rate - die Rate, mit der AirSim die kritische Drohnen-Update-Schleife in Updates pro Sekunde durchführt. - telemetry.update_time - die durchschnittliche Zeit, die AirSim für die kritische Drohnen-Update-Schleife benötigt. - telemetry.actuation_delay - dies ist eine sehr interessante Metrik, die misst, wie lange PX4 benötigt, um aktualisierte Aktuatorsteuerungsnachrichten (Motorleistung) zu senden - actuator_controls.0 - das Aktuatorsteuerungssignal von PX4 für den ersten Rotor.

Was wir dann mit diesen Metriken sehen, ist, dass die Dinge gut begannen, mit einer schönen flachen Höhe, einer hohen Update-Rate im Bereich von 275 bis 300 fps und einer schönen niedrigen Update-Zeit in AirSim um 113 Mikrosekunden und einer schönen niedrigen Aktuationsverzögerung im Roundtrip von PX4. Die Aktuatorsteuerungen stabilisieren sich ebenfalls schnell auf einer schönen flachen Linie.

Aber dann beginnt die update_time zu steigen, gleichzeitig steigt die actuation_delay und wir sehen eine leichte Spitze bei actuator_controls. Dieser Abfall sollte nicht passieren, PX4 gerät wegen des Verlusts der Update-Rate in Panik, erholt sich aber.

Aber dann sehen wir, wie die Aktuatorsteuerungen verrückt spielen, ein riesiger Anstieg der Aktuationsverzögerung, und zu diesem Zeitpunkt sehen wir eine Nachricht von AirSim, die besagt lockstep disabled. Eine Verzögerung von über 100 Millisekunden löst AirSim aus, aus dem Lockstep-Modus auszubrechen, und PX4 gerät ausser Kontrolle und die Drohne stürzt ab.

Die Quintessenz ist, dass, wenn ein einfacher takeoff keinen gleichmässigen, ruhigen Flug aufrechterhalten kann und Sie diese Art von Spitzen und ungleichmässigen Update-Raten sehen, dies bedeutet, dass Sie AirSim auf einem Computer ausführen, der nicht über genügend Leistung verfügt.

So sollte ein einfacher Start, Schweben und Landen aussehen

Hier sehen Sie die update_rate, die das Ziel von 333 Updates pro Sekunde einhält. Sie sehen auch die update_time, eine schöne flache 39 Mikrosekunden, und die actuator_delay irgendwo zwischen 1,1 und 1,7 Millisekunden, und die resultierenden actuator_controls eine schöne flache Linie.