Implementing Traction Control for an advantage in the 2009 game

[MikeE]

Originally Posted by rsisk

Unfortunately I think this puts us in the 'tinkerer' category isn't the second first derivative of tinkerer = engineer once you add in the velocity heading towards being able to calculate the results?

Tinkerer + math => engineer

[Bongle]

We're going with a reverse-ABS route for our first attempt:
-If slippage detected, reduce motor power somewhat, then gradually increase it again

Slippage will be detected by comparing the reported acceleration of our encoders with the reported acceleration from our accelerometer.

[IKE]

For the Tinkerers out there. Please keep one thing in mind. ABS, ESP, Stability control..... All of these get tuned by very skilled evaluator/engineers. I have a friend who does this work for Bosch. Testing and tuning is not simply tinkering, it is engineering. They do however had a pretty good idea of what their algoritms need to look like and then tune them in.

IKE

[Adam Y.]

Originally Posted by MikeE

Tinkerer + math => engineer

This is the only field where being a tinkerer will mean that your robot will end up in twenty thousand little itty bitty pieces as it thrashes it around because your tinkering resulted in a system that mathematically would blow up the world (An Texas Instruments engineers words not mine) if it were not for the fact that your robot is powered by a battery.

[waialua359]

Our programmer challenged our 2 year driver to try and beat the traction controlled robot from one side of our field to the other.
The driver lost EVERY time!!

In conclusion, implement it if you can........

[DonRotolo]

Originally Posted by rsisk

We use a potentiometer to measure the rate the wheels are turning.

A potentiometer? Not exactly an optimal sensor, look up "encoder" for a better choice

Originally Posted by rsisk

first derivative of tinkerer = engineer once you add in the velocity heading towards...

Originally Posted by MikeE

Tinkerer + math => engineer

The difference between a Tinkerer and an Engineer is that the Engineer will be able to tell you the results before you start.

[Rick TYler]

Originally Posted by Don Rotolo

The difference between a Tinkerer and an Engineer is that the Engineer will be able to tell you the results before you start.

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

[Mike Betts]

Originally Posted by Rick TYler

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

Rick,

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

Regards,

Mike

[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?

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