View Single Post
  #3   Spotlight this post!  
Unread 27-01-2009, 22:02
DonRotolo's Avatar
DonRotolo DonRotolo is offline
Back to humble
FRC #0832
Team Role: Mentor
 
Join Date: Jan 2005
Rookie Year: 2005
Location: Atlanta GA
Posts: 7,019
DonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond reputeDonRotolo has a reputation beyond repute
Re: Using encoders for traction control help

Quote:
Originally Posted by ellisk View Post
So, the step I'm stuck on is the "Limit commanded_speed based on maximum acceleration to prevent slipping" step from Abwehr's algorithm.
Maybe this will help, maybe not. I'm not a programmer.

If commanded speed is higher than what will support the maximum slippage - that is, if the joystick is pushed too hard - the wheel slips. First thing we need to do is figure out how much slip we have (which you seem to have done?) and now you ask how to reduce the commanded speed to one that maintains a slip level lower than your threshold (say, 20% slip).

This becomes a case of a PID loop. First we need to determine the Proportional error ("P") and correct for it: Let's say wheel speed is 100 and trans speed is 130, so we have 30% slip (130-100=30) and we have to slow the motors down. Cut back the current PWM value by a certain amount (let's say 1 PWM value out of 254 for every 10% of slip (the "correction factor", which would be 3 here)). Then, we loop around to the top, check the commanded value, check the wheel speed, check the trans speed and repeat the P error calculation - if still too fast, reduce by 1 and repeat all again.

OK, that will work for excessive acceleration. Deceleration is your problem, but it works the same way - or you can ignore it (reasonable for this game).

But, this is far from optimized: Maybe a step of (1PWM * (slip/10)) is not fast enough to control slippage. Maybe it is too fast. Or perhaps you need to limit or vary the step size according to the slip percentage.......This is called Derivative control, or "D", because it measures the slope of the P error curve (which is a calculus derivative of the curve equation, but that's not important here..). For example, if the error is 100% slip (wheels turning twice as fast as robot is moving), we might cut PWM by 20 counts at a time, 40% slip, maybe 6 counts, and so on.

To implement D, we can take the last correction factor (which was a 3 PWM step drop in the example), subtract it from the current (just-calculated) correction factor, then multiply it by some scale factor (start with 1, could go to 0 or up to maybe 5) to come up with a step size that is not a simple multiplication, but has some 'memory'. You might even use a multiplication with the P error also to give it even more nonlinearity, you have to play with the scale factors.

Got this so far?

The last case - Integral - is actually not necessary in a highly dynamic system. And your robot likely qualifies. What the "I" factor does is correct for small but persistent errors, by allowing them to build up over time so that they can be noticed and acted upon. You see, P and to a lesser extent D need to be somewhat insensitive to small errors, otherwise they'd go crazy all the time and oscillate. But a small error can, over time, cause a problem. You get the I factor by adding the last P error to the current P error, and keep adding them up forever. Once it gets big enough it has some impact, then the system corrects the error so that the I factor decreases (less than 0% slip subtracts) and the cycle repeats. But again, you don't really need this.

OK, so you go around and around, seeing where you are and where you need to be each time, and nudge in the right direction. If your nudges are too slow, bigger scale factors are needed, or a faster loop. Too fast (or oscillating), smaller factors or a slower loop. Factors are easier to change than loop speed. Eventually you fall below your target slip amount and your correction factors all go to unity (1) and commanded input = commanded output.

Be sure to put an over-ride for the driver, as turns can be better with high slippage. Maybe the trigger button turns it off.

I can explain this a dozen different ways, so ask about what isn't clear.

But first, find and read the whitepaper "PID without a PhD" as this will make you understand that PID algorithms are well-understood and easily implemented - it's just that tuning them (meaning getting the various multiplication factors correct) is a bear. Approach the system in the same way that the paper advises - in your code I see stuff I don't understand, and I don't see you doing the right stuff to the error values - and then see what happens.

I really hope this helps. Write back.
__________________

I am N2IRZ - What's your callsign?