paper: PID Control Theory for FRC Programming

[Matt Krass]

Thread created automatically to discuss a document in CD-Media.

PID Control Theory for FRC Programming by

[Mike]

Great job, helped me out a bunch.

[Tom Bottiglieri]

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.

[Matt Krass]

Originally Posted by Tom Bottiglieri

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!

[Greg Marra]

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.

[Mike]

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.

[Guy Davidson]

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

[LieAfterLie]

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.

[LieAfterLie]

Maybe even add some visual aids, graphs... ?

[kwilliam]

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.

[tseres]

...
[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....

[Qbranch]

Originally Posted by tseres

...
[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

[tseres]

thanks so much....although i wont be going to IRI...lol....but thanks

[tseres]

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.

[JBotAlan]

Originally Posted by tseres

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 )

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