Having already got my OpenLRS set up to send Mavlink data back from my plane (using the gitsly OpenLRS branch), the next step was to get Mavlink data displayed on my Taranis.

The Taranis need inverted levels to serial pin in the module bay so I build an inverter from the schematic here. 

I saw this topic a while back: MAVLink data displayed on OpenTX (9X/9XR/etc) radio screen via OpenLRS, plus telemetry pass-thru to PC and assumed this would also work on Taranis. No such luck! There is no EXT=MAVLINK option for Taranis in the configurator. 

However I managed to get the OpenTX build environment set up on Ubuntu following the instructions here without too many difficulties. Then is was a matter of redirecting the telemetry bytes into the existing mavlink code, and displaying the Mavlink settings and telemetry screens rather than the Frsky ones. I was quite surprised when it all worked however!  The Mavlink serial is also available from the serial connector on the OpenLRS module so that can be connected to a PC or Android device.

In the original 9X Mavlink firmware it was not possible to select which telemetry protocol to use except by reflashing. I need a mixture of S.Port and Mavlink telemetry depending on which plane I'm flying so that didn't suit me too well. I added an option in the model menu telemetry options to use Mavlink rather than S.Port or Dbus, so each model can have it's Mavlink or Frsky telemetry received and displayed :) . 

I also thought it would be useful to have the radio read the flight modes as they are receiver over Mavlink, this wasn't too hard to incorporate either. I created sound files for each Arduplane mode and added code to play them on receipt of a new mode.

Something else I would like do is to copy the Mavlink data into the normal Frsky variables so that they can be used in the normal way, i.e. read out, used in Lua scripts and for vario sounds etc.. It's on the to-do list.

Hopefully this will be useful to some people out there, I will post the code after I get a chance to clean it up slightly as it is a bit of a hack! For now the binary and sound files are here (they need to be in the SOUNDS/en folder):

https://drive.google.com/folderview?id=0B4xnWmfKh4FrVFl4YlU1Zm9nQU0&usp=sharing

Cheers,
Sam

Hello all,

I have been doing some work on Peter Braswell's Ardusoar code (http://diydrones.com/forum/topics/autonomous-soaring?xg_source=activity) to improve thermal centring.

I finally got around to getting HIL working in XPlane to allow some cross country soaring simulations. I am using the PT60 model which has a terrible glide ratio (about 1:7) so thermal strength has been set quite high (1000 ft/min) although thermal coverage is only 10%. The Ardusoar code is working very well - the extended Kalman filter does a good job of centring thermals and almost never loses them. The throttle is set to zero when soaring but is re-enabled if the altitude drops too low, allowing automated climbs back to a good altitude. The flight mode is AUTO until an updraft is encountered (climbrate exceeds a certain threshold) at which point the mode is switched to LOITER. In LOITER mode, the Kalman filter is updated whenever new measurements (GPS positions and barometric altitude) are available. The update takes 4-5ms and doesn't appear to slow down the main loop below 50Hz. My repository is here if anyone is interested in trying out the code. https://github.com/samuelctabor/Arduplane

Below is a several kilometre flight (this was a 5-hour Xplane flight) with quite a lot of thermal encounters. The code includes logic about whether a thermal at a given strength and height is worth taking. This leads to quite a few brief thermal encounters in which the algorithm begins to search for the thermal but decided not to continue based on the thermals strength (too weak for the altitude the plane is at).

Below is the altitude throughout the flight (after the initial climb to 850m, the motor is off). There are a few long thermal climbs, especially early in the flight up to 3000m (cloudbase).

Below is a close up of a typical climb. After switching to loiter mode (purple)  it takes a couple of circles to centre the thermal. 

The filter's states are saving in the onboard log to allow post-flight analysis. Here the algorithm's estimate of the thermal centre location is the blue track. You can see it moves it quite a bit during the initial centring and very little after that.

The internal model of the updraft strength is a Gaussian distribution. Effectively the Kalman filter tries to adjust the estimated strength size and location to match the measurements.

As you can see the states change quite a lot during the initial centring. After that they are quite stable except for some ripple. This is due to the XPlane thermals not quite matching the Gaussian distribution assumed in the algorithm.

I am hoping to do some real-world flight testing when the weather improves here. Eventually this code is going to be used in a 3m balsa Bird of Time glider I am building, but flight testing will probably be done on something a little more tough and expendable, probably a Parkzone Radian.

Happy flying!

Sam