EASY traction control?
 

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:ahh: ! 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?

Re: EASY traction control?
 

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

Re: EASY traction control?
 

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...

Re: EASY traction control?
 

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.)

Re: EASY traction control?
 

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.

Re: EASY traction control?
 

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.

Re: EASY traction control?
 

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

Re: EASY traction control?
 

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 :D.

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!

Re: EASY traction control?
 

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.

Re: EASY traction control?
 

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.

Re: EASY traction control?
 

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

Re: EASY traction control?
 

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).

Re: EASY traction control?
 

Where can I find the feedback node?

Re: EASY traction control?
 

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

Re: EASY traction control?
 

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.

Re: EASY traction control?
 

Another simple form of traction control as it is kind of hinted at in the WPI joystick filter paper is to use the PID rate limiter to go between the joystick command and the motor command. We tried this quickly and realized a dramatic improvement, however is the EGU/min value was too small, the ramp up and ramp down would take a while especially as the motor command was working its way (at the slow rate) through the deadband for the jaguars. I guess you could disable the deadband, but I'm not sure how this will perform on your bot.

Re: EASY traction control?
 

Umm, I personally have never programmed but we just just start out slow and begin to accelerate quicker and quicker so we dont lose grip of the floor and our wheels dont begin to spin. If your wheels to just spin then you have lost all traction, so just start slow then speed up I guess.

Re: EASY traction control?
 

You could program so "electric gears". Just have 2 or 3 settings that subtract from your joystick output. To get the buttons to switch without holding the button down, get three selects (programming/comparison). Wire the bottom's select into the false of the one above. Repeat, wiring the very top to the bottom (A feedback node should appear). Put the buttons select into the select, and then put whatever values you want in the true. The output of the top goes into your add/subtract and the joystick goes in the top. Put in a catch for when you add/subtract too much and go backwards when you aren't moving at all.

Re: EASY traction control?
 

One of our programmers is a wicked smart calculus and programming guy and he rigged up this monster program (at least to me) that would decreace the speed of a wheel if it was slipping, therefore giving it more traction (we have four wheel drive). I don't know the details, but he took the PMW signal that we were sending to the motor and figured out how fast the wheel should be going. Then, using the encoders that we installed on our gearboxes (which are basicaly rotation sensors), we figured out the actual speed of the wheel. We compared those two values and if the wheel was going faster than it should, it must be slipping, so we reduced the power to that wheel. (the code is a lot more complicating than that, though (it's LabVIEW, by the way))

We also have a system that has been previously mentioned, where instead of powering the wheels at the exact speed that the joystick is telling them to run, the code just increaces the speed of the wheel incrementally if the joystick-user wants to go faster/slower. We call this our acceleration control system.

But actually, I personally find the acceleration control stated above bad. Because the robot speeds up and slows down slowly, the turning and stopping is delayed and effectivly the robot's reaction time is slow. This was very cumbersome and most of the time people on our team were just constanly holding down a button that we had programmed which would turn off this feature and we would just drive carefully.

I have thought about keeping our traction control system, but re-doing our acceleration control system. Since mostly we were just driving carefully and slowly, we could simply divide the joystick value by 2 (or something) and then our robot would drive slower and we would have more control. In many games, and especially in 2009, drivers are manuvering precisely and this control is a giant benifit. If you did need to go fast (like you were trying to sprint down to the end of the field), then one could hold down/push a joystick button and the motors would use the actual joystick values and would not divide them by 2.

So that's my input, see what you think. To restate, I think the incremental acceleration control has merit, but after trying it out on a robot, I found it to be cumbersome because of the slow response time of the robot and would have rather liked to have had a slower robot that therefore had more control.

Whew, what an essay! :ahh: :D :p

Re: EASY traction control?
 

What 399 did was a simple open loop system. We took the joystick value and cubed it. this makes the values non-linear and has some deadband in the motors. The drivers have more control over the speed in the low traction environment.

Re: EASY traction control?
 

During our driver tryout period, most of them experienced the same problem, so I switched the traction control from automatically enabled to automatically disabled. It works well for accelerating and smooth curves when you're not colliding into other robots but, once you hit something, the system gets thrown off. Personally, I found it splendid to use until it was thrown off (and when I drove, I used it often, for what it was designed for), but our other drivers had other preferences.

Having a disable/enable feature is a good idea.

Re: EASY traction control?
 

On our team we realized that traction control wasn't very important, our drivers just need good self control. Especially if you have a low center of gravity like our robot Otis

Re: EASY traction control?
 

yea i read all that stuff on traction control and its some heavy stuff to grasp..
so yea like most teams..

we just set the values on the controller putting different speed options, so like on the logitech kit controller, button 3 would be a set slower value to avoid slippage and trigger would be max value speed.. so its up to the driver to figure out what speeds to use and when..

Re: EASY traction control?
 

Well, we decided traction control was not necessary by default... i.e. the encoders were inop so the driver learned fast to take advantage of our maneuverability to do a kind of self induced pit maneuver to spin the trailer around and avoid a pursuer. So a short wheel base and a "squared" stick transfer function seemed to work well.

We actually had the software/encoders for a three level traction control.

The first level was a backup and just the rate limited stick which others have mentioned. It does limit accel but drivers complain of sluggishness. This is caused by the rate limit being upstream of the motor lag. The motor follows the rate limited stick but its response is delayed about .4 sec. This delayed acceleration response is noticeable by the drivers. Also even though the wheels are not slipping, the delay reduces the benefits over a slipping robot.

The second level was a motor torque limiter. This was achieved by limiting difference between motor speed and commanded speed (effectively a current limiter). Only motor encoders are necessary for this and several teams were very successful with this approach.

The third level was real time adjustment of the motor torque limit value based upon wheel slip speed. The wheel slip speed requires reference wheels with encoders. V_slip = V_wheel-V_ref. If V_slip>0 then the limit was reduced by some factor.


I wrote a small ppt paper to introduce the subject of traction control for the software group early on in the project. I offer it as an addition source of confusion for you:)

Re: EASY traction control?
 

Here's a time-based VI for you, so you don't have to worry about inconsistant execution rate.
(again, you wire the dbl value (orange wire) through it)
I found that the drivers complained of sluggishness mainly because of the slow ramp-down. Because the ramp-down didn't seem to be neccessary (you can turn out of the way, you can turn sideways, etc), I made it optional to disclude it.
It's a polymorphic VI, in this case meaning you can use it for an array of dbl or a scalar dbl.
The 'setpoint' is your input.

It's under "ramp" at
http://kamocat.com/programming.html#control

I'm still working on something that describes robot movement in turn radius, forward speed, and sideways slip.

Re: EASY traction control?
 

This is going to be the easiest thing to program for the beginner.
We did a similar thing with 2 multipliers to the Axis Value depending on the button.

In our set up we used only the Y-Axis for the Value. We had a Trigger and a Pinkie Button, so the Trigger was a (y*.65) Value. The driver with the trigger depressed could use the slower speed in addition to the fact he would creep up to the full value on the axis. The Pinkie finger would be another value... depending on what you needed.

It isn't an elegant solution to the problem, but it worked for us. We didn't use a standard Tank drive system so Spinning Out was not as much of an issue for us.

And if your driver complains about using this method go tell him to program what he wants ;)

I attached our code... and you get to witness my Worst photoshop job ever...

Re: EASY traction control?
 

:ahh:
This is a terrible way to run your programming. Being a driver and a programmer, i know that the programming group should do their best to build controls the way the drive team needs it, even if it's not the easiest to do. Even if you were kidding/being sarcastic its not very good teamwork...:cool:

Re: EASY traction control?
 

I didn't realize I would offend someone. Sorry I guess...

to clarify I am the only programmer and the assistant Driver. I am always asking the main driver with how he can best drive the robot, is the crab drive correcting too fast, what feels most responsive, etc...

Re: EASY traction control?
 

thank you for clarifying. just putting my two cents in too fast i guess, sorry for snapping at you textually.