Sending and recieving heartbeats to BlueROV from surface computer using pymavlink

[EliotBR (Eliot)]

@joshholder

Thank you so much! You managed to identify the critical gap in understanding that I had - sensor readings as well as thruster firings are working as of now.

Great to hear!

@joshholder

So to clarify, within the mavlink_connection() object, it stores a list of received messages. When calling master.recv_match(type=‘ATTITUDE’), it grabs the first received ATTITUDE message on the list, returns it, and then removes it from the list.

It’s not a list - it’s a stream of packets (the main difference being it’s only one-way - once you’ve received a message you can’t un-receive it, or go back through previous ones unless you’ve saved them yourself in some other data structure). Some pointers/notes:

• Calling recv_match with a type check parses that stream:
  1. converts the earliest data into a message
  2. stores the message in the master.messages dictionary (keeps track of the latest message of each type)
  3. returns the message if it’s one of the requested types, otherwise continues parsing
  4. If it gets through all the data that it’s received (no more messages available to read) without finding the requested type then it returns None by default.
• If you set blocking=True then instead of returning None when it runs out of data it does a blocking wait and just waits for more data until eventually the requested message type arrives (if it ever does).
• If you set a timeout then it will read messages either until it runs out of them or until the timeout has been reached.
• If both blocking and timeout are set then the timeout acts as an early-stop, that prevents endlessly blocking if the message isn’t arriving.
• For completeness, calling recv_match with no type check just tries to get and return any message, if one is available, otherwise returns None (timeout and blocking apply as normal).

@joshholder

Follow-up question in this case: given that the list of received messages is always growing, is there some upper limit when messages start being culled from the list? Otherwise, wouldn’t the amount of data grow without bound?

Your operating system has a default UDP buffer length, but it’s not a circular buffer (i.e. if it gets full then old packets aren’t overwritten - new ones are dropped). From what I can tell the pymavlink UDP option doesn’t attempt to override/specify a buffer length, so it will depend on your operating system.

@joshholder

Also, do you have recommendations for documentation sources for mavlink itself? I completely missed this subtlety in my research

There seems to be another slight misconception here - Pymavlink is a Python interface to the MAVLink protocol, they’re not the same thing (i.e. there are several other interfaces to the MAVLink protocol, in different programming languages). The MAVLink documentation is a bit tricky to navigate, but has reasonably good coverage of the mavlink protocol, available messages (common and ardupilotmega for ArduSub), and relevant micro-services.

Pymavlink provides several utilities to make working with MAVLink easier, but has quite minimal documentation, and the documentation that does exist is written as though you already know how MAVLink works and happen to want to use a Python implementation of it (which is the case for the main developers of Pymavlink, but makes it not particularly beginner friendly).

The idea is seemingly to “lead by example”, in the sense that some examples are provided in the pymavlink repository, and if you want more information about particular functionality then you should go look in the code for how it’s implemented. We (Blue Robotics) have our own set of ArduSub-specific examples for small snippets of functionality, but the rc_override_example gist I made a few weeks ago is the first ‘complete program’ example we have.

@joshholder

even now I’m not able to find great documentation on periodic_event() or other mavlink functions.

periodic_event is a Python class which I found (quite recently) while looking through the mavutil implementation file, although it’s also used in some of the Pymavlink repo examples. It’s not related to MAVLink at all (it’s just Python code that checks whether a specified amount of time has passed) - it’s in mavutil because it’s a useful utility for working with MAVLink connections.

Because of Python’s popularity, Pymavlink is a reasonably common starting point for people wanting to start interfacing with MAVLink devices. The lack of beginner friendly docs is becoming enough of a support issue on our end that it will likely end up being one of our/my priorities early next year to write some decent introductory documentation that makes it easier for people to get started. I’m not yet sure if that would be best done generally and contributed to the official Pymavlink documentation, or if it makes more sense to target it at ArduSub and put it in our own docs. At minimum, we very much agree that the current Pymavlink docs don’t make it super easy to get started with development, and that’s important enough to us and the users of ArduSub that we’re planning to help change/fix it