View Single Post
  #4   Spotlight this post!  
Unread 01-03-2010, 16:38
Jared Russell's Avatar
Jared Russell Jared Russell is offline
Taking a year (mostly) off
FRC #0254 (The Cheesy Poofs), FRC #0341 (Miss Daisy)
Team Role: Engineer
 
Join Date: Nov 2002
Rookie Year: 2001
Location: San Francisco, CA
Posts: 3,078
Jared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond repute
Re: Update Rate of PID Loops

There are many competing factors at play when selecting a sampling rate/update rate for a PID controller. On the one hand, higher sampling rates minimize delays in the control loop and bring your system's discrete-time controller "closest" to its ideal continuous-time form. On the other hand, higher sampling rates can also lead to increased noise susceptibility, especially when you are using the "derivative" term, and increasing the sample rate eventually reaches the point of diminishing returns anyhow.

Implementing control systems that trade off between these factors is somewhat of a black art - my college adviser passed down the wisdom that, in general, the sampling period that you should shoot for will be one or two orders of magnitude (10-100x) smaller than the system's settling time (time from saturation to reaching its final destination). The popular article "PID without a Ph.D" agrees.

For example, consider a robot whose drive is commanded by a position PID loop. The setpoint is 30 feet away. For arguments' sake, lets say that Kp = .1 (Percent of full throttle per foot of position error**). For most of its trip from x=0 to x=30, the PID controller will be telling the robot to floor it (since Kp*error >= 1.0 until error is less than 10 feet). The amount of time it takes between the last output of 1.0 and the time that the error enters a final X% bound around the setpoint (for example, the "1% settling time" in this case would be the time elapsed between the time at which error=10ft and error=1% of 30 ft, or 3.6 inches) is the settling time. Lets say it takes our robot 2 seconds to slow down, possibly oscillate one or more times, and come to a stop within 3.6 inches of the target - using the 10-100x rule of thumb, our sample period should be between 200 milliseconds and 20 milliseconds, or 5 to 50 Hz.

The idea is that at a, say, 3 Hz sampling rate we would have a really bad settling time (if the system is even stable at all). As we increase the sampling rate from this point, we expect the settling time/stability to improve until, at some point before 50Hz, we converge at around 2 seconds 1% settling time. Above that sampling rate, we are not likely to improve significantly (and in fact we might hurt our robustness to sensor noise if we have a D term).

The above is just a rule of thumb; given a good mathematical model of any process there are some analytical ways to figure out what the ideal sampling rate should be, but unless you are building a space shuttle, the math is sufficiently complicated that I would say just play with your system and see what works.

I will point out two other related factors to sampling rate frequency:

1. Sampling rate jitter - this can be a huge problem, especially once you start talking about 5% or more. Jitter is the variation between successive sample times. It can be insidious when dealing with integral and derivative terms, for fairly obvious reasons (differentiation in a discrete PID loop is usually approximately by finite differences, e.g. x(t) - x(t-sample_period) ). You can compensate for it somewhat if you measure the sampling period between updates, but if you can do this, why not just use a timer in the first place?

2. Remember that in our systems, the cRIO does not command the motors directly. Rather, it commands speed controllers, which have their own set of delays. Victors update at something like 100Hz (or is it 120?) - this means that a potential delay of on the order of 10ms gets added to every single output if you aren't lucky. Jaguars have about half of this delay. So doing updates faster than 100Hz/200Hz is going to be fruitless.

** Note: I find that if I force myself to put units onto my PID controller gains, it makes life much, much more intuitive when it comes time to put in "initial guesses" for my parameter gains.

Quote:
Originally Posted by Tom Line View Post
Second note: This would be an Excellent EXCELLENT discussion to have at nationals and put a whitepaper here on chiefdelphi. Update rates of sensors, loops, and processing rate of code all tied together is something that simply doesn't get addressed very often.
Tom,

This sounds like a great idea (my master's is in control systems ) In classes or in text books, it is easy to find the PID equations and to understand the concepts. However, implementing control systems (and signal processing, and image processing) in effective code is a skill that is sadly underrepresented in the majority of literature on controls.

Last edited by Jared Russell : 01-03-2010 at 16:40.