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.
Secondary question:
Is there a way to tell autotune to cool things down a bit and use a range of lower PID values?
Replies
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.
I think I know why my quad flew well in AltHold mode, but started oscillating in AutoTune.
The key lies in this graph:
This graph shows the actual roll angle (green) and the desired roll angle (red).
The left shows what happened in AltHold mode when I flicked the roll control stick to its limits and let it return to centre again.
The right shows what happened when autotune directed it to roll and then let it return to horizontal again.
The actual roll (gren) is fairly similar in both cases. Both resulted in a fairly big (20 degree?) roll that happened rappidly.
But look at the desired angle (red).
In AltHold mode, the desired roll change becuase I directed the quad to roll. The actual roll follows closely. Because the actual roll reacts to the desired roll, both actual and desired
are always close to each other (small P error) and the slope of both are fairly close to each other (small D error).
In Autotune, the desired roll stays at 0 while the actual roll changes a lot. Because of this, actual an desired gets far apart (large P error) and there are big differences between the 2
slopes (large D error).
To visualize this, I graphed the P and D errors for both cases in this graph:
From this it can be seen that the P (red) and D (green) errors are a fair bit bigger for Autotuning (right side). But what makes matters worse is that in AltHold P and D often work
against each other. If one is positive, the other is negative. So when the sum of P an D terms are calculated they often cancel each other out to some extend. In Autotune, both P and D
are often reinforcing each other. This graph shows the sum of the P and D terms for both cases:
This graph shows the effect of the combined P and D terms. This reflects the size of the correction term that will be send to the motors. The maximum error value in Autotune is about 6
times the AltHold value. That is why the same PID values that flies perfect in AltHold has now grown by 6 times and becomes a violent beast that overshoots and oscillates with ever
increasing amplitude.
So what's the practical implications of this?
One implication is that my manual tuned values are very good at keeping the quad exactly where it needs to be - AS LONG AS IT STAYS CLOSE TO WHERE IT NEEDS TO BE. The P and D values are
fairly high (for this frame and power setup) and I have a setup that can rapidly adjust to any errors. So under normal circumstances, the actual angle will always adapts quickly to the
desired angle. So the error term would always be fairly small. Multiplying the fairly large P and D numbers with a small error gives an average correction value that always keeps the quad
right where it should be. The actual angle follows the desired angle close enough that I can never get a big error value just by using the cintrols. I would have many days of happy
flying. But should I ever encounter a situation that suddenly puts my quad at an angle far from where it is supposed to be (for example a rapid big gust of wind or mid air impact with a
tree branch or temporary glitch on one motor that caused it to rotate, etc) I would get a big error value. This would be multiplied with my big P, D values resulting in a very high
correction value causing me to loose control to oscillations with no hope of recovering again.
Another implication is that a pefectly good flyable setup in AltHold does NOT guarantee a stable setup for Autotuning. This will be more of a problem for any frame that can rapidly change
it's angle. Things thay may influence this will be: Light weight, small diameter (less rotational inertia), powerfull motors, etc. A good setup for autotuning is not one that flies well,
but more importantly one that can recover from big angular errors. In other words it is more important to see how it behaves if it finds itself 20 degrees in error from where it is
supposed to be than it is to see what it behaves like when it is close to where it should be. It should at least dampen any oscillations and stabilize over time and not let the
oscillations grow bigger every time.
So that's my theory on what went wrong. I would love to show test data to confirm this, but it will take a couple of weeks for spare parts to arrive (shipping parts from overseas to Aus
is either expensive or takes long). I would like to get my previous setup working again on the test stand. This time around I will tune it to behave well when I introduce a big 20 degree
error. (Still need to figure out how to do this safely). Maybe pull one of the legs down with one of these: ;-)
Hi Jack,
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!!
Leonard,
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?
Thanks Jack,
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.
http://diydrones.com/profiles/blogs/arducopter-2-9-pid-loops-for-st...
Thanks for the link - just what I was looking for!
Nice work.
Your conclusion begs the following question:
How does Auto Tune behave when you start with the default PIDs?
It's all in the discussion above, but for my drone using the default PIDs it started oscillating and crashed.
@Jack,
my congratulations on your excellent study.
You have been nominated honorary member of the
Peer to Drone Crash Investigators.
Do you suggest bug in Pixhawk software, Pixhawk hardware or
Pixhawk manual ?
I am surprised every time I don't hear any response from
developer of Pixhawk software, hardware, EKF1, EKF2, author of manual on PID following one another drone crash reported in public.
Darius,
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.
-
1
-
2
-
3
-
4
-
5
of 5 Next