I maybe missing something, but not sure on the difference between a separate ‘script’ for each maneuver, and each maneuver being defined and referenced inside one script? You can define anything you like in the script…
Currently it works really well - within the scrip we can create (for example) a ‘upline’ and a ‘downline’, and these are triggered by MP when you reach a WP… You could easily create a 3/4 loop and 1/2 roll and trigger that when a WP is reached… really endless possibilities…
Anyway, really early days - we will be changing to quaternion reference and vector navigation - so wind will be accounted for, etc.
It will take a while, but already it will fly a nice loop and roll - a good start I think
You wouldn’t necessarily need to use the same script for each maneuver, but it may help save some RAM and/or processing time to do so rather than parceling things out amongst different files.
As for organizing the single script - I tend to write ArduPilot Lua scripts as state machines of sorts. Rather than using a single update() method, I write a method for each state and then use a conditional statement or method to change states as appropriate. Consider this example: P_Brake_StateMachine.lua (2.5 KB)
All that said, I agree that it would be very useful to be able to trigger a “one-shot” script using a waypoint command rather than continuously polling for a trigger command in a persistent script. Unless I’m mistaken, that capability does not yet exist.
Currently when a ‘scripted aerobatics’ WP is reached, the maneuver number (what the maneuver is) and some parameters for the maneuver (say roll rate) are passed from the mission to the script. So the current method lets you set up many different maneuvers to each occur at different WP’s as part of a mission.
Future functionality could include anything - such as triggering individual maneuvers from a switch (like do a loop now). Probably you would want an interlock on this - so ‘aerobatic FM’ and then a switch to trigger say two different maneuvers?
Your own maneuvers can be coded. Maybe someone writes a GUI for programming an aerobatic flight - that would be really nice Once our aerobatic ‘navigation’ method is changed to more vector based, that may be in reach to someone?
I think it will take a while to figure out what works best
Andy, I completely understand, and it really is a very fascinating concept. I’m interested in the feature set for reasons beyond the scope of aerobatics (as you suggest is very possible), but I’ll try and limit my discussion to relevant points in this topic.
Confirm, though, that the script that handles the maneuvers must be running continuously and polling for the trigger waypoint and its parameters?
If that’s the case, it seems possibly wasteful of RAM and processor time to have it sitting effectively idle most of the time. It would be very cool to have a waypoint command actually trigger the execution of a script as a one-time event rather than having the script loop continuously.
Agreed @Yuri_Rage - thats exactly what I imagine. Specifically, a waypoint that can trigger/start a specific script by name. The script could run X iterations/repeats (e.g. 3 loops) of the move and then terminate. Ideally it could also call other move scripts too.
Since scripts can restart if there is a crash/error/failure during a mission, surely it’s possible to have a specific script start at a waypoint?
There is a bit of an issue with one script calling another, and I do appreciate the design choices made by the dev team in that regard. Each script is effectively sandboxed in its own environment. It is intentionally unaware of other scripts and incapable of interacting with them except by changing SCR_USER* parameters.
I’m unaware of any existing mechanism to restart a script after it has exited in error. Can you point me to the documentation on that?
I suspect there may also be an issue with executing a script on demand, since all scripts are presently read into memory at boot time and executed in turn on a schedule. Our suggestion here is a significant departure from that.
Hopefully Tridge or one of the other developers can chime in soon and give some insight as to the possibilities there.
If scripts run out of memory (or panic for any reason) all currently running scripts are terminated, and the scripting engine will restart, and reload all scripts from the disk. This is allowed to happen at all flight stages, even while the vehicle is armed and flying.
I just found and read that myself. In practice, that is not what I’ve seen happen, although I see exactly where it is explicitly stated.
My own experience is that a script that exits in error will terminate while others remain active in their present states. If the scripting engine runs out of memory, it simply stops entirely with a single error message, and the autopilot retains all other functionality.
My Bixinator (Bixler 2 + Pixracer) I was planning to test this with flew itself into a tree during it’s first config/setup flight. I’m hoping to get it back soon. (9x zoom - it’s a long way up!)
I’m looking for a FC to possibly replace the PixRacer that is (still) stuck in the tree to try this out. It’s not really clear to me what FC will support the aerobatics patches. I’ve noticed that the Radiolink Mini Pix is a good price on AliExpress for 11.11 - will it work?
