Thread: PID Control
View Single Post
  #7   Spotlight this post!  
Unread 21-03-2005, 23:31
Tom Saxton's Avatar
Tom Saxton Tom Saxton is offline
Registered User
no team (Issaquah Robotics Society)
Team Role: Mentor
 
Join Date: Dec 2003
Rookie Year: 2003
Location: Sammamish, WA
Posts: 98
Tom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud ofTom Saxton has much to be proud of
Re: PID Control

We started with the PID code from FIRST, but had to fix many significant problems.

1. There is only one set of gains for all the motors. This is a problem if you're using the algorithm to control motors which are different (drive and arm) or have different loads (more friction or just motor differences between left and right sides). We generalized the code to include the gain constants in the per-motor structure.

2. The way they do the integral term is ludicrous. It computes a running sum of the error over all time, then divides that by pid_time (the count of loops). The sum never gets reset, so it grows without bound even when you are changing the target value. Even worse, when you change the target value (set_pos or set_vel), it resets pid_time to 1. This is horrible for two reasons. First, it doesn't reset the sum, so the integral term that was mollified by dividing by pid_time (sum = 2000, time = 1000, integral term is 2) is now blown sky high (2000/1 = 2000). Second, there's only one pid_time global, so changing the target value for ANY motor causes the integral term for ALL of the motors to go ballistic.

3. The PWM values are set up like they are for a different motor controller. PWM_ZERO is 132, but the Victor's zero point is 127. There's even code in there to take into account the motor controller's deadband, so that small signals actually do something, but since the zero point is wrong, it completely misses the mark. The MAX_PWM and MIN_PWM values were also centered on 132, so you also had to find that hidden error.

4. There was a hard-coded limit of two motors (or more correctly, two PID controllers) with no hint at what was required to control more motors.

5. The per-motor structure wastes a lot of space with duplicate values for both position and velocity modes, although only one set will be in play at any time. On a controller with only 1800 bytes of RAM, wasting 32 bytes per PID controller is not good coding.

6. While there were great comments about how to tune the PID (once you fixed the bugs), there was not much in the way of how to use the code. It wasn't too difficult to figure things out if you already had a good understanding of both PID and C, but I would think the idea behind this code was to make PID more accessible to teams without strong software experience.

We did get it cleaned up and used it to control a total of six motors in four groups: left and right drive (2 CIMs each), arm elbow (van door) and arm wrist (globe). (Each pair of CIMs was controlled by one PID "motor," we just copied the same value to both PWMs.)

I hope to clean up our version of the PID code and publish it on our web site. PM me if you want to see it before I have a chance to clean out our debugging junk.
__________________
Tom Saxton
http://www.idleloop.com/