Acro Mode PID Options and "Fly by Wire"

3689475641?profile=originalThanks 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:






E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Developer

    Yes, again it is a setting that has been in there for a very long time when using the interlock option on ch7. The next release we will have an arming switch like many mini-quad users like. In general we will be trying to line up our interface options so that someone can transition pretty seamlessly.

    In general we need to make some of these options more accessible but it is harder than it sounds given the number of options and applications that Arducopter caters to.

    Unfortunately I can't release the names of the pilots without closely going over a legal contract I am bound by. When I can I will come back and post it here.

  • Thanks for the reply. Does acro mode have "air-mode"? If your not familiar with this mode, most FC reduce PID values when thro is lower than half thro, this was done from long ago as quads did not fly with less than half thro, same with heli's. But with batteries/esc/motors so much better my quad hovers at 18% thro also a lot of maneuvers are now done at zero thro, with non air-mode, the reduced PIDs made the quad fly sluggish. Here is a video that explains it better

    Who was these two fpv pilots?


  • Developer

    The self leveling part can be turned on or off and could be when it was first updated. It can also be adjusted to the taste of the user. BetaFlight has since implemented a similar feature called horizon mode that is quite popular.

    So it is true rate mode is in there and performs very well.

    I recently had the pleasure of two of the very best FPV racing pilots, in the world, test an aircraft running arducopter and the feedback was that it felt like a normal racing quad.

    So the book is closed on this one now. Arducopter, with a good tune and the appropriate settings, can satisfy the elite fpv racing pilots in the world.

    Still in question:

    • Can we get equivalent performance on the tiny quads.
    • Can we get equivalent performance for ACRO focused pilots (opposed to racing pilots)

    There are two factors that prompt those questions.

    1. We are currently limited to 1kHz update rates and after our next couple releases will probably only take this to 4kHz (but we will see).
    2. We do not do control that uses different states for extreme roll or pitch rates. So some ACRO pilots will not be able to achieve the blink-and-you-missed-it rates.

    There is one additional factor that makes this hard. Arducopter is used over a much larger range of aircraft so our default parameters are not great for smaller aircraft. This makes it harder for people to get going. We intend to fix this by having some internal parameter defaults that can be changed with a single aircraft-class parameter. We hope that will make this a little easier for people.

    So unless you are an absolute GUN then arducopter will do the job with the right tune and settings.

  • So fast forward 3 years, I am curious how the "acro" mode is now. Is there still self leveling part of it or is it true rate mode?

    How will it fair to betaflight? tia

  • Developer


    For my current development I am flying an underpowered QAV250 because it stretches the controllers to the maximum. So the comparison isn't easy but I think I am getting as good or better control in normal flight like you show here. For me to get an idea of how well the Naze32 is flying compared to what I am doing on the pixhawk, you need to fly MUCH more aggressively than you did in this video. By that I mean, full throttle descending down at 30 to 45 degrees, into a tight hairpin maintaining full throttle through 4 propeller stalls. My little QAV250 on 3s and a little overweight is pretty easy to push into those conditions :)

    I am currently working on a 1.5kW (continuous) copter based on 6" props to test the opposite end of the power spectrum. However, this is generally a non event because the copter has so much more power to control each axis. It will be fun though :)

    So the pixhawk should be running all my latest code on the 2.3 release but I won't finish all my enhancements to acro until 2.4 (1 thing on my list will have to wait for 2.4). The other thing I should make clear is that all these enhancements are not going to be released on the APM as it doesn't have the processing power/space required. It is nice to be working on a processor that doesn't limit what I can do!!!

    I learn a lot watching how other controllers handle extreme manoeuvres like the one I described above, so if you have any footage of those corners of performance I would be very interested to see them.


  • Hi Leanoard, thanks for responding so quickly in detail.

    As long as both neutrally stable mode and also self leveling acro modes are available then it's all good. Given you fly without any leveling i can't see you not doing that so i'm happy.

    You say you have TPA going since last November? Is this an arducopter port? Can you direct me to it? I'll install it on my APM based miniquad and get testing ASAP if possible!

    I would also be interested to see the apm become more suitable for acro FPV flights. I do a lot of that and for medium to long range stuff the telemetry and other features the APM provide would be very cool if only if flew the right way.

    And just to show off, here's my FPVing my Naze32 / KISS ESC driven mini quad;

    I think there is a way to go before an APM will fly like that but i'd love to see it.
  • Developer
    Hi Chris,
    Thanks for your feedback.

    To answer a few of your comments. First up, I consider the ideal acro mode to be one that is self levelling and not neutrally stable... As you say, this is a great way to help people get into acro flight. It especially helps during hover or for those coming from planes. I completely agree that this is not the way most experienced pilots fly (although I know some x heli pilots like just a little of the natural feel it brings). I personally fly with it turned off. So I completely agree with you here.

    As for the rates in acro, that slider simply sets the ACRO_RP_P and ACRO_Y_P parameters so you can precisely set them if you wish.

    TPA, I agree we need this!!! I have been flying with our version of TPA since November last year. This should be made available for pixhawk users in the next release. Our version of TPA is a significant improvement over the way it is currently done in other systems (in my humble *cough* opinion). To complement this is a new yaw controller and and autotune. I am very happy to say that my fpv quad now flies beautifully smooth through the whole throttle range and doesn't suffer from decent wobbles to anywhere near the same degree as it did before!

    My main focus in this project is to develop the control code to deal with the most aggressive flight performance I can manage. Currently the fussiest pilot is the fpv pilot and I am doing 90% of my development on a QAV250 using both normal and FPV flight. I am working hard to ensure the pixhawk controllers are at least as capable as the dedicated acro controllers. I am VERY happy with how this is going so far!!

    The other thing I should point out. I wrote that blog post a bit over 2 years ago before I implemented the acro you are now using. It has taken me a long time to influence the code enough to make it possible to make these changes but I am pretty happy with the results so far.

    Keep the feedback coming!! I am always interested to hear feedback from all pilots, especially acro and fpv pilots.

  • I fly acro mode using baseflight, cleanflight, multiwii and have messed about with the KK boards a bit. 

    I think your approach may be a little wrong. Reading the first post it appears as if you consider the ideal acro mode to be one that is self levelling and not neutrally stable. 

    I would consider this to be an acro training mode. True acro fliers want neutrally stable aircraft that only ever do exactly what the pilot tells them to do. I could not fly acro the way i do with an aircraft that was always trying to self right itself and i wouldn't want to try. 

    I have tried acro mode as it currently stands on the apm (3.2) with a miniquad and found it to be almost good enough. Firstly i would like to see control rates controlled by a number in the PIDs rather than a less precise and more limited slider in the basic setup options and secondly we NEED TPA. Throttle PID adjustment is vital for stunt performance on small high powered multirotors and without this there is no way i can see myself wanting to fly an APM in acro mode without TPA - it makes too much of a positive difference. 

    Here's a video of my fully equiped mini 'acro' apm based quadcopter;

    As soon as i start throttling up it shakes itself to pieces because the PIDs that are correct for the hover point are too high for full throttle. If i tune for full throttle then it will be badly tuned to fly at the hover point. That's why we need TPA.

  • hi Leonard
    Equations for translation between EARTH frame and BODY frame is (APM 3.1)
    bx = ex - sin(pitch) * ez;
    by = cos(roll) * ey + sin(roll) * cos(pitch) * ez;
    bz = -sin(roll) * ey + cos(pitch) * cos(roll) * ez;

    so I guessed the translation matrix is
    |- 1 0 -sin(pitch) -|
    | 0 cos(roll) sin(roll)*cos(pitch) |
    |_ 0 -sin(roll) cos(pitch)*cos(roll) _|

    the matrix like a R(roll)*R(pitch) where
    R(roll) is
    |- 1 0 0 -|
    | 0 cos(roll) sin(roll) |
    |_ 0 -sin(roll) cos(roll)_|

    R(pitch) is
    |- 1 0 -sin(pitch)-|
    | 0 1 0 |
    |_ 0 0 cos(pitch) _|

    so my question is that why the translation matrix is not the matrix like below?
    |- cos(pitch)*cos(roll) cos(pitch)*sin(yaw) -sin(pitch) -|
    | sin(roll)sin(pitch)cos(yaw)-cos(roll)sin(yaw) sin(roll)sin(pitch)sin(yaw)+cos(roll)cos(yaw) sin(roll)cos(pitch) |
    |_ cos(roll)sin(pitch)cos(yaw)+sin(roll)sin(yaw) cos(roll)sin(pitch)sin(yaw)-sin(roll)cos(yaw) cos(roll)cos(pitch) _|

    do you have any document about this?
    Thanks for taking the time to help
    from Lv

  • LTH,

    If you ever find yourself in the NE look me up - I owe you a 6 six pack for that great explanation of PIDs above.  Most write ups that I see go into the text book definitions of the terms and what's been missing for me are the "if the rig encounters A, the IMU applies B taking inputs from C and D.

    Thanks again for the time you took to write that out.

This reply was deleted.