May we have some traction control help?

[windell747]

We are currently trying to get our traction control to work. We based our traction control algorithm something like what we think team 121 is doing. We calculate the slip ratio and send that to the PID controller. The set point for us is 0 percent slippage. The values from the PID controllers are then added to the driver's joystick command to compensate for slippage.

So thats the algorithm. Here are some questions

1) How do you deal with the infinite slip ratio case as the driven wheel velocity goes to zero?
2) Is adding the values from the PID output to the motor command the best way to do this?
3) We would really like to have a simple yet effective traction control algorithm. Any suggestions on how we can improve?

I attached a copy of our code for reference.

[martin417]

We tried several different methods to calculate slip ratio, including the one I think you are using. What we found worked best was:

[(drive_wheel_rate-follower_wheel_rate)/Max_rate]

This algorithm always gives you a real number between -1 and 1.

[Tom Line]

Simply add one to your denominator. It won't effect your calculations, and removes the possibility of the NAN divide by zero case.

[DonRotolo]

A slip value of zero is not optimal. We have found experimentally that about a 20% slip rate gives the best acceleration. You may want to consider a higher slip rate.

[windell747]

Thanks for your responses! We will try these suggestions and get back to you guys!

[windell747]

Here is the update that I promised. We were able to get our traction control to work for the most part. I will summarize our method and will then outline some problems and ask questions.

Here is a summary for our traction control:
-calculate the slip ratio (driven wheel velocity-follower wheel velocity)/max_velocity. max_velocity=100in/s (for us).
-submit this slip ratio to the process variable of a PID controller.
-P=3 (for us), I=0,D=0
-add the PID output value to the current driver command to correct for slip if needed.

note: the max_velocity used in the slip ratio is defined as the maximum linear velocity of the wheels when the robot is off the ground.

Problems:
1)I am using the slip ratio of 0% instead of the optimum 20%. With my algorithm, there will be always be an error if the robot isn't moving because slip ratio would be zero in that case.
2)when I floor the joystick forward, traction control works pretty well. Then if I let the joystick go and fly back to center, I get some jerking in the driven wheels. If i were to bring the joystick back slowly, the jerking doesn't occur.

What am I asking?:
1) I'm not using sending a variable gain to the PID controller as discussed by team 121. The variable gain would be calculated as K*slip ratio. Is this a good idea? This method would seem to allow me to use a slip ratio setpoint of 20% and not cause an error greater than 0 when the robot isn't moving.
2) Should I filter my slip ratio and motor commands somehow? If so should I use a lowpass filter or something similar? Or a rate limiter? I would like to remain simple and effective.
3)With my current algorithm, if I floor it forward and then floor it backwards, the wheels lockup. This makes sense (PID limits: -1 to 1 and full reverse = -1 command = motor command of 0). I would like the wheels to speed up in the direction the bot is moving and pull the robots speed down. I'm thinking that the variable gain PID method would do this for me. What do you think?

I have a pdf of my code attached if any of you want to dive into the code.

[Doug Leppard]

Our drivers are happy with our traction control. We have the driven wheel encoder and a vex Omni wheel on the floor called the undriven wheel.

We found 20% slippage is the best. Our moving algorithm follows the joystick either increasing power or decreasing power according to the joystick position and wheel slippage.

But you have the 0 or little speed situation, for instance you may be in a pushing war and going almost 0.

For that we don’t do a ratio of slippage because it does not make sense. But we allow a certain number of rpms of the wheel which is slippage at a standstill.

It is very simple.

BTW we put a toggle switch on the driver’s station that allows the drivers to turn off and on the traction control; sometimes the drivers use the large amount of slippage to their advantage especially in turning.

[marccenter]

[quote=windell747;839623] Problems:

2)when I floor the joystick forward, traction control works pretty well. Then if I let the joystick go and fly back to center, I get some jerking in the driven wheels. If i were to bring the joystick back slowly, the jerking doesn't occur.

What am I asking?:

2) Should I filter my slip ratio and motor commands somehow? If so should I use a lowpass filter or something similar? Or a rate limiter? I would like to remain simple and effective.
QUOTE]

Absolutely, removing those uncontrolled large transients will help solve a multiple of problems on motor commands. I typically filter the joystick command input (which filters the motor command as it propagates its way through the control algorithms). Even a rate limiter with a 25 percent change per loop or time event can make a big difference.

My vote is to go with a rate limiter. I think it is simpler to implement and more intutitive to understand when explaining to high school students. We use rate limiters in Matlab/Simulink at work all day long and I believe a standard Simulink block has been specifically created for that feature in the Control System Library.

BTW, Does Labview have such a block already created? If not, here is one recommendation for FIRST to add next year - a standard blockset of commonly used control functions (Table Lookups, Rate Limiter).

[marccenter]

Originally Posted by Doug Leppard

Our drivers are happy with our traction control. We have the driven wheel encoder and a vex Omni wheel on the floor called the undriven wheel.

We found 20% slippage is the best. Our moving algorithm follows the joystick either increasing power or decreasing power according to the joystick position and wheel slippage.

But you have the 0 or little speed situation, for instance you may be in a pushing war and going almost 0.

For that we don’t do a ratio of slippage because it does not make sense. But we allow a certain number of rpms of the wheel which is slippage at a standstill.

It is very simple.

BTW we put a toggle switch on the driver’s station that allows the drivers to turn off and on the traction control; sometimes the drivers use the large amount of slippage to their advantage especially in turning.

Doug,
In order of implementing a traction control algorithm I have proposed for a FRC conference presentation paper with VEX and Easy-C Pro implementation: 1) rate-limiting joystick command input to motor command output - solves a multitude of problems, 2) control maximum motor speed command as a function of undriven wheel speed (non-feedback based slip control) Joystick position can be independent of the maximum motor speed command but you have indicated that you did
add joystick dependence. Can you indicate why? 3) feedback based slip control (driven wheel speed based to undriven
wheel speed)

[windell747]

Yes, labview already has a block called the PID output rate limiter. It can be found in Addons->PID Control->PID. BTW, what does the EGU/min input mean physically. I know the greater it is the faster the output response, but I want to calculate what this means to the rate limiter so that I can get a ballpark without doing a lot of testing.

simulink rocks!

[Doug Leppard]

Originally Posted by marccenter

Doug,
In order of implementing a traction control algorithm I have proposed for a FRC conference presentation paper with VEX and Easy-C Pro implementation: 1) rate-limiting joystick command input to motor command output - solves a multitude of problems, 2) control maximum motor speed command as a function of undriven wheel speed (non-feedback based slip control) Joystick position can be independent of the maximum motor speed command but you have indicated that you did
add joystick dependence. Can you indicate why? 3) feedback based slip control (driven wheel speed based to undriven
wheel speed)

Not sure if I follow what you have asked, so I may not be answering your question. Case below is when the robot is moving.

On the joystick. It would seek the power setting of the joystick. If the joystick was at 3/4 power then the power would increase (or decrease) to 3/4 power but without slipping more than 20%. So if the driver moves the power from 0 to 3/4 power then it will keep increase power until it reaches 3/4 power, but it will be much less power to the wheels until it reaches that power.

If you are going at 3/4 forward power and shove the robot into reverse, it will decrease power without more than 20% slippage so it will not go into full skid.

I hope this makes sense.