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

If a laser mouse uses a real laser, you should search the rules for the word laser.

I was pleased to see that my idea of using an optical mouse had already been thought of, and even tried, and found to be not effective at speeds > 5f/s. Now I don't have to spend the time to try it myself.

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

Jared this was helpful.

How about tracking the speed of a wheel and when the speed greatly increases more than normal what is expected bring the power back.

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

That was my thinking too - monitor the second derivative of wheel velocity. I'd expect this to be fairly noisy but usable with some filtering. I promise to report back red-faced if it's a dismal failure.

Out in the open field away from carpet, I think we'll be facing the situation where several (all) wheels will slip simultaneously, but many of the standard workarounds seem to assume single wheel slippage. (Obviously at high enough sampling frequency one wheel will be the first to go.) I see an integrated approach (pun intended) as the way to go.

And thanks to all for a very thought provoking thread.

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

This would work, as it would limit the acceleration of the wheels. If you are measuring the speed of the wheel, then the derivative of that value (the rate of change) is the wheel acceleration. The wheel acceleration can't exceed some absolute threshold, otherwise the wheel will slip.

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

I think you meant first derivative of wheel velocity (or second derivative of wheel position). This is your acceleration.

Here's the rub - encoders are digital sensors, with limited resolution. The "derivative" operator is continuous. You can approximate the derivative with the "difference" (i.e. accel = speed - last_speed), but this is only ever an approximation.

Luckily, the straight difference isn't the only way to approximate the derivative. For example:

accel = -last_last_speed + 2*last_speed - speed;

This is a smoother derivative approximation, but it is now time-delayed (since it is centered around the time of last_speed). This is the tradeoff of filtering - with smoothness comes time delay.

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

What I am planning on doing is finding what would be the best (on a linolium floor; Bill said that that would work) or at least have average results; we (programmers) were told that we would have "enough" time to mess around with the robot and see what works, and we DO know the coefficiants of friction and the weight, so we could change it based on that (we also have a few engineers that have been known to understand these kinds of things..... You know; something about a college degree...... :rolleyes:)

We have decided (or at least the programmers have) that it would be best to have a steady number, instead of sensors.... You know; ease and all that jazz..... :D

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

LabVIEW has some really helpful filtering VIs under Signal Processing -> Filters. It may be worth while to use these to implement higher order filters easily. For example, using a band-pass filter may be an easy way to detect sudden changes in wheel speed.

Every time I think about trying to compare the past to the present I think about filters.

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

No, I actually did meant the second derivative, or more precisely the change in the first derivative, i.e. looking for a sudden increase in acceleration as an indication of slippage.

I haven't thought through the resolution necessary to get reliable performance, but I am certain that processing power won't be the limiting factor.

And I agree with Eric's comments about Labview. I've spent too much of my working life re-implementing signal processing code to want to do it unnecessarily.

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

My one problem with this idea is what do you bring the power back to and now what is normal speed to track against now since it has slipped. Maybe it is the speed before the wheel slipped.

Our team is first going to ramp up power as first step. I would like to see a graph of a wheel speed as it is going normal then slipping. Maybe analyzing the graph you can use that to predict slippage and bringing it back to non-slip.

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

You're a jerk!:)

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

To answer the earlier question, what we do on carpet is use an idler wheel on a spring connected to an encoder. this will not really take away from normal force (very, very small spring load) but we are concerned this year that we have to use the actual wheel instead of a small wheel and that the low friction will make that one slip too.

The time step (or ITP time) for the cRIO is ridiculously small so we are using the simple difference and will use the labview filtering if we have to.

I can tell you the simple joystick filtering works way better than I thought, but will need a lot of manual intervention in a pushing match.

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

The first Q/A answer is in, and it's a good one. We do not have to use a rover wheel for an idler wheel. http://forums.usfirst.org/showthread.php?t=10917

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

This was an answer I did not expect. Well then - this becomes the most attractive of the various slip detection strategies in my mind (since you can get away with negligible downforce). Keep in mind that the poster of this question talked about a freely rotating caster - non-rotating casters would indeed provide turning resistance (even if slight) and might not be covered.

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

Most would say you need an unpowered wheel (and now that a speed sensor is legal, it seems to be the simplest method), but consider the case of a 4-wheel drive vehicle that has implemented traction control. The answer given by MikeE is similar to what is used in the real world. Yes, there are some considerations regarding the effects of the motors on speed, but if we assume we know the input (i.e., PWM value to the motor) we can use that to filter out those effects from the output (wheel speed second derivative)

You can also set a maximum allowable acceleration using an accelerometer. Discount the occasional collision of course, and make it easily disabled for those cases where you have that sliver of carpet under your wheels.

However, Paul Copioli mentioned that joystick control is effective, and I tend to favor the simple solution. And we'll disable that when the trigger is pulled...

Exactly the second derivative of wheel speed - the rate of wheel acceleration.

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

Thanks Don for starting this discussion it has helped a lot.