AutoTune: failing to level, manual tune may be req

Maybe @Leonardthall can have a peek when he finds a moment…

You increased the roll D term from 0.001 to 0.005 and it was oscillating hard.

Autotune can’t tune an aircraft that is oscillating. You may have better success if you start with your initial tune. Otherwise follow this:

If it can’t level in 5 seconds then there is something wrong. 5 seconds is already a long time.

1 Like

I appreciate you taking a look, and I see now that my feeble attempt at helping the issue actually worsened it. I started with the 4.07 autotuned parameters, assuming that the routine might have a better outcome if it began with a decent tune. I’ll do some manual tuning in the reverse direction and try again before reverting to the pre-tune values.

Possibly some artifacts of isolation.

1 Like

It succeeded nicely after I reversed course on the manual tuning and made it less aggressive rather than more.

Out of sheer curiosity, I’m going to run the autotune routine again with the newly autotuned PID terms as the entry values to see if it kicks out the same warning. My uneducated hypothesis is that the “Failing to level” message might be a good indicator of a too aggressive tune, causing visibly imperceptible oscillations in the autopilot. Of course, one could prove that by simply reviewing the logs, but I’d like to do a little experimentation to see if there’s merit to an approach where PID terms are reduced from those set by the autotune routine until another entry into autotune ceases reporting leveling failures.

Ok, all 3 axes complete (again) with few warnings about failure to level, and I think I have a conclusion and resulting methodology:

It’s probably not good practice to rely on “failure to level” messages as the sole reason that your tune is too aggressive, but it’s likely indicative of just that.

Autotune roll and pitch first. A couple of “failure to level” messages won’t hurt. If it fails due to those messages, see my comments in the next paragraph regarding PID terms. Once roll and pitch are autotuned, make sure the new terms are saved before moving on to yaw (which will, in effect, test the roll/pitch tune).

If autotune spits out “failure to level” messages during the yaw (or any other) routine, it’s likely indicative that the tune is too aggressive. Review the log for desired vs actual pitch and roll values along with RATE.ROut/POut. Determine where the oscillation/overshoots are occurring and (EDIT - see Leonard’s feedback below) back off on each of the PID terms by the same small percentage for the offending axis. I ended up just rounding all of the terms down to the nearest tenth or hundredth, and things seemed to improve, but that may not be the best tactic for every case. If the warnings continue, continue decreasing the aggressiveness of the offending axis and re-accomplish at least a few minutes’ worth of yaw autotuning (even after it’s successful) to confirm the absence of “failure to level” messages.

I’m happy to take criticism here - this is my first foray into copter tuning, though I have some pretty extensive (but narrowly focused) experience with the rover firmware.

Here are some graphs of the resulting tune. The top two graphs show RATE desired vs actual during a portion of the flight where I commanded increasingly aggressive inputs on each axis and then centered the stick. The bottom two show oscillation of roll and pitch during a brief period of autotune in the yaw axis, entering from AltHold. Based on the oscillation amplitude from my previously failed attempt and (particularly the roll rate) oscillation during commanded excursions, there may still be room for improvement, but I received no “Failure to level” messages on this demo flight, and the copter appeared to be stable.

Here’s a link to the log itself, including altitude hold, position hold, brief altitude hold + yaw autotune, large control inputs in altitude hold, drift, and RTL modes.


The safe option is to back off the P, I and D terms together by the same amount. Reducing the D term only can result in P term oscillation.

It is very rare that an autotune will result in a over tuned aircraft. Generally a failed autotune will result in very low tune values and a manual tune will be needed to get a flyable aircraft.

Where autotune can easily result in an aggressive tune is in the feel or command model as it selects the fastest or most aggressive parameters the aircraft can support with the assumption that the pilot will reduce these parameters to suit their flying taste.

If you do want a slightly softer tune and you have low noise levels you can reduce the AUTOTUNE_AGGR as low as 0.05. But it is rare that this will be needed and makes the tune more likely to fail due to noise.

1 Like

Leonard, thank you so much for the continued feedback. I will admit that the conditions during which I attempted all of this were a little windier than likely ideal, and perhaps that’s lending some confirmation bias to my observations. I will continue to tweak things, likely run autotune a few more times when conditions are more favorable, and see how the outcomes differ. I may be splitting hairs at this point, but I’m learning a ton.

When you mention backing off all 3 terms by the same amount, do you mean by the same percentage? The D term tends to be an order of magnitude less than P and I, and reducing it by the same raw value would perhaps zero it out.

@Leonardthall, if you’re so inclined and have a moment, I’d sure appreciate any feedback on the most recent log I posted in this thread. I understand if you’re too busy - not everyone can have the dev team at their beck and call, and I certainly don’t expect it.

1 Like

Yes, by the same percentage.

It looks like your aircraft could do better in Roll. Your filter settings are very low. If your frame is a little flexible that may also be giving you trouble.


Thanks much - I concluded as much about the roll axis. I don’t think the frame is very flexible, but perhaps the vibration damping mount that I’m using is a little soft. I’ll take a look at the filter settings as well.

I think this probably concludes the discussion required for my copter in this thread - I have another thread dedicated to this bulid where I will post any further results.

1 Like

A quick follow-up - you can pretty much disregard all after bonjour from me in this thread. I learned a ton about copter tuning, and my mistake was exactly what @Quadzilla suspected.

After a crash (completely unrelated to the tune) and subsequent repairs, I hard mounted the carrier board and got it in the air again. This time the entire autotune routine was much faster with zero errors displayed.

Lesson learned, the Cube series have internal IMU vibration damping, and it is likely counterproductive to add more. Just mount it fast to a rigid part of the frame and tune away!


And to back up what you say, see this pic I posted in the vibration thread: A Cube Orange hard-mounted on the mini-carrier with the GPS unit stuck right to the top of it ! And yes it flies fine, vibes are no problem.




Just received a Holybro X500

Installed a Cube Black on 2mm 3M pads , flashed V4.2.0-dev (e6fb4798) & setup & tried autotune with defaults settings… and get the failing to level, manual tune may be req message

I am willing to go into the Rabbit Hole -no problem with this- but my question is:
Why do we have to get into manual setting with a frame that is pretty standard ?
I am asking the question with the new user perspective in mind, expecting autotune to be an easy step to get into ‘‘ReadyToFly’’ and NOT having to get into complex manual PID tuning

1 Like

When you deal with aircraft ranging from 250 g to 500 kg there is no such thing as standard.

1 Like

What are the characteristics of the default PID when we load a vanilla firmware then ?
I always thought t was a 2kg size 500 quad frame

Agree with that but can’t not note that 99% of people flying arducopter are below 25kg (private and companies), so maybe 3-4 different base setup divided by weight class would be a great help.

Autotuned 3 different copters lately, 2 in the 10kg class and one in 25kg and all three told me to go by hand because failing to level.


Sorry, I over simplified my statement. We are dealing with aircraft ranging over:

  • 150 g to 500 kg
  • Thrust to weight of 10 : 1 to 1.5:1
  • ESC - Standard, active breaking, FOC
  • Battery voltage of 1 s to 100 s (4V to 400V)
  • Motor KV of 80 to 6000
  • Propellers of 3" to 60", 2 blades to 8, standard and ducted
  • Tri, Quad, Y6, X8, Hex, Octo, Dodeca
  • Frame design from floppy to rock solid
  • Autopilot mounting: hard mounted, internally isolated, home made isolation
  • Build quality of beautiful to shocking

We are building flying robots. If you are a hobbyist then enjoy the hobby and learn the basics of tuning:

If you are a professional and consider the aircraft tuned after starting from the defaults and running auto-tune then I have some bad news, you are not a professional (too many barely rate as novice hobbyist).

Perhaps you should be talking to the manufactures of these aircraft and suggesting they take the time to have these kits professionally tuned so that they can provide a standard tune for their customers…


@Leonardthall I agree with your statement and as a member of dev team I can understand the scope and depth of the tuning process.

But my question is related to new user experience and trying to make it easy for them to get started. Allow me to repeat the question : What is the default vehicle target for the default PID as implemented in the Copter Firmware ?

And why I experience an issue with what I always considered as the standard model: 1-2Kg Quad - 500 frame 9-10inch propellers (That I had no problem autotuning until 4.x)

I can open a new thread on this if you wish but I consider that this question has quite essential to have a starting reference to the wiki

There is no “default vehicle target”. The default parameters are chosen to be safe for a wide range of aircraft. The goal is not to let a few people with a particular frame to have a good tune out of the box. The goal is to minimise the chance of injuring a person or damaging an aircraft on the first arm. Given the range of aircraft this alone is a difficult proposition.

Have you considered the possibility that the problem is this airframe, or the way you built it?

Have you went back to 3.x and tested autotune on this airframe?

By the time you get to the “AutoTune: failing to level, please tune manually” message. Autotune has already relaxed the level requirements by a factor of 2. I suspect a log with ATTITUDE_FAST turned on will show high vibration levels, oscillation, or some other serious problem. Of course you may have just been trying to autotune in too much wind with a sloppy tune.

But to be honest, jumping on the forum to blame autotune, 4.x, the default parameters with complete confidence that the aircraft and your build is perfect… well… I tend to work out why I am seeing something before I start telling other people they have got it wrong.

1 Like

Fair enough, as I wrote initially I don’t mind going down the Rabbit Hole searching for the root cause and report back.
And please don’t take it as a blame but as constructive comment on how to make the ArduPilot experience easier and fun.

1 Like