Mavlink packages (commands) might get discarded when sent via uORB

[jbeyerstedt]

We are trying to communicate with a companion computer via custom Mavlink messages. The mavlink packages are sent via the MAV_0 UART connection, which is normally used by the telemetry radio.

All messages sent by the companion computer are received by our PX4 app, but the messages sent from our app are sometimes discarded. So there is no message on the serial communication at all.

To Reproduce
Configuration, where the issue occurrs:

1. MAV_0_RATE is set to the default value of 1200 baud
2. Stream data rate is set to 1 Hz
3. Send messages via uORB with a data rate of about 0.5 Hz.
4. See, that not all messages are sent via the serial connection

Workaround:

1. Set MAV_0_RATE to 5000 baud (no problem, because UART baud rate is 57600)
2. Stream data rate is set to 20 Hz
3. Send messages via uORB with a data rate of about 0.5 Hz.
4. Now all messages are sent properly

Expected behavior
There should be some kind of API for non-periodic messages (commands), where it is guaranteed, that the mavlink rate limiting does not discard these messages.

Possible issue/ explanation
Because the mavlink messages sent via the PX4 uORB can not be seen on the serial connection (with a logic analyzer) we think, that the rate limiting is discarding messages. This idea got verified, because cheating on the stream rate and setting a higher baud rate solved the issue.

When using the mavlink status command on the NuTTX shell, we can also see, that the "TX err rate" is very high and that the rate multiplier is quite low (0.05). The mavlink status streams command shows, that the "real" stream rate on the MAV_0 interface (instance #0) is also very low because of the rate multiplier. Therefore setting the stream rate 20 times higher, than really necessary leads to less or no discarded packages.

[LorenzMeier]

@dagar @julianoes I believe we have a set of issues in terms of handling available buffer space and we need to discuss a general approach on how to ensure we do rate-limiting appropriately (e.g. with a low-prio and high-prio buffer or equivalent) for these need-to-be-delivered messages like commands or log streaming. @catch-twenty-two will focus on this in the coming week.

[dagar]

Partially related.

• review PX4 Mavlink module write helper (send_bytes) #10389
• Mavlink parameter sync and general congestion review #10618
• Mavlink check transmit buffer before send #10394

[catch-twenty-two]

Got it, will take a look

[thomasgubler]

@bkueng FYI

[catch-twenty-two]

After discussing this with @dagar and @bkueng I'm going to take a first stab and make a high priority message queue option. Ill also take a look at a problem with message marshalling that @dagar had described where messages are sent out fragmented to see how much that is affecting sending. Making a high priority queue still wont guarantee that messages make it to the end point since there is no ack, but it should at least make sure they have a chance of making it out instead of being skipped over for a higher frequency message.

[AuterionWrikeBot]

➤ Jimmy Johnson commented:

Thomas Gubler r I haven't had anytime to into this with the other priorities I have had, I don't want it to get dropped if it is important. Let me know If I should reprioritize.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.