I had an interesting chat to Tridge today about adding autonomous aerobatic capability to Arduplane.
The ability to perform autonomous aerobatic maneuvers has been discussed before, but with the advent of lua scripts and reasonably priced 2mb flight control boards it would seem this is now within reach.
This wont happen overnight, but Tridge hopes to start developing the infrastructure required for us to start scripting autonomous aerobatic maneuvers into our flights. What does a geometrically perfect loop look like from the ground? Hopefully we will soon know! I am looking forward to helping with this development!
I’m imagining that an aerobatic library might consist of a number of various scripts that someone might develop to do various stunts. Is there a way to have the NAV_SCRIPTING waypoint specify a script by name, rather than using 1=roll, 2=loop etc?
This would also mean less code has to be baked into the firmware.
I have been interested in this idea for a long time, but assumed i’d need an SBC (ie ras-pi) to do it. nice to see that it might be easier than that! however, i have some questions…
my planes are not like the over-powered foamies that have a 1:1 (or greater) Pwr:weight ratio, so my fuel/gassers can’t just initiate such maneuvers just anytime/anywhere. i need to assure airspeed, attitude, altitude before beginning such. Then i’m thinking ill need to monitor attitude with roll rate; attitude with airspeed and maybe altitude and throttle percentage (for loop). Will the current methods support algorithms that use such data to adjust maneuvering controls in accordance with live positional parameters? in other words, could such a program know when to enter a loop and how to adjust (more or less elevator) real-time to maintain a predictable airspeed and maneuver shape? or is that more trouble than it’s worth? i just want to avoid not reaching the apex because the plane is a little heavier (full fuel or other payload) or coming over the top so fast that the exit loses much altitude…or a roll that is too slow (relative to the attitude/altitude) that ends up on the ground.
Flight Coach (www.flightcoach.org) was Tom’s idea - and the website really came to life by Artur Uzieblo - as part of this team I am keen to explore the application of autonomous aerobatics for training pilots and judges. It would be really interesting if Tom’s work helped with this
Tom produced this for me - which is one of the initial goals to fly autonomously…
It is a indoor EPP foam model - a 36" MSX - not ideal for Ardupilot - 3D control throws, unstable, and trim always different. I added a Matek H743-SLIM, BN-220 gps (no compass, no AS). I needed to add a 10A BEC as the 1A BEC in the ESC kept on browning out (no surprises there!). Because this is a ‘test bed’, I am using SBus out of the FC (as I will be using this on other models, and want to keep the setups similar) - so it also carries a SBus to PPM converter for the servos and ESC. For fun, while I was adding all this weight, I put on a ESP8266 to make changing missions etc easy.
That’s helpful. I’ve just built a Bixler 2 with a Pixracer and as soon as I saw this topic, I setup an Ubuntu VM so I can build the firmware with this code in it. I’m hoping to test this plane on the weekend (weather permitting) and should be able to flash the firmware try this out, very soon I hope.
just a thought… something that might help some planes is having some kind of ‘soft’ entrance/exit to, say, a loop. rather than slam the elevator to the programmed position as fast as it will go, allow for some kind of gradual activation and release.
@tridge would be best to answer, but because it is using the rate controller, it is no different to when the FC requests any pitch or roll rate… so all that is already taken care of - certainly it looks good, and it is a pitch rate - not a simple servo position…
Yes I can see that - but what I’m suggesting is that it shouldn’t be “the script” - it should be possible to create a different script for each different manoeuvre. A script for roll, a script for half roll, a script for 4 point roll, a script for loop, a script for inside loop, a script for half loop then fly inverted … as many different scripts as people can think of. It will get very messy very fast if every manoeuvre needs to be coded into the same update() method with state variables to figure out which manoeuvre is the current one in progress.
