Skip to content

HEARTBEAT handler failing to handle non-vehicle HEARTBEATs #1187

Closed
@morzack

Description

@morzack

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions