Lua interpreter in openTx

[bertrand35]

I suggest you wait a little bit, at least for flying. This branch is far from stable right now, with the INPUTS half implemented. Also the EEPROM format will be different, don't forget to backup your EEPROM before flashing this branch of you will loose your model settings!

And please contact me via emails if you want to give a hand at LUA scripts (or anything else) of course!

[jhsa]

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

Question.
will the common mortal person be able to understand it?
Not everybody knopw how to write scripts, whatever that is
Is still a radio for everybody or must we have a degree in rocket science to use it in future??

João

[bertrand35]

LUA scripts won't be enabled if you don't select the option inside c9x.

You won't be lost with INPUTS as you will find the current Expos/DRs, but if you want to have an expo on a pot it will be possible.

[jhsa]

Thanks Bertrand.. I must say that this LUA thing is a bit intimidating as some of us might not understand what it does or can do.. I'm sure it will be something very powerful but the question is do we have to know programing to work with it? what is it? how can we use it? real use for it? what we have to do to make it do what we want?
It just sounds a bit confusing at the moment.. I'm sure there will be be a full manual teaching us how to use it and benefit from it??

João

[ReSt]

João
As I understood above, it will not be available to stock 9x radios. It will require at least a Taranis

Reinhard

[dvogonen]

LUA is a programming languge. So by definition you are programming if you use it.

I have not looked into how Bertrand uses the interpreter, but my assumption is that the user will get the possibility to create complex channel output (expos, curves, filters and the like) as scripts rather than relying on built in routines. This is more powerful and a lot more flexible than anything that is available in any radio on the market today. So the idea is very interesting for those who want to use really complex mixes and have no fear of coding.

The vast majority of users will naturally +not be interested in writing LUA scripts.

[algo]

You can also think of the scripts as "plug-ins" that could be used by normal users to get extra functionality even if they didn't write them.

What is the cycle time on the Taranis anyway? I wonder what the limit is for amount of code that can run in these scripts before it slows down the radio too much.

[jhsa]

Reinhard I have the 9x now but i'm waiting for the HORUS. So, in other words this Lua thing is a development for developers and nothing normal people should worry about

[jhsa]

flaps30 if you like GVARS, you will love this one.

[G550Ted]

flaps30 if you like GVARS, you will love this one.

João, you're gonna get slapped, AGAIN!

Ted

[Flaps 30]

I am keeping an eye on this thread and you also João.

You are right there Ted. He is on the naughty list big time.

As for the Lua interpreter - Learning about Rocket science would be better. On the other hand, you never know what may fall out of it all that might be of use to us mere mortals.

[jhsa]

You are right there Ted. He is on the naughty list big time.

[Rob Thomson]

From my perspective, the biggest single advantage of Lua will be the ability to introduce a controls layer.

So... A control called 'crow' and 'vtail'. Etc.

This sort of layer will massively simplify glider programming, and be readily distributable.

I can't wait

Sent from my GT-I9300 using Tapatalk 2

[jhsa]

From my perspective, the biggest single advantage of Lua will be the ability to introduce a controls layer.

So... A control called 'crow' and 'vtail'. Etc.

This sort of layer will massively simplify glider programming, and be readily distributable.

I can't wait

Sent from my GT-I9300 using Tapatalk 2

wo wo wo, wait a second right there..
Opentx is the way it is not to be equal to the other radios and actually be better and more flexible where anything is attached to anything, and now you're saying that we must have something very complicated (LUA) to be able to program our radios the same simple way that all the not so flexible systems do? like V-Tail or crow programming?

João

[Rob Thomson]

Nope.

What I am saying is that once someone writes a lua script to abstract these functions, you can essentially redistribute the script (a file on the sdcard).

This will mean that complex mixes can be simplified.

This is actually a step forward.

The mixing system will still work in its normal format, so nothing is lost. The gain will come in that the abstraction of these mixes will help the firmware/radio appeal more to less technical users. (Who could just use the prey built Lua script)

Sent from my GT-I9300 using Tapatalk 2

[jhsa]

ah, i see, so this would allow the radio to behave like any other. Something like a menu would pop up where the users could just insert the values for some pre-defined mix, for example?

[Rob Thomson]

Check the pictures Bertrand posted on the thread earlier. It will become clearer.



Sent from my GT-I9300 using Tapatalk 2

[FloatingFoam]

Once LUA is integrated, it opens the doors to other possibilities as well, such as:

- The ability to write custom UIs for OpenTX. If you can create menus and entire UI screens in LUA, it would mean that the community could develop different UIs for different purposes. For example, a simplified UI for people who just can't understand the mixer. Or, the ability to write a custom telemetry screen that graphs your altitude/airspeed/whatever on screen in real-time. In this way, OpenTX would behave more like an OS with different LUA applications giving it personality.

- The ability to write custom Templates. What if you could download a LUA file to your SD card that would show up in the Templates menu and with one button press it customizes a model for a specific airframe? This can be done today by exporting the model, but people may find it more comforting to find their favorite model in the Templates menu when they buy the radio.

Right now it sounds as though LUA will augment the normal OpenTX functionality with a few custom math functions, etc. But there are many possibilities for where it could ultimately be taken.

[Rob Thomson]

All correct.

Lua integration will no doubt start simple... Then expand to cover all areas.

Rob

Sent from my GT-I9300 using Tapatalk 2

[jhsa]

as long as someone writes the scripts
Otherwise only the developers will be able to use it
I'm sure someone will, maybe on request?

[Rob Thomson]

My number one job - full house glider setup

But will wait for a Luna branch to becomr stable!

Sent from my GT-I9300 using Tapatalk 2

[fireball]

Would be a compiled version available for a sneak peak? I'd love to play around with it, but unfortunately I've got no time to set up a complete build environment at the moment...

[Helle]

Hy,

where can I find detail infos about the LUA interpreter and its funktions integrated in openTx
is there any description or a manual how the funktions are running with parameter and so on.

Helle

[Rob Thomson]

Nothing yet.

The lua branch has still not been ported to stable. It is very much beta dev only

Sent from my GT-I9300 using Tapatalk 2

[algo]

I haven't been able to compile the Lua branch for some time, am I compiling possibly with an incorrect option?

It looks more like maybe the templates haven't been updated for the curve refactoring. I have been thinking that it is just taking a while to get all the changes in or maybe a big commit is coming. No worries, just wondering out loud.

I compile with:

Code: Select all

make \
   PCB=TARANIS \
   HELI=YES \
   AUTOSWITCH=YES \
   AUTOSOURCE=YES \
   DBLKEYS=YES \
   PPM_CENTER_ADJUSTABLE=YES \
   PPM_LIMITS_SYMETRICAL=YES \
   PPM_UNIT=US \
   GVARS=YES \
   LUA=YES

Code: Select all

templates.cpp: In function 'void applyTemplate(uint8_t)':
templates.cpp:208:61: error: 'MixData' has no member named 'curveMode'
         md=setDest(4, MIXSRC_Thr); md->swtch=SWSRC_ID0; md->curveMode=MODE_CURVE; md->curveParam=CV(1); md->carryTrim=TRIM_OFF;
                                                             ^
templates.cpp:208:71: error: 'MODE_CURVE' was not declared in this scope
         md=setDest(4, MIXSRC_Thr); md->swtch=SWSRC_ID0; md->curveMode=MODE_CURVE; md->curveParam=CV(1); md->carryTrim=TRIM_OFF;
                                                                       ^
templates.cpp:208:87: error: 'MixData' has no member named 'curveParam'
         md=setDest(4, MIXSRC_Thr); md->swtch=SWSRC_ID0; md->curveMode=MODE_CURVE; md->curveParam=CV(1); md->carryTrim=TRIM_OFF;
                                                                                       ^
templates.cpp:208:109: error: 'MixData' has no member named 'carryTrim'
         md=setDest(4, MIXSRC_Thr); md->swtch=SWSRC_ID0; md->curveMode=MODE_CURVE; md->curveParam=CV(1); md->carryTrim=TRIM_OFF;
                                                                                                             ^
templates.cpp:209:61: error: 'MixData' has no member named 'curveMode'
         md=setDest(4, MIXSRC_Thr); md->swtch=SWSRC_ID1; md->curveMode=MODE_CURVE; md->curveParam=CV(2); md->carryTrim=TRIM_OFF;
                                                             ^
templates.cpp:209:87: error: 'MixData' has no member named 'curveParam'
         md=setDest(4, MIXSRC_Thr); md->swtch=SWSRC_ID1; md->curveMode=MODE_CURVE; md->curveParam=CV(2); md->carryTrim=TRIM_OFF;
                                                                                       ^
templates.cpp:209:109: error: 'MixData' has no member named 'carryTrim'
         md=setDest(4, MIXSRC_Thr); md->swtch=SWSRC_ID1; md->curveMode=MODE_CURVE; md->curveParam=CV(2); md->carryTrim=TRIM_OFF;
                                                                                                             ^
templates.cpp:210:61: error: 'MixData' has no member named 'curveMode'
         md=setDest(4, MIXSRC_Thr); md->swtch=SWSRC_ID2; md->curveMode=MODE_CURVE; md->curveParam=CV(3); md->carryTrim=TRIM_OFF;
                                                             ^
templates.cpp:210:87: error: 'MixData' has no member named 'curveParam'
         md=setDest(4, MIXSRC_Thr); md->swtch=SWSRC_ID2; md->curveMode=MODE_CURVE; md->curveParam=CV(3); md->carryTrim=TRIM_OFF;
                                                                                       ^
templates.cpp:210:109: error: 'MixData' has no member named 'carryTrim'
         md=setDest(4, MIXSRC_Thr); md->swtch=SWSRC_ID2; md->curveMode=MODE_CURVE; md->curveParam=CV(3); md->carryTrim=TRIM_OFF;
                                                                                                             ^
templates.cpp:218:83: error: 'MixData' has no member named 'curveMode'
         md=setDest(10, MIXSRC_Thr); /*md->weight= 100;*/ md->swtch=SWSRC_ID0; md->curveMode=MODE_CURVE; md->curveParam=CV(4); md->carryTrim=TRIM_OFF;
                                                                                   ^
templates.cpp:218:109: error: 'MixData' has no member named 'curveParam'
         md=setDest(10, MIXSRC_Thr); /*md->weight= 100;*/ md->swtch=SWSRC_ID0; md->curveMode=MODE_CURVE; md->curveParam=CV(4); md->carryTrim=TRIM_OFF;
                                                                                                             ^
templates.cpp:218:131: error: 'MixData' has no member named 'carryTrim'
         md=setDest(10, MIXSRC_Thr); /*md->weight= 100;*/ md->swtch=SWSRC_ID0; md->curveMode=MODE_CURVE; md->curveParam=CV(4); md->carryTrim=TRIM_OFF;
                                                                                                                                   ^
templates.cpp:219:83: error: 'MixData' has no member named 'curveMode'
         md=setDest(10, MIXSRC_Thr); /*md->weight= 100;*/ md->swtch=SWSRC_ID1; md->curveMode=MODE_CURVE; md->curveParam=CV(5); md->carryTrim=TRIM_OFF;
                                                                                   ^
templates.cpp:219:109: error: 'MixData' has no member named 'curveParam'
         md=setDest(10, MIXSRC_Thr); /*md->weight= 100;*/ md->swtch=SWSRC_ID1; md->curveMode=MODE_CURVE; md->curveParam=CV(5); md->carryTrim=TRIM_OFF;
                                                                                                             ^
templates.cpp:219:131: error: 'MixData' has no member named 'carryTrim'
         md=setDest(10, MIXSRC_Thr); /*md->weight= 100;*/ md->swtch=SWSRC_ID1; md->curveMode=MODE_CURVE; md->curveParam=CV(5); md->carryTrim=TRIM_OFF;
                                                                                                                                   ^
templates.cpp:220:83: error: 'MixData' has no member named 'curveMode'
         md=setDest(10, MIXSRC_Thr); /*md->weight= 100;*/ md->swtch=SWSRC_ID2; md->curveMode=MODE_CURVE; md->curveParam=CV(6); md->carryTrim=TRIM_OFF;
                                                                                   ^
templates.cpp:220:109: error: 'MixData' has no member named 'curveParam'
         md=setDest(10, MIXSRC_Thr); /*md->weight= 100;*/ md->swtch=SWSRC_ID2; md->curveMode=MODE_CURVE; md->curveParam=CV(6); md->carryTrim=TRIM_OFF;
                                                                                                             ^
templates.cpp:220:131: error: 'MixData' has no member named 'carryTrim'
         md=setDest(10, MIXSRC_Thr); /*md->weight= 100;*/ md->swtch=SWSRC_ID2; md->curveMode=MODE_CURVE; md->curveParam=CV(6); md->carryTrim=TRIM_OFF;
                                                                                                                                   ^
make: *** [opentx.elf] Error 1

[Kilrah]

Templates will either need complete refactoring because of the new inputs/virtual functions system, or will be removed altogether as the scripting possibilities make them redundant.

So... for now compile without them.

[algo]

Ah, thanks! I never really used the templates anyway.

[aclysma]

Hi, this is my first post here. I heard about this feature and am intrigued but was immediately concerned as to whether this feature could be made safe in a system with hard I/O constaints:

I briefly looked at the code changes. It appears that all scripts share the same VM and heap. So garbage collection times would scale with both size/complexity of the script and the number of scripts you were running. If any one of them were to use too much time, they would all stall. In addition, if any one of the scripts consumed/fragmented too much memory then anything on that heap (presumably only lua) would likely fail catastrophically.

Has there been any investigation as to garbage collection cost as script complexity grows? I imagine that even for small scripts, the cost of interpreting and garbage collecting on a 60mhz processor with a simple instruction set will be extremely slow. This type of code generally causes lots of cache misses.

I suppose this would be safe if the lua scripts couldn't touch anything critical, but it's hard to imagine them doing anything useful without being able to touch anything critical. It looks like lua is sandboxed at least in terms of combined processor time and memory access. What can it write to? My concern would be that an unsuspecting user would combine an important script like a "full house sailplane wizard" with something else that's heavy in processing time or memory and losing control. In short, I'm concerned that this feature, while perhaps useful for prototyping or other edge cases, is dangerous to anyone that does not understand the risk.

[bertrand35]

Hi, this is my first post here. I heard about this feature and am intrigued but was immediately concerned as to whether this feature could be made safe in a system with hard I/O constaints:

I briefly looked at the code changes. It appears that all scripts share the same VM and heap. So garbage collection times would scale with both size/complexity of the script and the number of scripts you were running. If any one of them were to use too much time, they would all stall. In addition, if any one of the scripts consumed/fragmented too much memory then anything on that heap (presumably only lua) would likely fail catastrophically.

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

Has there been any investigation as to garbage collection cost as script complexity grows? I imagine that even for small scripts, the cost of interpreting and garbage collecting on a 60mhz processor with a simple instruction set will be extremely slow. This type of code generally causes lots of cache misses.

I suppose this would be safe if the lua scripts couldn't touch anything critical, but it's hard to imagine them doing anything useful without being able to touch anything critical. It looks like lua is sandboxed at least in terms of combined processor time and memory access. What can it write to? My concern would be that an unsuspecting user would combine an important script like a "full house sailplane wizard" with something else that's heavy in processing time or memory and losing control. In short, I'm concerned that this feature, while perhaps useful for prototyping or other edge cases, is dangerous to anyone that does not understand the risk.

Even if it is possible, I won't recommend using LUA scripts for replacing the mixer. Especially for controlling a plane! I do prefer the custom templates solution.

[jhsa]

I think all this lua thing will need a good manual