My attempt at autotuning resulted in a crash this morning.
I fiew the quadcopter previously with a 2S battery. It was quite stable but underpowered.
After upgrading to a 3S battery I set the PIDs to what I believe is the default values:
Stabilize P: 4.5
Rate P: 0.15
Rate I: 0.1
Rate D: 0.004
Taking off and switching to Alt Hold went smooth. I then switched to Autotune and nothing happened. I believe this is because I had the throttle still a tad above hover. Closing the throttle down slightly to get it in the hover range started autotuning and on the first or second autotune roll it started oscillating ending in a crash. I was way too slow to recover it.
The way I read the log file, theses values were used for autotune:
Stab P: 4
Rate P: 0.2
Rate D: 0.005
Dataflash log attached. No CoG issues. Props and motors tuned recently, so low vibrations.
My primary question is:
What caused this crash?
My theory is that the motors may now even be slightly overpowered and I guess that an average PID settings may caused it to respond too violently. But I would appreciate if anyone else can confirm that from the log or share their own experiences.
Is there a way to tell autotune to cool things down a bit and use a range of lower PID values?
the moderators should divert all his comment to his own page...
Hey, Darius is an awesome guy, he told me so himself ;)
Sorry for the slow response, it has been a busy fortnight. This is a very nice and insightful analysis. Fortunately, this is something we understand very well.
There are a couple of points that I don't believe are accurate:
I still suspect you have a mechanical problem that is triggered by the large motor command you explain in your blog. However, I would like to elaborate on some of the issues you have described here as they are all well known and accounted for in the control code.
The problem you describe where the copter is stable when exposed to small errors and can become unstable at large errors is a normal consequence of using PID's with a limited output range. One of my blog posts go into this but the conclusion is that the larger the error the higher the acceleration the copter must be able to achieve to be able to stop at the desired angle. This is why we don't use a basic PID control loop we use what we call the "square root controller". This is basicly an acceleration limited PID controller. This acceleration limit is set to be half the ATT_Accel_XXX parameters with a maximum of that required to right the copter from 180 degrees in 1 second. Autotune updates these parameters based on measurements made during the tuning process.
The default Stab P value of 4.5 is very low and only very slow (low max acceleration) copters will have trouble with this (read avengers aircraft carrier).
So the process Autotune takes is:
Set Rate D to the maximum value that results in no more that 10% velocity bounce (set by Autotune_Aggr).
Set Rate P to the value that will result in 5% overshoot (set by Autotune_Aggr).
Set Rate I = Rate P to achieve approximately a 1 second time constant on persistent external forces (I really work out exactly what that time constant is).
Set Stab P to the value that will result in a 5% angle overshoot without saturating the motor outputs (not achieving the maximum acceleration)
Set the maximum acceleration ATT_Accel_XXX value based on the maximum measured acceleration achieved during autotune (approximately 50% to 75% of the actual maximum).
The requirements of Autotune is that the Rate parameters be reasonably stable and that Stab_P value be suitably small to limit the maximum acceleration experienced by the copter after each twitch. Most copters can use any Stab_P value without exceeding the acceleration limits because there is a hard coded, 1 second recovery, acceleration limit.
Again, very nice analysis. I hope this helps put your work into context with the arducopter control loops.
Thanks for all your work and interest!!
If you had taken the time to look through the chat you would see that I had already responded to this blog post.
If you don't see a direct response from a dev it is often because one of the other members of the community have already addressed the issue and we have nothing more to add. It could also be because we are doing this support as a hobby and have jobs and families that need attention. We may simply not had time to get to it yet.
Arducopter has so few crashes caused by problems in the code that the vast majority of our support is spent helping users discover what they did wrong or diagnosing hardware problems. When we do find a problem that could be linked to a possible code bug, the dev's go nuts looking for the bug.
If you are interested in how Jacks analysis fits into the arducopter control system take the time to read my post on the next page.
Thanks for the detailed explanation again. That little bit of extra information always helps to make things a bit clearer. Some of us do realise that this hobby would be a lot more frustrating if it wasn't for the devs that constantly improve the product and provide free user support. Thanks for the commitment!
I will wait for some parts first and then do some bench tests again. I think I understand what you are saying, but I will probably only full understand once I see it in action during testing. I will give feedback in a couple of weeks once everything is up and running again.
By the way, are there any documentation that goes into the implementation details of the PID / autotune processes?
I have been planning a first setup guide but I haven't got to it yet, maybe after the next release. So just what is on the Wiki.
Down the page in this blog post is where I describe the square root controller if you are interested.
Thanks for the link - just what I was looking for!
Just read through the discussion and although there where some valid points there may be one thing that’s been overlooked. Your PID’s are just to low. Crank’em up!(All of them. And “I” should be at least as high as “P”) And then try autotune again. Although you’ve probably got the problem fixed by now this may help someone else.