Added support for MavSDK (native MAVLink by OlliW MAVLink enhanced OpenTX firmware)

[rotorman]

Dear Alex, I added to your lovely telemetry screens support for OlliW MAVLink enhanced OpenTX firmware. The modifications are tested with OlliW opentx16s-2.3.11-rc05 firmware running on RadioMaster TX16S. MAVLink telemetry data was input via TX16S external UART AUX1 port at 57600 baud from ArduPlane v4.0.8.

Native MAVLink support is nice, as one can omit additional hardware, such as Mav2PT converter Teensy or ESP board and also no precision is lost in conversion (MAVLink -> Mav2PT -> FrSky PT -> LUA telemetry vs. MAVLink -> LUA telemetry). This is IMO especially interesting for long range radio users, such as DragonLink. MavSDK supports also return-channel, but the additions in this PR do not make use of that (this also means that only UART RX line of the radio can be connected).

There is one unchecked issues to me with present PR: MAVLink and CSRF should probably not be enabled at the same time, so a different kind of selection dialog for FrSky PT, CSRF or MAVLink might make more sense. If MAVLink is enabled, then it overrules FrSky PT parsing. Due to lack of CSRF hardware on my side, I could not test if anything bad happens if both are enabled when CSRF hardware is present.

If you would consider possibly fixing/checking the issues and merging this PR to your telemetry screens, I would be more than delighted.

Best, Risto

Update: I added an Excel sheet that I created to help me understand how the data is passed from MAVLink via Mav2PT over FrSky PT to your telemetry table and how OlliW firmware is mapping MAVLink messages and payloads to his Lua functions. TelemetryVariablesMapping.xlsx

Update2: I created on RC Groups a post listing the changes I made to your script: https://www.rcgroups.com/forums/showthread.php?3840599-Blog-6-Modified-Yaapu-telemetry-widget-to-support-MavSDK-native-MAVLink-on-OpenTX

[yaapu]

Nice job, but I will not merge this until mavlink support will be officially included in OpenTX, main reason is I would not be able to provide adeguate support, sorry.

Edit: you did a really good job, hope you understand my reasons, thanks

[rotorman]

I understand. I'm keeping my fingers crossed that MAVLink gets integrated into OpenTX someday!

You might want to have a look at my tiny draw.lua mod nevertheless. This fix for ARMED dialog is also interesting for Mav2PT, that combines telemetry.statusArmed and telemetry.landingComplete into one, which results the ARMED dialog sometimes not display and sometimes only very briefly.

[rotorman]

Please also see the fixes in Yaapu Config.lua and menu.lua for map detail selection, which was not working correctly in 1.9.3-beta2 (it reset after each change back to min value -2). Now also the limits are checked when map product is changed and only adjusted to closest limit, without resetting the value completely.

[yaapu]

Please also see the fixes in Yaapu Config.lua and menu.lua for map detail selection, which was not working correctly in 1.9.3-beta2 (it reset after each change back to min value -2). Now also the limits are checked when map product is changed and only adjusted to closest limit, without resetting the value completely.

this is fixed in my dev version, thanks anyway

[yaapu]

You might want to have a look at my tiny draw.lua mod nevertheless. This fix for ARMED dialog is also interesting for Mav2PT, that combines telemetry.statusArmed and telemetry.landingComplete into one, which results the ARMED dialog sometimes not display and sometimes only very briefly.

this fix would apply ONLY to MavToPT, armed and isflying are independent in ardupilot, I advised Eric to combine them because there was no way to have the is_flying info from mavlink

[rotorman]

You mean MAVLink #245 EXTENDED_SYS_STATE with MAV_LANDED_STATE MAV_LANDED_STATE_IN_AIR ? If so, this is an interesting message and I might ask OlliW to implement this.

[rotorman]

Thank you for the tip! Done. I am considering drawing a small antenna symbol and picturing it instead of writing an "RSSI: " (original "RS: ") to save space and be optically even nicer.

[yaapu]

An icon would brake rssi layout with crossfire and would be much less precise, people like to see the value for rssi, you can however make your own version with graphics improvements, that's the beauty of opensource

[rotorman]

I like the value as well and did not mean to replace it, but just the prepended label "RS: " ("RSSI:" in my mod) with a symbol. In drawRssi() instead of lcd.drawText() -> lcd.drawBitmap(utils.getBitmap()) Value will still be displayed with lcd.drawText() right of the symbol.

[yaapu]

ok then go ahead :-) usually images are even cheaper than text for the cpu, at least for small texts

[rotorman]

Here is a small overview of my changes: https://www.rcgroups.com/forums/showthread.php?3840599-Blog-6-Modified-Yaapu-telemetry-widget-to-support-MavSDK-native-MAVLink-on-OpenTX