Thread created automatically to discuss a document in CD-Media.
Great job, helped me out a bunch.
Just a note:
The equations given in text state the following:
POUT = KP * KERR
But your code shows the proper integer based math method of performing this expression.
POUT = KERR * KP
It’s quite clear why the variables need to assume this order, but I did not find it documented that there IS a difference between the “text book” equation and your example… (it is more accurate to “round” later in the equation, after your numbers have built up.)
Either way, great paper! I plan to include this in my “required reading” for new programmers on my team. 
I’ll keep that in mind for the next revision of the paper. Meanwhile if anyone has any comments or suggestions, feel free to post them here, or PM/Email them to me. I hope this paper is of use to everyone and I’m also available to answer specific questions either through CD or the contact information in the paper.
Good luck!
Well written and very clear!
You may want to consider adding some comments to the code examples, such as why you limit to ±127 in case any completely new FRC programmers read this.
I used this paper today as a reference when writing 237’s PID control code.
Bumping it up to bring to the attention of other teams.
Thank you very much for this paper. This really helped me undferstand the concept of a PID, and will definetly be used when we write our PID code.
-Guy
Very helpful. You might want to move the P code example showing the #define KP 5 / 10 to between the P and I sections though, as it doesn’t show I control.
I finally learned what this PID stuff is about, thanks.
You might want to also mention that since motor velocity control is a speed you’re comparing encoder ticks per time rather than a target value that has a defined range, and therefore also give us a simple method for determining the range, such as maybe start at this many ticks per time period as the min/max, then scale it down when the motor is full and gives less than that number, then printf that max to initialize it to for future code so that it starts out at the right range. I know this really goes beyond the basic PID concept, but it is relevant to speed control.
Maybe even add some visual aids, graphs… ?
Matt, this is an AWESOME paper! I wish I had read it earlier when I was learning PID control this year. I read this one instead and had the programming team read it, but your paper is an improvement. Wonderful explanations, good example code, and excellant usage scenarios! I will be sure to include a link to your paper in our own programming team’s handbook.
…
[dotdotdot]
i’m a new programmer, and well, i don’t understand how this works…i sort of understand the concept…you get feedback somehow from the robot…ya…that’s about all i understand…
A little off topic, but, if you need some help with the interfaces to sensors and such, i’ll be happy to help. Also, check out this post on on-chip peripherals and this one on encoders..
If you are going to IRI, just come by the field and you’ll see the 1024 pit area. Ask anyone on the team for “Q” and they’ll point you in the right direction. Good luck!
-q
thanks so much…although i wont be going to IRI…lol…but thanks
ahhhhh…after looking at a lot of other things…
so i guess PID is basically having software control the robot rather than just the PWM outputs are the same as the joystick values…so there’s a layer of software that processes all the input and output data.
Exactly. Programming this way makes you paranoid–you start to trust the code, have a sensor go bad on you, the arm takes off and tries to rip the control system off the robot while destroying a gear box (BaneBots…
) and you don’t hit the disable switch fast enough. (true story, times about 50 this season:D )
But don’t let that steer you away from a smarter robot. The pros greatly outweigh the cons. For example, auton becomes easy.
Good luck,
Jbot
ya…i know it’s not easy, but it is worth it. this year we didn’t really have any PID, but the driving was sort of “software controlled”. the only problem is we didn’t have any sensors and our robot can’t go straight. lately i have been developing omni code potentially for next year that uses a gyroscope. we dont need any encoders because the gyroscope algorithms/functions we made will automatically correct for any motor error.
The entire basis of a PID control routine is the ability to sense what’s going on and take action to make it match what is desired. Without sensors, you can’t have any sort of closed-loop feedback control.
…we dont need any encoders because the gyroscope algorithms/functions we made will automatically correct for any motor error.
Gyroscopes are fine for rotational sensing, but without encoders, how is the robot going to know how fast or how far it’s moving?
I guess if all they really want to control is orientation that shouldn’t matter.
But on the topic of the paper : great idea, I think the community needed a simple down-to-earth explanation. I know it was pretty overwhelming sophmore year trying to figure it out on my own without any real programming experience or calculus experience.
I also like how you gave a lot of ideas for applications, that is very useful… alot of people think PID is just useful for moving arms and such but it can be used for a lot of other things !