“Hardware abstraction layer” - not sure if the acronym was intentional or serendipitous 
1 Like
And of course a short aerobatic sequence 
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?
Hi Tim
You need a 2mb board to support scripting. I think the Mayek H743-SLIM is a good all round choice…. but of course several others if you look at the hardware page https://ardupilot.org/plane/docs/common-autopilots.html and some info here
https://discuss.ardupilot.org/t/about-the-ardupilot-lua-scripting-category/56225
1 Like
It will not.
There are lots of good options out there (check our Wiki!) - I’d suggest
looking at a H7-based boards for scripting.
1 Like
Thanks @peterbarker then I’m going with the Durandal - also discounted for 11.11. 
(I don’t want to have to do any soldering)
@andyp Would like to try this out on my old AcroMaster which last flew when I was on the PX4 devteam.
Upgraded to mRoX2.1-777 with Matek M8Q CAN GPS.
I’m not clear on how to set up a mission with aerobatics though…
Hi @tridge It looks like this code has been merged into master. Does that mean it’s in the 4.1.1 or 4.1.2 build if we download from firmware.ardupilot.org, or do we need to build it ourselves to get the aerobatic scripting code? I’ve been setting up a build environment because I’m assuming the later.
So I’m expecting I need to:
- checkout the Plane-4.1 branch
- merge the above aerobatic scripting commits into my local branch
- build using waf
- install the resulting .bin on my Pixracer using QGroundControl
Is that right?
Hi Tim
If you download from the ‘latest’ directory, that should reflect ‘master’ and saves you building anything ArduPilot firmware : /Plane/latest It is the .apj file you want (assuming your are installing from Mission Planner, etc).
The nav_scripting changes are not in 4.1.1. or 4.1.2 (or any other stable or beta release). Changes in master are not back ported to previous releases (unless maybe super critical?).
The changes in master will hopefully one day make it into a beta then release candidate. But this takes some time.
If you build your own firmware, you can either build from master directly, or cherry pick the aerobatic scripting commits into 4.1 as you suggest. I am not sure of any other required dependencies if you do this… @tridge would be able to comment here
2 Likes
Thanks @andyp - I’m still figuring out how the ArduPilot build stuff works. That’s very useful, so I’ll try ‘latest’ - although I managed to get Plane-4.1 to build on my new M1Pro MacBook which was quite fun!
@andyp @tridge I’m having trouble constructing a mission with a NAV_SCRIPTING item. I’ve tried the latest Mission Planner beta, but I don’t see it as an option.
I tried the latest mavproxy, which has a “SCRIPTING” item, but when I add one to a mission, I get an error when trying to “Write WPs” to the FC. This is with SITL on master.
Is there an example mission.txt posted somewhere, and what is the best way to plan a mission on a Win11/WSL system?
The easiest thing currently is to use stable or beta MP, and select ‘unknown’ as the mission item and enter 42702
Eventually MP will have an item called SCRIPT_TIME. @tridge has included that in this MP build MAVLink: update xml · ArduPilot/MissionPlanner@b910140 · GitHub
There is no functional difference either way. Then the 4 arguments in the mission for the script item are manouver # (1 = roll, 2 = loop), timeout, roll (or pitch) rate, throttle.
Remember to remove the .txt from this file before loading (needs .txt to be uploaded here)…
CMAC_NZ_Loop_Mission.waypoints.txt (800 Bytes)
1 Like
@andyp Thanks, I now have an AcroMaster doing loops in RealFlight/SITL. Now I just need to move the waypoints from New Zealand to Colorado
1 Like
Quick question, can this scripting be interfaced by an external device via mavlink? I am thinking of capabilities as demonstated in this 2012 video.
If, say, you have a heavy lifter device (CPU, GPU, coupled to whatever sensors) doing visual processing and path planning, could you then command something like SET_ATTITUDE(…) over mavlink to get behaviour as in the above video?
What I can’t understand is why flight controllers are so limited. A cell phone has a multi-core processor with gigabytes of RAM, and without the battery, 4 cameras and multiple radios and GPS would be about the size of an FC. A Raspberry PI comes with up to 4G of RAM with a similar form factor. So why is a flight controller limited to 256k, 512k or 1M of RAM if you are very lucky?
Can anyone explain this?
Hey fellow Tim!
I’ll take a stab at this one! They’re definitely not limited, they’re just built for very different things. A cell phone is a linux/unix running system with an OS that runs arbitrary code from all over the internet, has large graphical workloads with high framerates, etc, is much more expensive, and is incapable of connecting to the hardware a flight controller needs. The STM32H743VI in the H742-SLIM for example, is a badass workhourse with 35 communication interfaces (USB, 2 CAN, 7 UARTs, 6 SPI, 4 I2C, etc) each that can offload data exchange from the CPU with 4x DMA controllers, 22 timers (useful for outputting PWM and running a highly synchronous real time system), 3 separate 16bit ADCs capable of reading 36 analog channels… etc. Oh and it’s $10 in quantity of 1000.
While it is possible to run ardupilot as a linux program– being a flight controller is in no small part a task of reliably and predictably coordinating large amounts of hardware with disparate communications interfaces and output methods. It doesn’t take more than 150mHz, (with special math accelerator hardware) a couple megabytes of program space, and a few hundred kB of ram to do sensor fusion, control systems, flight logic, and fly a craft.
Here’s a more in-depth answer about the design differences. I agree the RAM and flash sizes are rather lagging but as that answer points out the predictability of a less pipelined/prediction optimized processor is very important for time critical applications like flight computer.
If you’re really interested in running directly on a linux machine though, check out NavIO!
2 Likes
@andyp Have you spent any time tuning TECS and the nav L1 controller? I find the defaults result in pretty disappointing WP following with the AcroMaster.
1 Like
Hi @kd0aij I have found the standard settings to work well in the models I have used with little tuning required (a foamy (no compass or AS), 40 size trainer, and 2m F3A model). But generally:
- Set the WP radius in m to 2 x the cruise speed in m/s
- Be sure to have completed the servo_auto_trim then autotune
- Do an airspeed calibration
- Then gather and set the basic TECS params (including Trim_arspd, Scaling_speed, Trim_throttle, Arspd_fbw_min, Arspd_fbw_max, Tecs_thr_damp, Tecs_time_const, etc)
- Then I would do an autotune again
- Then L1 tuning (NavL1_period, NavL1_damping, Tecs_speedweight)
I have probably missed something I am sure! The wiki is great with this stuff… If you have bi-directional telemetry, it is all done in 4-5 flights. The 40 size trainer flew a ‘perfect’ mission on its 4th flight - and was my first experience with Ardupilot - a credit to the dev team!
BTW, the Acromaster (if it is the foam model I am thinking of?) is a bit, how do I put it… ‘average’ in terms of servos, linkages, and general repeatability of flight. Rudder trim / side thrust is really important on these sort of models - I would sort that in manual mode first so it tracks straight.
I hope that helps?
1 Like