The project effectively turns them into a ground control station for operating your drone. That is, the transmitter not only allows you now to receive the most detailed telemetry data, but also provides a full, bidirectional MAVLink communication link with appropriate bandwidth to the drone and therewith the set of capabilities possible with this. For instance, you’ll find the project to offer unprecedented camera and gimbal control capabilities.
The project has several aspects:
- Hardware: The solution does NOT need any additional hardware, such as converters, teensys and so on!
- OpenTx: Extension of the OpenTx firmware to handle MAVLink.
- Telemetry Scripts: Fully practical MAVLink telemetry script.
Comment: I distinguish between drones and racers. As regards the communication link racers don’t need the same capabilities as drones do, in terms of bandwidth and bi-directionality, and the options available for racers may be considered sufficient. This is IMHO clearly not so for drones, and MAVLink is the protocol used by the de-facto standard open source drone projects PX4 and ArduPilot. And this is what this project is about.
This project is already quite functional, but clearly, it is work in progress. There is really soo much more one still can do and improve … 🙂
The following picture and video gives an impression of the current state of affairs (as of 15.Feb.):
Comment: In this video I’m saying that the frequent loss of telemetry connections are due to being indoors. However, it turned out that the real reason is that I had upgraded the SiK radios to the latest firmware using MissionPlanner, which appears to be screwed up. Since I flashed the SiK’s with a proper firmware I don’t have any of these issues anymore. 🙂
This video demonstrates that it works in the „real world“, by means of a drone quick shot (as of 13.Mar.):
- Github repository with scripts and all the stuff you need: https://github.com/olliw42/otxtelemetry
- Github repository with firmware source: https://github.com/olliw42/opentx/branches
- PR in the OpenTx github repository: https://github.com/opentx/opentx/pull/7702
- Discussion thread at rcgroups: https://www.rcgroups.com/forums/showthread.php?3532969-MAVLink-for-OpenTx-and-Telemetry-Script
The idea to add MAVLink support to OpenTx is not new (see e.g. here, here). It also was extensively discussed ca 2 years ago here, and a first albeit very rudimentary implementation was pr’ed here, but both the discussion and the PR went stale long ago.
However, telemetry with sufficient data rate is obviously of great importance, especially for drones, and the currently available options to combine them with OpenTx-based transmitters are – as impressive works they are – little else than hacks and workarounds to get some of the functionality. The FrSky passthrough protocol is a good example. It needs special code on the flight controller, a special converter, the wiring is also not so nice, and the data rate is low. In comparison, MAVLink drone systems typically use full-duplex serial wireless links with baudrates of e.g. 57600 bps. Examples are the abundant 3DR telemetry units, Dragonlink and similar uints, wifi-based telemetry units, and so on.
So, hardware-wise, all it really should need for installing the telemetry unit is to connect two Rx,Tx wires to the RC transmitter.
Anything else, like using additional modules to squeeze some of the data through the SPort pin, really doesn’t make much sense to me. I know that this view may not be shared by all, but to me this looks obvious. So I started this project, and arrived at the following concept:
Obviously, I considered it a strict requirement that one should not need any additional hardware like converters, and accordingly rejected any potential solution which didn’t comply with this. The good news is, this is indeed achieved.
However, this doesn’t necessarily mean that one doesn’t have to do some hardware work on the transmitter. This is so because many transmitters simply don’t provide suitable connections to the outside. In these cases one has to solder some wires to the transmitter’s main board, and depending on your soldering skills you may consider this very difficult or very simple. But that’s really all this project needs hardware-wise. I note that now also OpenTx transmitters are available which expose an UART port to the user, such as the RadioMaster TX16S. These are actually kind of perfect fits for the project.
Comment: My only OpenTx-based transmitter is a Jumper T16 Pro, and the project is thus currently biased towards it, since this is what my development platform is. However, in principle, it really should work also for the FrSky Horus or the RadioMaster TX16S, i.e. transmitters with a large color display. The project IMHO doesn’t make sense for transmitters with small(er) display.
B. OpenTx Firmware
The OpenTx firmware additions I’ve created can be described by three layers:
FrSky Sensor Mimicry: The incoming MAVLink messages are – as far as reasonable – translated into corresponding FrSky sensors. That is, a sensor discovery will find a dozen or so of sensors, which can then be used exactly like any „real“ sensor. For instance, they can be put on the screen, but also can be used in scripts as normal. The idea here is to provide a most simple access to the data and to allow us using it in familiar ways – hopefully your favorite script will just work.
MAVLink SDK: This is a higher-level interface to access the MAVLink functionality in scripts, and is really the main driver. The idea here is to make it as simple and convenient as possible to write a telemetry script. For instance, the rich functionality provided by the well-known Yappu FrSky Telemetry script can be realized by calling some simple Lua functions, but of course richer functionality such as camera and gimbal control or guided drone control is also provided. This set of functions is provided by the mavsdk module; that is, in the Lua script they are called as, e.g., mavsdk.getGpsLatLonDeg().
MAVLink API: This is a low-level interface to access the MAVLink functionality in scripts. It provides full access, and allows us to implement sophisticated ground control station capabilities, but it obviously makes writing scripts more difficult.
Comment:The MAVLink API is more difficult to implement than I initially thought, and it is currently effectively not existent. I need to spend more time on this.
I hold the code additions to OpenTX in my OpenTx fork. I also have opened a corresponding PR in the OpenTx github repository. Let’s see what happens with it 🙂
C. OlliW Telemetry Script
A further and important part of the project are practical Lua scripts. The cornerstone is the MAVLink Telemetry Script. On the one side, it re-implements familiar telemetry features, at least to some extend (and I want to acknowledge that the layout of this part is indeed much inspired by the Yappu FrSky Telemetry script!). However, it clearly also aims at adding new functionality such as gimbal and camera support, and other stuff.
As indicated in the above, no additional hardware like converters and such is needed, but some hardware work needs to be done.
What needs to be done is to get access to Rx & Tx capable pins. For the Jumper T16 this means that one has to solder three wires (Gnd, Rx, Tx) directly to the transmitter’s main board. Several options are possible. I have chosen the UART3 pins. But also pins on the unpopulated Bluetooth module area would be possible, and other pins too. So, if you prefer those over the UART3 pins, because you consider them easier to solder, then please tell me, and I will adapt the firmware accordingly.
This now very much depends on which wireless link you are using: In case of a 3DR telemetry radio you also need power to run it. Again, several options are possible. I did it by soldering two further wires to appropriate points on the transmitter main board.
The following video shows what I did with my Jumper T16 Pro:
3. Firmware and Script Installation
A. Installing OlliW’s MAVLink OpenTx
The installation of the modified OpenTx firmware is relatively simple.
But it is limited to the Jumper T16 transmitter currently, and only one options configuration is provided. If you want to use it with different options or on a different transmitter, then please contact the discussion forum.
The procedure is as follows:
- Download the latest firmware binary, named openttx-t16-2.3.7-XXX.bin, from the Github repository.
- Start OpenTx Companion for 2.3.7.
- Switch off the transmitter.
- Connect the transmitter via USB to your PC.
- In OpenTx Companion search the menu „Read/write“ and select the option „Write Firmware to Radio“.
- Select the firmware binary by clicking the „Load…“ button.
- Hit the button „Write to Tx“.
- Be patient, the process can take few minutes.
I certainly hope that the code additions will eventually be merged to the OpenTx main branch, and that this chapter really becomes obsolete. However, as said in the above, that’s not my decision, and not under my control. We just can hope 🙂
B. Installing OlliW Telemetry Script
Also the installation of the OlliW Telemetry Script is simple, and essentially works as for all the other scripts out there.
The procedure is as follows:
- Download the latest sd card content from the Github repository.
- Power on the transmitter.
- Connect the transmitter via USB to your PC.
- This – at least on Windows – will bring up an explorer showing the content of the SD card in your transmitter.
- Drag and drop the downloaded folders named „WIDGETS“ and „SOUNDS“ into the explorer showing the transmitter’s SD card content. This will copy the files to the transmitter’s SD card.
- Disconnect the transmitter from USB and switch it off.
- Power on the transmitter, and install the widget script according to the OpenTx manual.
C. Video Tutorial
The procedures are also described in this video: