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

A simple moving average filter of the joystick inputs works well. For those who are coding in C this isn't to bad an algorithm to code. There are a couple forms of moving averages to play with. The number of averaged samples and the sampling rate can allow tunning. For those using Labveiw it's real easy. Just drag, drop and wire. Play with the constants to get the feel you want. This is just controlling the rate of change. In Labview there about 5 filters that could be used however only 2 yield good results. The great thing about Labview is you can graphically watch the behavior. Our filter is working well and allows even the kids who are button smashers to drive. One thing is that it doesn't do as much good for is stopping. We always slide a little. I would suggest that all teams make an effort to apply some form of traction control. With out it it's going to be hard to play the game.

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

yes they do
correct me if im wrong but if you put a cim rotating clockwise on one side and vive versa the clockwise side will go faster therefore creating a right-handed turn

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

Actually, Alan is correct. The directional bias on a CIM, although not zero, is so negligible that it is almost unmeasurable.

What is far more common, historically, is that one side of your robot will have more friction than the other. However, this year we have added Jaguars into the mix. The neutral PWM for a Victor and a Jaguar are not the same and the software must match the hardware or you will see significant discrepancies.

Regards,

Mike

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

For people who are doing simple traction control by filtering the joysticks, are you all basically recording the last joystick value, and then comparing it to the current one, and if the difference is too large you'll cap it out at a certain maximum?

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

That's exactly what we're doing - I previously posted a VI that uses shift registers to compare the old motor output values to the new reading on the joystick - located at http://www.chiefdelphi.com/forums/sh...ad.php?t=73009

I think it's the simplest way to do it - thus far, it has worked quite well.

good luck,

Evan

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

It seems almost criminal not to mention that it's possible to take values from the drop in electrical potential from one side of the motor fuse to the other. After applying a physical or code implemented low pass filter, the value returned is actually just a flat DC voltage that increases proportionally to the current drawn by the motor. A bit tricky to implement, but as far as being "poor man's traction control," at about $2 per motor or less it'd be a shame not to try.

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

It's a great idea, but it violates the electrical rules. Custom circuitry must be powered through a circuit breaker. It can't connect to the battery side of a breaker. You'd need your own sensing element -- say, a foot-long length of wire.

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

Is it considered powered? Or is it basically like a potentiometer?

Argh.
<R46>
A. Each speed controller branch circuit must be protected by one and only one 20-amp, 30-
amp, or 40-amp circuit breaker on the Power Distribution Board. No other electrical load
can be connected to the breaker supplying this circuit.

<R44> Custom circuits shall NOT directly alter the power pathways between the battery, Power
Distribution Board, speed controllers, relays, motors, or other elements of the robot control
system (including the power pathways to other sensors or circuits). Custom high impedance
voltage monitoring or low impedance current monitoring circuitry connected to the ROBOT’S
electrical system is acceptable, because the effect on the ROBOT outputs should be
inconsequential.

<R66> Inputs to custom circuits can be connected only to the following sources:
A. Power Distribution Board protected 12Vdc outputs


The only real information I've found is in the "suggestions" PDF, and it just says to use good engineering judgment. Since the Analog breakout can handle direct motor current to measure battery level, engineering judgment tells me that it has sufficient internal impedance to handle this job without worry. The voltage I measure is maxing out around 60 mV, and since current isn't an issue..... :confused:

I think this has become a Q&A question.... ha. Then Again, maybe I'm overthinking this and it's just illegal, like you said.

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

On the current measurement front, just order yourself a pair of 620-1106-ND current sensors from Digikey and hook them up. This goes in line with the power leads to the motor and has three pins that you can hook your pwm cable to for the analog input. You can pot it in epoxy after soldering the wiring to it. You might want to filter the output of the sensor as it will follow the chopped current to the motor nicely.

Eugene

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

I'm wondering why everyone seems to be focused on measuring current. As far as I know, the equation we need (which calculates the amount of torque you are applying to the wheel, which cannot exceed the force of friction pushing back or you will slip) involves only voltage and angular velocity, not current.

http://www.gizmology.net/motors.htm

Could someone who is using current sensing in their traction control clue me in on how you are doing that?

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

Current is a function of wheel velocity. When the wheel begins to slip, the motor will spin faster and draw less current. As long the as change in current draw was sharp enough, I'd imagine it could potentially be simpler than measuring your velocity relative to the floor.

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

I think it would be so diificult to measure this acurately using current draw, but again maybe it is possible.

We have ATC using an encoder wheel on the floor. We found you can have 50% slippage and still have good traction. found 20% is best slippage for maxiumu speed and traction.

So maybe with that much variation using current it is possible.

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

I also discovered this. It was sort of disappointing. I applied postgraduate-level dynamics and control theory to create a mathematically nearly-optimal traction control system, then found that just low-pass filtering the inputs and outputs of my velocity control PID loop gave almost identical functional performance.

If anyone ever needs to kill a fly with a flamethrower - you know where to find me!

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

The current tracking is an interesting concept and maybe it will work when you are accelerating.

But what about decelerating? Slowing down in a controlled manner is just as important as speeding up. I am not sure how you apply current tracking to control slowing up. Possibly with some well defined current flow you could.

Like someone already asked, I would like to hear from someone that has already done it.

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

Almost correct.

Current is a function of wheel torque, not wheel velocity.