Wild ride after successful Auto-tune

Airframe is a Hover 1 quad.
X configuration frame.
Cube Orange/Here3 on 4.4.3 Copter
Taranis X8R receiver
Running T-motor 3508-29 KV390 motors
1552 DJI folding props.
6S 8000mah battery
Foxtech Multi-pal 40A Opto Esc’s
FC and GPS puck are mounted on the top plate of the frame.

Autotune took quite a while but it was completed. Only did a 2 axis tune. (Pitch and roll)
It flew well both before and after the tune. It was a few days later that it was flown again.
Bin file link for the subsequent flight:
As it climbed to altitude it started acting erratically and then went full bonkers. It was pitching and banking wildly.
It was in Position Hold for the beginning of the flight. Switching to stabilize or RTL and trying to gain control had little to no effect for a few minutes. Fortunately, it had lots of altitude.
I used the Plot Ardupilot site and it looks like the MAGs were spiking.
Actually if you look at any of the values for RCOUT, GYRO, MAG, VIBE, they all look like this graph.

It finally executed an RTL with a bit of a bouncy ride down.
Any suggestions on what to look at would be greatly appreciated.
Thanks in advance

I don’t think .05 for Auto Tune aggression did you much good which is often seen with a value that low. Looks like you missed setting some PSC parameters also. So, it was instability waiting to happen. And if you are going to enable the notch filter at least enable batch logging so it can be set. Motor Ranges are at default also. And the vibe levels are high.

I think you needed to do more initial tuning before running Auto Tune. It was pre-mature and the aggression tuned some of the PID parameters very low for that craft.

“As it climbed to altitude it started acting erratically and then went full bonkers. It was pitching and banking wildly.”

The author of Auto-tune is revamping the program. You could use the stock tune and VTOL-quicktune right now. This is what I use if the craft need some adjustments. Also if you find your quad is twitchy this simple tool in Mission planner will normally fix it for you.

You also could recalibrate your esc’s using the radio as a precaucion.

Hello @Hover1 , welcome to the community,

Did you do the mandatory tuning steps required before starting the autotune?

You should have at least done the notch filter calibration, the SLEW rate limiting, the magFit and the FF disabled flight.

Not doing that is asking for trouble.

Please follow How to methodically tune (almost) any multicopter using ArduCopter 4.4.x to reduce the probability of future “full bonkers” flights

The OP title states a flyaway after tuning. You can see if your recommending a system that needs some updates why i would question this.

Come on, you wouldn’t banish a car because there’s a facelift coming next month, would you?

The fact that there is an improvement coming doesn’t mean the current state of autotune is completely broken. It just doesn’t work if you feed it crap. But guess what, so do I. If you feed me crap I will not function properly too. And correct me if I’m wrong, but I don’t think the next generation of autotune will change that and become the cure-all. If you feed it crap the results will still be bad. They’ll probably be better than today but not as good as they can be when starting with a decent drone.

Also keep in mind that not everyone who uses autotune has a problem with it. We only see those with a problem here because they are the only people reporting it.

Anyway, what do you want people to do now? Entirely halt all tuning, testing and production until the perfect algorithm is found?

With ArduPilot, lots of features are continually under development. Should we notify users about each of these features to not use them?

@Hover1 Sorry you have to witness this heated discussion and sorry I may have called your drone ‘crap’, I didn’t mean your drone in particular and it will certainly fly great once properly tuned. Also there are a lot of drones in worse shape than yours when attempting autotune (if that makes it better). I just needed a clear, strong and unmistakable word to get my point across.

I have remove the heated conversation above as it is not relevant to topic at hand.


I can see you have followed what looks like the mission planner setup guide or similar.

It does look like you have got into a large occilation but the aircraft appeared to be flying reasonably stable before this.

The aircraft seems to respond reasonably well in pitch but roll looks like it may be oscillating. However, the loss of control appears to be more in pitch.

The loss of control seems to be very sudden. I wonder if this is a motor out or maybe a position controller oscillation.

You do have a very large offset between motors. But when I zoom in it doesn’t look like the classic motor loss output. Maybe this is an ESC calibration problem or an offset CG.

It does look strange though. You are commanding a decent of 3.5 m/s. It looks like this decent is what kicks off the oscillation.

Ok, so why did this oscillate…

Before I go into my long discussion on Autotune, I thought of another potential cause of this oscillation. It is possible you are using fixed PWM esc’s and have set the PWM range too large, maybe not set the spin min and max properly. This can create a dead band at the top and bottom of the thrust curve. Once you enter it with a significant disturbance you start oscillating.

The results of autotune are not great but also suggest problems with the way the aircraft is setup or handling. Autotune needed to drop ATC_RAT_RLL_P to 0.02783866 to stop the overshoot. Pitch was a little better but still less than half what I would like to see. It is hard to know without seeing the autotune log. You have halved AUTOTUNE_AGGR to 0.05. This should only be done on a low noise aircraft with all the filtering set up. This makes autotune very fussy on the overshoot and doesn’t leave much room if an aircraft has any problems.

Can you provide the Autotune log?

There has been a lot of discussion about autotune lately. So I will address that again here. The Ardupilot developers have always tried to make it as easy as possible to setup aircraft and manually tuning aircraft has always been difficult for users. Autotune provided the first automated tuning algorithm that produced great results. However, it demanded a reasonably well setup aircraft to begin with. I designed it to fail if the aircraft didn’t respond as expected. However, Autotune has been adjusted over the years to make it continue rather than fail. The thought was that a bad autotune was better than a bad manual tune.

I am making changes to return Autotune to the original behaviour where it would stop tuning rather than “do it’s best” when an aircraft shows problems. I have also found a few little areas where we can improve the autotune result. We have started testing but I am not sure what version it will be released in. I may start a blog looking for testers soon.

There have also been some discussion about the importance of the setup instructions. While it is possible to skip steps and get an aircraft flying reasonably well, following the instructions for manual tuning, control testing, filter setup, autotune, control testing again, all adds a lot of safety. These steps help catch problems before they become serious incidents like this one.

While I may not describe each step as “mandatory” I would say that it would be irresponsible for developers to advocate ignoring those steps as they are there to keep aircraft and people safe.

@Hover1 In particular the section of the Wiki you should use to check your tune is here:

These steps are designed to excite oscillation in a more controlled way, letting you sneak up on it.


Thank you for the replies,

I am guilty of being very lazy about this setup.
It flew reasonably well before the Autotune and “appeared” to fly well after, and I assumed all was good. I am also guilty of poking around the parameters but I do not have a full understanding of the complexities of the system. I have built many multirotors and Autotune has been the one piece that seemed to make it an easier FC to deal with.

I will learn from this and go through all the steps necessary to get a better overall tune and a better understanding of the system before trying the Autotune again.

“Can you provide the Autotune log?”
I have attached the autotune flight bin file.

Thank you again for helping analyze this and I appreciate all the developers’ hard work with this FC.

1 Like

Hi @Hover1

It looks like autotune went low because of the low AGGR.

The AGGR threshold is the overshoot plus the noise. With all that has been done over the last few years on harmonic notch filtering it has made setting this parameter harder because some people have got really clean setups now that can take 0.05 but others need a higher setting of 0.01 because of the extra noise.

I would suggest trying with 0.1 and 0.05. If you find 0.05 gives just slightly lower values than 0.1 then it is probably the better tune. However, if 0.05 goes much lower, especially in D, then use the 0.1 tune.

It is always good to do a manual tune (maybe quick tune now) because you have a reference to compare the autotune results to and you also improve the autotune result because the aircraft is more stable before each test.

The changes I am making to Autotune will be much more likely to simply fail autotune with a message if AGGR is too low. So I hope people can then get a warning they need to increase AGGR or fix whatever the problem is.

Just to be clear though. While I am sure that the autotune result wasn’t a great tune I am I am not 100% sure this is what caused the oscillation. Make sure you double check:

  • ESC calibration and the expected PWM range if they are fixed PWM
  • Spin Min
  • CG location
  • All propellers are on the same plane.

A quick check you can do is make sure all the RC out for the motors are close together when you are hovering in no wind.

Thank you @Leonardthall again for the help. I will move forward with these suggestions as soon as this nasty blizzard goes away.
Montana, either love it or hate it.

I am recommending 32 bit escs. If not 32 bit I recommending the old school radio calibration even for BLHeli_S based on my bench testing last month using a beta 6 and 1 esc from Troy Naquin. We are getting to run on my new baby Y6 do to space issues.

Check out this 4 n 1 and the best part no need to calibrate: Amazon.com

For non 32 bit try this.

My Uncle had a ranch lease in Wyoming he loved it.

I will redo the ESC calibration and as @Leonardthall said I will make sure motor outputs are more closely matched.