Homebrew "dumb" traction control, discussion/development...

[RoadWarrior222]

Hey folks,

I'm not sure if I want to wait until hell freezes over to get a professionally polished plug and play traction control unit. Well that's one small reason, another being that it's cool to figure out crap yerself. Call it an intellectual exercise at the moment if you will. But there is an intention that it has the potential become hardware that could be put together by anyone who can socket a SMEC.

While I expect that some useable level of functionality can be achieved, I don't think it will progress much beyond "experimental" because this approach I'm thinking of has limitations. Although with prolonged development it is potentially possible to overcome those, it would lead to a large and complicated system that would become complex to build, test and adjust, and still not quite fit inside a small steamer trunk.

So, working on the KISS principle, what exactly is it that makes traction control complicated? IMO, timing, response time, making a microprocessor respond to changing inputs in real time. While having a metric butt load of advantages, in that it's programmable, adaptable and you can hook a 'pooter up to it and adjust it, the fact remains that you have to be an expert in both system hardware design AND real-time programming to get anything out of one. So, we're gonna throw the baby out with the bathwater, because all we really want is an empty frigging tub right? Buh bye microprocessor.

So analog and digital logic circuits can respond in real time. You can use analog to compare values, and digital logic to make instantaneous (well 15ns or so) yes/no decisions. Basically, why use a huge and complex multipurpose array of logic gates to make a few simple choices. Why make it "do the math" if you can process inputs with analog circuitry. Why program a fugging BASIC Stamp to turn on lights when it's dark when you can do it with one frigging transistor... ahem.. sorry that's me getting pissed with seeing things like that posted as "cool hacks" :D

Okay, so I'm calling it "dumb" but I'm not yet leaving out the possibility that it get's "smart" in a different way, by having an analog "computer" incorporated at some point. They can be built to integrate or solve differential equations... instantly. Do we need to? Not sure yet.


So, version 0.0.1 Alpha....

If we can get pulse trains from driven and undriven wheel sensors, convert them into sharp square wave pulses, we can then feed them into a flip-flop set up as a phase detector, which will produce an output when inputs go out of phase. Use output to cut spark... DONE!!!

Well not really. The phase detector will trigger for phase difference of the same frequency, as well as frequency shift, so while this might be a useful building block, we need to suppress output for equal but out of phase frequencies, and also suppress output when undriven > driven. As well, we need to convert pulse trains from each sensor using multipliers or dividers such that f1=f2 when at a steady speed. Or use identical sensors at each wheel. Further, "break spark" is a bit of a neanderthal way to do things. Another thing to investigate here, is the sensitivity of a flip flop to phase variance, and whether it can be tuned... i.e. how much out of phase do it have to get? (I'm suspecting one peak has to go off about 50%)

Approach #2a and b... a: use frequency to voltage conversion, and compare voltages with a comparator... b: use custom sensors and compare voltage... some of the considerations above apply. a: A 9400 chip will do it, but I'm a little concerned about conversion speed, got an inkling there's a delay, may be significant or not, might have a frequency maximum near or in useful range, really need to dig the data sheet out. There's probably better chips these days, this one may have appeared on 2400 baud modems. OTOH you can pirate parts off old modems maybe :eyebrows: b: melike the concept, thinking Faraday dynamo, metal disk with a magnet on it and contacts at hub and rim... potential for disruption due to rain, snow, dirt, corrosion, stray fields etc. voltage output small... probably exceeded by that induced by commercial broadcasting in the wiring at low rpm... OTOH, just wire them pos to neg, if the output goes positive, driven wheel is going faster! OTOH-2...hmmm connect all 4 wheels and get the total output of each axle vs the total output of the other axle... hmmmmmm.


Anyway, those are kind of "ball rolling" ideas, don't want to get too deep down the rabbithole just yet, no one else will come down unless I stand near the entrance waving cookies.


RW222

BTW: please use another thread for discussion/debate of commercially available or forthcoming systems.

[ShelGame]

Why not just do it all with the ECU (ie, LM/SMEC/SBEC) and the SDS? ;) Invisible traction control...

[RoadWarrior222]

Well that could handle a portion of it, but I was thinking another input or two was required and there wasn't enough cycles or memory spare for fancy functions.

[ShelGame]

Here's what I was thinking -

Since we know the gear ratio, and we know the RPM, we know what speed the tire should be going, right? So, when the RH side is spinning, the SDS speed will be higher relative to what you would expect from RPMxRatio, and when the LH side is spinning, the SDS speed goes down disproportionately compared to RPMxRatio. For a manual trans car, this should actually be really simple. There will be a little tricky stuff to determine what gear the car is in and then compare to the known gear ratios. But, not impossible.

The real tricky part would be auto trans cars where the converter throws an extra variable into the mix - the slip ratio. Since the converters speed ratio is not fixed, we can't use the simple RPMxRatio to calculate the expected speed and compare to the SDS speed. But, we can calculate the acceleration of the vehicle based on the SDS speed (which is actually already done by the cruise control routine, we just need to hijack it). Then compare the acceleration to a calibrated value (based on the car weight, power output, tire size, coeficient of friction, etc.). If it either exceeds or does not meet the intended acceleration, then indicate slip. This will obviously be much less accurate than the manual trans version above. And, even less accurate at high converter slip ratios like launching - which is where wheelspin is most likely to occur.

Once slip is detected, we can do one or several things to reduce power - drop boost, retard timing, cut spark, etc.

As far as memory and cycle time - the auto trans stuff might be a bit tricky to do with an LM; but I think the manual trans method would work fine with all of the ECU's.

[roachjuice]

How about just regulate boost with the computer. Dunno if that works or not. I could never get the computer to control boost.

[RoadWarrior222]

Hmmm cunning. Is there always zero clutch slip at launch though? I know you hope there's none by the time you move a few feet... but getting to moving, I thought there would be some slip before it grabbed. Also if a driver suspected slip, like setting off on wet or slippy surface, the natural tendency would be to modulate the clutch very carefully as well as the throttle.... leading to more clutch slip. I'm getting a headache though trying to think whether clutch slip and tire slip are mutually exclusive... mostly.

I think there's a problem if it relies on co-efficient of friction though, that's going to be too variable based on track prep and state of tires, even just for strip use only... not considering mud/ice/wet street conditions.

However, it is sounding like a first gear launch TC program for manual cars with stock diffs could be a first step.

For autos, I'm wondering if it could "learn" power output vs slip, by 2nd or 3rd gear pulls under good traction conditions.

[RoadWarrior222]

Phase Detector approach...

It just occurred to me that if you have two phase detectors and invert the input of one pulse train into the second phase detector, you then should be able to determine whether you are seeing different frequencies or different phases of the same frequency (i.e. the rear sensor out of synch with the front sensor)

Analog types give an output proportional to phase difference. So if both outputs add up to a nominal value, say the level is 5v and one is at 1V and the other at 4V then you know the frequency is the same, but it's out of synch, but then if they go to 3V each, you know the frequencies are off, 4 or 5V each, very off... This could be useful, the magnitude of the difference would allow you to mildly to severely retard spark according to degree of difference.

[RoadWarrior222]

Next I'm thinking, invert one output of one of the PDs, then feed them into a difference amplifier, which would have constant output as long as the difference was the same, no matter if one skipped a hair, or you went out of phase from turning, then large differences would produce large output... use output to scale response.

---------- Post added at 04:12 PM ---------- Previous post was at 04:11 PM ----------

Maybe I should see what exactly a PLL does... and get my head round it...

[shadow88]

Where is the KISS approach again?

Just sayin' here, one of the first traction control devices was on the Buick Riviera. I think it used a driveshaft speed sensor and a front wheel speed sensor???? If it detected wheel spin above a 10% it would retard ignition timing to reduce power.

Or go the purely mechanical approach and get a torque biasing differential and better tires and suspension settings.

[RoadWarrior222]

Heh, we're only up to a couple of ICs so far...

[Aries_Turbo]

arduino has a prewritten PID algorithm.

frequency to voltage conversion from the wheel sensors (average the front and the rear) and send that signal to the A/D inputs on the arduino.

compare the two voltages and when they differ the PID code will automatically adjust an output (PWM to something or whatever) to bring the front and wheels signals back together.

that seems pretty simple to me.

that reminds me, i need to work on my PID controlled boost controller some more. :)

Brian

[Reaper1]

I think it's all gotten too complicated already! LOL

You need to sample the rates of the wheel speed sensors, which produce square waves and is counted as a frequency. MegaSquirt already does this! Now, do you want to count the rise or the fall, that's the biggest question, but nothing too complicated.

Now, all you want is for one wheel sensor to be within a certain range of frequency of the other wheel sensor. This would be user programmable since different tires attain the best traction with a different slip, so this is not something that can be set in stone.

I think Neil did it right. You do NOT want to cut boost, spark, or timing all together. You want to retard timing to bring power down to reduce the wheel spin. I personally think that an EGT monitor is a MUST because after cutting so much timing can cause serious issues over a long period of time. So, you need to be able to tap into the feed to the coil from the ECM, and interpret it, then resend the information. You also need to read and interpret the EGT, which can be done as a voltage, but would have to be calibrated.

Now, here's something to think about. WHEN do you want the traction control to kick in? Obviously when the throttle is opening, or above a certain tip angle. So, you need to feed the information from the TPS, read it, interpret it, then send it through a logic function to determine whether the traction control is needed. The reason for this? Because if you are on the brakes hard and lock either the front or rear tire that is associated with the wheel speed that the traction control is using, it could try to retard timing while you aren't on the throttle, and this could cut the engine. Not good. As a redundancy, I think a feed from the brake switch would also be beneficial so that basically when the brake is on, traction control is off. This is simple logic and is a pretty easy yes/no type of function.

Clearly we want the traction control to be able to be defeated for burn-outs or other types of hoodlum activities, so we need an "on/off" switch. This switch would not turn the unit on or off per-se, but rather simply activate a by-pass in the program so that the normal timing being sent by the ECM gets relayed to the coil.

To me, this seems kinda simple and could be programmed in C fairly easily. I wouldn't know the first thing about how to get it on to a chip, but I could probably come up with most of an electrical schematic. I have a friend that does know microprocessors and could tell me what needs to be done to make that part work.

If Rob can get the timing retard to work on the launch control in the stock ECM, it *might* be possible to even use the stock ECM to do the timing stuff, but I don't know how you would make the hardware inside be able to do the logic stuff.

[ShelGame]

I think it's all gotten too complicated already! LOL

You need to sample the rates of the wheel speed sensors, which produce square waves and is counted as a frequency. MegaSquirt already does this! Now, do you want to count the rise or the fall, that's the biggest question, but nothing too complicated.

Now, all you want is for one wheel sensor to be within a certain range of frequency of the other wheel sensor. This would be user programmable since different tires attain the best traction with a different slip, so this is not something that can be set in stone.

I think Neil did it right. You do NOT want to cut boost, spark, or timing all together. You want to retard timing to bring power down to reduce the wheel spin. I personally think that an EGT monitor is a MUST because after cutting so much timing can cause serious issues over a long period of time. So, you need to be able to tap into the feed to the coil from the ECM, and interpret it, then resend the information. You also need to read and interpret the EGT, which can be done as a voltage, but would have to be calibrated.

Now, here's something to think about. WHEN do you want the traction control to kick in? Obviously when the throttle is opening, or above a certain tip angle. So, you need to feed the information from the TPS, read it, interpret it, then send it through a logic function to determine whether the traction control is needed. The reason for this? Because if you are on the brakes hard and lock either the front or rear tire that is associated with the wheel speed that the traction control is using, it could try to retard timing while you aren't on the throttle, and this could cut the engine. Not good. As a redundancy, I think a feed from the brake switch would also be beneficial so that basically when the brake is on, traction control is off. This is simple logic and is a pretty easy yes/no type of function.

Clearly we want the traction control to be able to be defeated for burn-outs or other types of hoodlum activities, so we need an "on/off" switch. This switch would not turn the unit on or off per-se, but rather simply activate a by-pass in the program so that the normal timing being sent by the ECM gets relayed to the coil.

To me, this seems kinda simple and could be programmed in C fairly easily. I wouldn't know the first thing about how to get it on to a chip, but I could probably come up with most of an electrical schematic. I have a friend that does know microprocessors and could tell me what needs to be done to make that part work.

If Rob can get the timing retard to work on the launch control in the stock ECM, it *might* be possible to even use the stock ECM to do the timing stuff, but I don't know how you would make the hardware inside be able to do the logic stuff.

If you had an external box, and you wanted to send a signal to the ECM to retard timing, or reduce boost or whatever, one way to do it would be to calculate a value proportional to wheelspin and output it as a 0-5V signal. We can then use that signal to proportionately retard the timing, reduce boost, etc.

I still think, for a manual trans, you can do almost everything inside the ECU using only the SDS and the RPM.

[RoadWarrior222]

Well yah, I can make my approach sound simple... "All you do is read the difference in frequencies and use it to retard spark."

IR splainin' the process.

'coz by the time you thrash out the details for external interfacing and logic, you're gonna end up with as much "glue" between an MS, SMEC or Arduino and the vehicle as the whole gubbins takes as a standalone.

I'll leave the SMEC developers to figure it out for SMEC the MS developers to figure it out for MS, because what I really want is a box* I can nail into any vehicle I ever get and use it with minor adaptions.



(*an altoids tin, natch.)

[RoadWarrior222]

Note to self, before ordering up AWD hubs, check if I can get output from a hall effect or variable reluctance sensor off the fins on the rear drum.

[Reaper1]

If you had an external box, and you wanted to send a signal to the ECM to retard timing, or reduce boost or whatever, one way to do it would be to calculate a value proportional to wheelspin and output it as a 0-5V signal. We can then use that signal to proportionately retard the timing, reduce boost, etc.

I still think, for a manual trans, you can do almost everything inside the ECU using only the SDS and the RPM.

Can you explain that last part, Rob? I don't understand how only the SDS and the RPM can give a good traction control without a wheel speed reference to go by?


Well yah, I can make my approach sound simple... "All you do is read the difference in frequencies and use it to retard spark."

IR splainin' the process.

'coz by the time you thrash out the details for external interfacing and logic, you're gonna end up with as much "glue" between an MS, SMEC or Arduino and the vehicle as the whole gubbins takes as a standalone.

I'll leave the SMEC developers to figure it out for SMEC the MS developers to figure it out for MS, because what I really want is a box* I can nail into any vehicle I ever get and use it with minor adaptions.



(*an altoids tin, natch.)

The only reason I brought up MS is because it is an open source code and assembly that you could use the bits that have to do with the timing pick-up to run the wheel speed stuff. I'm not saying it's "easy", but it would cut out a LOT of work I'm sure.

If you want a stand-alone box, then you are going to have to make it the ignition control as well. Otherwise you will have to have "glue" between the box and the ECM.

I get what you are doing now. You are explaining the hardware interface. I thought you were trying to hash out what was needed to make it work still.

[ShelGame]

Can you explain that last part, Rob? I don't understand how only the SDS and the RPM can give a good traction control without a wheel speed reference to go by?

RPM x Gear should equal SDS. It it doesn't, then you have wheelspin (or possibly clutch slip). If the SDS is higher than predicted by the RPMxGear calculation, then the RH wheel is the one spinning, if it's less, then it's the left.

The problems are determining gear, and clutch slip. In the case of clutch slip, I'm not sure it matters. I think you'd still want to reduce power whether is clutch slip or tire slip. Determining gear number accurately could be tricky.

Due to the toruq converter, this is practically impossible on an auto. But, could work with a manual.

[bakes]

the one thing is the SPD sensoris only reading off the right drive shaft . with a open diff this makes this a little more difficult.

[RoadWarrior222]

Yeah, but it's a happy accident that that side will spin first most of the time. (Unless you balanced up the car with you in it or have a 400lb wife)

[ShelGame]

the one thing is the SPD sensoris only reading off the right drive shaft . with a open diff this makes this a little more difficult.

It doesn't matter though. If you're comapring to the RPMxGear calculation, if the SDS is higher than RPMxGear, then the RH wheel is spinning. If the LH wheel is spinning, then the SDS will be lower than the RPMxGear calculation.

All you really need to know is if the SDS = RPM x Gear x tolerance (+/-10%?). If it's outside that tolerance zone, positive or negative, you cut power to stop wheelspin (or clutch slip).

[RoadWarrior222]

I concur, back of my envelope says about 10% for turning diameter/circumference differences.

BTW I'm thinking it might be better to ignore whether you're braking or not and just configure a minimum RPM, say 1000, below which it leaves be....

[Reaper1]

That would be simpler, but in a road race or auto-cross situation your revs are going to be higher than that while braking.

[RoadWarrior222]

I'm failing to see the downside... you brake by feel, if retarding spark makes the engine slow you down more, you lift up.... plus if you've got fuel cut that leaves you lean, it keeps your motor safe...

... though I'm still pondering the "what about" when you want to be left foot on the brake and right foot on the power, to bring the arse round while you control understeer with your right foot... but if you're actually trying to do that, there's almost no strategy that's helpful from a TCU, may as well flick it off going into the corner.

[Reaper1]

What does the stock cal do under this situation? We know it pulls fuel, but what does it do to timing? I really don't know that answer, hence my question.

[ShelGame]

What does the stock cal do under this situation? We know it pulls fuel, but what does it do to timing? I really don't know that answer, hence my question.

Nothing. It only kills the injectors...

[Reaper1]

OK, so I suppose that really there would be no issue with pulling timing under engine decel while under hard braking and high vacuum situations. Left-foot braking would show a different TPS position and a different vac signal, so the cal would already make the appropriate adjustments, and the rpm would already be high enough, so it would do its job as needed. :thumb: