[proposal] mavactive: util to send heartbeats in the background

[ES-Alexander]

According to the heartbeat microservice docs:

A component is considered to be connected to the network if its HEARTBEAT message is regularly received, and disconnected if a number of expected messages are not received.

Accordingly, for active mavlink connections it's useful to be able to send regular heartbeats without needing to set that up manually as part of every script/program.

This PR provides a mavactive class for managing an active mavlink connection, which:

• Sets up a thread for sending regular heartbeat messages
• Allows live control of heartbeat parameters (e.g. to represent changes of autopilot state)
• Allows killing (and reviving) the heartbeat thread at any point
• Swaps out the internal file object of the managed mavlink connection with a wrapped equivalent that's thread-safe for writing

[ES-Alexander]

It's possible this is better placed within mavutil.py, for example here (just after the mavlink_connection definition), but I'm not sure so have proposed it in its own file for now.

[peterbarker]

On Sat, 14 Aug 2021, ES-Alexander wrote: Accordingly, for active mavlink connections it's useful to be able to send regular heartbeats without needing to set that up manually as part of every script/program.

Doesn't this lose the whole idea of a heartbeat - that your component is actually alive? Sending the heartbeat as part of your main control loop (rather than in a thread) would seem to be rather more preferable as it is a much stronger indication your component is alive and kicking.

[ES-Alexander]

Sending the heartbeat as part of your main control loop (rather than in a thread) would seem to be rather more preferable as it is a much stronger indication your component is alive and kicking.

Interesting take. I'm seeing it more from the perspective of if you had something like a slow sensor or processing step then having a separate thread for heartbeats enables frequency consistency and simplifies the main program logic (i.e. our hearts keep pumping even if we're busy - it doesn't always make sense to focus on it 'consciously'). A similar idea applies for a passive observer, where you want to keep getting information so the heartbeat is just there to say "hey I'm still here, please keep sending messages" - simplified logic is appreciated.

I'd agree that a thread-based heartbeat would be a worse indication of aliveness in the specific case of the main program getting into a blocked state that it can't get out of. For cases where the main program ends (e.g. via completion or exception) both multi-threaded and single-threaded methods are equivalent, and for cases where the main process is subject to long enough waits/calculations to be significant on the heartbeat timescale then a threaded approach is perhaps preferable.

I'd also make the case that having separate threads for different functionalities can be helpful for simplifying logic in each functionality (they can be programmed and operate independently). I'm not saying this approach is always better than a single-threaded approach, but it provides a choice that (at least to me) seems sufficiently useful that it should be available, so users can make their own decision about what is most appropriate for their particular use-case 🙂