Date: Tue, 7 Mar 2006 04:26:13 -0600 (CST) Subject: what pid control is X-UID: 142 Content-Type: IMAGE/JPEG; name="img2760.jpg" I just read through enough of the control systems books to understand how a PID controller works conceptually. Here's the way a math person would look at what I've read so far. 1. Model the system you wish to control with an ODE. a. The "plant" to be controlled is distinct from the "controller". b. The ODEs are preferably linear with constant coefficients. 2. Take the Laplace transform of this ODE. 3. Substitute in the feedback terms in the transformed ODE. a. Proportional feedback is K * error. b. Integral feedback is (1/T)*integral(t0, t, error). c. Derivative feedback is K * D * derivative(error). 4. Move all terms with the output variable to be controlled on one side. 5. The polynomial in s (remember, this is the Laplace transformed version) that multiplies the output variable is set to zero to get the characteristic equation. 6. The roots determine the system response. There are intuitive explanations for why the different kinds of feedback are useful. What happens in the algebra is that by having three different gains for proportional, integral, and derivative feedback, there are more coefficients to tweak. This allows greater control in moving the roots of the characteric equation around in the complex plane. The roots determine the system response. (ASIDE: Why is this so? Because linearity allows superposition and convolution which then allows the complex exponential functions to form a basis for the solution space. The roots determine the particular exponential functions that are in the response.) This is pretty amazing in that really no hard math is required. All you need is literally the same level of algebra I had in middle school. There are some advanced concepts. But the math is simple. I think the state space methods later in the book are converting the higher order ODE into a first order system of ODEs. This leads to matrix methods. And there are all kinds of design techniques for coming up with the magic coefficients for the rest of the book. I can see now how a computer using genetic algorithms or other optimization strategies could design a control system for you. The problem is coming up with an accurate model (as it always is). In the picture is what I've sketched out tonight. There's really no control system there. It's just the geometric relationships between the wheels given an angle of turn. So the robot has 1. Rear drive wheel thrust (duty cycle) 2. Front wheel angle of turn These two variables uniquely determine all four wheel positions and how fast they should rotate (assuming uniform ground and traction - this assumption may be completely bogus, I'm too tired right now to think straight). I'm going to use the gyro to determine wheel position. This makes an assumption that all wheels have traction so the robot is tracking with the steering direction. The potentiometer on the steering assembly is only used as a limit stop as I don't trust it. So I'm thinking that the output to be controlled is the rate gyro output. The front wheels will turn and the rear wheels differentially driven until the rate of turn error goes to zero. I have to work out the details later today. One more thing. The Berkeley Blue Team (autonomous motorcycle) used a two CPU dual core Opteron board just for vision. That's four cores of fast 64 bit processor. That gave them a nominal 4 Hz! (incredibly slow) Their robot had additional computers too. The Stanford team (autonomous Touareg SUV) used three Pentium M blades (they had 6 or 7 available but didn't use all of them - I think they used 3) for the entire vehicle. That's a fraction of the computing power. The difference is that Stanford also had 5 SICK LIDAR units (pulsed time of flight scanning laser rangefinder). Berkeley's machine relied exclusively on vision. Stanford was able to run their entire vehicle at a 10Hz rate. That's 2.5x the sensory speed with a small fraction of the computing power. This illustrates how compute intensive vision is. Personally, I think vision is much cooler. In the future, optical vision will dominate. But with today's technology, it is pushing the outer limits of what is possible. My robot relies on vision. I'm not sure how it will work out. To get around the broken Geode PCI bus mastering, I'm thinking of adding a Sony network camera I saw at Fry's for $100. This camera would be for high speed. The Berkeley team used two cameras in a stereo configuration for obstacle avoidance. These ran at 4 Hz as mentioned above. If moving at 30 mph, then the robot travels 11 feet between each frame. The slow framerate is ok so long as the cameras can see out far enough. However, they also have one high speed 40 Hz monocular color camera for road detection. Basically, I'm saying that they went through the same problem and I can learn from them. With an IMU, inaccurate GPS, and no LIDAR, the only way of staying on the road is good vision at high speed.