Lua interpreter in openTx

[aclysma]

No it will be detected and the script will be killed! Try to write an endless loop and you will see!

I agree. If anything bad happens in any of the script, for any reason, all script will stall/be killed since it all shares one sandbox. If lua is doing anything important, it's a risk.

Even if it is possible, I won't recommend using LUA scripts for replacing the mixer.

I think we both recognize why such a script poses a serious danger. But simply having this feature invites people to use it like that. What is the point of this feature if it can't affect the transmitter's output?

This feature is interesting but I doubt many end-users will fully understand the potential hazard. This feature requires a unique level of understanding to use it in a way that is safe. I think it would be wise to exclude it from any "released" firmware builds.

[Kilrah]

No, if a script takes too long it is killed without affecting the others.

Sent via mobile

[bertrand35]

Yes, a script which consumes too much CPU or too much RAM will be killed. The SCRIPTS menu will display how much a script consumes (CPU and RAM) and its state (error / killed / leak)

[mhotar]

I should agree with aclysma , if we can not trust to Lua for replacing the mixer, how we can make custom can-mixes?

[aclysma]

No, if a script takes too long it is killed without affecting the others.

If you look at the code you will see only one lua_State object. They share the same heap, garbage collector, timeslice, and variable/function namespace! If you combined two scripts that used the variable name "Time" the scripts would stomp on each other's values. If they both defined a function "GetTime", both scripts would use whichever definition of "GetTime" the lua state parsed last. The current implementation is functionally equivalent to appending all .lua files into a single file, then calling each function that represents a "script" in sequence.

Also, since it's all running in the same task, even if there were multiple lua_State objects, there is not sufficient isolation to guarantee the scripts cannot affect each other. If one of them hitches for garbage collection for the whole timeslice, the other scripts will not execute. It would be necessary to put each script in its own RTOS task, and each task would need its own lua_State.

https://code.google.com/p/opentx/source ... rc/lua.cpp

[algo]

It is possible to offer isolation via environments although I'm not sure if they are being used here (looks like not). Properly written scripts would be using local functions/variables and would not affect other scripts regardless of whether or not they are in their own environment. True, it might not hold the developer's hand as much as it could.

The Lua garbage collector is quite flexible and Lua is used in many real-time games. It may or may not be a problem. I personally have never even noticed it. Most of my work with Lua is in security/cryptography, graphics, and high speed finance (ie. many real-time applications; sometimes using massive amounts of memory/objects). However, I generally use LuaJIT and not standard Lua. Too bad there is no LuaJIT for the ARM Thumb (at least not yet anyway).

[bertrand35]

In my workspace I have added isolation with one lua_State per script. I have some scripts ready: a dynamic template example, a mixer example, a sounds example, a snake game, and many other test programs to test isolation, infinite loops, syntax errors, memory leaks ...

[jhsa]

Can we have tetris??

[aclysma]

In my workspace I have added isolation with one lua_State per script. I have some scripts ready: a dynamic template example, a mixer example, a sounds example, a snake game, and many other test programs to test isolation, infinite loops, syntax errors, memory leaks ...

Good to hear! That is a huge improvement. I also noticed that you do have what appears to be a hard limit of 1000 instructions. That will catch a lot of stupid runaways although it will miss garbage collection hitches or any time spent in the core lua API (like string manipulation functions.) I have heard that it is possible to give some of those functions arguments that induce a runaway. Thankfully the RTOS would catch that (although that would be a way for one script to take down the other scripts.) To completely solve the problem, each script really ought to be in its own RTOS task with a private heap. Of course that wouldn't be cheap.

I'm assuming lua states would still share the same heap? Also regarding the GC times, my concern is less of how lua scales with object count (especially now that scripts don't share a single lua state) and more with how a 60mhz ARM processor will deal with it. I've worked on realtime projects that used scripts (console games) and we always were fighting script to the very end of the project to keep the frame hitches under control. We had the luxury of being on a 3ghz+ processor with far more sophisticated architecture than a cortex M3. So even with simple scripts I still think GC time is a concern given the hardware this would be running on.

That all said, separating the scripts into separate lua states was definitely the most important thing to address. I still wouldn't trust this feature personally, but I do think as a practical matter it is much less likely to bite someone with that change.

ASIDE: It would be really nice if someone would open source a language that is runtime-compiled, has no dynamic memory allocation (after initial compile/load), and could disallow unbounded loops, recursion, and jumps (so not turing complete.) That would be so perfect for this application. It'd probably look a lot like GPU shader languages like HLSL.

[bertrand35]

LUA scripts will be used in 2 different ways:

1) as standalone scripts

It will be used especially for templates, but why not for games if somebody wants to write them. I took the snake game from here: https://code.google.com/p/eluaexamples/
Now suppose those standalone scripts are very very heavy... even if the other scripts are slowed down, it's not a huge issue, you are not supposed to fly when configuring a template or playing a game!

2) as permanent scripts (max 6 scripts per model)

These scripts provide a way to program complex mixing (such as Antenna Tracking), to modify the screen appearance (or a portion of the screen), play different sounds (i.e. the one who wants a timer counting from 30s to 1s). I also think it could be useful to program sequences in a very powerful way. Such scripts should not be too complex and use so much RAM! Moreover the number of instructions called and the memory usage will be limited.

So ... let's wait a little bit for the first "real" scripts to be tested and we will discuss at this time if we go the right way or no.

Also I just had a look and I think there is no possibilty to use luaJIT on the Taranis. It would indeed have been great!

Bertrand.

[bertrand35]

It will be a MAJOR release, with many differences:
- LUA interpreter added
- The Expo/DR screen will be replaced by an INPUTS screen far more powerful
- The curves system will be different (with any number of points from 2 to 17)
- The outputs will have the possibilty of a curve associated
- Many little enhancements

Some other features in this branch:
- Curves will have a "smooth" checkbox
- It will be possible to have expo in mixes and differential in inputs (expo and diff will be considered as curves)
- Custom switches will have a better precision for v2 (negative timers, steps by 1s for timers instead of 3s, 1m for altitude etc.)

[nischris]

Is there somewhere that documents information about where the LUA scripts should be located on the SD card, and when they execute?
e.g
How to execute scripts manually.
Will scripts execute automatically? When? When models load? Other times? How does the firmware identify which scripts will run? By name?
How many scripts will run automatically?
Will it be possible to disable automatic scripts?

Thanks.

[Kilrah]

No doc yet.
One-time scripts can be executed from anywhere using the SD browser.
For run-time scripts you put them in the SCRIPTS folder, and load them on the scripts page.

[nischris]

That's lovely thanks. I guess the scripts page allows a certain number of scripts per model to load when the model is loaded.

[dinamich]

I am writing Lua documentaton, working version is available at https://github.com/projectkk2glider/ope ... -in-OpenTX

[nischris]

Looks good

[ridgerunner]

OK, so I just got a brand new second Taranis (Rev B with the improved sliders and 2AH battery), so I decided to load it up with V1.99 and try out the LUA feature...

First I downloaded the latest BIN firmware file (2014-04-25 version) and the CompanionTX Windows installer executables (opentx-taranis-20140425.bin,
companionInstall_v1.99.exe) from GitHub.

Installed CompanionTX on my Win XP box with no issues and was able to back up the as-delivered firmware and flash the new 1.99 version (2014-04-25). This all went very smoothly. Reconnected to the PC using the new boot loader feature (activated by holding in the two trim buttons while powering on).

I then selected, copied and pasted the delta mix LUA code from the wiki to a text file which I named: delta.lua. I created a new "SCRIPTS" folder in the root directory of the SD card and copied the new delta.lua file there. Here is the contents of the delta.lua file:

Code: Select all

local inputs = {
                 { "Aileron", SOURCE },
                 { "Elevator", SOURCE },
                 { "Ail. ratio", VALUE, -100, 100, 0 },
                 { "Ele. ratio", VALUE, -100, 100, 0 }
               }
                 
local outputs = { "Elv1", "Elv2" }

local function run(input1, input2, ratio1, ratio2)
  value1 = (getValue(input1) * ratio1) / 100
  value2 = (getValue(input2) * ratio2) / 100
  elevon1 = value1 + value2
  elevon2 = value1 - value2
  return elevon1, elevon2
end

return { input=inputs, output=outputs, run=run }

On the default Model01 model, (and on a newly created model Model02 - makes no difference; both exhibit the same behavior), I selected the LUA scripts screen and was able to see, select, and activate the delta script. The delta setup screen looks just like the screenshot in the wiki, and I was able to select the 2 input sources to be the Ail and Ele sticks (or iAil and iEle inputs - both behave the same), and set the value1 and value2 weights to plus and minus 50.

In the Mixer screen I then set up channels 5 and 6 to be driven by the new 1Ele1 and 1Ele2 inputs (script outputs).

The problem is that the channel 5 and 6 output is highly intermittent (mostly off) and jittery/unstable.

Mostly the outputs remain at zero but will occasionally and briefly display different values.

Here's the version I'm running (2014-04-25)


I left the INPUTS screen as-is:


I added the delta.lua script...


And set it up like this: (Note that Ail and iAil both behave similarly)


Then I added two new mixes to channels 5 and 6 to use the script outputs as their source:


Here's the details of one of the two mixes:


Should work, but the channel 5 and 6 outputs on the CHANNEL MONITO screen just flicker intermittently


Anyone else having problems (or success) with the LUA delta mix example?

THERE IS SOMETHING VERY FISHY GOING ON HERE!


Thanks,
Jeff Roberson

p.s. Can't wait to get this uber-cool feature working!

[ridgerunner]

It turns out you don't need to call the getValue() function from within run() to get the inputs. The input values are passed directly to run() as arguments/parameters. Here is a version of delta.lua which works correctly:

Code: Select all

local inputs = {
                 { "Aileron", SOURCE },
                 { "Elevator", SOURCE },
                 { "Ail. ratio", VALUE, -100, 100, 0 },
                 { "Ele. ratio", VALUE, -100, 100, 0 }
               }
                 
local outputs = { "Elv1", "Elv2" }

local function run(input1, input2, ratio1, ratio2)
  value1 = (input1 * ratio1) / 100
  value2 = (input2 * ratio2) / 100
  elevon1 = value1 + value2
  elevon2 = value1 - value2
  return elevon1, elevon2
end

return { input=inputs, output=outputs, run=run }

Oh, and the update rate sure feels quick to me!

[dinamich]

Good catch ridgerunner! This one if my fault, the input type SOURCE changed in 4/22/14 nightly build and now works without getValue() as you found out. I have now updated original wiki documentation.

You can also have a peek at working version of new documentation here https://github.com/projectkk2glider/ope ... -in-OpenTX

You will also notice that the order of returned arguments is reversed (value1 is returned as "Elv2"). This bug is known and will be fixed soon.

[dinamich]

Just to wet your appetite, here is a Lua script that detects number of LiPo cells connected to A2 input. http://youtu.be/hum5w5zJX-U

This functionality is not yet available in nightly builds, but it will be soon.