logger causing mavlink manual control dropouts

[dagar]

When logger is running and you're using mavlink manual control inputs it's common to see RC lost messages that correspond with logger activity, like start/arming (logger writes header, version, parameters, perf data, etc), or later in flight if a PX4_WARN is logged.

I'm guessing this is because it's the high priority logger main thread gathering these things which far exceeds the priority of the mavlink receiver thread.

Could we push this back into the the low priority writer thread? https:/PX4/Firmware/blob/master/src/modules/logger/logger.cpp#L1456-L1467

[LorenzMeier]

It's actually interfering with the commander monitoring, so we definitely need to fix this. @bkueng At this high priority any activity in the main logger thread has to be limited to pure topic copying. And/or it has to be dropped in priority.

[bkueng]

Could we push this back into the the low priority writer thread?

Not really since the mavlink log streaming needs that too. Let me do some testing. A potential easy fix is to insert some usleeps to allow other modules to run.

[bkueng]

I could not reproduce this, even when lowering RC loss timeout. Writing log file headers does not use the CPU that long that this alone could trigger RC loss. However what happens is that the main logger thread might need to wait until the full header is written (using usleep so other processes can run in the meanwhile). The duration of this depends on the quality of the SD card, I measured 180ms, and it's a fairly good one.
During that time the semaphore counter used to increase, causing more logger activity afterwards. But this is fixed in #8979, so I'm fairly confident that the root cause here is fixed as well.
If not, please reopen the issue.

I was able to trigger some global position warnings with HIL when increasing the duration that it takes to write the log headers during arming. When applying #8979, these warnings disappeared.