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.
Yes, this is Randy highlighting that we seem to have lost the warning about AutoTune. These things can disappear from the wiki as it is updated and people take new features like autotune for granted. Autotune has always been intended to be run after a basic level of manual tuning. Since I wrote Autotune it has become normal for people to ignore the manual tuning step and run autotune from default PID’s. This significantly increases the risks.
By “warning about ESC desync risks to the page and point them towards the Lua script” (as Randy suggested), we hope people will get at least a basic tune before running autotune as intended.
As I pointed out before QuickTune is an automated version of my manual tuning instructions. So it makes sense to encourage people to use QuickTune or Manual Tuning as the first step in tuning an aircraft. Then people looking for more can try AutoTune.
At no point in the link you posted did Randy say he “does not want AUTOTUNE recommended”.
I think it is a fairer statement that “Tridge also is anti-AUTOTUNE”. This statement is reasonable for quad planes and he has seen the problems I described associated with trying to finish autotune rather than simply failing.
Thanks @Leonardthall I do appreciate all the help and guidance. I did a fair amount of manual tuning and flew the vehicle pretty aggressively prior to autotune. I’m looking at the ESC config and battery parameters. That sounds like the likely suspect at this point.
I can wrap up this post now with what I think happened based on guidance from you all and reviewing the ESC and Ardupilot data logs. The ESCs log a lot of useful data - battery voltage, current, temperature, rotor RPM, etc. Looking at the battery voltage measured on all the ESCs there was a drop in voltage, as indicated by @andyp1per; however, this was a newly charged battery with only 8 minutes of flight - so the battery should have had more flight time. The RPM data as measured by the ESC for motor 2 does indeed drop low near the end of the flight but the other motors stay in a “normal” region. Pursuing the suggestion by @Leonardthall to look at the ESC “safety settings”, motor 2 did have a cutoff if the battery voltage dropped below 15V. None of the other ESCs had that setting. The cell voltage on the battery look good after the impact - except for one. Five cells are at 3.8 and one is at 3.3.
So, my conclusion based on all this is the battery had a malfunction in flight from that one cell (disappointing as it’s a new battery) and that triggered the safety feature on ESC #2. These are new ESCs for me - so good learning experience - but also a tough way to learn due to a battery going bad in flight.
Really glad you were able to confidently determine the faults and how to resolve them.
A lot of crashes can be with no clear solution and may never be resolved. Glad this was not the case (Sorry if you did lose any equip during the crash tho).
How you charge your battery.
One reason could be that the balancing during charging of the battery is not working.
So please check this. If the balancing is not working correct this accident will happen again.
Excellent info! May I suggest making QuickTune part of the default build instead of Autotune if that’s the direction we’re heading? Many of us are running F405 chips that aren’t able to run LUA scripts which I believe QuickTune is. Instead, making Autotune an optional LUA script.
Disagree. Those using older hardware should accept the fairly well documented task of manually tuning before optimizing with autotune.
@Leonardthall, correct me if I’m wrong, but autotune would likely be hampered by the low rate scheduling inherent in scripting, and would likely produce a less optimized tune if it worked at all under that architecture.