Go to Post Cash is always better, remember that when fund raising. - LordDumpling [more]
Home
Go Back   Chief Delphi > Technical > Programming
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 05-02-2011, 20:03
de_ de_ is offline
Registered User
AKA: Dave Edwards
FRC #1310 (Runnymede Robotics)
Team Role: Mentor
 
Join Date: Apr 2005
Rookie Year: 2005
Location: Toronto, Ontario
Posts: 256
de_ is a jewel in the roughde_ is a jewel in the roughde_ is a jewel in the roughde_ is a jewel in the rough
Re: Any PID experts ?

Thanks for all the input. We tried a number of combinations but gravity combined with the realities of a no-backturn gearbox (which leads to significant jumping going downwards as the backturn pins engage and disengage as the motor is turned on or off or reverses direction, we went back to KISS (dropped the PID code) and currently just go full speed up to within 5% of the target and power off. The no-backturn motor keeps us there. We did something similar going downwards but I believe are not going full power down. So far so good ...

I suspect a generic PID algorthim is aimed at systems that has largely symetrical responses on either side of the target but we were highly assymmetrical (especially with the anti-backlash) making a single set of tuning parameters hard pressed to do a good job in both directions
  #17   Spotlight this post!  
Unread 05-02-2011, 22:02
Alan Anderson's Avatar
Alan Anderson Alan Anderson is offline
Software Architect
FRC #0045 (TechnoKats)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2004
Location: Kokomo, Indiana
Posts: 9,113
Alan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond repute
Re: Any PID experts ?

Quote:
Originally Posted by de_ View Post
I suspect a generic PID algorthim is aimed at systems that has largely symetrical responses on either side of the target but we were highly assymmetrical (especially with the anti-backlash) making a single set of tuning parameters hard pressed to do a good job in both directions
That's where the "gain scheduler" Palardy mentioned comes into play. It changes the tuning parameters based on measured conditions. In your case, the sign of the error would be used to determine which set of parameters (the "going up" or "going down" numbers) to employ.
  #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)
Team Role: Engineer
 
Join Date: May 2001
Rookie Year: 1997
Location: Canton, MI
Posts: 1,488
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.
  #19   Spotlight this post!  
Unread 05-02-2011, 23:02
Matt Krass's Avatar
Matt Krass Matt Krass is offline
"Old" and Cranky. Get off my lawn!
AKA: Dark Ages
FRC #0263 (Sachem Aftershock)
Team Role: Mentor
 
Join Date: Oct 2002
Rookie Year: 2002
Location: Long Island, NY
Posts: 1,187
Matt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond repute
Send a message via AIM to Matt Krass
Re: Any PID experts ?

Not to toot my own horn, but I wrote this a while ago:
http://www.chiefdelphi.com/media/papers/1823

It's aimed at the old control system, so the code examples don't apply directly (the new controller doesn't have the same limitations in regard to math complexity) but the concepts are still valid. I'm in the process of rewriting this to be a bit cleaner with the new control system as the basis for the examples, but it'll be pretty similar to my original paper.

As stated in the paper, please feel free to contact me directly via email, PM or anything like that if you have any questions at all.

A fair point, I wasn't very clear about how the D term works in this paper, I really didn't touch well on the fact that it's usually a negative coefficient to help counteract overshoot by regulating speed, but on some systems, I've found a positive value works out well, depending on exactly what response you need, and if overshoot is acceptable, etc. I will be making this much clearer in the next version of the paper.

I really hope that helps, and again let me know if you have any specific questions,
Matt
__________________
Matt Krass
If I suggest something to try and fix a problem, and you don't understand what I mean, please PM me!

I'm a FIRST relic of sorts, I remember when we used PBASIC and we got CH Flightsticks in the KoP. In my day we didn't have motorized carts, we pushed our robots uphill, both ways! (Houston 2003!)
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 20:53.

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