EASY traction control?

[windell747]

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.

[web_master_dpep]

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.

[Brdn666]

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.

[RoboMaster]

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!

[biojae]

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.

[ComradeNikolai]

Originally Posted by RoboMaster

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.

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.

[LieningOver]

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

[kapolavery]

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

[vamfun]

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

[kamocat]

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.

[JasonF]

Originally Posted by Brdn666

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.

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

[Burmeister #279]

Originally Posted by JasonF

This is going to be the easiest thing to program for the beginner.
....
And if your driver complains about using this method go tell him to program what he wants
...

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

[JasonF]

Originally Posted by Burmeister #279

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

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

[Burmeister #279]

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