Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HEARTBEAT handler failing to handle non-vehicle HEARTBEATs #1187

Closed
morzack opened this issue Apr 14, 2023 · 0 comments · Fixed by #1188
Closed

HEARTBEAT handler failing to handle non-vehicle HEARTBEATs #1187

morzack opened this issue Apr 14, 2023 · 0 comments · Fixed by #1188

Comments

@morzack
Copy link
Contributor

morzack commented Apr 14, 2023

Hey all: this is an issue with an associated PR (#1188) that I just put together.

I recently noticed a problem with dronekit and Herelink setups: basically, dronekit will attempt to parse every HEARTBEAT message that comes through, regardless of what type of system produced the message. This leads to issues, as Mavlink allows for non-vehicles to send HEARTBEAT messages (https://mavlink.io/en/messages/common.html#HEARTBEAT -- check out the autopilot field).

The symptom of this problem is a large number of dronekit APIExceptions, of the format (from herelinks):
dronekit.APIException: mode (33554832, 0) not available on mavlink definition
or
dronekit.APIException: mode (0, 0) not available on mavlink definition

I have confirmed that these messages are from the Herelink setup itself. This can be confirmed by checking the mav.tlog produced using mavproxy and cross-referencing the messages. (I can link a gist of the tlog if desired, but it doesn't really provide more info)

Anyways, this has been recently addressed in the pymavlink repository and a fix was merged into their master: ArduPilot/pymavlink#769

I'm proposing a change (see PR) that uses mavutil's probably_vehicle_heartbeat function to ignore HEARTBEAT messages that don't come from vehicles.

This also relates to several other PRs/issues, such as #990, but should be more all-encompassing and robust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant