![]() |
Re: PID control loops - feedback is our friend!!!
All the code for PID feedback loops i have seen posted on CD has used only the current and last measured values for the derivative and integral part. Has anyone tried using 3 or more frames? Is the result better?
|
Re: PID control loops - closed loop feedback
going back more than 2 loops is only useful for the intergral part - if the arm is not moving you keep adding a small part of the error - so the control signal can actually build up over several loops before the motor move enough to eliminate the error
but for the differential part you only want this reading and the last one - the D is like giving the system a swift kick for a loop or two, so it needs to be very responsive to the most recent action of the system. There is another type of PID control that does keep track of several previous commands and positions- its an adaptive algorythm - one that responsed differently if the mass of the system changes (like if you pick up a ball with your arm) or it the friction of the system changes (like if you move from carpet to smooth surface) and it adjusts the gains of the feedback accordingly. But I think thats really too fancy for what we need. so far on our drivetrain and our arm motion, we are only using proportional feedback this year - its works well so we dont want to get lost in complexity. |
Re: PID control loops - closed loop feedback
For the typical low performance robot (I think FIRST robots count here), PD is needed for position control (proportional/derivative) and PI is needed for velocity control.
Usually with positioning servos, the control is sloppy and there is a lot of friction, so you can get away with just P term. Adding the D term allows stiffer snappier control, but, again, with the typical chain driven arm snappy isn't the image that comes to mind. W/velocity control, often folks get away with just the I term. Something like: output += SomeFudgeFactor * VelocityError; So if you are slow, the output is built up until you are at the right speed, etc. Team #492 had a arm for manipulating the 2x ball which was pretty sloppy and oscillated terribly when overhead (chain slop). So we simply checked for range and divided the output by 16 (or some other large number) when overhead. Worked great. That is an example of "gain scheduling" where you change the gain based upon position (or some other external factor). |
Re: PID control loops - closed loop feedback
Quote:
|
Re: PID control loops - closed loop feedback
Quote:
Quote:
|
Re: PID control loops - closed loop feedback
We use 2 PI loops to maintain target velocities on our 2 arm joints. The integral is essential for our loop because it is what keeps the arms from falling due to gravity. For the proportional to work, it needs to have a speed error. So in order for the proportional to prevent the arm from dropping, the arm needs to drop a little first. The integral is non-zero when the arm is stationary, which is what keeps the motor at stall torque.
Here's the code for the PI loop for our elbow. Code:
//Joystick dead zoneBy the way, our P and I constants are both 1 / 8 on our competition robot, and our elbow loop runs at 10 Hz. Oh we also have a target position mode which feeds a target velocity into our PI loop. That's the RepositionElbow() function that you see in there. |
Re: PID control loops - closed loop feedback
thats pretty cool - I dont see any obvious mistakes in it.
have you been able to test it on your bot? the one thing Im curious about, why did you close the loop on arm velocity instead of arm position? for our arm control we integrate the joystick input and it creates a desired arm position - then we use a straight proportional desired-actual postion with a gain constant to create the motor drive the arm sags a little bit if its holding a ball, but thats a function of the gain- the more gain you use, the less it will sag (before the error signal is enough to hold it) closing the loop on position makes it easier to deal with the up and down limits - you just dont let the desired position exceed the limits. |
Re: PID control loops - closed loop feedback
Yeah the elbow loop works really well. It took us a lot of testing to get the right constants but 1/8 and 1/8 works best for us.
The wrist loop was a little more difficult to get working because of chain slack. Our wrist chain runs from the base of the robot up 5 ft to the joint so we can maintain a low CG by keeping all the motors in the base. What happened was when we moved the arm down it would overshoot a lot and be really bouncy, even though it worked perfectly on the way up. To fix that we reduced the constants on the way down. We did target velocity because that's basically what was coming out of the joysticks -- a target velocity. With target position, if something is holding back your arm, and your joystick is full forward, your target position is changing, but the actual position never changes. Then if you bring the joystick back to neutral and allow the arm to move again, it will shoot forward to its target position, even though that isn't necessarily what you wanted. Our arms sag a little bit when a ball is placed in them, but not much and the integral adjusts accordingly pretty quickly. In fact, we tested once with the robot at 90 deg (we were hanging from the bar) and the arm fully extended to 10 feet, and we placed a ball in it and it sagged about 3 inches with a huge lever arm before the integral picked up the change. |
Re: PID control loops - closed loop feedback
The PI loop on the wrist was immensely successful for us (I ran the arms at the Sacramento regional this weekend). The only problem it has, other than the bounciness on the way down Jay described (in actuallity that is a small problem, we only *fold* the arm once or twice in a match, to stow a ball or to stow when hanging), is that it can be slow to react when holding a ball. The integral has to get pretty high to move the arm up from extended to vertical (say, when we pick up a ball from a goal), and until I learned to correct, it would overshoot vertical (if thats when I moved the joystick to neutral) and fly down the other side. After about four rounds on Friday, though, I got that worked out and it worked really well for the rest of the tournament.
We had tried to build a PID loop earlier in the year, and didn't really end up with a workable solution. The important thing, it seems, was the engineer who came down and helped us map out the logic of the process. Once we knew what we wanted to do, it was actually only took about a half hour to write the function (and update as needed later). By the way, you can see the pictures of the arm straight out on our website, in my signature =). edit: The Reposition functions for the arms came from our old code for the arm, before we implemented the PI loop. It takes the distance from the desired position to generate a velocity. Pretty much, we only use it for the preset buttons on our control box and autonomous mode. |
Re: PID control loops - closed loop feedback
wow that arm looks huge - now that you mention it, we did the same thing with our arm - used a much smaller gain going down than up - didnt want the arm to slam into the roller on the front of our bot.
if your arm goes over the top and down the other side, that does make it tricky. In general the way to get a feedback loop working is to start with low gains and increase them until you start getting overshoot - then back off a little. (or goto engineering school for 4 years and learn all the math :c) |
Re: PID control loops - closed loop feedback
Quote:
|
Re: PID control loops - closed loop feedback
Quote:
e.g. Foo += Something is equivalent to Foo = Foo + Something; Therefore Foo is accumulating the integral of Something. You are correct that the integral is needed to drive the error term to zero, but for position stuff that is rarely needed (particularly in low performance systems like what we are working on). WHat is really needed is to drive the servo *close* enough to the correct position that you don't care about the residual error. Integral terms are hard to get right and lead to a lot of instability and are really useless in a dynamic environment as they are fighting your ability to change the setpoint. They only make sense if your servo is relatively static or has a constant force in one direction that needs to be compensated for with the integral term. But if the error amount is dynamic and changing sign, the integral term just gets in the way. |
Re: PID control loops - closed loop feedback
Quote:
|
Re: PID control loops - closed loop feedback
Quote:
You state you are controlling velocity, yet what you are really controlling is position, but by a round-about way. Velocity is the first derivative of position. Your code takes the velocity error + the integral of the velocity error. Well, that can also read as: The first derivative of position error + Position error. Hence, in fact, you have a classic PD controller for position. As your controller integrates the velocity error, you get, essentially, an error term that grows as the position error grows. That is the "proportional" error term. Cheers! |
Re: PID control loops - closed loop feedback
Quote:
.... on second though, that isnt really a problem as the integral term isn't needed when the error is large. And i was presumptious enough to think that years of science and engineering could be faulty.... :) So what this means is that if one limits the integral each iteration, one can integrate for the entire time the robot functions? I understand this would work now, but it still seems a little odd, id rather just integrate for a shorter period of time. Is this common practice? |
| All times are GMT -5. The time now is 14:04. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi