[slik]

feat: MAVLink 2 external RF module

Adds MAVLink protocol support for external modules

• RC is sent as RC_CHANNELS_OVERRIDE
• Parsing basic telemetry values from HEARTBEAT, SYS_STATUS, GPS_RAW_INT, ATTITUDE, VFR_HUD and RADIO_STATUS

Build option -DMAVLINK=ON, off by default

Also ELRS TX MAVLink handset support:

• lua bindings implemented, so ELRS can be configured from the radio (the lua tool elrs_mav.lua included in the mavlink-handset)

Tested: TX15; Zorro and TX12 mk2 require something to be turned off to fit, for example -DGHOST=NO -DDSMP=NO

[rotorman]

Whoah, the last two are pretty high frame-rates, somewhat unusual for a MAVLink link.
Is the plan to fly racing quads with MAVLink?

[Vavooon]

I see, these are the same as CRSF values.
But I though of some points:

• ArduPilot already works fine with the same intervals while paired with a CRSF-capable receiver.
• It might cause confusion for users who are expecting the same update rates regardless the protocol
• ELRS allows to use up to 1000 Hz update rate in MAVLink mode
• MAVLink can (theoretically) be used on INAV or Betaflight racing quads

[rotorman]

Please also consider proper MAVLink system and component ID handling. For more, please see: https://mavlink.io/en/services/mavlink_id_assignment.html

[Vavooon]

Please also consider proper MAVLink system and component ID handling. For more, please see: https://mavlink.io/en/services/mavlink_id_assignment.html

Would you mind pointing us to the exact part you mean? We use common sysid:compid sets, e.g. 255:MAV_COMP_ID_RADIO and 1:MAV_COMP_ID_AUTOPILOT1

[rotorman]

See: https://mavlink.io/en/messages/common.html#MAV_COMP_ID_TELEMETRY_RADIO and you might want to also read https://discuss.px4.io/t/what-is-and-how-does-one-select-a-system-id/6905/6

Have a look e.g. at mLRS system for reference: https://github.com/olliw42/mLRS-docu/blob/main/docs/MAVLINK_PARAMETERS.md and https://github.com/olliw42/mLRS-docu/blob/main/docs/PARAMETERS.md#rx-mav-system-id
Some related code snippets to look at: https://github.com/olliw42/mLRS/blob/f90920c98b7679552cefc106faedad006cd296da/mLRS/CommonTx/mavlink_interface_tx.h#L38 and https://github.com/olliw42/mLRS/blob/f90920c98b7679552cefc106faedad006cd296da/mLRS/CommonTx/mavlink_interface_tx.h#L647

Do you plan to submit a PR to ExpressLRS with your mods, or is the plan to offer the RF module side support in your fork (only)?

[Vavooon]

@rotorman Sorry, I'm still not getting the point. Do you suggest to change SYSID/COMPID to other values or make them configurable in the menu?

Yes, we have the ELRS part ready, gonna submit it soon.

[rotorman]

Configurable would be good indeed, as this way conflicts could easily be circumvented by the end-user.

[Vavooon]

@rotorman Great, what do you have in mind? Is it source and target SYSIDs, or COMPIDs as well?

[rotorman]

Consider a practical use case, where over a single MAVLink stream multiple craft can be controlled.
You also want to possibly address the RF module itself and vice-versa - the RF module (or other parts of the system) might want to send messages to the handset, which on the other hand might not work as GCS, but only relay the info towards the GCS.

In general, MAVLink router functionality would also be very interesting, e.g. connecting to other MAVLink speaking devices either via USB-VCP or via AUX ports that some radios possess.

[Vavooon]

With all my love to over-complicate things, I'm not sure we will see practical MAVLink multi-vehicle networks any time soon :)
However, I think it's worth to make SYSIDs configurable in this PR as it should not be so much work.

Regarding MAVLink routing, that'd definitely be a task for later. So far we probably should only add it to the ELRS side to work with existing Backpack functionality.

[Vavooon]

@rotorman So what's your idea regarding (default) handset component ID?
We use MAV_COMP_ID_RADIO but now it looks like to me that it is rather intended for data links (similar to MAV_COMP_ID_TELEMETRY_RADIO which we already use for ELRS TX module.

[rotorman]

Have a look e.g. at mTX project (OpenTX fork with MAVLink additions) for pointers: https://github.com/olliw42/mTX-otx/blob/daa9c3cb9ca52b45ed3c2c45d0d649144a8ad1e9/radio/src/mavlink/mavlink_telem.h#L79-L80

[Vavooon]

I'm not sure we should use 254 as default system id, as it might require users to change MAV_GCS_SYSID in order to get RC input working.
Also, ELRS already uses 255 as SYSID: https://github.com/slik/ExpressLRS/blob/3069ab605e163739d5aa9b56443355e3d1032485/src/lib/MAVLink/MAVLink.cpp#L349
A handset with ELRS TX module looks like one MAV system to me.
Even if we relay MP over Backpack or USB VCP, it likely can be considered as a single system, just different components, as they perform various roles.

Regarding component ID, MAV_COMP_ID_MISSIONPLANNER + 4 is in fact MAV_COMP_ID_ONBOARD_COMPUTER4 which is quite a difference.
My idea is to stick to [MAV_COMP_ID_USER1](https://mavlink.io/en/messages/common.html#MAV_COMP_ID_USER1) (or USERx) for now

[rotorman]

Please consider that a handset can have multiple RF modules (most EdgeTX radios currently support internal and external RF modules at the same time), thus seeing a handset + RF module as a single item would not be ideal.

[Vavooon]

Are there real world use cases though?
I don't mean that it's a single item, but a single system with separate component IDs.
In your example I see it as:
MAV_COMP_ID_HANDSET
MAV_COMP_ID_RADIO1
MAV_COMP_ID_RADIO2

[rotorman]

@slik I cannot yet see a PR against ExpressLRS repo with your changes to see the reaction to your work from ELRS dev. team side.

[vifino]

Hi! Would this also be relevant for using with mLRS?

I would definitely also love to see a full MAVLink router on EdgeTX eventually.
I imagine routing between transmitter module, USB and aux serial ports, for stuff like injecting RTCM corrections from the radio or an ADS-B receiver (like ADSBee).

[rotorman]

No, mLRS speaks either CRSF or mbridge, not the lingo this PR proposes.
Regarding MAVLink routing - https://github.com/olliw42/mTX-otx/ can do it, but it is based on old OpenTX.
See 5 year old post of mine: https://www.rcgroups.com/forums/showthread.php?3840597-Blog-5-Native-MAVLink-telemetry-with-RadioMaster-TX16S

[olliw42]

Hi! Would this also be relevant for using with mLRS?

@vifino: see https://github.com/olliw42/mTXe ;)

[Vavooon]

@rotorman We have added configurable SRC and DST SYSID as you asked. Please check whether it looks good to you.
Regarding ELRS PR, we're still fixing some issues, and we will post an update once we have a PR.

[rotorman]

Happy to see that you added end user selectable source SysID and target SysID options into the UI!

In order to simplify testing for the interested parties, you could for now turn the MAVLINK feature on in this PR by default:
https://github.com/slik/edgetx/blob/e2b90262af0c782d07ac6e6aa1f729a352f13d29/radio/src/targets/common/arm/CMakeLists.txt#L17

This way, the binaries would be directly flashable, e.g. by using EdgeTX Buddy PR selection (including the optional MAVLINK feature of this PR):
https://buddy.edgetx.org/#/dev/flash/pr?version=pr-7832

Waiting eagerly for your ELRS PR and the feedback from the ELRS dev. team to that upcoming PR.