First time I’ve ever encountered this message after many, many autotunes on 4.1 dev. I’m on 4.1 beta now, same quad as before. Any idea how to fix it? @rmackay9
What mode did you switch from when selecting Auto Tune?
PosHold. I also tried Loiter and Althold, same results.
I have only seen that reported when switching from Loiter or PosHold. But then I haven’t run AutoTune on 4.1.
Interesting. I almost always autotune from Loit or PosHold, and have never seen that message.
It’s been suggested to switch from AltHold due to what you reported. There is a note about that in the Wiki.
Yea I’ve seen that before, but thought it was associated with old firmware versions? I’ll have to give it another shot.
Thanks for testing out 4.1. This message appears when the vehicle is having trouble leveling the vehicle between twitches. During leveling it uses the original gains so the message means you may need to do a bit of manual tuning before attempting the autotune.
This message appears if it can’t get the vehicle within 2.5deg of level for 5 seconds. If the vehicle does eventually level and continue to twitch though you don’t necessarily have to take any action. If it’s really not twitching though then you’ll probably need to try and improve the original gains a bit.
I encountered this message while trying to autotune in 4.1 today (entering from all modes mentioned above). The PID parameters were already previously determined by an autotune under 4.07, but I wanted to see if I could tighten them up a bit with the new firmware and hopefully using AltHold only (as recommended).
The wind started to get a little gusty just as I began the routine, and I think that may be to blame. I will report back with more results once the wind dies down.
1 Like
Txs. This message appears when the vehicle has been unable to get within 2.5 deg of level for at least 5 seconds.
It is possible that we should extend this 5 seconds to reduce false positives… I’ve seen the message display a few times during an autotune but it didn’t eventually complete.
1 Like
I had no better success this evening even as it got quite dark and the wind died to a steady breeze with no gusts. I reviewed the logs a bit, and I don’t see any pitch/roll excursions during stabilized flight in AltHold that appear to stay outside +/-2.5°. I did induce some pilot overrides to keep it from drifting too far, but that shouldn’t affect the autotune (I think).
I may be looking a gift horse in the mouth. The thing flies great. In part, I’m just fascinated by the autotune algorithm, and I’m baffled as to why it completed so easily in 4.07 yet fails miserably with just a firmware update (I also recalibrated the accelerometers between this afternoon’s failure and this evening).
If anyone is inclined to help analyze, here are some log files:
Log from my second attempt today, starting with PID values from the 4.07 autotune
Log from my last attempt with some manually changed PID values
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:
https://ardupilot.org/copter/docs/tuning-process-instructions.html
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.
2 Likes
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.
2 Likes