Re: Implementing Traction Control for an advantage in the 2009 game
 

What I am thinking of is a simple, program-level, "pseudo-pulse"; can't think of the word off the top of my head, but it would pretend that the input is pulsing at a rapid rate, and then have a button mapped to turn this pulse on or off, just in case it needs to be off. Granted, the on-off button would only work in teleop, but it's still better than nothing and can easily be implemented by a loop with a wait of, say, 10 ms. Would this work, or would this just be interpreted as just a steady stream? I didn't look too deep into the specifics of the control system, but this is my interpretation of a traction control mechanism implemented in the software level. And yes, I am a rookie.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Would the "pseudo-pulse" be variable depending on conditions? If not, then you're effectively driving the motors slower, not actually preventing a slip.

A Traction Control System looks at the all of the wheel speeds and determines which are slipping, then slows only those wheels.

My team is definitely trying to do this [4WD, all independently driven] but we can't figure out one thing:

How do you determine if a wheel is slipping when all four wheels are powered?

Any answer would be appreciated.

Re: Implementing Traction Control for an advantage in the 2009 game
 

An accelerometer perhaps? It's not bullet proof, but I'd imagine it could work pretty well. You can figure the theoretical limit of your acceleration. If you're slipping, you aren't accelerating that fast. So slow down until a decrease in wheel rpm produces a slight decrease in acceleration.

Re: Implementing Traction Control for an advantage in the 2009 game
 

FIRST off, it's important to note that even absolutely perfect traction control (runs riiiight at the limit of static friction at all times) compared to a wheel slipping a reasonable amount (dynamic friction but not so incredibly fast that the materials do not have time to interact with eachother before the surfaces move) has very little difference in acceleration.

The coefficients of friction (preliminarily) for static is 0.06 and dynamic is 0.05. If you calculate out how long it would take for a 120lb robot to accelerate to 10ft/sec, you'll find the difference in time to be about 0.1sec. Not much difference.

But, if you were going to go ahead with it anyhow, I think integrating the accelerometer over time to get real velocity would be a good start. Then, using encoders for wheel speed and the accelerometer integration value for real speed, you have a surefire indication for weather or not you are slipping, then you're control logic/software can take over from there.

I realize other methods of detecting slip have been mentioned in this thread, but knowing the real velocity of the robot gives you another cool ability. If for example you are using a tank drive train (motor for left, right side of robot) and one of the sides of your robot gets on carpet, your control system can independently adjust the traction control action regardless of the surface the wheels are on (power would be increased to point of slippage on carpet, which would be a higher force than can be exerted on the opposite (regolith) side). Should make your routine surface type independent.

It would be very interesting to learn what the coefficients of static+dynamic friction of the moon tires are on the carpet. Does anyone know/want to figure it out?

Okay, time for bed. :o

-q

Re: Implementing Traction Control for an advantage in the 2009 game
 

Extending on what QBranch said, its kind of a bad idea to implement traction control when you have no traction in the first place.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I was thinking of just adding some inertia on the joysticks, for not to allow sudden variations on the axis, like a capacitor would do to a square signal.

I already figured out how to get the derivative of the movement of the axis, so I can measure sudden moves to correct it, but that's as far as we've got.

Re: Implementing Traction Control for an advantage in the 2009 game
 

You could use voltage and current feedback from the motors with the analog sensors currently available. Through test trends would appear when the wheel lost traction, possibly a spike in amperage. Also if the wheels are independently driven you could use encoders and compare the rotation rate of wheels being driven similarly so if left front and right front are both moving forward, but left front is slipping the rotation speed of that wheel should be faster.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I looked extensively in to optical mice last year however they do not work at high enough speeds to be feasible (even for this challenge) if you find one fast enough please inform me but the best i could get was ~5ft/s before it losses all idea of whats going on.
I realize this may be a pain (mostly for the mechanics) but the easiest way to determine wheel slippage is to compare the speed of each wheel to the speed of an driven encoder wheel next to it. Or (since the robot moves as a whole) you could get away with three encoder wheels telling you how the robot is moving and do some calculations to figure out how each wheel is moving.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Perhaps a rate limit between the joystick reading and the pwm requested, will be helpful.

Re: Implementing Traction Control for an advantage in the 2009 game
 

solve for your current acceleration, using laws of motion, then compare with the accelerometer, using the derivative of the accelerometer data you can tell what speed your going, adjust motion for collisions, it seams helpful in terms of traction control.

Re: Implementing Traction Control for an advantage in the 2009 game
 

EricS,

We tried the joystick method and it works great. It was very simple to implement and we just wanted to see if it made a difference ... it does big time (as we expected)!

I do not think this is the best way as it does not actually account for actual wheel speed. Caution: this post might get a little long.

First, a description of what we did. We forced the maximum PWM input change from the joystick from one time step to another to be a certain value (ours ranged from 1 to 10). We only had it working in the forward direction as we had a bug that made it not working in reverse (we were trying to do it fast).

When diving around on the actual surface with the actual trailer and wheels with the trailer loaded (about 40 - 45 lbs) here is what we found:

The "poor man's traction control" worked great except when you tried to turn the trailer and it took longer than the ramp up. The wheels would eventually break free and spin but backing off on the throttle would bring it back down and gain traction. I think people will be suprised when they see how much trailer weight affects turning performance. Anyway, it proved to us that traction control is a must.

In my mind there are 3 basic ways to do traction control this year:

1. Poor man's - as described above just control throttle rate.

2. Middle Income - Encoders on the driving wheels only. Control the rate of change of wheel speed (also known as acceleration) to match what the surface can handle.

3. The super rich - Do the same as number 2, but add a frame of reference like a non powered wheel or an accelerometer. In addition to controlling the change, you also make sure the wheel speed is close to the frame of reference speed.

Our team is leaning towards #2 and here is why:

1. As I proved in a different thread, the maximum acceleration we can have is equal to g*CoF, where g is the acceleration due to gravity and CoF is the coefficient of friction between the floor and the wheels.

2. Since this is a known quantity we can set the maximum wheel speed change per time step based on testing.

3. In addition, we can cap the maximum speed (if you think that is important.


If this proves to not be enough, then we will probably use an accelerometer as a reference.

Re: Implementing Traction Control for an advantage in the 2009 game
 

First off, thank you for the informative post and test results. Many would have kept this as an advantage.

Didn't your team use idle wheels last year to measure wheel speed? Did last year's experience influence your opinion so far?

Re: Implementing Traction Control for an advantage in the 2009 game
 

Methods for doing traction control:

1. Use what you know about the physics of your environment (open-loop):

1a. Limit acceleration of the wheel to the acceleration that provides the maximum tractive force. Works great in theory, but the dynamics of the robot (i.e. weight transfer from wheel to wheel when turning, irregularities in the wheel tread) make this style slightly unreliable. Still, it should be much better than nothing.

2. Sense the difference between your true robot velocity and your wheel velocity:

2a. Combine driven and non-driven wheels. Sense the speed of both. This will absolutely detect wheel slip, but you lose some downforce to the non-driven wheels.

2b. Use inertial sensors (accelerometer + gyro) to get your robot speed. The problem is that these sensors are noisy and will drift when integrated.

2c. Use a camera/mouse/ultrasonic range finder/RADAR/LIDAR to detect true robot speed. I've yet to see a reliable implementation of one of these methods on a FIRST robot, however.

3. There are other clever ways as well:

3a. Kalman filters are based on complicated mathematics, but can take different types of sensors with known uncertainty characteristics and fuse together their outputs to get a generally reliable view of the overall picture. This would be a robust way to use inertial guidance, for example.

3b. Even in a 4WD robot with 4 independently-powered wheels with encoders, you can detect (some kinds of) slip without the need for additional sensors. You know where on your robot the wheels are mounted. You can measure the speeds of all four wheels. If you examine the speeds of three wheels at a time, you can compute what the speed of the fourth you HAVE to be in order for there to be no slippage. You can do this for all 4 combinations of three wheels and deduce which wheel(s) are lying to you. If all four (or even three, and sometimes two) wheels are slipping, you're still out of luck, but if one wheel loses traction before the others, you will know.

---------

How much agility will we really gain with these methods on this floor? I don't know - but I do know that in the kingdom of the blind, the one-eyed man is king. A small edge might tip the balance of an otherwise level playing field this season.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I can't speak for 217, but one thing that scares me about non-driven wheels this year is that every pound of downforce on a non-powered wheel takes away from your maximum tractive force (and therefore acceleration). Does the loss of this force make up for the benefits of an otherwise simple way to get high-fidelity anti-slip control? I don't know.

Re: Implementing Traction Control for an advantage in the 2009 game
 

It might work better to use a laser mouse since it works on more surfaces and is more powerful