Scripting DeviaitonTx

In poking at something - I forget what - I noticed that they had added a Lua interface to OpenTx on the Taranis .

Cool. We can do that. And maybe better. But not on the 7E, so if that's all you are using, you may want to skip this.

I'm still in the very early stages of looking into this, so it may never happen. Or it may require more CPU than any current Tx except the Taranis has. Or - well, you've been warned that this may never happen!

But I've got some questions for the community that could well guide that research.

First, technology. I'm thinking that in order to deal with the slower cpu and memory limits, we may not want to run scripts on the Tx directly. Instead, they'd be compiled on your desktop and the results of those installed on the Tx, working much like the protocols on the 7E. The advantage of this would be a potential speed advantage from compiled code instead of a script and not needing an interpreter (which would live in flash, not SRAM). This should make it more likely this will be possible, increase the number of scripts you can have, and lower the impact running them has on your Tx.

So, anyone think that having to compile the scripts on your desktop would be an issue? How about if you can run them as scripts in the emulator without compiling them? How about if there's a tool that you could point at a script directory and your Tx disk, and it'd do "the right thing" for you?

Similarly, should the scripts compile to a single file to load into RAM (meaning we can check at build time whether or not they fit), or should they be separate files that can be updated individually?

If you're ok with compiled scripts on the Tx, what conditions would it be acceptable for breaking installed scripts? I'm assuming running a broken script would cause a popup saying "you need to reinstall" rather than a crash. But if we compile to ARM code, then updating deviation would probably break things every time. If we compiled to byte code - splitting the difference, as it were - then it would hopefully only break when the interpreter used in the firmware was updated.

Ok, now questions about "What do we do with it?"

I'm thinking that there would be a directory of scripts to use per model. Maybe this is wrong, and we should have one set for the Tx, and the model file loads the ones it needs when it pulls in the config. Or mabye we need both. Anyone have any thoughts?

What I'm thinking about doing (at least initially) is making the scripts a set of values, like channels. A script could access the value of any set of existing channel (basically reading sticks and switch positions, etc) and then return a value like a channel value. These values could be used as sources or switches in the mixer, for alarms in the telemetry monitor, or put in a display box or bar graph.

So, example uses might be a monitor that watched an amperage telemetry value to keep a running total of mAh used, and given a model-specific argument for battery capacity create a "fuel gauge" bar graph.

Similarly, you could use a bar graph tied to altitude for a visual display of altitude vs. some legal ceiling. Hmm. If we could use telemetry as a mixer source, we could do that now, but let's leave that to do if this breaks, or someone wants such on the 7E.

If your telemetry system included multiple cells, it could calculate the minimum cell voltage for a telemetry alert, or even watch for one cell being badly out of whack.

Using them as a source doesn't provide anything that virtual channels don't do, but it might well make some things easier to deal with. For instance, the stick offset calculations for stagility mode use a max metric because calculating the real offset was a PITA. This would make doing that right trivial!

Can you see any other uses for a simple "calculate a new channel value" type thing here? Possibly something else that scripts that return a single value like this might do? I'm thinking this might be a way to deal with the issues I couldn't work out for doing flight modes, but haven't figured out how yet.

Once this is working, adding the ability to interact with the user can be considered, which might well let us create a "Setup wizard" that could embed protocol knowledge, and let you set up buttons/switches for dual rates, flip mode, video control, etc. on the Tx, without having to wade through the manual.

Anything else you can think of this could be used for? I haven't gone through all the OpenTx/Lua docs yet, because I want to think up uses before seeing theirs. That way, I won't be biased by their usage, and if they came up with a better solution than I did, I can steXXXadopt it later.

I have an idea for a script (tho note alot of it is doable just as mixers) but still imagine it as a script doing it automatically with a cool touch icon and stuff...

Launch mode for gliders.

Sure you can setup switches to move all your control surfaces into launch position but with a script you could have a little touch screen icon that said launch mode and looked bad a$$ lol, you touch that and it goes into launch mode then you write the script to stop running after you start giving stick input (you can't do that with a mixer, you have to flick the switch for regular mode)

Also I can see a script integrating really well with the CHDK scrip "KAP&UAV" (canon camera open source FW) the CHDK script is controlled via an arduino running off one or a couple AUX channels but again you have to manually manipulate the channels on the TX, I can see a script being able to take over all that stuff switching channels on and off and making controlling the camera automated. In fact it could actually replace the arduino "camera controller" all together.

You know I'm a 7E guy and I've made my 7E do a lot of stuff and built several of my friends 7E's but more than a few times over the last few months I've had the money and had a taranis in my cart finger on the "check out" button... You've got me glad I didn't now sir, this is exciting!

I know your a boat guy, I'm not but I'm interested to see what boat ideas to come up with too!

Edit: Just looked at their scripts and WOW, when you go look threw them make sure you check out Ultimate Naze32./ Cleaflight!!
I wont say any more ideas now that I've read theirs but wow, wait till you read what those guy's have came up with!

I'm all hears! Just took a look at their DLG Flight Graph. Man, if I could have that on deviation, granted not on the 7E, but my 10 (even tough the screen size could be an issue) would see service once again. Or even maybe on the 7E Ultimate, I'm not sure PB will pursue the Ultimate branch, so I'm waiting to perform the mod on my backup 7E.

Nicest thing I read on deviation since UniversalTX, will have to learn scripting, but only thing I can say is go for it mwm.

Well, it's certainly on my list. After the 6S switches, and another unnamed project that I think is even more exciting. And probably the holidays.

But I'm looking for feedback on the technical questions! How important is it to have source on the Tx, and if a compile step is ok, do you care what it produces? Or to be specific, what granularity of updates do you want: replace an individual script, all the scripts on a model, or all the scripts on the Tx? And for that matter, do you need model-specific scripts?

I think model specific scripts and replacing individual scripts would be a must (I have 6 different DLG and each has is specificities) , now how would this fare in terms of complexity of programming and space used (once again the 7E is the culprit), is up to the programmers, which I'm not

That we want it or not, sometime in the future the Devo7E code needs to be froze and no more should be added to it (it is already a very capable TX), those who want more should be directed to the Ultimate mod. Granted you need to have a "little" soldering skills to replace the mcu, but a lot of people have done the transceiver diode mod and succeeded.

Anything ever come out of this post? As far as adding Lua to Deviation? Would be really cool to be able to adjust PIDs ect via tx..

Don't think so,it's why I moved on to a Taranis, only use the Devo6 for my micro stuff indoor.

Going to sell my two devo7e (after Ultimate mod) and my Devo 10, all with Multimodules (shameless plug ).

Lua on the Devo Tx's will never be up to what it does on the Taranis, except for maybe the 12. The problem is memory.

From the FAQ on requirements , they recommend at least 256K of Flash and 64K of RAM. At first glance, that looks fine - but that's the requirements for eLua!. The devo10 binary is 200K of Flash and 21K of ram, so that won't fit. They do say that by stripping features and squeezing things down, you can fit in half that, but still - no way.

Similar languages have similar problems. A minimal micropython port (sans all the hardware features) is about 80K on STM32F4. mRuby has been ported, but AFAIK hasn't been released.

Using a language with simpler syntax - LISP or Forth - helps with that. The armpit scheme interpreter is just under 40K of flash. Forth is infamous for being small size, but the odd syntax would make deviationTx even less intuitive.

Going with a less powerful language helps. There are BASIC interpreters that run on low-end Arudino's. The most interesting option is picoC. It's a C interpreter originally written for UAVs. There's a port to the STM10x processors, if I can ever get it to build.

A last option is do whatever parsing they do on your desktop instead of the Tx. That is unfriendly, and would require more than just an editor on your desktop, so again not friendly. Not sure if this is better or worse than using Forth.

Well, I managed to get micropython - apparently smaller than eLua - to be small enough to fit in the space left on a 10. By taking the compiler out of the VM,. That means you have to compile the files to byte codes and copy those to the transmitter. I'd rather avoid that.

I haven't quite given up on this yet, and have a couple of more options to look into. But I've got no idea what's involved in doing PID tuning on the Tx. Could someone describe that so I can incorporate it into my requirements?

Interesting stuff, I never used taranis, but using scripts it means we can have "Tx menu driven features/controls", instead of all controls to be from a switch or a pot ? what could we do with it?

There are also VTX, which could be controlled by RX, so basically we could create a menu, "VTX" and then Channel and power can be set from deviation?

www.banggood.com/VT5804-Pro-5_8G-40CH-25...itter-p-1149558.html

But myself never looked into it.

I'm not sure about a menu per se, since it's not clear that the deviation GUI is that flexible. But having a way to select a script from a directory and run it is certainly possible. And if you had a channel that normally preserved itself, then you could set it from one of those scripts. The Lua folks call those "one-time" scripts.

I'm really more interested in what the call "model scripts". I can see at least three things to do with those:

• Output a string to a display box - say a named flight mode, or as a 0-100 value
• As a telemetry value, so you can have alerts on combined values or based on history
• as a way to compute channel values

The last one is what makes things interesting. While there might be some worry about speed of an interpreter - we're already running an interpreter for those! It just interprets the .mixer settings in .ini files. Assuming the language is designed for embedded applications - no gc being a critical idea - then it shouldn't be a problem. In the long run, having the mixer .ini files translated to the same stuff used by the language would make this all transparent,and save space by not having to have two interpreters.

Given the recent advances in using scripts on the Taranis to do things like configure your video transmitter and adjust PID settings in Betaflight from the radio, I think that some kind of scripting support is starting to become more and more important for Deviation.

A powerful language is hardly needed, so if LUA really needs so much code and RAM to interpret and run, it's a poor choice for sure.

I can program in most languages, but Forth or lisp is probably a bit esoteric, even for a old coder like me.

As far as I understand it, the LUA scripts on the Taranis that communicate with Betaflight to control PIDs or the VTX use a subset of the Multiwii Serial Protocol over the FrSky SmartPort telemetry link. To implement this on Deviation means having the ability to parse an incoming data stream, get input from the user, display forms and data on the screen and create appropriate packets to be sent back over the telemetry link. A scripting language with garbage collection and a VM seems overkill for that kind of functionality.

A micro C language would be very nice indeed. I can dream in C.

I looked at Lua, micropython (what I use for scripting STM32F4 boards) and picoc. They all use 70Kb or more flash. This is fine for the Taranis, as it has 512K of flash. But the only devo with that much ram is the 12S. I just posted a note on the thread about the new Tx from BG , as the builders seem to be listening to us about future features.

The only way not to have some sort of VM is to have a compiler. Going to a more primitive one - for instance, picoc just builds and evaluates the parse tree - doesn't help a lot. That's also what the simpler LISP implementations do. I think they and Forth get their small size by combining that with a language syntax that's pretty much the parse tree, but I never did a lot of Forth.

The conventional route to not having a garbage collector is to burden the programmer with having to keep track of what memory is being used, free it when it's done, and then fix the bugs when they forget it's been freed and try to use it. I think I'd rather go with Scheme. Rust does these things in the compiler. That might be adaptable to an interpreter. Not clear it's much easier than just dealing with the bugs in that case, though. The other approach is the DDI algorithm: you just ignore it, require the programmer to not allocate memory in some places, and reset things at regular intervals. Micropython does this.

I've thought about designing a language specifically for scripting embedded systems. The idea is to use forth/lisp like features, but with a conventional syntax. I was going to borrow it from Haskell, as it's syntax is only strange to programmers. I also borrowed the concept of a Monad from Haskell, in that calculations are done in a pure environment, and if you want to change the state of the program - or outside world - it happens in a special statement. That might make the DDI algorithm practical. I put together a simple test interpreter for this to play with the idea. It's not dead yet.

I hope you figure out a way of adding it. If not for the Walkera transmitters, then for a future Jumper model.

I'm extremely happy with my Devo10 - scripting is currently where OpenTX has an advantage. I would be happy with a desktop version for compiling, most of the LUA scripts I've seen on the Taranis has been shared and just used by most users anyway, so they wouldn't care if it was a compiled file or the like. But adjusting PIDS and settings VTX settings from my Devo10, ahhh, a boy can dream

I have two 12s Devos would also love to see this become a reality but unfortunately i have no experience in coding/programming or i would be all over this trying to help out..Would make it much easier to set up PIDs and filters ect on flight control boards if it was just a simple few button clicks on the tx or turning a channel pot for example..

With the recent advances in Betaflight with LUA scripts that basically makes the taranis a configurator menu, both for VTX, FC and even camera now, I really think this is important. It's really the only thing that could pull me away from Deviation, and I freaking LOVE my DEVO10 With Jumper now intersted in making Transmitters for Deviation, having the right amount of flash should be possible. I think it's extremely important for the longterm survival of Deviation that it can at least somewhat keep up with the pace things are happening in the microquad scene. If not, openTX will be the focus for both users and possibly manufacturers as well.

Yes! I want it!

there is another compiled script language called PAWN, which is C like scripting language with smaller footprint compare to LUA.

I have played a bit with open tx, but I prefer deviation, but yes scripts and telemetry such as sensors detection are missing in deviation.