I have heard a lot of different versions of what a PID loop is. I am going to post my version as taught to me by my PID coach when learning to tune and autopilot on a UAV. Also i am going to throw some tuning tips in as well.


P term -

The P term is like a big strong man on the steering wheel. He sees he is off course and muscles the steering wheel over in the direction he thinks he should be going. Nothing really accurate about it, just proportional to the obvious error that he perceives.

I term -

The I term is like your average backseat driver. He looks closer at the error they are off course and is tugging at the steering wheel gently... at first... to get back on course. But the longer he sees the error the more excited he gets and the harder he tugs.

D term -

The d Term is a very nervous individual. He doesn't mind so much that he is in error as he minds speeding past where he wants to be and having to go back. So he is constantly looking at how fast their collective goal is approaching and is fighting both the P-strongman and the I-backseat driver to prevent them from overshooting their target.



Now for a little tuning tips...

Start Small -

Use very small Control values. Forget about the D term for now. it will only cause you grief until you get some solid results from the P term .

Set your I term low as well. Especially if you expect large errors to occur. Remember that the I term is adding up all the error and when he is in error for any length of time he will exert a very strong powerful force on whatever you are controlling. I think an error limit routine in your code with help deal with this. For instance if you are flying a UAV, and you want to change altitude. You would, of course add power. Well how fast does your overloaded uav climb? If you went from 500 to 600 feet it might take a few minutes. Meanwhile your PID loop has made 6000 readings in the last second! Now lets send the UAV to 3000 feet! See what I mean?


Change one thing at a time -

Don't get carried away changing ten different values in your PIDs. You will go crazy. Enough said.



Set your trims -

On a UAV you want to trim the aircraft to fly staight and level before you start telling the autopilot how to fly it. Remember that a PID controlled anything works on error. Environmental factors will give you enough to overcome without throwing in some error on your own.

Nested PIDs -

Sometimes you want to use nested PID loops. Example is my heading control routine. If i pass the PID turn values directly to my rudder I could get some really high turn rates. So I nest that PID inside my turn Rate PID. So my heading PID gives me a suggested turn rate that I check against my maximum allowed turn rate. If the PID suggests a turn rate of 15 I set it back to 7 (i like a turn rate of 7 degrees per second and that is my set Maximum) then i pass that to my Turn rate PID. My turn Rate PID checks the YAW rate gyro and then calculates how much rudder is added or reduced to satisfy the suggested turn rate from the Heading PID.


Record Everything -

I don't mean video Camera either. Record all of your data. In a UAV I record the ALT, desired altitude ,AirSpeed, Desired airspeed, Heading, Desired Heading, and all the servo positions.

Why you may ask? Duh! For tuning!!

You can easily write software or use excel to 'see' what the aircraft or whatever your controlling is doing. this makes it sooooooo much easier to tune!


Now, if you are feeling froggy -

Design your device with real time tuning i.e: Write it so you can chage you PIDs on the fly...literally! Flying a UAV is risky at best. If you have to launch and recover your UAV a hundred times to tune it you risk killing it a hundred times. It is best to have two people to tune a UAV. one to fly and one to upload new PID terms and then release the bird to the autopilot to see what happens. When you are satisfied (or not) give the pilot control again and make changes.


Accelerometers and Kalman filters -

you would be really surprised how well a UAV can fly if the aircraft is inherantly stable. you definately need to kill the noise on your gyros because these will be needed for turn rates and envioronmentally induced roll (Wind gusts and air pockets). Do you really need to know the attitude of the aircraft if the aircraft at zero with fly straight and level? Remember, if you want to use all the positional data on your aircraft then be prepared to isolate the autopilot gyros and Accelerometers from the vibration from your Fuji boxer 4 stroke engine 9 inches away!

When you tune the UAV correctly the aircraft with fly without all that extreme math and do well with just you PIDs cranking away.


Good luck! Try not to make new craters with your UAVs

Views: 2824

Reply to This

Replies to This Discussion

Great post! Many thanks for the useful advice, which sounds spot on.
I had a question regarding the I term in PID loops. If I grows over time based on accumulated errors, what mechanism causes it to get smaller? Is it overshoot that reduces it?

For example, if I've taken a long time overcoming a force - like gravity in your example- and my I has grown to its limit, I should be able to reduce my error to 0. But once I've reached 0, isn't my I term still large? Is it D that counteracts it? Or is there another mechanism that does it? Or do I need an opposite error to reduce it until I steadily reach 0?

Thanks, Jason
I have a similar question to Jason.

I am wondering when, or how, to reset my Integral term.

Currently, I am setting a threshold to reset the integral term, i.e. when the error is suitably reduced, the I term is set to 0.
I struggled with this for a while too.



You are correct. The effect of the I-Term is not to overcome gravity. It is to make sure you get all the way to your target altitude. The amount of throttle to give an engine becomes rediculously small if you leave it all up to the P-Term when we talk about 2 or 3 meters. The I Term builds up enough error to cause that servo to move to the required posistion to give us that small amount of throttle.

Now we may pass our desired altitude by a meter or more. The I-term starts to shrink and the aircraft starts to lose altitude but this time the I-Term-Max is not met and the process starts to get closer and closer to stability.

The D terms just dampens this all out causing stability to be reached even sooner.
You should not do this. The I-Term should not be set to zero because it may be the I-term keeping on your target. you may get autopilot induced oscillations by the I term resetting to zero and affecting the entire PID greatly.
So what you're saying is that the I term sorts itself out by to overshooting slightly. To deal with too much overshoot, I need to introduce the D term to counteract the I term and slow down as I approach an error of zero.

The way I was thinking of it was if I had an outside force such as wind preventing P from ever reaching zero, the I term would eventually rise to oppose that force. Just because you've reach zero error doesn't mean the opposing force has gone away. Thus zeroing I will remove the compensation sending the plane in the opposite direction of the force.

In Jordi's code, he limits the error correction after adding the I term. Doesn't this make I pretty much useless for large errors? Wouldn't it be better to limit P, I and D separately before summing them?

For example:
error = 100°
error * head_P = 65°
I * head_I = 10°
error = I + P = 75°
error = constrain( error, -35°, 35°);
error = 35°; (where did I term go?)

I see how I will show up for values under the 35° limit, I'm just wondering if this an issue or not?

Jason
Great post!!!
Just remember, the I-Term is there to give that little push to get rid of the last little errors. The P-Term is the muscle to make the big adjustments. The I term isn't really there for large errors. The P-term is. The P-term is like 40 grit sand paper. The I-term is like a buffing wheel for polishing for lack of a better word.

As far as constraints...

The I-Term can seriously affect you PID loops if allowed to be in error too long. The I-Term is a constant multiplied by the compounding error so the longer you are in error the more the I-term will affect your PID. I highly recommend limiting the compounded error so as to not let it get huge and then overshoot by alot. But not too small that it can't do its job in harsh circumstances.

It is certainly not bad to constrain the complete output as the example shows. Look at turn rate. maybe you don't want to turn at 70° per second.

I suppose you could limit all of the individual outputs. We never did. We just limited our Accumulated error to managable values.
Thanks for the info. It really helps.
Jason
Here is a PID simulator I through together so you can "See" the effects of the PID loop on an altitude.

Download it Here
Michael, Thanks for this great article/post. The simulator really puts into prospective all of the salient points of your explanations.

Just a little experience advice. You don't need I or D gains on almost anything for basic astable aircraft unless you are looking for rockstar performance that is imperceptable to the eye. IE P gain on roll is all that is required. I use zero derivative gains on any of my controllers and have stellar response. The few integral gains I use are on airspeed and altitude holds and that just because its easier to have the controller find the aircrafts trim point for a given airspeed then it is for me to manually tweek the pushrod in and out flight after flight until its perfect. My altitude/airspeed hold is very unconventional but works on the same classical control techniques. (energy height feedback). So in summary if you cant get basic control with simply P gains to start with you are never going to be able to tweak it out. You will only make it works. The I and D are used to increase performance but if the performance isn't first there based on the P then you will be chaseing a moving target.

*Note attached Google earth file's altitude its on rails with no steady state error
Attachments:

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service