View Single Post
  #18   Spotlight this post!  
Unread 05-02-2011, 22:59
Chris Hibner's Avatar Unsung FIRST Hero
Chris Hibner Chris Hibner is offline
Eschewing Obfuscation Since 1990
AKA: Lars Kamen's Roadie
FRC #0051 (Wings of Fire (on sabbatical))
Team Role: Engineer
 
Join Date: May 2001
Rookie Year: 1997
Location: Canton, MI
Posts: 1,489
Chris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond repute
Re: Any PID experts ?

Quote:
Originally Posted by de_ View Post
- yes, good idea, if we could design something where the effects of gravity can be neutralized (gigantic spring), I could see how the current PID class could work well but so far we don't know how to do it. So currently with the same power, going up goes slowly and controllable, going down races at high speed and gathers lots of momentum. This behaviour is a bottle neck to a super high performance (ie high speed) ladder.
This is where some feed-forward control comes in.

Feed-forward is a motor command in addition to the feedback motor command from the PID. Mathematically, it is:

MotorCommand = P*error + I*errorIntegral + D*derivative + feedForward

The feed forward command depends on the physics of the system, and can be as simple or as complicated as needed. For an elevator, it should be a fairly simple constant value used to fight gravity. Since F = m * g, and m and g are constant, F should be constant. Therefore, your motor command to fight gravity should be constant.

So, how do you find this constant value to fight gravity? In the case of the elevator, it's pretty easy: 1) set up a PID controller (the I-term is necessary for this), 2) command your set point to some arbitrary value, 3) wait until your system settles at the set point, 4) read the motor command that is keeping it still. Voila, you have your feed-forward constant.

What feed forward does for you is this:

Let's say you have the issue you're seeing: the elevator goes slowly up, but races down. In reality, to let it go down, you may not really want to command the motor in the down direction - you may only want to relax the upward command. The feed-forward takes care of this. In the elevator example, let's say you set your feed-forward constant at 0.10 PWM duty cycle in the up direction. If you command the elevator to go up 10 cm, the PID may command the motor up 0.07 and with the feed forward addition the total motor command would be 0.17. If you commanded the elevator DOWN 10 cm, the PID would command the motor the same 0.07 but in the down direction (with gravity it would go racing downward), but when you add the feed forward term, the motor would be commanded UP 0.03. Since it requires 0.10 to hold it steady, 0.03 up would result in gentle downward movement of the elevator.

I hope that makes some sense, it got a little long-winded.

For an arm, the feed forward term should be a function of the angle of the arm. For example, if 0 degrees represents the arm straight up, then the feed forward term should be C * sin(armAngle). If you do a little math to determine the torque at the motor as a function of arm angle, you'll see why C*sin(armAngle) makes sense.

In summary, if you can develop some simple physics equations of the system, you can come up with a feed-forward method that makes sense. The idea is that the feed-forward motor command should be what the physics say the motor command should be in a perfect world. The PID is then there to take up the slop and make up for errors and imperfections.
__________________
-
An ounce of perception is worth a pound of obscure.