You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have found that some MAVLink2 messages generated by BlueOS, sent via mavlink2rest, and written to a tlog file by QGC, and read by pymavlink, have bad CRC values. I am not exactly sure where the bug lies, but I thought I'd share my findings to see if others can help narrow it down.
Steps to reproduce
I am looking at ~20 tlog files from 3 different BlueROV2 systems:
R1, upgraded to Navigator + BlueOS, with a Ping sonar
R2, Pixhawk + Companion, with a Ping sonar and WL UGPS
R4, Navigator + BlueOS, with a Ping sonar and WL UGPS
I created a Python tool to help me examine BAD_DATA messages, and found a few patterns:
Just about every tlog file generated by a system running BlueOS has BAD_DATA messages, in contrast to the Companion system, where I haven't found any (but I don't have a ton of data to look at yet)
The most common BAD_DATA messages are 132 (DISTANCE_SENSOR) and 232 (GPS_INPUT).
I am also seeing a few 259, 260, 262 and 269 (camera messages).
A few appear to come from QGC (sysid==255) but the vast majority appear to come from BlueOS (sysid==1 and compid<>1).
FYI that I am running a patched version of pymavlink, without this patch pymavlink will get confused by the BAD_DATA messages and crash.
Primary pain point(s)
At the moment this just makes log analysis a challenge. (I haven't yet traced these messages through ArduSub to see if they are causing problems in ArduSub.)
Prerequisites
I have checked to make sure that a similar request has not already been filed or fixed.
The text was updated successfully, but these errors were encountered:
Pymavlink is happy to receive and unpack this message live, but it barfs when reading the QGC-generated tlog file that contains this message. So I think it's a bug in QGC. If you don't mind, I'll keep this issue open as I continue isolating the problem.
OK, I think I have figured this out. This occurs when you send a MAVLink2 message with trailing 0's. For DISTANCE_SENSOR messages, this happens when signal_quality is 0.
Then:
mavlink2rest does not truncate the zeros as required. The CRC is correct, but only if the zeros are included.
pymavlink will happily parse the message with the trailing zeros and the corresponding CRC.
QGC will truncate the message without re-computing the CRC. The truncated message (with the old CRC) is written to the tlog file.
pymavlink will crash when reading the tlog file with the truncated messages.
Bug description
I have found that some MAVLink2 messages generated by BlueOS, sent via mavlink2rest, and written to a tlog file by QGC, and read by pymavlink, have bad CRC values. I am not exactly sure where the bug lies, but I thought I'd share my findings to see if others can help narrow it down.
Steps to reproduce
I am looking at ~20 tlog files from 3 different BlueROV2 systems:
I created a Python tool to help me examine BAD_DATA messages, and found a few patterns:
Here is a typical run of the tool I'm using:
FYI that I am running a patched version of pymavlink, without this patch pymavlink will get confused by the BAD_DATA messages and crash.
Primary pain point(s)
At the moment this just makes log analysis a challenge. (I haven't yet traced these messages through ArduSub to see if they are causing problems in ArduSub.)
Prerequisites
The text was updated successfully, but these errors were encountered: