Thanks for taking the time to read another Blog post.

"Not another Blog post" you say, "Get off your *** and code something up I hear you say" :)

Yeh I know, I hope to have some time over xmas. I am using this BLOG to clarify what I want to do, attempt to make notes that I can refer to (when I finally get my finger out), and get feedback from people to better understand how to best achieve my goal.

Just a quick note on the diagram above. I describe it below but I have remove a number of components that we currently use in the code because they unnecessarily complicate the drawing and are not used in my setup. They could be included in the controller if the user desired.

My Goal is to improve the ACRO mode

The Arducopter has been developed with a significant focus on autonomous flight. The hardware and IMU code is working extremely well. However ACRO mode is much simpler than the quality of the majority of this code and hardware deserves.

The unrestricted ROLL_PITCH_ACRO code is found here:

However it is combined with a YAW_HOLD code by default, shown here:

instead of the YAW_ACRO code here:

I understand this has been because it significantly improves when flying a helicopter.

There is also some restricted ACRO code, that is accessed by setting AXIS_ENABLE to 1, here:

The difference between what I refer to as restricted and unrestricted is weather or not the code allows the airframe to rotate through 360 degrees in any direction.

True ACRO mode will allow the pilot to do flips in roll and yaw or any combination there of.

Restricted ACRO mode is basically controlling STABILIZE mode using a rate input rather than an absolute angle input.

Ideal ACRO mode

The idea ACRO mode is "Fly by wire". By that I mean that the airframe is stabilized as it is in STABILIZE mode but controlled by rate inputs like it is and ACRO mode. I have shown a number of PID control loops above that illustrate potential options to implement this.

The first is the rate only control loop that is currently used by default. This PID design suffers from the absence of absolute attitude feedback. This means that noise, sensor drift, and external forces can cause the attitude of the airframe to vary when no variation is commanded.

The second is the rate controlled stabilize loop that can be set by assigning AXIS_ENABLE to 1. This is a very nice option in that it allows small and precise attitude changes to be made by small stick inputs. This makes it possible to precisely control the airframe not only at hover but also in fast forward flight when pitched forward at 30 degrees. This mode could also be combined with the ALT_HOLD throttle mode to make learning to fly ACRO easier. However, this PID design doesn't result in crisp response because the rate is only increased in proportion to the difference between the desired attitude and measured attitude. This difference must build up to achieve full rate. The last option addresses this problem using a feed forward technique.

The third option is what I would like to eventually implement. This is a feed forward PID design. Here the desired rate is directly fed into the rate controller. However unlike the rate only PID design, the rate is also fed into the attitude input via an integrator (or rate times time step sum). The attitude feedback part of this PID controller only attempts to correct the error in attitude, it is not responsible for commanding the desired rate. In this way we are able to achieve full rate without the "wind up" effect of the attitude controller but still achieve a very stable attitude when zero rate is commanded. If the copter is hit by an external force, the attitude feedback part of the PID will reset the attitude to where it should be. This brings me to the attitude error limit. This is there to prevent poor PID coefficient choices from causing the airframe to continue to move far after the rate command has been set to zero.

Gimbal Lock and Ardupilot

This brings me to a very important point that is missing if we want to be able to use an unrestricted and stabilized implementation of ACRO. Currently the roll and pitch controllers assume that the commands to move the airframe in roll, pitch and yaw correspond to the measurements of attitude. While this is not far from the truth during hover it creates a larger and larger error as the pitch or roll angles increase.

This made flying the quad very strange for me initially. I am used to flying aircraft where I could "Bank and Yank" the aircraft through a turn (roll to say 45 degrees and use pitch to turn). Because of this effect we need to "Bank and Yaw" instead.

While rolled 45 degrees to the right, an input in Yaw to the right (measured by the attitude controller as an angle from north around the horizon) will cause an equal rotation rate in both Yaw to the right and Pitch down. This will cause the Pitch controller to add a pitch up once as this error grows but because this pitch up is at 45 degrees from the horizon it will cause both an increase in pitch up and an increase in yaw to the right.

Ideally what we would do is translate the coordinate system of the earth to that of the airframe before commanding a desired pitch, roll and yaw rate. In this case if the airframe is rolled 45 degrees to the right and a yaw command to the right is applied the yaw controller will command both a yaw and pitch rate command that keeps the nose of the airframe on the horizon.

Without this facility we can't implement a stabilized, unlimited ACRO mode.

Stability in ACRO mode

The common perception of perfect ACRO mode is that we command a rate in any axis and the airframe moves in that axis. While this is good, it is what is known as neutrally stable. When we fly an aircraft we like the aircraft to have a tendency to right its self without user input, this is known as positively stable. This can be implemented into the PID controller using a user defined attitude to rate feedback loop. Basically the roll and pitch angle is multiplied by a stability factor and subtracted from the desired roll and pitch rate. This results in the airframe moving back to level when the sticks are released in a similar way to STABILIZE but when full stick is applied the airframe will continue to rotate in what ever direction is commanded.

An ACRO beginner would set the stability factor high resulting in performance very close to STABILIZE while an experienced pilot might set it to zero or very small so that the attitude can be set not move if the sticks are let go.

OK it's over

Well this pretty much sums up my intentions. The reason I have chosen to focus on ACRO is because most of what I describe above can be done without effecting any other of the auto modes (limited stabilized ACRO mode with a stability factor). And this also happens to be what I want to fly with when I do my 55 km/h runs down a valley out the back of a friends farm house.(Video to come, but I want to get lower).

Any way, if you have read all the way to this point I congratulate your patience. Thank you in advance for any feedback, comments, and (especially) corrections, you can give on the ideas expressed above.

You may be happy to know that I think I am out of things I want to put on my BLOG now :) Now I just need to fix my USB port on my ARM2 so that I can program it without holding the USB cable.


Equations for translation between EARTH frame and BODY frame:






Views: 6371

Comment by Marooned on August 31, 2012 at 11:23am

I know it's not the response you expect but.. this is exactly why I voted for opening the wiki. I would love to see such detailed descriptions on how it all works. Currently we have short info on available modes but without details on how the PIDs are involved in that proces. This result is in lack of knowledge what PID param should I change if I want to achieve X in mode Y.

If I'll run this site I will even run some competition with some prizes for writing great articles.

Anyway, sorry for some off topic :)

Comment by Ryan Beall on August 31, 2012 at 1:38pm

I can't speak to quads because I've only run some of the old stock code, but your feed forward approach should work pretty well depending upon how you write the adhoc logic and error saturation stuff.  I wrote the exact same PID setup for a heading hold code for the tail on a traditional heli.  It works like a champ.  You just have to be careful how you saturate the error etc.  Secondly I don't actually estimate the heading attitude on the heading hold code (ie: i just integrate the gryo to get a non drift corrected pseudo heading) and the heading locks in fine.  The drift is negligible for something that is being manually piloted.  The amount of deadband you have just by having your hands on the controls doing minor adjustments are probably still greater than the gryo angular drift in most cases I've found.  But neither here nor there I think you are on the right approach and flight test will tweak our your adhoc logic quite quickly as it did in mine!  Good luck!

Comment by Jonathan M on August 31, 2012 at 1:56pm

Glad to hear someone is working on ACRO mode.   I need to deep dive what you are saying here, but I believe what you are doing will make this perform more closely to the HoverFly Pro's  manual mode (their acro).  I fly the HF Pro on my larger Y6 that I am hoping to make an aerial video platform.  The manual mode is incredibly smooth on this controller and allows for smooth shooting. It will hold an attitude very well.  Compared to the APM's current acro offereings, it's a night and day difference.  My experience with the current acro on the APM is that it needs constant feedback from the pilot to hold an attitude, especially if your CG is not perfectly aligned with the APM.

Comment by leonardthall on August 31, 2012 at 5:37pm

Thanks everybody for the comments.

Marooned I agree with you. It took me quiet a while to work out what the STAB_I terms worked because they bypass the rate controller. And I had to reverse engineer the code to work out what the Stab_D and Stab_D_S factors did in the PID loops. That is part of the reason I created the pid drawings, because they would have helped me if I saw them when I first started tuning the Quad.

Ryan, I saw your code and your explanation of it before I started reading through the code myself. Your explanation of what you did was one of the things that made me realize that the ACRO PID loops were as simple as they are. I hope things go as well for me as they did for you :). I still have to work out how to load my compiled code onto the APM2 (and fix my USB port before that). But the most important thing is making sure that I have the time to get the code right without silly mistakes.

Jonathan, I had the same experience with ACRO as you did. In reading through the code I found the AXIS_ENABLE setting. I have not tried it out yet but it should improve the feel at the expense of the ability to do flips (I am not good enough to do them yet).

I think that one of the things that makes ACRO mode so poor for many people is the STAB I terms in the stabilized PID loops. Ironic because this term isn't used in the standard ACRO mode. The reason I say this is because historically this term has been used to account for offset CG and minor differenced between motors. These effects are more properly handled using the RATE I term instead. So if people have taking the standard tuning approach to the APM2 then when they switch to ACRO they won't have the PID settings required to properly stabilize the platform.

That is the topic of another BLOG post but I am hesitant to focus too much on that because it could be misconstrued as bashing all the fantastic work the the DEV Team has done to date. It is an important topic though because I think that this is primarily what is responsible for most of the difficulty that people have with tuning their PID loops.

I can set 4 of the 9 roll pitch PID factors to zero and get rock solid control. A first time user only needs 4 non zero factors to get good results and one of them is the RATE I Limit term that generally doesn't need to be touched.

The other aspect that I think makes it harder for beginners is the default PID factors are well tuned for low powered airframes. Too many people need to reduce them to make their airframe stable. How often have you seen the advice "Reduce your RATE P setting" to someone complaining that their Quad is unflyable. I think it would be much better if the default settings were over damped and slow for these quads and a good setting for the higher powered airframes. That way we would get more stable flight experiences "out of the box" and start to replace the comment above with "I have been flying my quad for a few months now and decided to try to tune up my PID's. I increased RATE P and wow, it handles like it is on rails now".

Any way, Thanks again for your comments and to the DEV Team for doing a great job!!!!

Comment by Rick Eis on September 1, 2012 at 12:06am

Hi leanardthall,

I'm curious, you say, "I can set 4 of the 9 roll pitch PID factors to zero and get rock solid control. A first time user only needs 4 non zero factors to get good results and one of them is the RATE I Limit term that generally doesn't need to be touched."

Which are the 9 roll pitch PID factors and which are the 4 you can set to zero, yet still get rock solid performance?

Thanks again for taking the time to help,

(I tweaked my radio and will let you know the results, thanks again :)


Comment by leonardthall on September 1, 2012 at 1:32am

Hi Rick,

This is a good reference to tuning up the 4 parameters I am talking about.

This is the approach I used to tune up my Quad. I did have to back the parameters off to ensure that I had a stable response at all throttle settings through. So basically what I did was tune the quad up this way at hover then tested the quad at 75% throttle ish and then backed all RATE parameters off by the same percentage if until I couldn't hear any wobble in the motor response.

This is the full PID loop for roll and pitch:

I set STB_XXX_I, STB_XXX_IMAX, STAB_D, and STAB_D_S all to zero. This simplifies the system a great deal. As I said above, a new user could also leave RATE_XXX_D zero as well and still get good results.

If I was attempting to choose a set of PID's that would work out of the box for most people I would tend to choose a set of values that made the system react a little slower than some would like but not oscillate in all but the most unstable airframes. Most people don't need lightning fast response, they just want it to be easy to control.

Let's face it though, my comments are just hot air. The Dev Team are making difficult choices and attempting to provide PID values that make everybody happy. It is a very difficult task!

Comment by Rob_Lefebvre on September 1, 2012 at 5:43am

Leonard, I like your ideas a lot.  Ryan, great to see you around!

Somewhat tangentially related to this, I'd love you both to have a look at what I was working on.  I am trying to get an acro mode that works for flybarless helicopters.  What is in trunk currently does not work at all.  Most of us have tried to use the standard Acro mode, but the problem is that it gets into wild oscillations before it ever gets to control and stability.  Our understanding is that the gyro output is far to noisy due to some physical effects on TradHelis.  The servos light up due to angular vibrations before they are responsive enough to control the rate.  The noise is bigger than the signal.

Jonathan Challinger had an idea to get around this simply using a non-standard PID tuning technique.  Set the acro P term to zero, and set acro I and Imax to huge numbers. Basically the I term acts like a P term, but since it's integrating, it can integrate the noise away.

I also tried to understand the "Phubar" controller that Ryan worked on, and I wanted to implement that here.  I tried to do so, but I'm not sure I totally understood the algorithm as it was written in an unfamiliar language for me.  What I did do is create a "Leaky Integrator" which is part of the implementation.

You can see what I did here:

Ryan, I'd love your input on what I've done so far and what still needs to be done.

After reading Leonard's stuff here, I have another idea to make it better, using some feedforward.

What I'd like to try is to multiply stick input by Acro P, and feed that to the swashplate, and then also keep using the I term as I currently am.  Maybe this is what Phubar already does, I'm not positive.  But what I know I can't do, is multiply rate error by Acro P and send that to the swash, as it just becomes a bloody mess.

I tested what I currently have, and it's not bad.  But it is a bit soft due to the need to wind-up the integrator before it responds.  I'd like to improve that, and maybe the stick-to-swash feedforward will do that.

Comment by Rick Eis on September 1, 2012 at 7:37am


I'm wondering if you could take a few minutes and describe in layman's terms what is going on in the "full PID loop for roll and pitch" that you posted for me?  This is the first time I have looked at one and I really would like to understand it.  Maybe there are others too that may benefit. :)

Thanks again for taking the time.


Comment by Phil Cramer on September 1, 2012 at 7:47am

All, just offering encouragement. I'm keen to have a smooth and graceful video platform.

Now that I'm understanding the concepts and approaches to setting up each of the flight modes, I see that what I thought was a baseline flight characteristic, steady hover, is overshadowed by the complexities of missions and multiple platforms. 

Keep on going, guys!

Comment by Jason Short on September 1, 2012 at 10:36am
You should download a fee trial of Flash and run my simulator. In no time you can try all these ideas and plot the results so you can try all sort of scenarios.


You need to be a member of DIY Drones to add comments!

Join DIY Drones


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service