Application of PID in code/real world

[mark219]

I'm a little bit of a newbie at Java coding with FRC. I want to use PID as a part of my drive train and other precision parts of the robot, however I'm not sure of its application. I know that PID stands for proportion, integral, derivative, and have a basic understanding of integrals and derivatives (just started learning about integrals in calculus). Essentially, all I know about PID is that it is a way to minimize error, but the question I am asking is how does it work? Can you show an example of code? Is its only use for autonomous mode?

[Ether]

Originally Posted by mark219

the question I am asking is how does it work?

https://www.youtube.com/watch?v=UOuR...n0gJUQ&index=2

[Tparbotmail]

How do you find this video on YouTube?

[Justin Buist]

Originally Posted by mark219

Essentially, all I know about PID is that it is a way to minimize error, but the question I am asking is how does it work? Can you show an example of code? Is its only use for autonomous mode?

There are uses for PID in teleop; it's just not an auton thing. In this game I could see mashing a button to put the robot into a crawler mode where you could put a speed limit on a tank tread when crawling over some of the obstacles. Going over the rumble wall you may want to reduce power to one side when it's entirely in the air so that when it does make contact it doesn't spin the robot to one side, but you would also want to it to come back up to speed quickly once it's under load.

The code is incredibly simple and so is the math. Tuning your PID values is not. Here's the crux of simple PID calculation code:

double error = target-current;
double errorChange = error-lastError;
double correction = Kp*error + Ki*errorSum + Kd*errorChange;
lastError = error;
return correction;

Figuring out what the values for Kp, Ki, and Kd are is the tricky bit. Let's try an example. Say you're driving a car and you only open your eyes every second or so and make a rash decision about how to jerk the wheel about. This is your Kp value. Assume your steering wheel works at a 1:1 ratio to your tires here. If you open your eyes and find you're driving 5 degrees left of the line you want you'd jerk the wheel 10 degrees right to get you back on track. When you open your eyes again you might be just slightly right of the line, say 3 degrees, so you jerk 6 left, and you kinda keep doing this until you oscillate around the line. That would be how a robot would respond if you give it a Kp value of 2.0. It would double the response to the immediate error. I'm not saying Kp of 2.0 is ever a good idea it's just an example. But first you have to find a Kp value that gives you that subtle and sane oscillation around your target. Once that's done you work on Ki which, as an integral, represents your general inability to keep on track. Once dialed in that dampens the oscillation in that it reduces the effect Kp has on the correction. If you keep correcting solely on Kp but your'e 10% off each time you dampen it down. Finally you define Kd to fix what you can't compensate for with Kp and Ki. Kd is generally going to be 0 unless you want to get really freaking precise about something.

Hope that helps.

[mark219]

Originally Posted by Justin Buist

There are uses for PID in teleop; it's just not an auton thing. In this game I could see mashing a button to put the robot into a crawler mode where you could put a speed limit on a tank tread when crawling over some of the obstacles. Going over the rumble wall you may want to reduce power to one side when it's entirely in the air so that when it does make contact it doesn't spin the robot to one side, but you would also want to it to come back up to speed quickly once it's under load.

The code is incredibly simple and so is the math. Tuning your PID values is not. Here's the crux of simple PID calculation code:

double error = target-current;
double errorChange = error-lastError;
double correction = Kp*error + Ki*errorSum + Kd*errorChange;
lastError = error;
return correction;

Figuring out what the values for Kp, Ki, and Kd are is the tricky bit. Let's try an example. Say you're driving a car and you only open your eyes every second or so and make a rash decision about how to jerk the wheel about. This is your Kp value. Assume your steering wheel works at a 1:1 ratio to your tires here. If you open your eyes and find you're driving 5 degrees left of the line you want you'd jerk the wheel 10 degrees right to get you back on track. When you open your eyes again you might be just slightly right of the line, say 3 degrees, so you jerk 6 left, and you kinda keep doing this until you oscillate around the line. That would be how a robot would respond if you give it a Kp value of 2.0. It would double the response to the immediate error. I'm not saying Kp of 2.0 is ever a good idea it's just an example. But first you have to find a Kp value that gives you that subtle and sane oscillation around your target. Once that's done you work on Ki which, as an integral, represents your general inability to keep on track. Once dialed in that dampens the oscillation in that it reduces the effect Kp has on the correction. If you keep correcting solely on Kp but your'e 10% off each time you dampen it down. Finally you define Kd to fix what you can't compensate for with Kp and Ki. Kd is generally going to be 0 unless you want to get really freaking precise about something.

Hope that helps.

Thank you,
This actually does help me quite a bit in terms of visualizing an implementation of PID. I am more of a model based learner, so reading text off of wikipedia trying to learn it doesn't work for me. The video that Ether posted above also helped in learning what PID does/is. Towards the end it has a slide about tuning Kp, Ki, and Kd, however it states that the way that these are found are not really 100% precise but will generally work for most implementations of PID. (For reference: )
Just curious, is this how you guys also tune your Kp/Ki/Kd values, or do you just estimate based off of guess and check. Also, wouldn't guess and check error also have to be tweaked differently for different surfaces (i.e. testing a robot drive PID system on school hallway floor v.s. testing robot drive PID system on competition carpeting)?

[plnyyanks]

I go over some good papers/math explanation of how PID works in this post, take a look and read some of the linked resources. My details are LabVIEW specific, but there's some good java examples on ScreenSteps, and also as a subsystem.

Originally Posted by plnyyanks

There are many, many threads on CD and the general internet about PID control. Try searching around.

Here's some good resources from NI:

And here are some more resources:

And this page looks like it has some cool simulation resources, and some overviews about the theory behind the controller.

As for the best way to tune, Ziegler-Nichols is a decent start, but there will inevitably be lots of guesswork involved unless you take the time to really characterize your system (not usually practice in FRC timeframes). Below is a previous post I made about how I always tuned PID controllers.

Originally Posted by plnyyanks

Really, the best way to tune PID constants in Guess and Check - after a little practice, you get pretty good at guessing the correct constants. This is pretty much the method we use on 1124, and we haven't really found the need to migrate away from it.

In our robots, we've found that an I parameter is rarely needed - we usually get what we want with only PD (or sometimes just P) controllers. It's really dependant on your application and the type of feedback you want. There's no really easy way to say it: it's a long, time consuming process.

Some more links to read into

To do this in LabVIEW, you have your PID VI, and one of its inputs is a cluster of three doubles, which are the P,I, and D constants that you tune to your liking. The best way to tune quickly is to probably run your code through a computer (using the Run button on Robot Main.vi - not building/running as startup) and modify that parameter cluster until you get satisfactory results. Just remember to reinitialize your PID VI (it's another control - wire that input to a button on your front panel or something like that) to "apply" your changes. NI also has a good whitepaper about working with PID in LV. It's a good read - check it out.

[mark219]

Originally Posted by plnyyanks

I go over some good papers/math explanation of how PID works in this post, take a look and read some of the linked resources. My details are LabVIEW specific, but there's some good java examples on ScreenSteps





As for the best way to tune, Ziegler-Nichols is a decent start, but there will inevitably be lots of guesswork involved unless you take the time to really characterize your system (not usually practice in FRC timeframes). Below is a previous post I made about how I always tuned PID controllers.

Thanks, I will definitely read more into it and will respond/private message you if I have any further questions!

[Ether]

Originally Posted by Justin Buist

Here's the crux of simple PID calculation code:

double error = target-current;
double errorChange = error-lastError;
double correction = Kp*error + Ki*errorSum + Kd*errorChange;
lastError = error;
return correction;

There's a line of code missing: errorSum += error