Implementing Traction Control for an advantage in the 2009 game

[FRC4ME]

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

[Paul Copioli]

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.

[lemon1324]

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)

[jreuter]

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.

[KilroyLaxer]

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?

[Gdeaver]

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.

[JesseK]

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

- edit - (like this)

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.

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.

[KilroyLaxer]

Originally Posted by JesseK

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

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.

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.

[MrForbes]

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

[thefro526]

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.

[dani190]

Originally Posted by squirrel

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

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

[Phazonmutant]

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?

[Doug Leppard]

Originally Posted by squirrel

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

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.

[rwood359]

Originally Posted by Doug Leppard

Now the driver never has to worry about pushing power too far, the computer controls that both in accelerating and de-accelerating.

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

[Jared Russell]

Originally Posted by Phazonmutant

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?

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.