Wheel Speed Sensor Setup (for TCS)

[Micko..]

We're setting up a traction control system on our car, and are trying to determine the best way in supplying the front wheel speeds to the ECU. There is a speed sensor on each wheel supplying pulse outputs, and our ECU is a Dragonfire, which is a first off prototype, where the traction control function has not been used before.

Our problem is that we're not sure whether to supply the ECU with the average front wheel speed, or the fastest, or slowest, or what? Whcih option have people found works best? How do commercial TCS do this? We're using a spool at the back, so rear wheel speed pickup is not an issue.

Thanks in advance.

[Erich Ohlde]

I would use fastest front wheel speed. Your front wheels aren't being driven, i'm assuming, so the fastest front wheel speed should show actually vehicle velocity.

[Chris Boyden]

There is a speed sensor on each wheel supplying pulse outputs, and our ECU is a Dragonfire, which is a first off prototype, where the traction control function has not been used before.


National semiconductor makes a frequency to voltage converter that will accept the wheel speed frequency input and output a voltage proportional to that. At the back of the LM2917 datasheet, there are three circuits that describe how to do the three functions you described, if you already haven't figure that out. I have not implemented a TCS, but I would venture to guess that the critical speed would be the high speed wheel. If you are in a turn, and the weight transfer puts more load on the outside tire, which is turning faster, that it would be more important than the slower and unloaded wheel. However, the unloaded wheel is still providing grip, so the average may be better. I dunno? If you wanted to try all three, slowest, fastest, and average, you could use a three position switch/analog mux to select the function you want to test.

DataSheet Link: LM2917 (http://www.national.com/pf/LM/LM2917.html)

[Garlic]

Axle speed is what you really want, you can do it with front wheel speeds, a steering pot, and a math channel.

In lieu of that, I'd use fastest, as the inside will be more likely to lock.

[Z]

I am curious to know how many teams have accelerometers ("G-sensors") in their electronics packages? If so, does anybody use these for their traction control. Ie. if the engine/rear wheels are turning faster than the accelerometer says the car should be going, then cut power. An accelerometer built into the ECU box might be easier to do and more reliable than wires going to sensors on the front wheels. It might also be more accurate - a driver resting his foot on the brake pedal might lock the inside wheel (when it is off the ground during corner exit) so that average front wheel speed measured is only half of true speed.

Accelerometers can also be used to measure yaw rate for "Stability Control". Six accelerometers, suitably positioned, can track all motions of the car.

Z

[Garlic]

Response time and accuracy (of measuring car speed) make accelerometers a very poor choice for traction control. You need much better resolution than that! If you have both, compare the two-night and day. They do make good means of fine tuning your wheelspeed based algorithms, as you can change gains or targets based on lat or long accel.

You can write some real simple codes to deal with one wheel lockup and the like.

tooth-triggered speed sensors are some of the most reliable out there. They are also super cheap. They don't drift, they don't offset. If they break, they generally stop working- they don't give erroneous signals. Brake heat is a minor issue on these cars.

[Garlic]

However if you are really against wheelspeeds I'd say an optical sensor would not be a bad choice. Although I'd still like to know what my front tires are doing.

[Chris Boyden]

what happens if an optical sensor gets mud on
it?

[Garlic]

Not sure if I was clear on my previous post, I meant an optical sensor on the chassis, pointed at the ground, to measure overall vehicle speed.

As for 'mud', well I can't imagine how you'd do that. There are optical sensors that handle rain and dirt just fine. If you are getting into mud you have more problems than traction control. http://fsae.com/groupee_common/emoticons/icon_wink.gif
Common sense and good mounting, shielding, etc will prevent any issues there... I'm sure teams have run them, as well as IR sensors that also can't be blocked, with no ill effects.

Of course like I said I think wheelspeeds are still more robust and accurate than optical, just that optical would be better than using an accel.

[Z]

Garlic,

My thinking with the accelerometers was that they could be built-in with the ECU, so no connectors, wiring runs with dozens of cable-ties, holes-in-chassis, etc. Also the acc. doesn't have to "see" anything (except "inertial space") so no problems with mud-in-the-eye, or rocks-in-the-teeth http://fsae.com/groupee_common/emoticons/icon_smile.gif. (I'm thinking about their application off-road - where mud and rocks are standard.)

Do you know, or can you point to, the response time/(in)accuracy/cost of accelerometers? Also, what sort of signal do they put out?

Z

[Garlic]

Yea for sure accels can be a hands-off prospect, and can be placed almost anywhere. I highly recommend them; they are very useful for all kinds of things. Just not something like Traction Control. At least, not cost effective.

Sorry Z, I can't quote exact numbers. I work with this stuff all the time, and although I wouldn't ever say for sure (technology moves pretty quick), it wasn't long ago I was involved in a project to do just this sort of thing. You can get wheelspeed type sensors for a couple bucks, double that for something really good. A real reliable accel that is robust and samples fast enough that you can filter it's signal to something usable and still reacts well will cost you over $100, maybe double that.

With a wheelspeed, dust dirt, hell it can even operate underwater, doesn't matter. They are awesome little buggers. And all you need are two teeth of rotation, and you've got a basically instant speed to look at.

Don't let me totally discourage anyone, like I said technology moves fast and this is the place where you have the opportunity to test out new things... but keep all the pros and cons in mind, and hopefully I've helped show some.

[Chris Boyden]

With a response time of ~3 ms = 1 / 350 Hz BW
for the accelerometer, I don't see why wheel speed sensors are that much faster(assuming math is right).
Assuming 20" tires, you get roughly 2.76 Hz wheel rotation/per mph.
10 mph 27 Hz
20 mph 55 Hz
40 mph 110 Hz
80 mph 220 Hz
Now multiply this frequency by the number of teeth on the wheel to get the input frequency.
with 2 teeth, you don't get that much faster or more resolution even at 80 mph 440Hz. More teeth could definitely help with resolution and overall bandwidth. It doesn't seem that much faster to me, unless you start adding more teeth. filtering (integrating) the accelerometer will slow it down, but even with that are they that much slower? How fast is fast enough ?(ecu response time, tcs response time, etc)

How would one go about designing a controller that would cut spark/fuel based off of an acceleration set point. Without speed inputs from the wheels and rpm, how do you decide which side of the tire curve you're on? If you've applied too much torque and slip is past the point of max grip, how do you know if you're not applying enough throttle to max out acceleration, or if you are applying too much? Would you have to keep track of the slope of the acceleration(jerk) and the peak of the accel. Then you'd have to cut power when you've past the peak accel. With wheel speed sensors, you can base slip off of the difference between from and rear speeds. It seems like the signal processing of an accelerometer only system would be tough, yet conceivable. Either one would be fun to try.

[Garlic]

Two teeth on a wheel trigger would be senselessly limiting yourself. What I meant was it takes two teeth for the sensor to be able to compute speed... That should be just a couple inches on a FSAE car. Not a full rotation of the wheel. Wheelspeeds start limiting you when you go really fast, and you have too many teeth. FSAE cars have such a limited speed range that

Accels might be good for launch control, because wheelspeeds have low resolution at <5 MPH, but you don't really need any feedback for that anayway. Most ECUS use a RPM limiter for a short distance then taper into traction control.

There may be an accel capable, but it won't be cheap. Either way a good car should have both, at least for testings. Because accels are invaluble and wheelspeeds are cheap and easy. Then you can compare the two if you like!

Problem is this is fine tuning that most FSAE teams never even come close to approaching.

[Chris Boyden]

If you run wheel speeds into an ECU, then they could be limited by the sampling rate of the ECU. A custom TCS using analog circuits for processing could allow you to run much larger speeds and more teeth. 10kHz inputs to the f to V converters are easy to handle. 10kHz/2.7Hz/mph = 3700 teeth*mph. 3700 teeth/200 mph = 18.5 teeth. so round up to 20 teeth. Fast AtoD converters/mixed signal processors could handle 40 kHz (4 channels) sampling on AtoD channels.

[Garlic]

Right. So on a FSAE car, you can run 30-40 teeth, if you can get sufficient gap between them (large radius). This gives you great resolution, with the same cheap sensors.

[ss_torry]

When using the Honeywell GT1's, turns out the distance required on the circumference for one tooth and one gap is approximately 13.5mm (10.5 for the gap, 3 for the tooth). With 12 teeth on a wheel, this will provide measurable readings up to 3600 rpm. Info can be found here

http://catalog.sensing.honeywell.com/datasheet.asp?PN=1...AM=solidstate&P=2290 (http://catalog.sensing.honeywell.com/datasheet.asp?PN=1GT101DC&FAM=solidstate&P=2290)

We went for 20 teeth, reduces the measurable speed a little, but at 250 km/hr the wheels are doing under 2000 rpm anyway so it's no issue.

Found that with 13 inch wheels/20 inch tyre, 45 teeth per wheel will give you a speed range of 0 -> 250 km/hr, with great resolution. Problem this gives is space constaints, with a GT1 sensor this means the disc will be 193mm in diameter...

[Frank]

the GT1 specs are conservative...

you can use less spacing, height, etc than the specs

we got 12 teeth

UQ.. acceleration winners 2004FSAE and 2004FS

[Agent4573]

Just a note on the accelerameters, we have 3 built into the PCB board for our dash, and while they do come in very useful for data logging and figuring out what the car does on a normal basis, I wouldn't suggest them for traction control. The actual data points are anywhere from 5 to 10 percent off due to vibrations through the chassis and other factors. Taking the average off all the points yeilds fairly accurate results, but if you take a decent sample, say 10 samples and average them, then you've just turned your 3ms response time into a 30ms response time, plus you probably have more computing time w/ an accelerameter setup than a speed sensor w/ an d/a converter on it.

yeah i agree that the tcs uses the same vehicle speed sensor (http://www.autopartsdeal.com/vehicle_speed_sensor/vehicle_speed_sensor.html). this is very important part because this control unit receives the signals from these sensors.

[JeffreyH]

We ran an inductive proximity sensor on each wheel (going to both the ECU for Launch/Traction Control and the datalogger for logging), as well as a 6 axis IMU which I designed.

The wheel speed sensors were just basic Honeywell ones - they proved quite robust, we typically ran them off the brake disc carriers. I would concur with using the fastest front wheel speed as a measure of vehicle speed.

The IMU used an ADXL335 accelerometer and three ADXRS610 gyros mounted to give the appropriate axes. Simply had a 5V supply from the datalogger and 6 analogue outputs. It worked reasonably well but was susceptible to vibration and noise - we had to post-process the data a bit to get useful track maps.

http://lh4.ggpht.com/_lCh32qw0Xr0/S59WuqluIlI/AAAAAAAAASY/8C48ryHKauw/s800/DSC00104.JPG

[Speaking as an alumni from UOA, not a current member]

[JeffreyH]

Gah.. just realised this was dragged up from the depths of the forum. Oh well - hopefully my response is approved (undergoing moderation for images).

Apologies.

[2BWise]

Why not use both? There are limitations to using solely wheel speed and solely accel and you can create situations to "trick" the controller. You can integrate them together for plausibility for a more reliable system.