Differential vehicle wheel speed

Hey guys,

I'm new at Arduino's world, but I'm an old programmer using other platforms. I'm from Brazil and I'm building a resto-mod car by myself. So I'd like to create a wheel speed controller to take the wheel signal from the faster wheel to send this signal to my ECU (Fueltech) as an input signal. This would avoid lost input pin from my ECU just to make this calc internally.
My project intends to apply the same strategy for front and rear wheels, so I gonna need, at least 4 interruptions to read those values. The problem is the time to read those pair values because I need to read the faster signal (highest frequency) and just use this faster signal as an output signal.
I really don't know yet if I gonna need to have one controller for front wheels and another for rear wheels or if I can have both in the same controller (Arduino).
I know my English is poor, so if you can't understand feel free to ask me about it.
Bellow the picture to illustrate this controller:

What signals do your anti-lock sensors send?
Paul

Each wheel going to have a ring reluctor inside using a hall sensor (like camshaft position system), so it going to be a squared signal.
My first idea is to use an interruption for each wheel, calculating the highest frequency and returning this frequency as an output

For what does the ECU use the fastest wheel speed sensor signal?

Assuming the logic works well, there may be discontinuities when the fastest wheel changes; will that potential hiccup in the output signal cause the ECU any problems?

What's the maximum expected frequency of the wheel speed sensors?

Blackfin:
For what does the ECU use the fastest wheel speed sensor signal?

Assuming the logic works well, there may be discontinuities when the fastest wheel changes; will that potential hiccup in the output signal cause the ECU any problems?

What's the maximum expected frequency of the wheel speed sensors?

Summarizing the ECU uses this signal for traction control to know if there is a disruption of the traction wheel in relation to the reference wheel, to apply the appropriate correction.
Usually, the guys use one sensor for one front wheel (left or right) and another for the rear wheel (left or right), however, the wheel speed is different for the left or right wheel into a curve, for this reason I'm intending to use a differential calculation to take the faster wheel. This calc makes possible to have just one signal representing the velocity even in a curve or straight line
To make it clear I will have this differential calculation for front wheels and also for rear wheels. So 2 differents signals to represent front and rear wheel speed

For ECU that is already a common usage having this rotation signal. I just want to transform 4 signals into 2 output signals to use less ECU inputs. So instead to use just one sensor for one front wheel and rear wheel, i'd like to have sensor on all wheels and calculate the faster wheel in front and rear axle.

Summary of program working:

A few rambling thoughts:

A Mega has 4 16-bit timers (Timer1, 3, 4 and 5).

You could, in theory, connect the inputs from each wheel sensor to its own input capture pin (ICP1,3,4 & 5). Unfortunately, the way the Mega2560 board is wired the input capture pins for timer 1 and 3 are not brought out to connectors (ICP4 is on pin 49 and ICP5 is on pin 48.)

You could, in theory, use the wheel sensor inputs as clocks to each of the 4 16-bit timers via T1,3,4 & 5.) Unfortunately, the Mega2560 design neglects to bring T1, 3 and 4 to connectors (T5 is available at pin 47.)

You might be able to pin change interrupts on the Mega (available on pins 2, 3, 18, 19, 20 & 21.) The feasibility of this approach needs further consideration. I don't know the number of pulses per revolution of your wheel sensors but I've seen tooth counts of 39 and 48 teeth as examples. At 120MPH, a 48-tooth sensor would produce a 1.3kHz pulse stream which has a period of ~730uS so you'd be doing RISING or FALLING edge interrupts on 4 pins, each of which is going to be giving an active pulse every 730uS. Given the hardware connection limits of timer hardware solutions, this might be the best route but you'd need to characterize it.

TBH, I don't think I would try to have the Arduino replicate the waveform though it might be reasonably possible via output compare operations. My inclination would be to have the signals run to 4 tri-state buffers (like a single CD74HCT126 IC); pairs of outputs are wired together. The output enables are controlled by the Arduino: When the Arduino decides which channel has the highest frequency for a given axle, it enables the output corresponding to that channel's input, effectively tying that speed sensor input to the ECU through the buffer. That would be repeated for the other axle, giving two pulse trains to the ECU.

@diegorcsantos, you have not answered the important (essential?) question about the maximum pulse frequency from the wheel sensors.

And I have a strong suspicion that the difference in wheel speed when cornering normally is trivial compared to the difference when traction is lost.

My guess is that the loss of traction is identified because a wheel on one axle is either rotating very much slower or very much faster than the wheel on the other axle. In other words I remain to be convinced that your proposal will significantly improve the system.

...R

Blackfin:
You might be able to pin change interrupts on the Mega (available on pins 2, 3, 18, 19, 20 & 21.)

That would be the (oddly named) "external interrupts". The ATMega2560 has many more pins that have "pin change interrupts" available (most but not all of the pins have this interrupt available). Similar effect but they need a very different approach.
If the input signal is indeed in the tune of 1.3 kHz for four wheels, that'd be some 5.2 kHz total signals. Very doable to time with interrupts, as long as the time calculations (which are to be kept outside the ISR) are done reasonably efficiently.

wvmarle:
That would be the (oddly named) "external interrupts". The ATMega2560 has many more pins that have "pin change interrupts" available (most but not all of the pins have this interrupt available). Similar effect but they need a very different approach.

Yes. I was just referring to the Arduino attachInterrupt() documentation:

which simplifies the implementation of an ISR to specific pins with:

attachInterrupt( digitalPinToInterrupt( pinSpeedSensorFR ), fnSpeedSensorFR, RISING );

Blackfin:
TBH, I don't think I would try to have the Arduino replicate the waveform though it might be reasonably possible via output compare operations. My inclination would be to have the signals run to 4 tri-state buffers (like a single CD74HCT126 IC); pairs of outputs are wired together. The output enables are controlled by the Arduino: When the Arduino decides which channel has the highest frequency for a given axle, it enables the output corresponding to that channel's input, effectively tying that speed sensor input to the ECU through the buffer. That would be repeated for the other axle, giving two pulse trains to the ECU.

That was exactly what I was thinking in this project: to use Arduino like a switch between the signals, however as I said I have no experience using Arduino and CIs. But reading the CD74HCT126 datasheet I think that is the better way.
Could you help me on this journey?

Robin2:
@diegorcsantos, you have not answered the important (essential?) question about the maximum pulse frequency from the wheel sensors.

And I have a strong suspicion that the difference in wheel speed when cornering normally is trivial compared to the difference when traction is lost.

My guess is that the loss of traction is identified because a wheel on one axle is either rotating very much slower or very much faster than the wheel on the other axle. In other words I remain to be convinced that your proposal will significantly improve the system.

...R

So, about the frequency, let's take the maximum value. Imagining that my car can run at 250Km/h (about 155mph) would represent something like 2.000 RPM on the wheels. If I use a reluctor within 40 teeth, this would be a 40 x 2.000 / 60 = 1.333 Hz (Correct me if I'm wrong). Of course, I as the vehicle owner desire much more than 155mph, but the reality says other values.

diegorcsantos:
this would be a 40 x 2.000 / 60 = 1.333 Hz (Correct me if I'm wrong).

1.333 kHz

I strongly advise against fiddling with the control system of a 155mph car if you do not have the necessary professional engineering qualifications. If you were so qualified you would not need to seek advice from unqualified folk on the internet.

Get written approval from your automobile insurer before you make any changes.

...R

Robin2:
1.333 kHz

I strongly advise against fiddling with the control system of a 155mph car if you do not have the necessary professional engineering qualifications. If you were so qualified you would not need to seek advice from unqualified folk on the internet.

Get written approval from your automobile insurer before you make any changes.

...R

About the value format, I'm sorry, in Brazil we use . (dot) as Thousands Separators and , (comma) as Decimal Separator, so the value 1.3kHz (USA) is equal to 1,3kHz (Brazil) and 1,333Hz (USA) is equal to 1.333Hz (Brazil). Then, this information was not wrong info, just a conversion fault on my part. Follow the link for a better explanation.
Regarding your advising, I appreciate it, however, as I said above this is a resto-mod car project, so the start car state is a 1970s car without any electronics embedded. Everything desired on this project will be made by myself, that is the proposal. The ECU mentioned by me is a programable EFI system by Fueltech (that is a Brazilian company). Here is very common to convert carburated cars to injected cars. This ECU has a TC that I want to use as well, but the number of input pins is limited and I can't lose 4 pins just to use this feature, for this, I'm creating this "wheel speed controller". The ECU already accepts this signal (from the rotation sensor), for this reason, I'm concerned to have exactly the same output signal format from my controller.

Btw, I solved this challenge guys. As I said I don't have experience using Arduino, however, I have a large experience building systems. I followed the same steps, just reading the official documentation. I used the ISRs to count the wheels' pulses. I simulated it on tinkercad and that is working. I really appreciate @Blackfin help, he gave me the north to follow using CD74HCT126 IC to switch the output signal based on my signal key to select the faster wheel speed. That really worked!
Bellow a simple code just to take the speed of one wheel. I made this code just to validate my hypothesis using ISRs. I simulated this code using an oscilloscope to generate the square signal input.

// Car definitions
#define RELUCTOR 48        // Number of teeth
#define WHEEL_DIAMETER .65 // In meter (m)

// Program definitions
#define CYCLE_SIZE 500 // Take calculated each 500ms
#define WHEEL_INPUT 2   // Digital pin 2

volatile int pulses;
int speed = 0;
int rpm = 0;
unsigned long timeold;

void wheelPulse()
{
  pulses++;
}

void enableInterrupts()
{
  attachInterrupt(digitalPinToInterrupt(WHEEL_INPUT), wheelPulse, RISING);
}

void disableInterrupts()
{
  detachInterrupt(digitalPinToInterrupt(WHEEL_INPUT));
}

void setup()
{
  Serial.begin(115200);
  
  timeold = 0;
  pulses = 0;
  pinMode(WHEEL_INPUT, INPUT);
  enableInterrupts();  
}

int cycle;

void loop()
{
  cycle = millis() - timeold;

  if (cycle >= CYCLE_SIZE)
  {
    // Disable interrupts
    disableInterrupts();
        
    rpm = (60000 * pulses / cycle) / RELUCTOR;
    speed = (WHEEL_DIAMETER / 1000) * PI * rpm * 60; // KMH
    pulses = 0;
    
    Serial.println(rpm, DEC);
    Serial.print(speed, DEC);
    Serial.println("Km/h\n");

    timeold = millis();
    // Re-enable interrupts
    enableInterrupts();
  }
}

The final code is a little bit more complex. I defined some structs type to represent the wheel and I have created a library to implement the logic to be more generic as possible, allowing me to use this lib to manage wheel speed in pairs according to my necessity. I hope also helped some others with a similar question.
Thank you all and special thanks to @Blackfin

Really I was assuming this is some kind of souped up model car, not a real life race car.

Totally agree, if you have to ask on a forum like this you're not qualified to build such a project in the car. At least not a real life full sized car, not even if it's just used on the track (even though then it may even be legal to do so, on the public roads I seriously hope it's not).

There's a lot of interesting things to tinker with on a race car, but at the very least you must be knowing very well what you're doing. Small mistakes can have large consequences, especially when it's dealing with traction.

wvmarle:
Really I was assuming this is some kind of souped up model car, not a real life race car.

Totally agree, if you have to ask on a forum like this you're not qualified to build such a project in the car. At least not a real life full sized car, not even if it's just used on the track (even though then it may even be legal to do so, on the public roads I seriously hope it's not).

There's a lot of interesting things to tinker with on a race car, but at the very least you must be knowing very well what you're doing. Small mistakes can have large consequences, especially when it's dealing with traction.

I was here wondering what the dangers of poorly wheel rotation sensor signal acquiring would be. So let's think. Traction control briefly needs 2 signals: front wheel speed and rear wheel speed (that's all and nothing more). The system also needs to know which is the drive wheel (in my case the rear wheel). How does this system basically work? When the drive wheel turns faster than the reference wheel, the ECU basically delays the engine's ignition time, decreasing the final power until the wheels are at the same speed. This mechanism comes into operation whenever the ECU detects some slipping of the drive wheel. The maximum that a poorly made collecting of rotation signals can do is to tell the ECU that the wheel is not tractioning (slipping) and in this case, the horsepower will be reduced until the engine shuts down or, otherwise, it does not inform that the wheel is not tractioning (slipping) and the car will skid ( what an old car owner is used to). Both behaviors are easily detectable in a simple test. Remembering this controlling is made by ECU (more information click -> Active Traction Control) and it just is enabled when a lot of power is passed to the floor in a really short time. My car has this horsepower currently, so the worst scenario will be exactly how my car is currently in terms of HP vs wheel slip on accelerating.

I appreciate your concern. I know this project seems something atypical here, I need to be honest that I'm already regretting having asked here, as it seems to me that asking about a technology that I don't know disqualifies me from the technologies that I already know. As I said before, I didn't have experience using Arduino, however, everything related to my project, mechanic stuff, ECU, and high-level programming I know.

Otherwise, I feel happy to know this forum is very engaged with member's security and it is really awesome because there is a lot of students and hobbyists here.

Well, then it's obvious where you should start your work: understand more of the Arduino, it's abilities and limitations, and how to program it. This is not the kind of project to learn how to use the Arduino - this is where you apply your knowledge, so you can properly assess risks. There are heaps of possible projects, including within the automotive realm, that are far more suitable for learning how to use Arduinos.

One of the main risks is unpredictable behaviour. You probably know very well when you can expect your car to start skidding, and be prepared for it. However when you hit say a sudden oil slick, and you start sliding unexpectedly, that's much harder to correct for. Likewise when your Arduino project suddenly misbehaves and suddenly causes a wheel to lock up when you don't expect it. Interrupts is one of the areas where a minor programming error can cause very interesting behaviour!

A final concern: the parts used on Arduino boards are not the automotive rated versions...

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.