EASY traction control?

[grosh]

At the Oregon Regional we realized that traction control is really important. I have read a number of forums that talk about traction control...come on now ! Most of the discussion is like listening to the advanced chem teacher talking about thermodynamics to a third grader. We are new to LabView and programming for that matter. Is their anything we can do to EASILY get traction control. After looking through other discussion we like the idea of limiting the joystick values to slow the acceleration but don't quite know how that would work. Is there any easy way to slow the joystick response to slow the acceleration? Any other suggestion?

[Uberbots]

well if you dont want to try doing all the control loop stuff, you can get a fairly satisfactory slip control by simply ramping up/down the motor signal.

basically to make this work you would make your motor output "correct for" the joystick input. for example, if your joystick is at position .7 and your motor output is at .3, you would want it to increase at a constant rate towards .7.

in pseudocode:

if (motor_out > joystick) //ramp down
motor_out -= .05;
if (motor_out < joystick) //ramp up
motor_out += .05

if ( |motor_out - joystick| < .05) //fix the jumping error
motor_out = joystick

i figure thats pretty easy to turn into labview code

[Cuse]

Well, a very simple system to implement that is purely software involves just limiting the joystick values by an Acceleration Limit of sorts.

Essentially it's using the In Range and Coerce function in LabView (I take it from your post that is what you are using), and the idea is to use the Joystick Axis input as your X test value, and to have your upper limit = (the previous Axis Value + your acceleration limit) and the lower limit = (the previous Axis Value - your acceleration limit). With this very simple functionality, if the input, X, is out of range of either of those values, i.e. it is too much , it will output the coerced x value as (your X value + your limit) until it is within range and reaches the value you requested as X.

Unfortunately, as I'm unbelievably tired at the moment, I don't think that post was very coherent, so I'm just including a screenshot and hoping that makes this much easier to understand.

For the purposes of the example I just picked a number, 0.05, as your limit, but you'll have to experiment to see what will work best for your robot.

Frankly I don't know of any simpler way to implement a limit on the joystick values.

The example provided I believe was originally in a WPI paper somewhere...

[Alan Anderson]

Originally Posted by Cuse

For the purposes of the example I just picked a number, 0.05, as your limit, but you'll have to experiment to see what will work best for your robot.

We derive the limit from the throttle input axis on one of the joysticks. That way it can be tweaked on the fly to account for slightly different slickness on the field as conditions change.

(Actually, we don't have that feature enabled anymore. Our driver doesn't want anything to get between him and the drive motors. We humor him, and he in turn has piloted the robot to victory every time so far.)

[grosh]

Alan, I recognize you as the originator of another thread on traction control. That thread really got our programmers thinking, but with our the lack of experience we just could not get traction control implemented before our first FIRST competition.

Could you post your joystick limit code you were using?

PS- CUSE, what is the limit number (you chose 0.05) referring to?

Thank you for hanging in there with us. We hope to become more knowledgeable some day and be able to give back too.

[Alan Anderson]

Originally Posted by grosh

Alan,...Could you post your joystick limit code you were using?

It was essentially what Cuse posted. I hadn't discovered feedback nodes yet, so I used a shift register instead. Our maximum delta (constant 0.05 in his diagram) was taken from the joystick throttle (axis 3), increased by 1 and divided by -2 in order to make full "down" produce zero and full "up" produce 1.

At one point we tried modifying the delta based on the tick count, but the 50 cycles per second of the DS-to-cRIO communication was reliable enough to make it unnecessary.

[grosh]

Great idea! We will try this tonight. Thanks for the being patient with us.

[s0crates]

I can tell you that traction control helps a lot. We just used a much less elegant version of Cuse's code - about as simple as its possible to get. I think (our driver would probably agree) that it was one of the main reasons the max ever scored on us in a match was 4 moon rocks .

One slight twist to the standard traction control that we added was basically an override so if the driver switched speeds from -1 to 1 or 1 to -1, traction control was ignored. This allowed him to turn quickly, jackknife, etc. Without something like that, you always maintain control, not necessarily what you want when there's a 'bot on your tail and you want to perform some fast maneuvers.

-jonathan
PIGMICE!

[Chaos in a Can]

We're going to try something of a manual traction control.
When we tried the simple rate limiting method described here, our driver didn't like the feel of the robot.

Instead, pressing down one trigger (we use a 2-joystick tank style control) will scale down the motor power slightly and pressing both scales it down further. The change in the scaler is rate limited while increasing, so our driver can start from a standstill in the lowest "gear" by holding both triggers and release the triggers as he speeds up to smoothly accelerate.

At higher speeds, it doesn't do much, but it should make low-speed maneuvers more controllable.

[Cuse]

Originally Posted by grosh

PS- CUSE, what is the limit number (you chose 0.05) referring to?

Thank you for hanging in there with us. We hope to become more knowledgeable some day and be able to give back too.

The 0.05 is essentially just the maximum "step" you want to have the joystick value take in any given cycle of the code--it's your limit.

For example if you have the joystick full forward and you're requesting a value of 1, with the limit at 0.05 the successive steps up to 1 will go: 0, 0.05, 0.1, 0.15, etc until it reaches 1. You can speed up the steps or slow it down by changing that value.

Make sense?

If you have any other questions feel free to ask.

[grosh]

CUSE- what is the orange arrow at the top of the code?

[Vikesrock]

Originally Posted by grosh

CUSE- what is the orange arrow at the top of the code?

That's a feedback node. Basically data takes one cycle to get from the input (tail of the arrow) to the output (head of the arrow).

[grosh]

Where can I find the feedback node?

[s0crates]

programming > structures, right before shared/local/global vars.

[EricVanWyk]

I'll throw my bit in for the doc I wrote on this. It is located at http://thinktank.wpi.edu/ArticleRevision/262

Ain't great, but it might help a little.