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?
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
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…
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.)
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.
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.
Great idea! We will try this tonight. Thanks for the being patient with us.
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!
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.
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.
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).
Where can I find the feedback node?
programming > structures, right before shared/local/global vars.
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.
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.
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.
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.
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: 
