This is a work in progress. I've tried to address some fine tuning and performance issues.

Denny R. had made a comment about the inertia of bigger props causing issues. I've added a low pass filter to smooth the positive acceleration of the props to see if we can get at this issue. It may require tuning up Rate_P for a few folks, but I saw little issue in multiple flights.

Crosstrack had a small math error that decreased the resolution of it. I've fixed that and upped the default gains to get better tracking. 

Made WP hit radius 1 by default. even 3m is too much for quads. (If you pass a WP you will move on to the next)

The Loiter method is tuned a little better by default, and now uses GPS offsets when flying less than 1.5m/s. Code experimentation will continue on this front. Thanks to Emile and afernan for their help!

A fix in the Z Accel startup was added to get an averaged result.

Added the ability to enter Loiter with Optflow enabled. - still a work in progress, not for everyday use just yet.

This alpha is on GIT now and is for user's who want to test code. As always, you need to use the "relaxpatch" version of Arduino you can find in the downloads section

Update: We've found and patched some small type bugs in the latest and updated some GPS drivers in the Library. Be sure to pull the latest code and check for the status of each build run against the SIL sim server.

Update r3:

I pushed a version on to GIT that addresses a number of issues.

- the low speed GPS XY calculations were incorrect and have been fixed

- Nav_Rate I term has been removed in loiter control - it's too easy to get two iterms working out of phase

- A second derivative has been added to Roll and Pitch. I found it removed wobbles nicely - Can be adjusted in the planner as STAB_D with a default of .25 (just enough)

- Smoothing has been applied to the motor commands in a way that really quiets down the alt hold pulsing without much effect on latency

- Yaw now has a dynamic constraint and I've upped the yaw gain.

- The motors output now have an LP filter on them so that the accelerate just a tad slower than the deceleration. This is a test to see if it helps big Octo's and Hexa's

- The Rate_I term is now zero'd for first five seconds after takeoff to keep balance.

- Loiter gains are lightened up a bit

- Nav_Rate_P is lower to remove back and forth sped related hunting in loiter

- Compass is enabled by default

- New I2C Library now included which should solve I2C related lockouts

- optflow is still a work in progress.

Update R4:

This update is based on flights today in a very windy environment.

It occurred to me that we're handling the WP nav I terms incorrectly and I reworked the WP navigation to share the same I terms from the Loiter. Even though they use different error input, etc, they turn out to both deal with wind in the same way. I have not Flown WPs with this new code, but heavily tested it in the sim and It's really rocking in hard wind. Transitions from Loiter flight and Nav flight are very smooth. Please let me know if you have luck.

Update R5:

This is a quick patch based on a bad crash Marco had. My theory was an I term that built up during wind that needed to be reset, but wasn't. It's a corner case but It bit Marco pretty bad. Please re-pull if you have R4 running to go to R5. And please, please be careful. This is alpha code not for general testing, but for development. Don't fly it on anything you would feel bad about crashing. 


Update R6:

Includes fix for Acro mode reset bug.
I went through all of the global variables and gave them lengthy descriptions. It's worth a read if you want to learn more how the internals work. I'll be doing some more organization like this as we move forward with an architectural redesign for 3.0 \
This version is mostly clean-up, but does include 1 interesting performance enhancement. It's disabled by default because It's fairly untested. The idea is that the wind compensation created by the Iterms for lat and lon in Loiter and Navigation are carried over into Stabilize. This unifies all of the modes so that when you switch modes, you don't get a small, but fast change in pitch or roll. This is only noticeable in high wind environment. 
To get this to work, I look for near zero velocity and start moving the pitch and roll into the wind control items. This takes a  transformation from copter frame to world frame, but the result is the copter will hold the position against the wind with the sticks in the center of the controller. If you fly around the wind compensation will bleed off slowly - about 30 seconds.
Again, this is off by default and needs significant testing, preferably in the HIL sim first.JNL has already started and flown this version for real.
The feature may be off by default for another version or two, but just letting you know it's there.
I think it will go a long way to making the mode changes feel seamless.

Update R7:

Added an auto-land timer for RTL. If you don't change modes for 20s after the copter arrives at home, it will begin to auto-land. If you have failsafe and no GPS, you will immediately begin auto-landing.
Failsafe RTL now goes 10M up as it RTLs to avoid obstructions.
Added SIL test for failsafe. 

Update R8:

Minor tweaks and cleanup

Update R9:

Made climb rate controller for landing universal for all altitude changes

Update R10:

Updated Loiter controller - Works great in the sim, thanks Afernan.



Views: 42944

Reply to This

Replies to This Discussion

Hi Marco, Angel,

I have the aerosim and tried the HIL simulation with the MK Quad model (with default setting) and my APM 1. The simulation doesn't goes well, i have bad wobbles in all modes except for the acro.

- I modifed my the APM_Config.h as prescribes


- Compiled the project;
- Made all usual setup (reset, radio, etc);
- made the following setting parameters;























- My DX8 ( RX and APM powered) is not connected directly to the PC via the Aerosim USB connector.


I would appreciate if you could post your APM Planner param setting.


Thanks a lot!


Many parameters in the planner takes significantly lowered, like:

STAB R/P P: 0,5
STAB "R/P & YAW" I: 0

On average, almost all the "I" for the Stab and Acro want to "0".
Adjust the gain in the image for take a linear and complete control (100/0/100) in the sim, is always different for all users, i have: 3000/3000/1000/410.

Let me know.

Apart of the nominal settings, i see crazy behaviours due to incompatilities with other programs that interfer in the sim, like for example Camtasia screen recording, and maybe others. Once closed, the sim works fine.

This brings up a question I have regarding the use of simulators in HIL. The quad models in the simulators all seem to have stabilizers built in so the model can be flown by a human using only normal RC controls.

Is the HIL interface somehow bypassing the models' stabilizers, or are the HIL tests just exercising the navigation functions of APM and not the lower level stability functions?

So I know the feature is brand brand new, as is HIL with x-plane, but I've been running 2.1.1 r6 on there. The disarming of the motors on land is a nice feature, but I think I've missed something. The motors are disarming at about 2-3 meters in the air. Does this somehow look for 0 movement in X, Y and Z axis for a specific length of time before shutting down the motors gradually, or does it just kill them as soon as the land command is assumed to be executed?

My pre-land waypoint is at 3m, with a 5 second delay to allow any movement to be dampened. Land is at 0 altitude.

Update, tried this morning in much less wind.

At times it stayed stationary for almost a minute, then with a slight breeze, it would start hunting a bit.

At all times the front stayed pointing in the direction it was, when switching it to loiter.

Weirdly, it would also change altitude, by about 3 meters.

When hunting, the box would be about 5x5 meters.

I see there is a CLI function still, and a menu called logs, but nothing in there.

I'm going to get another xBee soon.

The Auto Land function is under progress.
I hope Jason put a parameter for enable/disable the automatic land if RTL is engage, with some heavy setup like mine the automatic land is not a nice idea.
They must also be included on several securities with the automatic shutdown of the engines, because in case of failure of some sensors may turn off the engines in flight at high altitude.
I think the best way is to put a new flight mode manageable with the radio switch, called "LAND" or "RTL+LAND", selectable by the planner.
In the tests we are making on the simulator in many cases do not turn off the engines, the drone continues to slam on the ground indefinitely, and the altimeter is much precise with the sim.

Angel: I will take in consideration, softwares and process running in background.



Marco:Pitch and roll control on stabilised mode are better now but i still have some issue with the yaw control. I have some analyse to do.

Phil: You made a good point. I think we have here two stability system working in series.

Thanks a lot!



Firrt record the fly with the internal recorder of AeroSim, then close the planner, start to grab the screen of the sim and play the recorder fly.

Real flight test on 2.1.1. r6

I´ve long tested in my two copters (small and medium size). No wind. Started with defaults.

I´ve concentrated in LOITER, since the rest of modes works pretty well.

I can summarize the following.

- There is always a "swing" or "bounce" around LOITER point that I can´t eliminate. It remains between 3-6 m . Sometimes gets smaller, but again start the movement.
- Increasing the LOITER_P, increase the size and speed of the swing. Default value is the best.
- LOITER_I increase the size of the  movement but become slower. It must be kept low (<0.1 - 0.05)
- STAB_B increase doesn´t show a clear improvement (up to 0.4). Back again to deffault (0.2)
- Reducing LOITER _P = 0.15 and LOITER_I=0.2 eliminate the swing, but LOITER point is not precise (moves in an area of 10m)

In summary, I miss an effitient damper control component, that let us increase P and I without diverge.

Comparison with HIL behaviour.
HIL is almost perfect, but real flighht not. What can we deduce?

HIL copter and GPS signal are "perfect" versus real hardware.

We can say that (IMHO):
1.- the code is correct
2.- The code is not robust enough under imperfections of the hardware (yet).

...see next chapter


Yes, it could be true that the code is not robust under imperfect conditions.  But maybe your hardware has a particular problem?  Maybe bad vibes that are making the gyros really struggle?

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service