Go to Post Teaching students should take place in the offseason. Applying the skills learned is what the real season is for. - [more]
Home
Go Back   Chief Delphi > Technical > Technical Discussion
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 21-03-2004, 14:47
Max Lobovsky's Avatar
Max Lobovsky Max Lobovsky is offline
Fold em oval!
FRC #1257 (Parallel Universe)
Team Role: College Student
 
Join Date: Jan 2004
Rookie Year: 2004
Location: Scotch Plains, NJ
Posts: 1,026
Max Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant future
Send a message via AIM to Max Lobovsky
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?
__________________
Learn, edit, inspire: The FIRSTwiki.
Team 1257


2005 NYC Regional - 2nd seed, Xerox Creativity Award, Autodesk Visualization Award
2005 Chesapeake Regional - Engineering Inspiration Award
2004 Chesapeake Regional - Rookie Inspiration award
2004 NJ Regional - Team Spirit Award
  #17   Spotlight this post!  
Unread 21-03-2004, 15:06
KenWittlief KenWittlief is offline
.
no team
Team Role: Engineer
 
Join Date: Mar 2003
Location: Rochester, NY
Posts: 4,213
KenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond repute
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.
  #18   Spotlight this post!  
Unread 21-03-2004, 19:31
Larry Barello Larry Barello is offline
http://www.barello.net
#0492 (Titan Robotics Club)
Team Role: Mentor
 
Join Date: Jan 2002
Location: Bellevue, WA
Posts: 85
Larry Barello has a spectacular aura aboutLarry Barello has a spectacular aura about
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).
  #19   Spotlight this post!  
Unread 21-03-2004, 20:44
Max Lobovsky's Avatar
Max Lobovsky Max Lobovsky is offline
Fold em oval!
FRC #1257 (Parallel Universe)
Team Role: College Student
 
Join Date: Jan 2004
Rookie Year: 2004
Location: Scotch Plains, NJ
Posts: 1,026
Max Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant future
Send a message via AIM to Max Lobovsky
Re: PID control loops - closed loop feedback

Quote:
Originally Posted by KenWittlief
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.
ah, sorry, i do understand what a derivative is, just didn't think about the fact that previous values wont affect it.
__________________
Learn, edit, inspire: The FIRSTwiki.
Team 1257


2005 NYC Regional - 2nd seed, Xerox Creativity Award, Autodesk Visualization Award
2005 Chesapeake Regional - Engineering Inspiration Award
2004 Chesapeake Regional - Rookie Inspiration award
2004 NJ Regional - Team Spirit Award
  #20   Spotlight this post!  
Unread 21-03-2004, 20:48
Max Lobovsky's Avatar
Max Lobovsky Max Lobovsky is offline
Fold em oval!
FRC #1257 (Parallel Universe)
Team Role: College Student
 
Join Date: Jan 2004
Rookie Year: 2004
Location: Scotch Plains, NJ
Posts: 1,026
Max Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant future
Send a message via AIM to Max Lobovsky
Re: PID control loops - closed loop feedback

Quote:
Originally Posted by Larry Barello
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.
Wouldn't it be vice-versa? I thought that the integral is neccesary for reaching the right value.

Quote:
Originally Posted by Larry Barello
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.
how is this the integral? This looks proportional to me, just the current error.
__________________
Learn, edit, inspire: The FIRSTwiki.
Team 1257


2005 NYC Regional - 2nd seed, Xerox Creativity Award, Autodesk Visualization Award
2005 Chesapeake Regional - Engineering Inspiration Award
2004 Chesapeake Regional - Rookie Inspiration award
2004 NJ Regional - Team Spirit Award
  #21   Spotlight this post!  
Unread 21-03-2004, 21:50
Jay Lundy Jay Lundy is offline
Programmer/Driver 2001-2004
FRC #0254 (The Cheesy Poofs)
Team Role: Alumni
 
Join Date: Jun 2001
Rookie Year: 2001
Location: Berkeley, CA
Posts: 320
Jay Lundy is a name known to allJay Lundy is a name known to allJay Lundy is a name known to allJay Lundy is a name known to allJay Lundy is a name known to allJay Lundy is a name known to all
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 zone
 ELBOW_CONTROL = (ELBOW_CONTROL >= 127 - ELBOW_CONTROL_DEAD_ZONE && ELBOW_CONTROL <= 127 + ELBOW_CONTROL_DEAD_ZONE) ? 127 : ELBOW_CONTROL;	
  
  //Calculate velocities
  elbowVelocity = (long)(elbowCurrPosition - elbowPrevPosition) * 1000 / (long)(elbowCurrTime - elbowPrevTime);
  targetVelocity = ((int)ELBOW_CONTROL - 127) * ELBOW_MAX_POT_SPEED / 127;
  
  //Check for target position mode
  if (elbowPositionMode) {
  	targetVelocity = RepositionElbow();
  }
  
  //Calculate speed error
  speedError = targetVelocity - elbowVelocity;
  
  //Calculate proportional and integral
  proportional = speedError * ELBOW_PROPORTIONAL; 
  elbowIntegral += speedError * ELBOW_INTEGRAL;
  
  //Limit integral
  elbowIntegral = MIN_MAX(elbowIntegral, -127, 127);
  
  //Output to motors
  ELBOW_MOTORS = 254 - MIN_MAX(127 + (proportional + elbowIntegral), 0, 254);	
  
  //Set prev values to current values
  elbowPrevPosition = elbowCurrPosition;
  elbowPrevTime = elbowCurrTime;
The thing is, none of our programmers had any prior experience with PID loops. We just had an engineer come in for 2 hours one day and explain the theory to us, but he didn't provide any code. I'm curious if our implementation is correct, or if there are any improvements we should make.

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

Last edited by Jay Lundy : 21-03-2004 at 21:52.
  #22   Spotlight this post!  
Unread 21-03-2004, 22:05
KenWittlief KenWittlief is offline
.
no team
Team Role: Engineer
 
Join Date: Mar 2003
Location: Rochester, NY
Posts: 4,213
KenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond repute
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.
  #23   Spotlight this post!  
Unread 21-03-2004, 23:06
Jay Lundy Jay Lundy is offline
Programmer/Driver 2001-2004
FRC #0254 (The Cheesy Poofs)
Team Role: Alumni
 
Join Date: Jun 2001
Rookie Year: 2001
Location: Berkeley, CA
Posts: 320
Jay Lundy is a name known to allJay Lundy is a name known to allJay Lundy is a name known to allJay Lundy is a name known to allJay Lundy is a name known to allJay Lundy is a name known to all
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.
  #24   Spotlight this post!  
Unread 21-03-2004, 23:18
10intheCrunch's Avatar
10intheCrunch 10intheCrunch is offline
Who's John V-Neun?
AKA: Alex Baxter
None #0254 (Cheesy Poofs)
Team Role: College Student
 
Join Date: Feb 2004
Rookie Year: 2004
Location: San Jose, CA
Posts: 129
10intheCrunch is a jewel in the rough10intheCrunch is a jewel in the rough10intheCrunch is a jewel in the rough10intheCrunch is a jewel in the rough
Send a message via AIM to 10intheCrunch
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.
__________________
~Alex Baxter
Programming, Arms operation, Team 254

Last edited by 10intheCrunch : 21-03-2004 at 23:21.
  #25   Spotlight this post!  
Unread 21-03-2004, 23:25
KenWittlief KenWittlief is offline
.
no team
Team Role: Engineer
 
Join Date: Mar 2003
Location: Rochester, NY
Posts: 4,213
KenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond repute
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)
  #26   Spotlight this post!  
Unread 21-03-2004, 23:34
Max Lobovsky's Avatar
Max Lobovsky Max Lobovsky is offline
Fold em oval!
FRC #1257 (Parallel Universe)
Team Role: College Student
 
Join Date: Jan 2004
Rookie Year: 2004
Location: Scotch Plains, NJ
Posts: 1,026
Max Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant future
Send a message via AIM to Max Lobovsky
Re: PID control loops - closed loop feedback

Quote:
Originally Posted by Jay Lundy
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 zone
 ELBOW_CONTROL = (ELBOW_CONTROL >= 127 - ELBOW_CONTROL_DEAD_ZONE && ELBOW_CONTROL <= 127 + ELBOW_CONTROL_DEAD_ZONE) ? 127 : ELBOW_CONTROL;	
  
  //Calculate velocities
  elbowVelocity = (long)(elbowCurrPosition - elbowPrevPosition) * 1000 / (long)(elbowCurrTime - elbowPrevTime);
  targetVelocity = ((int)ELBOW_CONTROL - 127) * ELBOW_MAX_POT_SPEED / 127;
  
  //Check for target position mode
  if (elbowPositionMode) {
  	targetVelocity = RepositionElbow();
  }
  
  //Calculate speed error
  speedError = targetVelocity - elbowVelocity;
  
  //Calculate proportional and integral
  proportional = speedError * ELBOW_PROPORTIONAL; 
  elbowIntegral += speedError * ELBOW_INTEGRAL;
  
  //Limit integral
  elbowIntegral = MIN_MAX(elbowIntegral, -127, 127);
  
  //Output to motors
  ELBOW_MOTORS = 254 - MIN_MAX(127 + (proportional + elbowIntegral), 0, 254);	
  
  //Set prev values to current values
  elbowPrevPosition = elbowCurrPosition;
  elbowPrevTime = elbowCurrTime;
The thing is, none of our programmers had any prior experience with PID loops. We just had an engineer come in for 2 hours one day and explain the theory to us, but he didn't provide any code. I'm curious if our implementation is correct, or if there are any improvements we should make.

By 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.
as i understand it, the code sums the integral from start to finish, but every iteration of the loop it limits the integral. This seems like a very bad idea. essentially, the effective length of time that sum occurs is changing as the integral is being limited when it grows large. Also, for errors that continue in one direction, the integral error will not change because it will reach its max and keep trying to exceed that. This brings me back to my first question in this post. how long in iterations or in time should the integral sum over?
__________________
Learn, edit, inspire: The FIRSTwiki.
Team 1257


2005 NYC Regional - 2nd seed, Xerox Creativity Award, Autodesk Visualization Award
2005 Chesapeake Regional - Engineering Inspiration Award
2004 Chesapeake Regional - Rookie Inspiration award
2004 NJ Regional - Team Spirit Award
  #27   Spotlight this post!  
Unread 21-03-2004, 23:40
Larry Barello Larry Barello is offline
http://www.barello.net
#0492 (Titan Robotics Club)
Team Role: Mentor
 
Join Date: Jan 2002
Location: Bellevue, WA
Posts: 85
Larry Barello has a spectacular aura aboutLarry Barello has a spectacular aura about
Re: PID control loops - closed loop feedback

Quote:
Originally Posted by maxlobovsky
Wouldn't it be vice-versa? I thought that the integral is neccesary for reaching the right value.



how is this the integral? This looks proportional to me, just the current error.
Note the "+=" that says add the right hand side to the left hand side. Which is an integral

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.
  #28   Spotlight this post!  
Unread 21-03-2004, 23:41
Larry Barello Larry Barello is offline
http://www.barello.net
#0492 (Titan Robotics Club)
Team Role: Mentor
 
Join Date: Jan 2002
Location: Bellevue, WA
Posts: 85
Larry Barello has a spectacular aura aboutLarry Barello has a spectacular aura about
Re: PID control loops - closed loop feedback

Quote:
Originally Posted by maxlobovsky
as i understand it, the code sums the integral from start to finish, but every iteration of the loop it limits the integral. This seems like a very bad idea. essentially, the effective length of time that sum occurs is changing as the integral is being limited when it grows large. Also, for errors that continue in one direction, the integral error will not change because it will reach its max and keep trying to exceed that. This brings me back to my first question in this post. how long in iterations or in time should the integral sum over?
You must limit the integral term: what happens when your output is at 100% and you STILL have an error term? DO you really want to continue accumulating errors? It is a bad idea and will cause excessive delays in working out the integral term (the official name for this is Integral Windup) when you regain control.
  #29   Spotlight this post!  
Unread 21-03-2004, 23:47
Larry Barello Larry Barello is offline
http://www.barello.net
#0492 (Titan Robotics Club)
Team Role: Mentor
 
Join Date: Jan 2002
Location: Bellevue, WA
Posts: 85
Larry Barello has a spectacular aura aboutLarry Barello has a spectacular aura about
Re: PID control loops - closed loop feedback

Quote:
Originally Posted by Jay Lundy
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.
...
There is nothing wrong with your code, but terminology is a little hashed.

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!
  #30   Spotlight this post!  
Unread 21-03-2004, 23:47
Max Lobovsky's Avatar
Max Lobovsky Max Lobovsky is offline
Fold em oval!
FRC #1257 (Parallel Universe)
Team Role: College Student
 
Join Date: Jan 2004
Rookie Year: 2004
Location: Scotch Plains, NJ
Posts: 1,026
Max Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant futureMax Lobovsky has a brilliant future
Send a message via AIM to Max Lobovsky
Re: PID control loops - closed loop feedback

Quote:
Originally Posted by Larry Barello
You must limit the integral term: what happens when your output is at 100% and you STILL have an error term? DO you really want to continue accumulating errors? It is a bad idea and will cause excessive delays in working out the integral term (the official name for this is Integral Windup) when you regain control.
ok, but i thought the solution to that is to sum over a shorter period of time and use a small enough coeffecient. The integral term just becomes an additional proportional term in the code posted above when the error is large enough.

.... 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?
__________________
Learn, edit, inspire: The FIRSTwiki.
Team 1257


2005 NYC Regional - 2nd seed, Xerox Creativity Award, Autodesk Visualization Award
2005 Chesapeake Regional - Engineering Inspiration Award
2004 Chesapeake Regional - Rookie Inspiration award
2004 NJ Regional - Team Spirit Award

Last edited by Max Lobovsky : 21-03-2004 at 23:52.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 14:04.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi