I once acted as a consultant (feasibility study) to someone who wanted to design a reliable NASCAR speedometer for INSIDE the car (to prevent tickets when going into/out of PIT ROW or when under YELLOW flag). I installed a few pieces of custom test equipment on a test race car and ran it for a few days. Here's what I found out: 1. The tires wear so rapidly, and changed shape so rapidly, that using a fixed mechanism was never better than 10% accurate. In particular, the right and left tires wore differently, and sometimes were deliberately inflated differently. 2. Since speed is the measurement of the distance per unit time of the car going FORWARD over the ground, the slippage when the car cornered is significant. 3. The best (and present) method is to detect the car between posts, which provides a reliable AVERAGE speed. But that does NOT provide instant speed values. Along with my mechanical engineer consultant associate, we decided: 1. No mechanical mechanism would provide a reliable source of speed measurement. 2. Either Ultrasonic Audio or RF doppler "radar" could be used if the sensors were mounted under the car, and would bounce off the pavement. The reflected signal would be frequency-shifted due to the pavement. Its like normal radar except that the sensors were seperated. 3. We decided that Ultrasonics would be cheaper but RF would be the most accurate. The Audio source would have to be intense to not be drowned out by the noise of the car. It was a fun project. But it took forever to get paid.... --Bob John Pearson wrote: >I thought about employing a speedometer and tach, plotting the relationships >for comparison. I only needed it for first gear so that simplified things. > >If all else fails and you end up using your right foot for your traction >control, try something I learned on street radials: Get the car moving, then >lift for a split second. Once you lift you can floor it without wheelspin. > >John >----- Original Message ----- >From: "Andrew Warren" >To: "Microcontroller discussion list - Public." >Sent: Monday, October 18, 2004 3:53 PM >Subject: Re: [PIC] Traction Control / Wheelspeed sensing > > > > >>Andy Meng wrote: >> >> >> >>>I am working on a wheel speed sensing and traction control system >>>as part of our schools Formula SAE race car. Basically, it has more >>>power than traction (about 80HP/500 pounds) and we don't have much >>>time to practice driving it, so the more help we can get in the >>>traction department, the better (especially in the >>>acceleration/drag race event). >>> >>> >> Andy: >> >> If you can give him a dozen-or-so runs to find the right launch >> RPM and shift point(s), I think your unassisted driver will >> perform as well or better than your electronic traction-control >> system. >> >> If you don't have enough practice time for him to learn how to >> launch the car, you certainly don't have enough practice time to >> tweak and tune a traction-control system. >> >> But, since you probably want to have something to do between now >> and the end of May... >> >> >> >>>The basic principle is to compare the speeds of the front (non >>>driven) and back (driven) wheels to determine how much slip/loss >>>of traction there is. Apparently, about 10% slip is best. >>> >>> >> 10% is only a general rule-of-thumb; the optimum amount of slip >> could vary between half and twice that value. Tire compound, >> construction, temperature, and condition all affect it, as does >> the surface you're driving on. >> >> Also... Comparing front-wheel RPM to rear-wheel RPM is easiest >> if a) tire deformation doesn't significantly change the rolling >> circumference of your rear tires, b) you're not cornering, c) >> you have a locked differential. >> >> I wouldn't expect you to have a problem with tire deformation and >> I assume that you're only planning to use the traction-control >> system for the straight-line acceleration event, not for the >> autocross... But since you probably have a limited-slip or (yuck) >> open diff, you need to think about how you'll measure wheelspeed >> when your rear wheels aren't spinning at the same rate. >> >> >> >>>If the back wheels are spinning too fast, the throttle is cut >>>electronically (strict throttle by wire is prohibited for obvious >>>reasons, but just cutting fuel/spark isn't) to limit the slip (and >>>hopefully maintain it with decent control). >>> >>> >> Consider retarding the ignition timing instead. >> >> >> >>>I have designed a wheel speed sensor (there will be 4 copies of it) >>> >>> >> How many pulses per revolution? More pulses gives you the >> potential for quicker response, but also could lower your timing >> resolution and make your front-to-rear ratio calculation less >> accurate. Have you done the math to find a good compromise? >> >> >> >>>it has a hall effect sensor, PIC10F or 12F (timing pulses), MCP2515 >>>CAN controller, and a CAN transceiver IC that hangs on the bus. >>>Hopefully the CAN transceiver will make it pretty easy - all it >>>needs is SPI data from the PIC. >>> >>>The other end will be a bit more difficult. I still haven't worked >>>out the algorithms yet. I think it will likely consist of a similar >>>CAN interface feeding a 16F or 18F PIC (some of the 18's also have >>>a built in CAN interface). This PIC will have 4 outputs so it can >>>individually cut cylinders. I think this PIC should probably be >>>done in C to make it easier to try new algorithms. >>> >>> >> Have you added up all the timing to make sure that you can do >> everything (read the wheelspeed, transmit the data to your >> central PIC, process it, reduce/increase power) fast enough? >> >> Four sensors with embedded microcontrollers sending data >> asynchronously, plus a central PIC that has to act on that data, >> is a complicated system. Think hard about ways to reduce the >> complexity. >> >> >> >>>I would appreciate comments on the system outlined above. >>> >>> >> If it were me, I'd simplify the output side of the system by >> choosing to reduce engine power by retarding the timing; it's >> fast, effective, and less intrusive with fewer unwelcome >> side-effects than cutting fuel or spark. It also requires only >> one output instead of the four that you're planning on. >> >> I'd simplify the input side, too. The entire system can be made >> ENORMOUSLY simpler if you find a way to sense slip without >> measuring wheelspeed. Such a way exists, but I don't want to >> ruin the surprise for you. >> >> Good luck... >> >> -Andy >> >>=== Andrew Warren -- aiw@cypress.com >>=== Principal Design Engineer >>=== Cypress Semiconductor Corporation >>=== >>=== Opinions expressed above do not >>=== necessarily represent those of >>=== Cypress Semiconductor Corporation >> >>_______________________________________________ >>http://www.piclist.com PIC/SX FAQ & list archive >>View/change your membership options at >>http://mailman.mit.edu/mailman/listinfo/piclist >> >> > >_______________________________________________ >http://www.piclist.com PIC/SX FAQ & list archive >View/change your membership options at >http://mailman.mit.edu/mailman/listinfo/piclist > > > -- Note: Attachments must be sent to attach@engineer.cotse.net, and MAY delay replies to this message. 520-219-2363 _______________________________________________ http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist