WARNING! AutoTune bug in Copter-4.0.1/4.0.0

Note: Copter-4.0.2 has been released with a fix!

We’ve discovered a serious bug in Copter-4.0.1’s AutoTune feature (it also affects Copter-4.0.0) that means that the vehicle may suffer from poor attitude control when AutoTune completes or is suspended or aborted. We strongly recommend that users avoid using AutoTune until Copter-4.0.2 is released with a fix.

This bug does not affect Copter-3.6.x.

The issue is the original gains (i.e. pre AutoTune gains) are not restored when AutoTune completes or is suspended/aborted. In most cases this means the vehicle will use “Inter Twitch” gains which are relatively close to the original gains (only the I-term is 10x less than the original) but if the pilot was unlucky enough to interrupt AutoTune during a twitch, the gains could be very far from the original and cause a crash.

There have been two confirmed cases where this issue caused such poor attitude control that the Crash Check was triggered leading to a crash.

Sincere apologies for the issue.

5 Likes

@rmackay9 Thank you for the notice, please also note that I just installed 4.0.1 to test on a Y6F and before even reading your bulletin i noticed that on MP in extended tuning FILT comes up with 0.
On the full parameter list both FLTT and FLTD are set to 20 and even though changed to 10 (since i am using 16" props) extended tuning stays the same.
Maybe this is another issue to be checked and connected with the Autotune bug?
Edit: Just uploaded 4.0.2rc3 for testing on my firmware Hexa test build and found the same issue.
Maybe its only an MP thing? @Michael_Oborne

2 Likes

@MerkaTony,

Yes, it’s a Mission Planner issue and it’s included in this issue. Hopefully MichaelO can take care of this one in the near future.

I have done a simple flight test using Copter-4.0.2, and I want to autotune tomorrow. Would it be okay?

1 Like

From Release notes for 4.02-rc3:

Bug Fixes:
a) AutoTune fix to restore original gains when AutoTune completes

As serious it is though specific confirmation would be nice.

Hmmm i think you can add a third crash to this bug. Unfortunately i did not read this thread early enough.

Well at least i know what caused the weird behavior today. I hope the repairs won’t cost too much and take too long. I was flying at around 5m height and crashed into low grass.

I have a Video and the log-Files if it helps to fix this issue: OSD Video and Bin-File Altough i see this is already fixed in the new beta.

What happenend:

I am building a mapping hexacopter with two redundant cube orange. I was already flying the drone successfully. And i also managed to do a Autotune without a crash. But i think i simply had luck landing it at the first attempt. Today i was confident to do a second Autotune (changed some parameters). And it was doing absolutely perfect. Staying rock solid in the air. Until i switched back to AltHold after the successfull Autotune. Suddenly my roll was overshooting and caused a crash. Switching between new and old PID values did not work and so i lost control.

@rk2cy_u,

Yes, I think that Copter-4.0.2-rc4 is safe. It’s been through 4 or 5 days of beta testing and appears solid. We will probably release it as the official version tomorrow.

1 Like

@MlePh,

Sorry about that. We tried to get the word out (posting here and on facebook) but it’s tough to reach everyone. Perhaps we can work on adding an automatic warning when using MP with specific versions of the flight code.

Copter-4.0.2 will likely be out tomorrow because it’s been through enough beta testing that it appears to be ready.

1 Like

Updated to 4.0.2 and did an autotune and no change, still not recording the new PID’s.
The copter flyes fine it just won’t record the new PID’s after.
Please help!

Are you sure you’re following the whole procedure !?

After AutoTune finishes, the copter will revert to “old” PIDs. You’ll have to switch out of AutoTune, then back to AutoTune, which will load the “tuned” PIDs. Then you can manually fly in AutoTune to check the new feel. If you like the new PIDs, land and disarm while still in AT and this will save them. You don’t like the new PIDs, switch out of AutoTune - to Loiter, AltHold or whatever - land and disarm, and the “old” PIDs will be kept.

1 Like

Today i tested the AutoTune again with Arducopter 4.0.2.

The Tuning was working. No Crash this time. BUT there seems to be still an issue when saving the parameters. After Landing in AutoTune and rebooting the flightcontroller, my Stabilize Pitch Rate was set to 0.95. Fortunately the parameter-PreArm was recognizing it. I received an ACRO_BAL_ROLL/PITCH error message. So i looked at the values and set it to 8 manually.

And altough i think i have set “Lock and Roll Values” i got different values for each axis.

Log, Parameters and DVR-Footage

@MlePh,

I can’t answer all your question but re the “Lock Pitch and Roll Values”, this is a check box in the Mission Planner’s Extended Tuning page but does not affect AutoTune. AutoTune will run the tune for roll and pitch axes separately and is almost guaranteed to come up with different values for each axis.

@rmackay9

That the pitch and roll values are tuned seperately makes sense. Sounds reasonable.

But still there seems to be a problem with storing the values. I did another Autotune today. After the successfull Autotune i tested the new values, switched between old and new values, landed in Autotune and the flightcontroller saved new rates. I looked at the rates in the tuning tab in Mission Planner where they looked ok. But after another take off my Yaw was moving extremely slow, Roll was alright and Pitch also felt much less responsive than before. So i looked at the parameters again and found out that ATC_ACCEL_Y_MAX was set to 1000 which caused this slow movement.

After changing the ATC_ACCEL_Y_MAX value to 20000 i am happy with my tuning.

But i am sure that Autotune did not get to such a low value. I tested all axis after the tuning and they all felt very well balanced. So i think there is still something wrong when storing the tuning values.

You can see in a log what values autotune was trying and what it ended up with.

@xfacta

As far as i can tell the changing of the parameter happenend after i had landed. But still, the value of 1000 was for sure not the value i was flying with before. I was testing the Yaw axis after the autotune (before landing) and it was working normal. A Value of 1000 barely rotates the copter.

Same with the ATC_ANG_PIT_P value that was set from 8 to 0.959 after my first 4.0.2 autotune test.

Take a look at my log files: https://cloud.maschinendaten.at/index.php/s/Pgq5wibJWqgiC2r