PX4 enters failsafe if a new flight starts while MAVSDK log download is still running from an onboard computer

MAVSDK
1

have a Jetson onboard computer connected to a PX4 flight controller.

Architecture:

  • a watcher process monitors flight state over mavlink-router TCP (tcpout://127.0.0.1:5760)

  • after landing and a disarmed/grounded delay, it starts a one-shot log downloader

  • the downloader uses MAVSDK to enumerate and download PX4 .ulg logs

  • watcher and downloader are separate processes

The downloader is able to:

  • connect successfully

  • enumerate PX4 log entries

  • download .ulg files

  • upload them afterward

A successful run looks like:

Timeout! (log_files_impl.cpp:380)
Requesting missing chunk: 204/223 (log_files_impl.cpp:381)

Sometimes there are chunk retries during transfer:

Timeout! (log_files_impl.cpp:380)
Requesting missing chunk: 204/223 (log_files_impl.cpp:381)

The real issue is this:

If a new flight starts while the log download is still in progress, PX4 goes into failsafe.

This is not just a UI issue. The vehicle behavior changes and failsafe is triggered.

Questions:

  1. Is PX4 log download via MAVSDK expected to interfere with flight if arming happens during an active transfer?

  2. Can log_files.download_log_file() consume enough MAVLink bandwidth / FC resources to trigger failsafe?

  3. Is the correct design to guarantee that log download only happens while the vehicle remains disarmed and grounded?

  4. Has anyone seen PX4 enter failsafe when a MAVSDK log transfer overlaps with new flight activity?

Important details:

  • watcher already waits for a grounded/disarmed delay before starting downloader

  • this is specifically onboard MAVSDK log download, not QGC log download

  • watcher and downloader are intentionally separated so flight-state detection and log transfer are independent

  • the problem appears only when a new flight begins during an active log transfer

Environment:

  • PX4

  • MAVSDK / MAVSDK-Python

  • Jetson Linux

  • onboard downloader service

  • mavlink-router used for watcher TCP monitoring

I’m trying to understand whether this is:

  • expected unsafe usage

  • MAVLink bandwidth saturation

  • PX4 logger/log transfer limitation

  • or a known MAVSDK behavior when download overlaps with flight

Tags

  • px4

  • mavsdk

  • mavlink

  • drone

  • jetson

2

Hi there!
I unfortunately do not have the answers to all of your questions.
In general, pulling a log while in-air should be no problem. If pulled then directly from the sd card in flight and that worked out fine.

What kind of error/failsafe do you get? What is it triggered by? Or can you share a log?

3

Well I tried this in QGC and I observed same behavior. I started the download and then tried to arm the drone it went to fail safe status almost instantly.

If I try to download the file during flight the flight status changes from in air to fail safe mode. This behavior is same when i try it with MAVSDK or from QGC.

Just wanted to update this thread in case if you are working on this project this is the behavior. i have been pulling my hair for a week.

This is one wire solution - that is only one connection through ACM* port and both downloading and flight through QGC works.

Also tested the two wire solution where i opened the connection using TELEM1 port for downloading the logs it worked fine now I did not get disconnection even if logs are being downloaded and flight is in progress but download speed took a huge hit.

@nitru if you think i have reached right conclusion please let me know

4

I`m happy if it works for you.

There is really no reason why the original attempt should have failed, but without any evidence, its kind of hard to debug this one