Acro mode tuning --> This is not logical to me

I usually tune the PIDs of a copter by tuning the innermost loop first (angular rate p,i,d). I am tuning the innermost loop by flying in acro mode and looking at the step response to angular rate jumps. I am looking for a quick and response without overshooting. In the end, my 18" 5 kg copter almost reacts like my 5" betaflight race copters (but of course there is much more latency in the rc link in arducopter).
Then I tune the angle controller (p) by flying in stabilize and looking at the step response to angle jumps.

Today, I tried to improve my tuning and there are some things that I don’t understand. My copter is a bit special, it has a large device mounted on top and therefore a large moment of inertia.
During tuning (slowly increasing the angular rate p gain), I noticed some angle (not rate) overshooting and wondered if there is some feedforward active somewhere.

I then found out that even when flying in acro mode, the parameters atc_ang_pit_p (and roll) are fully active! Only when I set them to a number close to zero, I can stop the overshooting. Is this to be expected? I think this is very strange, I wouldn’t expect a parameter for angle to be active when commanding angular rate.

When I disable atc_ang_pit_p (and roll), I can set atc_rat_pit_p to 0.6 (same for roll). I can also set atc_rat_pit_d to 0.005 (same for roll). This results in very crisp and precise response in acro mode. Almost unreal for a large and heavy copter.

But now with the “perfect” angular rate tune, I cannot get a proper angle tune for the stabilize mode. I cannot set atc_ang_pit_p (and roll) to a value higher than 0.75, otherwise I get oscillations in angle. But the response is then sluggish, and the target angle is only achieved very slowly. Acro mode still flies pretty good (but not as good as when I set atc_ang_pit_p to a value close to zero).

My questions: Do you think that this is logical? Why is it a bad approach to get a perfect angular rate tune first? From my understanding, every high-level control should be based on a proper angular rate control…?

Thanks for your input!


I guess that acro mode isn’t really interesting to the arducopter community? And this might be why no one really starts to tune in acro mode, right? But I would still think that this theoretically gives the cleanest approach…

It is interesting and I’ll get back to you once i have time.

How good is your notch filter?

This couldn’t be further from the truth. Acro mode gets a huge amount of focus from me.

The sharpest acro tune you can get will be delivered by autotune. It will tune both your rates and the angle controller.

1 Like

Same for me since 2007 :slight_smile:

Why did I see the influence of atc_ang_p in acro mode? Shouldn’t any angle control loops be disabled in acro mode?

I then found out that even when flying in acro mode, the parameters atc_ang_pit_p (and roll) are fully active! Only when I set them to a number close to zero, I can stop the overshooting.

The angle controller is active in all modes. If you want full rate only then you need to set that bit in ACRO_OPTIONS

FWIW I believe that it is our angle control in acro that makes us superior to betaflight

1 Like

@Willa i don’t know much about the beta flight control architecture but the arducopter control system uses a command model that the response of the aircraft is driven to through the rate and angle controllers. The command model is set up through ATC_ACCEL_X_MAX, ACRO_RP_RATE_TC, ACRO_RP_RATE, ACRO_Y_RATE_TC, ACRO_Y_RATE for acro.
These parameters dictate how the aircraft will respond to your inputs in acro. They are set up based on pilot desired feel however they are limited by the capability of the aircraft response. So you can’t set up the controller to command 720 deg/s at max stick input if the aircraft can’t physically achieve it.

Now the command model takes the pilots inputs and defines the target rate and angle. The rate PID controller and the angle P controller then look at the error between what is commanded and the anctual response and drive the aircraft actual response to the target (desired) response. That is why it is able to use the angle P controller to aid in controlling the aircraft.

The overshooting that occurs when you use angle P could be that the aircraft can’t keep up with what was commanded.


Great, thanks to all for all your explanations! I wish I had more time to dive into this and understand more about how control loops work in arducopter. This is really interesting.

FWIW I believe that it is our angle control in acro that makes us superior to betaflight

Just by interest, why is that an advantage? I never tested arducopter on small copters (they all run betaflight), but if you say arducopter performs even better (I would define “performance” in this application as smallest delays and smallest deviations from commanded angular rates), then I might give it a try!

Current performance is very good with appropriate tuning, but it is likely that you will want this to get really close to betaflight - Copter: run rate loop at full filter rate in its own thread by andyp1per · Pull Request #27029 · ArduPilot/ardupilot · GitHub

The reason I believe it to be superior is that the flight controller is able to control angle requests far more quickly and far more accurately than your fingers and brain can when using pure rate loops. Purists might not see that as an advantage, but I really prefer the feel. The downside currently is that noise can get into the target which a pure rate solution doesn’t suffer from - however theoretically this can be avoided so may find its way into the code in the future.

If you want tons for videos on tuning small copters on ArduPilot then go no further than my channel :stuck_out_tongue:


Hey andy, could you please build a test firmware with this pr for me, for matek h743bd board. I wish to test it but I don’t have a pc for now.

I will be doing a blog/builds soon…

1 Like

@Willa So it boils down to:
How good are your notch filter and LP filter settings?

I think they look approximately ok:

Prompting: Why two notch filters?

I wanted to have more filtering / more bandwidth on the first harmonic, and less on the subsequent harmonics…

There should be no need.
Ideally you would use DSHOT and the RPM data would drive per-motor notches.
If DSHOT and RPM is not possible you should still be able to configure one filter to do the job properly.
Hint: it will be worth doing whatever you need to to get DSHOT and all that nice data working!

Provide a .bin log and we can check

as I have some experience in AP building and tuning copters from 5 to 36 inches props, let me say my vision.

  • No matter what the flight mode you use. On 12+ " copters you SHOULD limit Angle rates to 50-60, Yaw max speed to 45-50 deg/sec, AHRS max angle to 12-26 deg.
    Otherwice you will have real problems. Big cow makes loud “mooooooo” and have huge inertia.
  • PIDs works stable in all modes. So I tune them in AltHold for “normal” copter, and for 5-10" FPV.
    Only difference- for FPV I recheck them in ACRO and usually make small increasing for “digital” response.
  • About AP FPV ACRO VS Betafly ACRO. Unfortunately to achive response and sharpness of BF I switched off all feauches of AP ACRO to make it stupid as monkey.
    ATC_Rate_FF_Enable =0, all XX_TC=0. ACRO_RP_Rates= 500 (but I see no difference with 360)
    As for me- it’s a good drone, not worse as BF good tuned one.
    But other guys who fly better as me in ACRO sayd- it’s a perfect drone.
  • Notch filtering. In my cases on Mark-4 7’ frame vibes less 10%. So I see no neccessary to tune them. I check both variants and see no difference on AP SW.
    Especially I think Bd-Shot to have RPM on FPV for FFT is maniacal request :slight_smile:
    I have one experimental 15’ drone with hard FC install. Normal vibes 40-60%. At big wind each 30-50 sec message “Vibe Compensation ON/ OFF”. But ths is only drone wich have no disasters during 1.5 years.
    AP is really great SW.