Added support for MavSDK (native MAVLink by OlliW MAVLink enhanced OpenTX firmware) #90
Conversation
- added support for google maps downloaded via MissionPlanner - new tiles resize tool for google maps supporting sat and hybrid maps - new zoom control using a switch as up/down wheel emulator - added scrollable status message history (up to 200 messages) using the emulated wheel - added flight time to message history - added a status bar in message view with flight mode and flight time - improved mini HUD in maps view - many memory and speed optimizations
added support for reading older config file versions
Added scaling to RSSI as to rc05 from OlliW.
rotorman
changed the title
Decimal digits overrun fix
Oversaw fully that I was missing telemetry.lat and telemetry.lon assignment. Fixed herewith.
Bugfix: Flightmode needs +1 as also done by Mav2PT.
Uniform handling for resetting home pos on arming
Especially for systems that do not separate telemetry.statusArmed and telemetry.landComplete, but handle them together (Mav2PT, OlliW MavSDK), the previous code did not display "ARMED" dialog correctly. If it was seen at all was dependent on the (random) state of timer for blinkon variable at the time of call to drawArmStatus(). The change here defaults to approx. 1.5 second display when state is changed from disarmed to armed, which can be shortened only in case in this time disarmed is again chosen. The result is clearly displayed "ARMED" message.
Improved indenting
Removed misleading dilution of precision unit (it's unitless) Issue yaapu#88
|
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 |
|
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. |
Fixes the bug that every change of map detail reset the value. Here also the limits are correctly checked according to map product selected.
Fixes the bug that every change of map detail reset the value. Here also the limits are correctly checked according to map product selected.
|
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 |
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 |
|
You mean MAVLink #245 EXTENDED_SYS_STATE with MAV_LANDED_STATE MAV_LANDED_STATE_IN_AIR ? |
Added credentials
Added credentials, also to display output
|
ok then go ahead :-) usually images are even cheaper than text for the cpu, at least for small texts |
I did not touch the CSRF RSSI display though as don't have hw to test it. Additionally, this commit wraps all mavsdk calls into if mavsdk ~= nil then ... end wrapper, so that on non-OlliW OpenTX firmwares the script does not get disabled anymore even if the user selects from configuration to enable MAVLink nevertheless. I might add a warning pop-up of some sorts as a feedback for the user of this misconfiguration.
…g on OpenTX build without OlliW MavSDK extensions.
…tion. GPS connected directly to OpenTX UART). Added a menu item to select the source of home position - either from armed position or from radio position (the latter could be moving, which gets constantly updated. Think e.g. flying from a car or a boat). Added a small radio icon to symbolize if the radio GPS is selected. Minihome icon is displayed for "normal" behavior. This works also w. std. FrSky PT and tested with vanilla OpenTX v2.3.11 with internalgps build option baked into (test was done with u-Blox SAM-M8Q GPS outputting NMEA at 9600 baud).
…er not to miss a message (OlliW buffers also 4 messages). 2) Added battery failsafe parsing. 3) Added a red blinking rcradio symbol to signal if radio GPS is enabled but no GPS hardware is connected to radio or the OpenTX build does not have internalgps baked in.
…show red blinking icon if internalgps is not baked into OpenTX firmware.
HomeDistance scaling change to km, if > 9999 meters.
… as MAVLink can output also higher numbers as they are.
Merged Yaapu beta4
|
Here is a small overview of my changes: |
Indentation (spaces instead of tabs)
…geTX todays main branch).
yaapu
force-pushed
the
dev
branch
2 times, most recently
from
9bad45b
to
1b2d8fa
Compare
…nd PREC2 if required for more beautiful appearance.
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