I remember adding LTM to my tracker a while back. If I’m not mistaken they determine that GPS coordinates are Northern or Southern hemisphere by “N” or “S”. But perhaps that has changed.
There is a huge amount of redundancy in Mavlink, but of course it is massively rich in function. Good for everything, but maybe not the special case of very long distance limited bandwidth telemetry.
FrSky PT is enough to drive a nice HUD, and report mission progress, especially on long distance flights, like you do.
Hello Alex, I’m back. What would you like to do next with bi-directional? I tested Ground Mode with the Horus today and it seems to be ok. Tomorrow I’ll test Air Mode. Do you have any more transaction types you would like the try?
Parameters are organized in pages, you toggle pages by pressing the PAGE up/down button.
Tuning pages are shown first right after the scripts detects the frame type.
After the tuning pages you get the parameters defined in the lib/default_params.lua file, these are shown for all models and all vehicle types.
You can have per model and per vehicle parameters defined in the YAAPU\CFG folder params<1|2|3|…|n>.lua
<copter|plane|rover>params<1|2|3…|n>.lua
Format is the same for all parameter files, it’s pretty simple just take a look at one of the examples.
I’ve merged in FPort support in master. Please see this post for details:
Note that the changes for FPort support should also help a lot of people using SPort. We have new BRD_ALT_CONFIG options, plus I have improved the handling of half-duplex mode to work on a wider variety of boards.
I had some time to work on bidirectional telemetry and finally found a way to add COMMAND_LONG support.
For those interested in the details I had to create a minimal GCS_MAVLINK backend dedicated to frsky telemetry initialized with a dummy empty serial driver (this type of backend usually is tied to a FC serial port and handles all mavlink traffic between the vehicle and a GCS).
The equivalent mavlite structure for the mavlink COMMAND_LONG is:
2 bytes for command id
3 bits for parameters count (max 7 parameters)
5 bits for confirmation counter
up to 7 parameters as 4 bytes floats
payload max size grows from 20 to 31
I do not blindly pass through all commands, right now I allow only
MAV_CMD_DO_SET_MODE:
MAV_CMD_DO_FENCE_ENABLE:
MAV_CMD_PREFLIGHT_REBOOT_SHUTDOWN:
MAV_CMD_DO_START_MAG_CAL:
MAV_CMD_DO_ACCEPT_MAG_CAL:
MAV_CMD_DO_CANCEL_MAG_CAL:
MAV_CMD_PREFLIGHT_CALIBRATION:
MAV_CMD_REQUEST_MESSAGE:
I also updated my FrskyLuaGCS script to support invoking command_long messages from my HORUS.
I updated my PR for bidirectional telemetry, the code is here
@Eric_Stockenstrom I released a dev version of the Lua GCS, it’ here this version can send mavlite command long packets, I’m working on a simpler tool that just sends a specific command every couple seconds, it should make it simpler to work with the new mavlite command_long message.
Alex, I am playing with full camera control of a GoPro Hero 7 Black via Malvink, courtesy of @olliw42 Right now it is limited to only control via QGC but it looks like this could accommodate some basic camera control via Mavlink from the Horus.
In order to use the mavlink control I do not even need a fork. All the autopilot is doing is relaying messages, so some extra ones need to be added to the common xml file:
(these are stable ones)
PARAM_EXT_REQUEST_READ
PARAM_EXT_REQUEST_LIST
PARAM_EXT_VALUE
PARAM_EXT_SET
PARAM_EXT_ACK
(I think these are WIP and not essential)
PROTOCOL_VERSION
TUNNEL
So I just paste these in to the common xml file and compile. Stable, Master, or whatever custom branch. I was hoping to be able to merge these but I cannot do this with submodules. The maintainer of mavlink in Ardupilot has basically ignored my requests to add the stable messages to the mavlink submodule. If it looks like we can use this in OpenTx I will directly ask Tridge to get them added – frankly I do not understand the point not merging stable Mavlink messages into Ardupilot.
@olliw42 has done some pretty fantastic work on this. At the moment it does requite a Storm32 board to handle these mavlink messages and an ESP32 to talk to a GoPro, but in theory an ESP32 could do it all if you were not doing gimbal stabilization. Rumor has it Olli is jetting a Jumper T16 Pro.
Ardupilot is only relaying messages from the GCS to the mavlink camera controller.
for the realy to work ardupilot needs to identify the messages so it requires an updated common.xml
I guess that QGC uses
PARAM_EXT_REQUEST_READ
PARAM_EXT_REQUEST_LIST
PARAM_EXT_VALUE
PARAM_EXT_SET
PARAM_EXT_ACK
to determine camera capabilities and then probably uses the camera microsystem commands to trigger image/video.
This is a very complex flow to replicate from OpenTX, so complex that misson planner has not even implemented it.
Anyway for this to work the frsky library would need to have access to the mavlink channel used by the FC to talk to the storm32 and read/write messages in that channel.
In ardupilot’s current implementation this is not easy at all.
Each vehicle has a GCS component which routes messages between the various mavlink channels created by reading the SERIAL_PROTOCOL settings. I could not find an easy way to read/write mavlink channels thru this GCS so I resorted to creating my own frsky mavlink backend.
Having a private backend let’s me process most of the messages locally but does not allow to talk with other devices via relay.
Handling this from ardupilot seems like a lot of work but it should be easier by going the MavToPT way.
The MavToPT firmware has acces to a real mavlink channel so it has native relay functionality provided the messages are targeted at the right ID.
@olliw42 does have this fully implemented in the daily build of QGC. I actually have just been testing this. It may not be feasible with OpenTX for reasons you describe. I am trying ti get my head around how MavToP would work since it does not have any UI component now – well I guess you can add switches or a button pad to the ESP2! Anyhow, I am pretty happy with what i have now actually as I can control a decent camera on longer flights. So I am not going to distract people with this just yet.
I am trying to understand the physical connections when using your bidirectional telemetry implementation with a Pixhawk 1 and FrSky X8R. Currently, I have the typical FrSky PassThrough setup as described in the Wiki along the the SBUS to RCIN connection for R/C control. This setup works great for Yaapu telemetry and your new mapping feature.
Are you using a bi-directional inverter as in Tridge’s FPort inplementation for F4 based FC boards?
One more question if I may, it seems the FPort implementation needs a receiver that supports the FPort protocol like X4R but your bidirectional telemetry implementation can work with an X8R. Is this correct?
Why?
I was thinking about a pure lua based GUI.
With @Eric_Stockenstrom’s help we could build a full solution.
A lua based GCS would issue mavlite commands from opentx to the ESP32 via bidirectional frsky, the esp32 would convert mavlite to mavlink and forward to the FC. The FC would inspect the message and relay mavlink to the camera controller.
For bidirectional sport telemetry nothing special is required, if you have the yaapu telemetry script working you are all set.
Current master does not have bidirectional sport support, in order to test the feature you’d need to use my branch.
For fport you have 2 wiring choices:
use RCIN on your board
use a serial port with SERIALn_PROTOCOL = 23
Option 1 is oneway and only allows for RC control, it uses a full software serial implementation and tridge needs to extend it to be two way before we can have telemetry on it.
Option 2 allows both RC + telemetry on a single wire.
It’s two way but right now telemetry is one way only for I haven’t integrated my patches with the fport code.This option requires the very same options/adapters/inverters that are needed by sport, which options to use depend on the board capabilities. For an F4 board for example you still need an inverter ,check here for some examples.
Yes, for fport you need an fport capable receiver like the x4r.
For bidirectional sport X8R works just fine as well as any other sport capable receiver like the R9 series, xsr etc…
@Eric_Stockenstrom I released a dev version of the Lua GCS, it’ here this version can send mavlite command long packets, I’m working on a simpler tool that just sends a specific command every couple seconds, it should make it simpler to work with the new mavlite command_long message.
Nice work Alex ! Impressive. I have some time to get into this again. Could you let me know when the new tool is ready?
