2809 - Traction Control Demo
 

Video: http://www.youtube.com/watch?v=l1Qk2YPdCY8

Hi All,

So, here's are preliminary traction control demo. Don't mind the flooring or the two very dillusional people muttering away.:ahh:

Cheers,
M_M and JNo.

Re: 2809 - Traction Control Demo
 

That's pretty neat. Quite cool.

How are you guys detecting a loss of traction? Encoders are my only guess...

-Tanner

Re: 2809 - Traction Control Demo
 

Yep, there's an encoder in the system. Actually there's two, and some secret sauce.

It's amazing how 2 years of kinematics can actually be applied to real life.

And no, there's no accelerometers, or idle wheels.

M_M

Re: 2809 - Traction Control Demo
 

Wow, very amazing guys. I'm not even sure how we would do that...

Thumbs up to ya'll! Good luck with it.

-Tanner

Re: 2809 - Traction Control Demo
 

Thanks!
You too.

M_M

Re: 2809 - Traction Control Demo
 

That's sick.

Someone deserves a high five.

*High Five*

Care to elaborate on the mechanics and the programming theory behind it?

Re: 2809 - Traction Control Demo
 

Already Done.

Re: 2809 - Traction Control Demo
 

Helloooo from the North East:D
Oh Boy that is a great job........ DRIVE the bot and lots of great times will be ahead for your Team ...:yikes:
GOOD LUCK in 2009;)
MOE and Team 88 TJ2 TYE DYE for ever oh yeah ???? OH YEAH !!!!:o

Re: 2809 - Traction Control Demo
 

Well, I'd love to tell you all exactly how this was pulled off, but I'm honestly not sure how much detail I"m allowed to reveal. (We haven't had a discussion with the team about this yet, so I don't want to jump the gun.)

Here's what I can tell you though:
- We use two encoders, one per side, in addition to another type of sensor.
- We found the accelerometers WAY too noisey, especially with the bumpy playing surface.
- All four (well, 3 and a bit wheels) are driven, we have no idlers.
- Haven't worked out (unfortunately) how to implement any type of optical sensor to figure out linear velocity. [I'm convinced those new-fangled "gamer mouses" would work, but we don't have the $$$ to test this theory.]

That video is no where near the final product btw. We have to calibrate and optimize for the playing surface and the weight of the trainer.

Anyway, I'll tell you what I can. Please feel free to ask quesitons. If anyone can guess what we did I'd be happy to PM you with our solution. It can be a game of sorts.
BUT, I'll probably have a white paper drawn out by our first regional (Toronto) and it'll be posted for all to see.

M_M

Re: 2809 - Traction Control Demo
 

I'm glad to hear that you won't be littering the field with wheel spinach. I don't think the Swifter would be much help in cleaning up that kind of mess!

Seriously, that looks like a really good traction control system. From the demo it looks like the robot is a lot easier to push around with the system turned off. Is that true?

Re: 2809 - Traction Control Demo
 

Great Job Team!!

Very Impressive

Re: 2809 - Traction Control Demo
 

This is the most efficient and incredible traction control system our team has ever seen. We would like to use the encoder as well to assist in our traction control. Can you help us?

Re: 2809 - Traction Control Demo
 

Sure, what do you want to know?

Re: 2809 - Traction Control Demo
 

wow guys well done...

Is there any way you guys can share that and help us out?

Re: 2809 - Traction Control Demo
 

We would like to use the encoder to measure the rotations of the wheel per second then multiply by the radius of the wheel in order to find the distance the wheel should be traveling (theoretical distance). Then we would use another sensor to measure the distance our robot has actually traveled. If the actual distance is less than the theoretical distance our wheel is slipping. Do you have any suggestions on the sensor we should use to measure the actual distance traveled or any suggested code we could use in order for the change in speed of the motor, in turn lowering or speeding up the rev/sec., to be automatic?

Re: 2809 - Traction Control Demo
 

that robot looks a whole lot better than my team's rookie bot

Re: 2809 - Traction Control Demo
 

Does your ystem work for acceleration as well, or just shoving? It would be nice to see a comparison of acceleration with and without TC. The pushing thing--it looks nice, but have you collected more empirical data than "he stumbles back more with traction control on"?

Re: 2809 - Traction Control Demo
 

Really impressive - I'm really looking forward to watching these bots in action! In what language did you implement the traction code?

Re: 2809 - Traction Control Demo
 

Well, if I had to hazard a guess at what that other sensor might be, I'd be willing to guess that it is a current sensor. Since torque is proportional to motor current, you could monitor the current draw of your motor to determine at what torque your wheels started to spin, then put in some fairly simple code to limit current to that maximum amount.

Not sure why you'd need encoders with that setup... hmmm.... perhaps rather than measuring current, you are measuring voltage across the motors and comparing it to motor speed.

It looks like Ontario has spawned another great team. Good luck at Hershey Centre, GTR is a great tournament.

Jason

Re: 2809 - Traction Control Demo
 

If you listen to the audio on the video you can hear the traction control at work. With the TC off you can hear the motors whirring away and the wheels spinning even when the robot is held stationary. With the TC on you can hear that the sound is very different, the wheels are not spinning even though the robot is being told to go forward, but held from doing so.

Re: 2809 - Traction Control Demo
 

Yep, the robot is just pushing, and will even compensate when you push back on it. The issue we found is that once you start slipping, it's really easy to move you around.

Hopefully we can get another video up when we test on the playing surface tomorrow.

Re: 2809 - Traction Control Demo
 

The method you're using appears to be the TLS method, in which the speed of the driven wheels is compared with the speed of the undriven wheels. However, since no wheels are idle than there must be another way of sensing your speed. You aren't using an optical sensor or an accelerometer, and ultrasonic sensors would get too much interference from other robots.

My only other idea would be attaching a free-swinging pendulum to the robot. An encoder or Gyro attached to the axel of this device could then be used exactly the same as an accelerometer but without the noise. This does seem like a lot of work though. Does anyone else have a simpler solution to detecting speed?

Re: 2809 - Traction Control Demo
 

Here's a hint; you don't need any bearing at all on the robot's position, speed, or acceleration to prevent slipping. You don't need current sensors, either; just an encoder on each drive wheel.

I assume 2809 is probably doing what we're doing this year. More details to come on Monday (if it works).

Re: 2809 - Traction Control Demo
 

We are using a torque sensor on each wheel. You can only apply so much torque to a wheel before it slips. Since everything is constant (robot weight, playing surface, wheel, ...) then all you have to do is apply power to the wheel till you reach a predetermined torque target and the wheel will not slip and you will approach max acceleration and pushing power.

I don't know if this is how you are doing it, I am guessing, but that is what we are doing.

Re: 2809 - Traction Control Demo
 

Torque sensor eh? For curiousity sake, how do those work in your system?

Re: 2809 - Traction Control Demo
 

Dude, that sounds WAY complicated. The trouble we're finding is that with the bumpiness (is that even a word?) of the surface, anytype of sensor like that creates (or created in our case as we stayed FAR away from it) a lot of noise. Never thought of a pendulum though, that would be kinda neat. But again, with the vibration I feel like the dampening system would need to be quite intense.

Re: 2809 - Traction Control Demo
 

A torque sensor? I never thought of that. May I see which particular sensor you are using?

Anyway, it turns out the torque a DC motor produces is related only to the voltage (effective) you are sending it and the rpm of the motor. We measure the rpm of the motor with the encoder, plug that into the equation, and get back the maximum voltage we can send without causing enough torque to slip.

The beauty of the system is that it involves no PID loops, no tuning, no trial-and-error. We have about 15 measureable constants and 2 measureable variables (battery voltage and motor rpm), but nothing needs to be manually tuned. Yay for physics.

Re: 2809 - Traction Control Demo
 

Yeah; my team also gave up on the accelerometer after one day of testing. The noise is too high for any integration to be useful at all. If you tilt the thing one tenth of a degree, it will within seconds think the robot is driving across the floor at 12 ft/s.

Re: 2809 - Traction Control Demo
 

I feel like you'll also need current.... see the power equation.

And no PID? Are you just doing direct drive with a variable cap? (To hold the torque.)

Re: 2809 - Traction Control Demo
 

I've always found model based control systems to be kind of a crapshoot. Maybe its just me though.

We found follower wheels to be the optimal solution. It may not have the best results, but its a simple system thats easy to integrate and works good enough.

Re: 2809 - Traction Control Demo
 

My question with the follower wheels is how well it works when you're driving in a hostile environment with lots of bumping etc.

Re: 2809 - Traction Control Demo
 

My team's traction control design works in 2 ways:

We have 4 encoders total, 2 on free-rolling wheels and the other 2 on drive.
The (open-loop) system for "slip prevention" maximizes the wheel torque (motor power) based on the robot's actual velocity (from free wheels) according to an equation that we found empirically. This ensures our applied power will never slip no matter that external forces hit us (and extreme joystick inputs applied).

Our 2nd (closed-loop) system for "slip recovery" detects slip (that is, rotation rates of powered wheels vs free wheels) and proportionally steps down the power accordingly until the slip is gone.

End result? Today at our scrimmage we never slipped with traction control.....but we were pretty slow and underpowered. Any quicker and we start to slip. For better or for worse I suppose.

Re: 2809 - Traction Control Demo
 

my guess is these guys do double differentiation on the encoder position to get acceleration, and basically make sure they aren't accelerating beyond a certain value.

or you could do an extrapolation of acceleration of some sort, and look for a discontinuity as a result of wheel slippage...

hmm

algorithm devising at 5am doesnt work well.

Re: 2809 - Traction Control Demo
 

Well the 2809 'bot is just hours from being boxed & shipped, and it appears the only thing not slipping is mike's tongue in regards to how he and the kids pulled this traction control off. it's a sweet set up! it is incredible what you can achieve with fiberglass magnets.

I have to take my hat off to this rookie team...Great Job!!

Just wait 'til we show you the automated range finding and the 3-point shot.

Jeff

Remember the Avro Arrow!
Develop & Keep Engineering in Canada

Re: 2809 - Traction Control Demo
 

I admire your modeling capabilities. We use a simplified version that allows for real time adjustment of the static torque limit and then rely on a slip speed to modulate this limit. The slip speed is derived from reference wheel encoders on each side.

It has always been my thought that teams that stay under the static coefficient will do better than those who modulate between the static and dynamic coefficient using slip detector. So we strive to stay under the static torque limit. In case we do slip due to unpredicted loading conditions and external forces, we then bring in the extra reference wheel to sense wheel slip and modulate between the dynamic and static coefficient torques. This helps with maintaining lateral stability since when wheels slip, they usually break out at different times and cause turning moments.

The modulation is done by simply adjusting the static torque limit by a fixed factor about equal to the ratio between static and dynamic friction coefficients. Encoder noise is a concern since the normalized limit is about .1 or only 10% of the maximum command. We are prepared to close a PID loop outside of the torque limiter functions if need be..but so far seems ok without it.

We simply use Ke(motor back emf constant) to determine the maximum speed of the motor at 12 volts. Then we normalize the driven wheel speed with the calculated max speed and compare it to the commanded speed and limit the command so the difference does not exceed the static limit. This static limit is adjusted by the driver with the throttle input control to match the surface conditions of the day prior to the match. Voltage compensation is also used.

We considered using more parameters, however, it seemed that drive train torque loss variations with speed , resistance changes with temperature, loading condition variations would be a bit too much for us to model.(f even possible. )

Besides, since our wheels cannot crab, any turning puts us in a side slip condition so the best we can do is the dynamic coefficient during these times which would probably be most of the match. Any modulation of the wheel torque during this time would result in a slightly lower acceleration than the dynamic coefficient would allow (at least thats my current belief). So, not too sure that the torque limiters are worth the cost...except for maintaining lateral stability, but one could do this with just a heading rate hold loop. However, good strategy can extend the non-turning phases of the match and the good traction control people might have a few feet advantage in a drag race with those that don't have it.:)