@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
Thanks, that helps. I’ve only done a few short missions myself, and those were just one circuit around the pattern with small VTOLs to test transitions and airspeed sensors. I don’t recall doing any TECS or nav tuning at all for those, but now that I’m looking closely at the flight path in relation to the waypoints I see that there must be a lot involved with tuning and waypoint placement to achieve a desired trajectory.
And yes, my AcroMaster has long ny-rod type rudder and elevator linkages which probably do change length with temperature. But the aileron linkages are good And I do have Precision Aerobatics Addiction and Extra MX airframes available for later.
2 Likes
With the yaw controller in place, we can now also do this:
But still many enhancements to come!
2 Likes
Very cool. This is my RF8 Acromaster with PR19365.
Questions:
When are YAW2SRV_INT/SLIP/DAMP parameters in effect?
How do you rotate the runway heading in a RealFlight airport?
1 Like
@tridge My mRoX2.1-777 won’t boot when flashed with latest master or PR19365,
but is OK with stable and beta. How would I go about troubleshooting this?
I also find that I can no longer locally build a version of master which boots on the X2.1-777. But both the official download and my local build of 4.1.4 boot up OK.
nice!
at the moment the YAW_RATE_* rate controller is in effect under 3 conditions (when enabled with ACRO_YAW_RATE and YAW_RATE_ENABLE):
- in ACRO mode
- in AUTOTUNE mode
- when in a NAV_SCRIPT_TIME mission item
I am considering making it active at all times (when enabled), with the desired rate either fed from the coordination rate or from the lateral acceleration. The advantage would be that we would get the autotuner for the yaw damper, which should make tuning for good rudder control a lot easier. I’ll discuss with @priseborough
1 Like
MSX foamy doing a rolling circle for real 
It looks amazing!
3 Likes