MissionPlanner icon indicating copy to clipboard operation
MissionPlanner copied to clipboard

LOG browser download - Incorrect Mavlink implementation ?

Open jnoxro opened this issue 3 years ago • 2 comments

Issue details

We have come across a possible bug in mission planner for Windows whilst downloading logs from our custom autopilot.

As per MAVLINK documents, log data should contain a field named .count, which is the amount of data included in the log packet https://mavlink.io/en/messages/common.html#LOG_DATA, and a count of 0 signifies the final log item. However, it seems mission planner on windows may be using a count of anything less than the 90 limit to signify the end of the log, hence resulting in the download ceasing after the first item in our case.

This was tested by us changing our code to declare a count of 90 for each log data, which resulted in a successful entire log download, when reverting the code to declare the correct count for each log data packet payload (somewhere between 20-90), mission planner stated the download is complete after the first log item is sent - resulting in a saved log file with 1 line.

Problem does not persist on a Linux installs of mission planner and apm planner, nor does it occur on QGroundControl on windows.

An extra note: the logs we create onboard our autopilot are stored, encoded, mavlink messages, if this causes any problems.

Version

1.3.77 - 1.3.8110.38294 (windows)

Platform

Mission planner interfacing with a custom autopilot using mavlink c library v2.

Airframe type

N/A - autopilot is currently set to report mavlink vehicle type ground rover

Hardware type

Custom made, tested over multiple stm32 boards

Logs

The TLog shows multiple LOG_DATA mavlink messages were received https://pastebin.com/cGUrXiWG And the created LOG is a single line https://pastebin.com/gz5q0ag9

jnoxro avatar Apr 22 '22 15:04 jnoxro

so whilei understand its not exactly to spec, mission planner is designed to work with ardupilot, and ardupilot doesnt currently send a 0 count packet at the end of a transfer, instead relies on the < 90 assumption

https://github.com/ArduPilot/ardupilot/blob/f0efc1300eb0f00524505594f5c2e491436dd029/libraries/AP_Logger/AP_Logger_MAVLinkLogTransfer.cpp#L313

https://github.com/ArduPilot/MissionPlanner/blob/0e845fb14aac7a956bb72ed669f4f8c4031095fb/ExtLibs/ArduPilot/Mavlink/MAVLinkInterface.cs#L5761

https://github.com/ArduPilot/MAVProxy/blob/15d26873a884416c8f42ef07a10aba78636b80ca/MAVProxy/modules/mavproxy_log.py#L65

meee1 avatar Apr 23 '22 02:04 meee1

also using the current implementaiton in both, a lost packet would results in no recovery of that data, as the packet set is stored/saved at a 90byte interval.

meee1 avatar Apr 23 '22 03:04 meee1