iNavFlight
Scripting engine - run custom code/script during flight
Description
A light-weight stateless interpreter (like PicoC or Lua) that will allow users to write their own scripts to control servos, leds, VTX power etc.
Who does this impact? Who is this for?
Users who need to run their own logic on top of what INAV provides
Forked off https://github.com/iNavFlight/inav/discussions/6454
Seems like PicoC might be better choice here IMO. Very interested in this idea!
I have thought about this a bit and have already played with a few pieces of test code:
Language
PicoC sounds great at first, but in detail there are problems:
- Relatively high memory consumption (approx. 2-3 times as much as LUA)
- A script cannot be called repeatedly. The interpreter would have to be reinitialised before each call: This costs power and static variables are then also not possible.
- I had some strange crashes during the tests
- The project seems to be dead, no commit in git for 4 years, the last serious commit was 7(!) years ago.
Lua doesn't have all these problems, but is bigger, but surely you could disable some parts that are irrelevant for iNav to save memory.
RAM
With a simple script LUA needs about 30-40 kb of RAM, if the script has to be kept in RAM too it will be exciting at least with the F405 (128 kb RAM + 64 kb CCM), maybe you can use a part of the CCM. In any case, good and reliable dynamic memory management is necessary, which is where umm_malloc (https://github.com/rhempel/umm_malloc) is an obvious choice, as it allows LUA to be guaranteed a fixed area, without running out of memory for more important tasks. Of course, it can then happen that the lua scripts are "shot down" due to lack of memory.
Storage location:
SD, further limits the FCs on which Lua runs, but I would not like to use the config section and further bloat the MSP.
API:
The functionality of the current programming framework should be the minimum, other ideas would be:
- Fully customisable OSD elements
- LED strip control
- UART/I2C access
- ... But the API can also be extended little by little.
INAV has a programming framework right now. It's not script and it's closer to PLC, but you can write simple programs to control some of the UAV behavior in flight. https://github.com/iNavFlight/inav/blob/master/docs/Programming%20Framework.md
I know it and I don't like it:
- I find the logic highly cumbersome (yes, I don't like it in Open/EdgeTX either).
- Things that are done in one line of code need several lines in the programming framework.
- It is cumbersome to share "scripts", no one can tell from the CLI output what the "logic conditions" are doing. I have often seen screenshots of the configurator being shared instead of the CLI output.
It would also not be a replacement for the logic conditions, only an addition for power users
The thing is, probably on most popular FCs, there is not enough flash to add any interpreter
Why? Only F411 and F722 are out. LUA has a compiled size of approx. 120 kb, of which a few parts can be deactivated (I/O-lib, for example). With the load code and the memory management you should get under 120 kb, all other processors have 1 MB or more flash memory, on the F405 for example there are currently 540 kb occupied. So this should not be a problem.
I would not say "only". Quick check: F722 and F411 are roughly 30% of all FCs user right now
- find the logic highly cumbersome (yes, I don't like it in Open/EdgeTX either).
I wonder if an easier change would be to make the existing logic conditions easier to use. Right now, logic conditions are similar to machine language in the CLI. Giving the logic conditions names/aliases and having simple op codes in the CLI input/output would go a long way to making them more understandable, and akin to simple assembly language. An enterprising individual could also pretty easily create a simple language that compiles to logic conditions.
@ungood why not just use the programming tab in configurator. That makes logic conditions pretty simple.
Easier than the CLI, but not ideal, IMO. I was replying to Scavenger's comment, though: The challenge of sharing "scripts" in iNav (and OpenTX) is that it's darn near impossible to tell what some logic is supposed to do when there are a lot of dependencies between logic conditions - this is why we use good variable names when programming. Also, if I want to use your "script" I have to remap all the logic conditions to ones that I don't use in my own "script". This would be solved if we could name logic conditions instead.