Shop our Airplanes Products Drone Products Sales
l shems's blog View Details
Posted by l shems | Dec 15, 2018 @ 02:49 PM | 788 Views
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.

Name: swash_120.gif
Views: 0
Size: 5.0 KB
Description: (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
Posted by l shems | Dec 09, 2018 @ 10:40 AM | 709 Views
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.
Posted by l shems | Nov 25, 2018 @ 03:39 PM | 1,406 Views
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!
Posted by l shems | Sep 06, 2018 @ 12:11 PM | 18,344 Views
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().

Code:
local table,fileName=...

local indent = ""

local function outputTable (tbl)
  if not (type(tbl)=="table") then 
    return tbl
  end
  indent=indent .. "   "
  local res= "\n" .. indent .. "{\n" 
  for k, v in pairs(tbl) do
    if type(k) == "number" then
      k="[" .. k .. "]"
    end
    if type(v) == "table" then
      res=res .. indent .. k .. " = " .. outputTable(v) .. ",\n" 
    elseif type(v) == "function" then
    elseif type(v) == "string" then
      res=res .. indent .. k .. " = '" .. v .. "',\n" 
    elseif type(v) == "boolean" then
      if v then res=res .. indent .. k
...Continue Reading
Posted by l shems | Dec 08, 2017 @ 01:00 PM | 3,920 Views
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
Posted by l shems | Nov 14, 2017 @ 02:45 PM | 4,591 Views
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:

Quote:
Script error: /Scripts/TELEM/Graph.lua:68: bad argument #6 to 'drawLine' (number expected, got nil)
So what's on line 68:
Code:
    lcd.drawLine(0          ,P.y0    ,LCD_W-1    ,P.y0      ,DOTTED ,CURVE_AXIS_COLOR)
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:
Code:
CURVE_AXIS_COLOR = GREY(12)
LINE_COLOR = GREY(8)
CURVE_COLOR = GREY(4)
TEXT_COLOR = GREY(15) 
MAINVIEW_PANES_COLOR = GREY_DEFAULT
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.)

Name: screenshot_x9d+_17-11-14_20-41-16.png
Views: 61
Size: 1.4 KB
Description:


Posted by l shems | Nov 05, 2017 @ 08:09 AM | 4,061 Views
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'

Name: screenshot_x12s_17-11-15_19-01-22.png
Views: 186
Size: 35.3 KB
Description:

Well, that sounds nice, no?

Let's start .....
Posted by l shems | Oct 29, 2017 @ 05:46 AM | 6,349 Views
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
Posted by l shems | May 07, 2016 @ 04:42 AM | 7,618 Views
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!!

Name: screenshot_x10_18-02-06_23-14-35.png
Views: 42
Size: 33.6 KB
Description:

have fun and
Just Fly!

Posted by l shems | May 05, 2015 @ 12:03 PM | 10,569 Views
I will publish my DLG design analysis here to share it with others and get feedback. So please feel free to do so