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

LabVIEW has a "Range and Check" (or something similar) block which allows you to cap a value to a range and/or check if it is in that range--may be useful to your purpose.

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

Thanks, thats what we ended up doing.

----------------
Now playing: The Police vs. Rick James - Put On The Super Freak [Leebuzz]
via FoxyTunes

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

A mechanical lowpass filter should theoretically help:
tightly couple the accelerometer to something massive (like the battery) and loosely couple that mass to the frame (mount in spongy foam).

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

Until something goes all nonlinear on you -- then the Tinkerer with the duct tape gets you home.

I recommend "To Engineer is Human: The Role of Failure in Successful Design" by Henry Petroski for some good cases where engineers learn from the unintended consequences of engineering inadequately foretelling the future.

(And I know you know this, Don. I just love the idea of Red Green backing up engineers with his handyman's secret weapon.)

(Although My Father the Retired Aerospace Engineer swears he never built anything that didn't have "Missile Tape" on-board somewhere.)

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

Rick,

I also have this book on my shelf. An excellent read...

Regards,

Mike

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

I'm going to chime in here and say something that's been on my mind. Perhaps it has already been mentioned.

The coefficient of static friction of the rover wheels is 0.06.
The coefficient of kinetic friction is 0.05.

So, if we spend our six week build season implementing traction control, is it really worth it for an extra 120lb * 0.01 = 12lb of frictional force?

Or am I oversimplifying the physics...

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

One thing you must consider is that the dynamic coefficient of friction is actually related to speed. If you spin your wheels fast enough, your dynamic CoF will go down. If you are constantly spinning you will be pushed around by those that are not spinning their wheels.

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

The other thing to consider is that many people here on CD have been getting static/kinetic ratios much higher than the FIRST-published values.

Even given .06 against .05, it is a difference of 17-20% tractive force(depending on your reference value)

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

If all we were worried about was linear accelleration, I've also wondered whether a 20% improvement is worth the complexity you add. However, there was a compelling post by one team who measured a 50% increase in turning time when slipping vs. when not slipping wheels.

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

Ok, so first off i'd like to say I'm diggin' this thread. I <3 this thread.

Now down to business. So, my team thought up traction control once we found out the game. We thought about having pulsing wheels that are activated off of the controller and having the z-axis control how long the time is between pulses. And we have that working, BUT unfortunately that was based upon the assuption (or lie) that we had free spinning wheels on the bot,and of course with my luck, we do not. Now, we thought instead of using an accelerometer and graphing its outputs to determine the greatest amount of acceleration before slippage (usually occuring at the beginning, also known as breakaway friction.) and using it as a point to reach complete controlability for one half of the pulsing and the other being to run both wheels at a very low input. And of course, with my luck, when we do graph said acceleration, it has impossibly tough-to-tell results. So, i have a couple questions. 1. Does anyone know how to make a working graph that would average out the noise we have and give us a good base reading? 2. Is there any other way of working this only using the accelerometer?

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

Our team has impemented filtering of the joystick inputs. While not as good as sensor feed back type traction control, the improvements are quite obvious. It's also less complex. For those who are using sensor feed back remeber that the control loop is going to be disturbed heavily by impacts.

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

Are there any teams who are doing driver-based traction control?

- edit - (like this)
I.e. rather than a direct 1-to-1 magnitudal relationship from the joystick to the motor outputs, there is more of a geometric or exponential scalar applied? That way, the motors really only apply the full torque when the joystick is out on the perimeter, whereas halfway the software only sends, say 20% torque. Drivers could learn how and when to slow things down vs. the software doing wonky acceleration/decceleration 'detection' algorithms that are hard for the drivers to get used to.

Maybe it's dependent upon what the drivers are comfortable with, but I would think that I could 'feel' the way the robot handles alot faster and better than software could, and with alot less hassle. I mean, true slip detection is very hard to add in to a control algorithm if you don't have all independently-controllable wheels, or at least have electronically-controlled differentials in between them...and proper weight distribution plays a huge role too... Maybe that could be a new 'control' feature -- a force-feedback system that the driver wears to physically simulate the g-forces on the robot.

Hmm, maybe it's just me and my racing experiences talking here, and the fact that I'm a control nut when it comes to my car.

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

Lol yeah, for the efforts of being lazy, that was my first suggestion, but everyone else decided we wanted "intuitive" controls, or in the words of one of the team members " We want this robot to be able to be driven by a ferret." So, yea, more work for me.

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

Has anyone tried simply detecting a sudden increase in drive wheel speed and modulating motor control based on that? I'm dying to see if it'll work for simple straight acceleration....haven't conned the electronics/programming team into getting the encoders wired up and trying to write some code yet...

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

I think this was mentioned above but I'm not sure. On my team we discussed having a progressive acceleration function where it would limit the acceleration of the bot. We were thinking that if the driver went from zero value to a full throttle the code would progressively accelerate the wheels up to the desired speed. We think it'll work but if not we may pursue something else.

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

I will try it when i get into the shop today. Il try and post back when i can and give u guys an update on weather or not that works...

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

Just read over the thread, here's some thoughts from a 2nd-year team member: (warning, long)

1) For the teams that don't have mentors experienced or trained in engineering, it's difficult to understand how signal processing and sensors play together. For example, I've never even heard of things like high-pass or low-pass filtering - I thought accelerometers returned pretty decent values. Therefore, it seems like what we're going to go for is the simple solution that's been mentioned - limiting the rate of change of the joystick.

Regarding that, if you dig into the Jaguar.cpp class, the SetSpeed method (I believe) has an exponential curve implemented by default. It shouldn't be too hard to modify this to have a variable curve.
Specifically:
The Atack3 joystick has a "throttle" knob below the joystick. In the default code, this switches between Arcade and Tank, but I'm pretty sure custom code won't do this (haven't actually checked though). If that's the case, it should be simple to have the knob set a curve power that you pass into the SetSpeed method.

That may be a little unclear, so just to explain - the SetSpeed method essentially performs this function on the passed speed:
f(x) = x^p,
where x is the (passed) speed and p is the passed power, f(x) is the speed going to the motor.
By default, p=2. The knob could set this to be anywhere from 1 to say 5. The slope of this curve will be increasing for p>1. As p increases, the slope increases faster; that is to say, the second derivative of f(x) is more positive.

If I understand the formula correctly, though, you'll need to add a coefficient for each p that fits the curve to the 0-255 range that the jaguars can accept. However, the SetSpeed method is called for both autonomous drive and teleop (which raises the question of why there isn't the coefficient...). So, given that the joystick ranges from 0-100 on a given axis, you'll have to adjust the passed speed in the Drive method. I haven't quite worked this out, but I think the basic concept is sound.

Theoretically, the benefits to this approach are (a) a simple-to-understand and code change that can (b) produce a much more fine-tuned traction control system that doesn't involve complicated sensors.
Also, this would be simple enough to code for turning, too.

2) Our team considered having the wheels mounted on two axles that pivoted opposite of each other (ex. front turns clockwise while the back turns counterclockwise to turn the robot right), but after calculating the turn radius (especially with the trailer), it wasn't deemed worth it. Has anyone actually built something like this?

3) Just to clear up some confusion regarding the "minor" gains from traction control: Other people have pointed out that just looking at the difference in dynamic and static friction is oversimplistic, but that's not even the main reason to use traction control. Wheels deliver negligible power when they're slipping, so the main goal of a traction control system is to limit slippage. This has the benefit of improving handling.

4) If the accelerometers are noisy, wouldn't differentiating their output to get jerk result in even more noisy data? Also, question for those who don't have a problem with noisy accelerometers - do you buy custom ones?

5) Would calibrating the motors result in increased performance? How would one go about that?

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

This is what we have done. that was the reason for our three wheel bot proto type that I posted.

We allow up to 20% slipage of the drive wheel, if it goes above that the computer backs off the power.

Now the driver never has to worry about pushing power too far, the computer controls that both in accelerating and de-accelerating. I saw the test bed this weekend, pretty cool.

We haven't put it in the four wheel bot yet, but I suspect it will help our turns also.

I think the bots are drivable without traction control, but it makes a big difference and takes the load off the driver.

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

I haven't figured it out yet, but I'm having more trouble controlling deceleration than acceleration.

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

1) I don't think that this system as I understand it would actually implement any "traction control", per se. Rather, it would result in a different mapping of joystick position to motor speed (which may or may not be helpful). But throwing the stick forward will still result in slip.

2) Yep, this pic was posted not long ago: http://www.chiefdelphi.com/media/photos/32590

3) This is true. Traction control will affect your overall acceleration ability, but handling is usually the bigger benefit.

4) Yes, differentiating a noisy signal will give you garbage. Differentiation is essentially a high-pass filter, and "noise" tends to be high in frequency.

5) Calibrating the speed controllers will help your motors to behave more linearly. This will help ensure that any assumptions you made about their dynamics are closer to reality. That said, all of the speed controllers should come calibrated.

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.

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

Daniel is wise, you should pay attention to him.

Eugene

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

Doug-- Because of the weird resonances between the pwm outs and the motor kick-back, the amperage ranges wildly as you accelerate and decelerate, making it tricky to determine slip. You could potentially compare the values to a baseline, and if it's higher or lower adjust the pwm output.(baseline determined in conjunction with accelerometer...?)

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

That is why I think it would be difficult at best. We use an undriven wheel with an encoder to test agaisnt the speed of the driven wheel.

I would like to hear about someone who had used tracking current and how it worked or didn't work.

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

So, you guys appear to have validated the following file attachments obtained from some of my colleagues who are presently enrolled in an Hybrid-Electric vehicle class at UofM-Dearborn.

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

I love it when science works right!

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

What is surprises me is that the difference between asphalt, wet asphalt and regolith is about the same for the slippage factor and traction. You would think it would be a greater difference between surfaces.

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

If you could accurately measure average motor current, and therefore motor torque, given the typical longitudinal traction curve shown in the plot posted earlier, just what would you be inspired to do?

Eugene

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

Correct me if I'm wrong, but I believe that this works:
I'd make a table of a few test values, finding the current draw at various pwm outputs with no slip, and then have my program look for a result that was more than twenty percent less current draw than the values in the table. Since speed and current are inversely proportional this should mean that the motor is spinning more than 20% faster than normal loaded speeds-- hence spinning out. I'd then have it decrease the wheel speed(move the pwm output towards neutral), and then check the wheel for slip again, adjusting as necessary until 20% slip was achieved. Sort of a recursive algorithm.
Basically, since the current draw means nothing by itself, test values must be taken. They probably even vary from motor to motor.
And as for decelerating.... I think that has to be a joystick filter thing. Not much you can do with currents alone.


By the way Eugene, thanks for the current sensor tip. I'm still checking the legality of my method, but it looks like the output from those ICs will even work with the program we have(just new test values). :]

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

Don't you just want to maximize torque and let the wheel slip
take care of itself? Imagine your self somewhere on the x axis
of the first curve and adjust the motor PWM drive (which will
adjust the slip) in the direction of increasing average current.
Where do you end up?

In the case that you want a specific torque that is less than
the maximum there are two spots on the curve and you might
prefer the one on the left.

Why is the situation any different when braking, as long
as the current is going through the current sensor?

Don't forget to install a suitable RC filter on the output of the
current sensor. For Jaguars with their very high chop rate
it might not matter. For the Victors that chop at 120 hz it will
matter...

Eugene