Hi all,

we have something new that people are working on: EdgeTX! And that with the blessing of OpenTX, from which it was forked.
This opens up the possibility to suggest some changes to the LUA API. Because, let's face it, after some initial blooming of scripts for the Taranis, its is rather quiet lately. And widgets didn't add to the fun. What are the main problems with the current implementation?

Well, first you would need to decide what the current implementation was intended to achieve.

I have no real clue there, but at least some model settings where exposed to LUA, so that wizards could work. Well, those have never been really useful, because once you used a wizard to create a model, try changing it. No way to understand without diving into it and spend more time on figuring out than on jus throwing the model away and use the wizard again. I see lot's of people doing that. Not really the best way, but moderately useful.

Then we saw people using it to display telemetry data in more intelligent ways. Graphs, nice cockpits, artificial horizons, ... Really nice, but not that well supported because of all radios having different layouts, and no API functions to support that.

Finally, we never saw people really trying to exchange small scripts they developed themselves. Main reason in my opinion is the fact that they stopped working after every major release, and you would have to make sure they worked on all radio types, not really easy.

So, room for improvement!

Introduction
In the F3K model glider competition, there is one task that asks for a specific timing strategy. It is called 1, 2, 3 and 4 minutes in any order. This document describes the task, and the specific decisions that need to be taken by the pilot, and tries to formulate the optimisation strategy.
However, currently, it is not clear if there is an ‘easy’ general strategy for a pilot that he can use to support the decisions to optimise his possible score.

Description of an F3K glider plane and it’s useage.
An F3K glider plane is maximum 1.5 meters of span, and weighs between 200 and 500 gram, depending on type and ballast load chosen. The pilot can launch his glider with a discuss launch technique to about 50-80 meters high, sufficient to fly about 1 to 2 minutes without thermal activity in the surrounding air. When finding favourable thermal activity, the pilot can use his remote control to control the plane, optimise the flight path, and stay aloft for an extended period of time. If the pilot desires so, he can also land the plane to end the current flight and make a restart. A landing and restart will take about 2 seconds for a trained pilot, up to 10 seconds.

Description of the F3K competition task “1, 2, 3 & 4 minutes, in any order”.
In this task, the pilot gets 10 minutes to make his flights. He has to try and fly as long as possible on each flight, but no longer than the target time. The score of a flight is the actual flight time of that flight, with a...Continue Reading

Hi,

been looking into the heli stuff for the Taranis, as it is heavily underpresented on the net. One of the first things I wanted to get sorted out is to do a Swash setup without the special heli page.

Actually that is quite simple: just mix the signals from the servos on your swashplate so that the plate tilts forward on elevator down, sideways on ailerons, and moves completely up and down on the collective pitch, applied through the pitchcurve linked to throttle.

For a 120 degrees swash plate, we can't mess up to much, since three points always make a plane. Just realise that the ele servo (yeah, confusing name) is 100 % from the pitch axis, whereas the pitch and aileron servos are linked at 50% distance from the pitch axis.
So, in order to tilt the plate forward, without moving the entire plate up or down, you should mix 50% to the pitch and aileron servo.

Same goes for roll. In order not to roll faster then pitching, you should limit the pitch and aileron servos to 86.6% of roll input.
Only thing left is to mix the collective pitch into all three.

(pic from here)

See below the effective mixes I set up, named CYC1, CYC2 and CYC3, as on the special heli page.

CYC1 = 100% colPitch + 100% elevator
CYC2 = 100% colPitch + 86.6% aileron - 50% elevator
CYC3 = 100% colPitch - 86.6% aileron - 50% elevator

This is based on the assumption of minimal tilt of the swashring, neglecting all effects of the finite radius of the swashring.
Also, the non linear behaviour of the...Continue Reading

As the developers of OpenTX do not always have time to fix BUGS, I opened this thread to inform people about which bugs are in which version.

This in order to prevent hours and hours of breaking your head on why something doesn't work as expected.

feel free to add.

Hi,

after some research on the mixer scripts I have decided I will use them for flight critical functions. Why? Because they are so powerfull that they clean up complex mixer lines, and make the models readable again. Also, they make space for other stuff to be done in the normal mixers.

There are still some drawbacks, like no being able to change the parameters with LUA, but they can be overcome.

But, hey, they explicitly say you shouldn't use them for critical functions?

Well, they are loaded at model startup. Some voice alerting can be done if it crashes. But they crash nicely, that is to say, if one crashes, that doesn't crash another one running.

So as long as you do stupid simple mix actions, the risk can be taken, in my opinion.

Let's go!

With read and write access in LUA on opentx, it is tempting to use a settings file to persist certain user choices for some scripts. However, though writing a settings table to a file is easy, retrieving it by reading the file content string per string is tricky. Formatting, nested structures, etc.

The solution to this is to write the table to a settings file in a format that is lua interpretable, and will return a table on using the lua loadfile() command.

In this way, you use the lua interpreter to parse the structure from the save table.

The following script, to be saved under the name "saveTable.lua", can be used to dump a table to a file, that is then retrievable using loadfile().

...Continue Reading

Make sure you open the post en click on the read more to see the all pages. Otherwise you will see page 8 as last page, and not page 16.

O previously posted some analysis on DLG design in this Blog. After some discussions about smaller than 1.5 meter wing span DLG's possibly outperforming the full size ones on the last WC in the Ukraine, I dug up my old analysis, and worked on it a little to find out if I could derive the theoretical optimum span for a DLG. That is to say: optimum for maximum airtime in still air at a fixed launch speed.

It turns out that actually the current launch speed determines the optimum terminal velocity to design the plane for. So making the plane faster or slower with respect to this terminal velocity would lower the total airtime for this launch speed. A terminal velocity of only 60% of the launch speed would be the optimum design speed for obtaining maximum airtime.

Secondly, the maximum airtime itself can be expressed in the L/D ratio and the launch speed only! So, basically speaking, just optimise L/D and you will optimise maximum airtime (for the optimum design speed that is). The expression is quite simple:

t_(flight,max) ≈ 2 / 3g ∙ (L/D)_optimum ∙ √((L/D)_optimum ) ∙ v_launch

When entering an L/D of 12 to 20, and a v_launch of 40 m/s, the still air time will be between 115 and 245, with an average 180 seconds.

Finally, the question I started with. The expression for terminal velocity that you...Continue Reading

OK, last topic to cover in this series.

We have succesfully made a graph showing some source value with a 'One-time' script, and used some library functions to get it loaded as a widget.

Now I want to use it on the Taranis as well. Let's first just run it and see what happens:

So what's on line 68:
Well, something must be provided here, but this global is not known on the Taranis, so it get's a nil value.
Let's add it at the first line of the script, and give it some value we DO know in the Taranis. And at the same time define the other colors:
Well, it's running (either use the standard "go.lua" script we wrote in the other post, or add the 'background()' call to the first line of the 'run' command.)

We are going to create a graphing script from scratch, using the widget framework to support Horus as well . Main requirements:

1. Any source, selectable as option
2. Fully scalable to support different lcd and widget sizes
3. First-In-First-Out fixed timeframe drawing buffer
4. Adjustable timeframe width with 'plus' and 'minus'
5. Autoscale on height
6. Reset on 'exit' and restart on 'enter'

Well, that sounds nice, no?

Let's start .....

OK, new blog entry.
I will share some of my experiences and solutions to problems I encountered using the LUA scripting on openTX. Please feel free to comment. It is meant to become a help to anyone wanting to create, adapt or migrate any LUA script for OpenTX. Tutorial files are added in this first post, and in the last of this thread.

It is assumed that you have read and at least partially understood the OpenTX LUA reference guide. I will assume OpenTX 2.2, OpenTX 2.1 should work as well for all examples, unless stated otherwise, but OpenTX 2.0 is not going to work without extra lines managing the lcd.lock() functionality. Some special article will covering the OpenTX 2.0 specialties, to allow creating interoperability.

Also, if you intend to use or change the scripts, or follow some instructions on this site, I will assume you have ZeroBrane installed. This helps enourmously in developing and testing LUA scripts.

The on-line LUA manual is used as a reference as well. We use the LUA 5.2 version, as OpenTX is build around this.

Be aware that OpenTX is not designed to be LUA friendly! ! !

OpenTX has a LUA API, but that is about it. The people behind OpenTX probably didn't imagine how powerful LUA can be, and that it opens the possibilities for completely different approaches towards using an OpenTX radio. They probably don't even have any interest in the possibilities it opens, and is for them just an add-on provided to complete their framework.
Be...Continue Reading

We proudy inform you that the JustFly.solutions website is now online.

All development done has finally turned into a product.

Check the links below:

Transform your Taranis into a "normal" transmitter

JustFly.solutions supplies Apps for the Taranis

Full support for ALL FrSky OpenTX radios!!



have fun and

I will publish my DLG design analysis here to share it with others and get feedback. So please feel free to do so