+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 22

Thread: Wheel Speed Sensor Setup (for TCS)

  1. #11
    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.
    mmmm..... Garlic.

  2. #12
    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.
    UNM FSAE 2003 to 2005

  3. #13
    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.
    mmmm..... Garlic.

  4. #14
    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.
    UNM FSAE 2003 to 2005

  5. #15
    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.
    mmmm..... Garlic.

  6. #16
    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

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

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

  8. #18
    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.

  9. #19
    Guest
    yeah i agree that the tcs uses the same vehicle speed sensor. this is very important part because this control unit receives the signals from these sensors.

  10. #20
    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.



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

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts