Crash with ArduCopter v4.4.4 [battery caused, not caused by autotune]

Then why is Randy and Andrew saying not to use Autotune.

It looks like you lost motor 2

Perhaps not coincidentally your battery is sagging at this point. Your voltage scaling looks wrong for 6S, so not sure what you actual voltage is - but you can see that your hover throttle is rising. Its possible this is a desync, or maybe your battery sagged enough that too much was asked of the motor. Its worth looking at your ESC settings and certainly worth using a fresh battery for each axis.

If this happened in autotune it could happen in flight - its worth getting to the bottom of.

1 Like

“btw, you are aware that Randy does not want AUTOTUNE recommended, but rather point users to QUIKtune scripting due to many instances of AUTOTUNE crashes…Tridge also is anti-AUTOTUNE…just fyi”

Can we get on the same page?

@Quadzilla - thank you for the good discussion. This is interesting and it seems there may be different messages from developers about autotune. I think this discussion should be continued in a separate thread as my question does not relate to the merits or deficiencies of autotune, but rather what happened in this specific instance.

I guess the words in the title “Autotune crash” through me. BTW I was a tester for the Pixracer pro most all my designs use them.

I spoke to Randy on the phone about this yesterday. His position on Autotune is not as black and white as you paint it.

Fact is, if you tune it methodically (and without skipping ANY steps) using the Blog post you greatly increase the probability of getting a working vehicle, without any unpleasant surprises.

If you skip steps and go straight to autotune, you do have high probability of crashing. And yes, it is in the human nature to blame autotune and ignore the fact that the user skipped mandatory steps.


Hi, I not painting anything. My Statement comes from a well respected Dev. Personally I like VTOL Quicktune.

Then use it. That is fine. And it is even better if all the configuration procedures before the *tune (autotune or VTOL-quicktune.lua) are done correctly and in the correct order.

1 Like

Regarding QT it works well in Realflight!

I asked Arderw for a better option for tuning and he made it. I like to point out that we are a open source community we are all subject to experience and have a equal voice.

Thanks @andyp1per . I think I’m following what you’re saying about motor 2. It does go to a max value after 19:13:48. That’s odd on the battery voltage - however, the battery was at 23V (unloaded) after the flight. With this setup, I’ve seen 1-1.2V drop when loaded.

The ESC setup is another good angle - do you or anyone here have recommendations on setting for Castle Phoenix Edge 50 Lite? I configured the ESCs for “multirotor” mode using the Castle Creations software which has their recommended settings. These ESCs log data as well so I’ll pull that file and look at it.

@Quadzilla - that’s awesome you tested the Pixracer Pro! I’ve used the Pixracer variants for quite a while and have had good success with them.

Another related question / discussion point: is there a recommended axis order for running the autotune? I did yaw, roll, pitch - does the sequence impact anything?


The recommended order is on the guide I posted. roll, pitch, yaw and then roll pitch again.

Don’t have any suggestions, but just wanted to point out the CC Edge 50 ESC uses PWM signal, so it will need throttle calibration to know its max throttle.

Thanks! I’d suggest stating that explicitly in the documentation for autotune as well as your guide. To be clear, I i read your guide and and saw that order but did not see anything that said the order impacts the outcome.

Yep, been through all that.

Please read my posts, I constantly say that the exact order is important. The Blog is already close to the 64000 characters limit. I do not think that it is helpful to explain for the 1001 time that the order affects the outcome.

But do correct me if you think otherwise. And any way that can be used to reformulate the document to make it clearer is also welcome. But I will not make it longer and I have repeated that the order is important many times.

This is not true. Randy is not recommending people do not use autotune.

We are also promoting Quick Tune as an alternative as it will often be more tolerant of poorly setup aircraft or aircraft with flexible payload mounts or frames. Quick tune generally results in a tune that is acceptable to the majority of users. However, Quick Tune is not expected to achieve an optimal tune, just good enough for most people.

Autotune does not crash aircraft. It can show up a weakness in the ESC’s where it can result in over current or desync shut downs due to the sudden input. The crashes associated with autotune are a result of a hardware problem/weakness that could be triggered by any sudden control input to the ESC. We see this in autotune first because it is normally done in the first couple flights.

Quick Tune is an automated version of my manual tuning instructions. Its main short coming is the oscillation detection may not be perfect for all aircraft. This means we need to back the PID values off a little more to be safe.

Autotune is based on achieving the optimal control response. It is also more fussy about having an aircraft that is already reasonably well tuned to start with. It is also more sensitive to noise because it is making precise measurements on each twitch and noise makes these measurements difficult. Autotune is not designed to tune aircraft with flexible payload mounts attached, overly flexible frames, or large wobbly wings. This is why autotune is not ideal for quad planes with poor roll authority.

Now we are getting people using Quick Tune we plan to make Autotune simply fail when aircraft are causing problems. Historically there has been a lot of pressure to make Autotune not fail and this has resulted in more “bad tunes” coming from autotune.



I can confirm @andyp1per summary of the log. It does look like your battery is going through that voltage drop near the end of it’s capacity. As Andy pointed out your battery parameters are strange unless you really are using a 300V battery.

As the battery voltage drops the compensation algorithm will increase the output command to the ESC. This will tend to increase the input current to the ESC. So an input over current fault/shutdown may become more likely.

As Andy said:

One other point I noticed. You are using Castle Phoenix Edge Lite 50 ESC. It was many years ago but I did find a software problem with a Castle esc where one of their protection measures would shut down the esc and I lost a rather expensive aircraft as a result. It may be worth checking you have the latest firmware and that you have turned off any “safety features” that may cause the esc to shut down.


"we plan to make Autotune simply fail when aircraft are causing problems. "

“This is not true. Randy is not recommending people do not use autotune.”

Ok I’m going off a post I saw passing on what I see, not rejoicing just sharing.

What i read and not my post:

“btw, you are aware that Randy does not want AUTOTUNE recommended, but rather point users to QUIKtune scripting due to many instances of AUTOTUNE crashes…Tridge also is anti-AUTOTUNE…just fyi”

Thanks @Leonardthall and @andyp1per . I’ll look at the battery parameters which due look suspicious. And thank you for your comment about turning off the “safety features” on the Castle ESCs. I did flash the most recent firmware but probably left the safety features activated.

I’ll quote what I said in my prior message - “To be clear, I read your guide and and saw that order [ie, axis order for autotuning] but did not see anything that said the order impacts the outcome.”

You do say to follow the steps in order and that does imply the order you mention for autotune. However, a short sentence like “Follow this sequence for tuning each axis as that improves results” would be helpful in my view. Just a suggestion, not a critique.

1 Like