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