ABS on track / competition car?
Discussion
NDT said:
Thanks.
So it may turn out that they use exactly the same hardware but it's more than a calibration difference - there could be a strategy difference in the main OTP chip.
Correct.So it may turn out that they use exactly the same hardware but it's more than a calibration difference - there could be a strategy difference in the main OTP chip.
I would expect the pcb, processor and valve control ASIC to be the same between all variants. The pcb might be "less populated" with the input filtering passives etc (if they made enough of the 2 channel ones to make the tiny cost saving worthwhile over the cost of changing the process)
I suspect that the firmware in the micro will be different, even if that is simply an "enable 4 channel" bit being set. Unfortunately, if it is OTP, you can't change that bit.
Max,
I've had a quick read through the various posts, and I think you could get something that provides some degree of ABS functionality, but beyond that it's going to quite difficult. Anything new like the Conti MK20 or Bosch8/9 is almost entirely software based. The amount of data that needs to be inputted about the car to prevent system plausibility faults is fairly massive, and trying to do that without the base software is going to be impossible. It's highly unlikely to work with standard software as well. The differing types of sensors have to be inputted in to the base software, and to work, the software would need to see the exact type sensor that it was calibrated with. If you managed this, you'd then almost definitely get a system shutdown as any number of the following would be seen as implausible.
Basically, the way the systems are programmed is to fail and put the lights on to warn the driver if it sees ANYTHING outside normal operating parameters as it's a safety critical part that is only used by 99% of users in an emergency situation. There is a very real possibility that incorrect actuation could cause an accident. If the software for a truck was put in a supermini, it would see a yaw gain, think this huge truck was going in to oversteer and deman 100+bar from a front brake, which in the supermini would probably fire you in to oncoming traffic!
IMHO, you're best bet is to try and build a Simulink or D-Space project that you have total control over. If you can then reliably get this working with the main hardware interface to control the solenoids and pump you'll at least have a way of programming some basic ABS and TCS to begin with without the shutdown issues which would leave you with no system at all.
I've had a quick read through the various posts, and I think you could get something that provides some degree of ABS functionality, but beyond that it's going to quite difficult. Anything new like the Conti MK20 or Bosch8/9 is almost entirely software based. The amount of data that needs to be inputted about the car to prevent system plausibility faults is fairly massive, and trying to do that without the base software is going to be impossible. It's highly unlikely to work with standard software as well. The differing types of sensors have to be inputted in to the base software, and to work, the software would need to see the exact type sensor that it was calibrated with. If you managed this, you'd then almost definitely get a system shutdown as any number of the following would be seen as implausible.
- Wheel diameter out of range (greater than a few % either way of the original car)
- Yaw rate plausibility (yaw rate out of the expected range)
- Steering angle plausibility (if your steering ratio is different, the steering lock won't provide the ackerman it expects).
- Engine torque not as expected.
Basically, the way the systems are programmed is to fail and put the lights on to warn the driver if it sees ANYTHING outside normal operating parameters as it's a safety critical part that is only used by 99% of users in an emergency situation. There is a very real possibility that incorrect actuation could cause an accident. If the software for a truck was put in a supermini, it would see a yaw gain, think this huge truck was going in to oversteer and deman 100+bar from a front brake, which in the supermini would probably fire you in to oncoming traffic!
IMHO, you're best bet is to try and build a Simulink or D-Space project that you have total control over. If you can then reliably get this working with the main hardware interface to control the solenoids and pump you'll at least have a way of programming some basic ABS and TCS to begin with without the shutdown issues which would leave you with no system at all.
Edited by RacerMike on Friday 20th December 17:36
I agreed with that^^ Mike tbh. Which is why i have decided to roll my own s/w, and just use the production hardware. At low volume, where you don't care about costs, the current ARM devices bring a massive "sledge hammer to a nut" advantage. This negates a lot of potential issues with latency, error checking and resource usage etc. Obviously, for a production system that you make 10M of, you aren't going to stick in a processor that has 3x too much RAM for example. For me, that is not an issue!
One of the reasons i am building the HIL test rig is to allow me to play around with the basic low level h/w driving code first, and to make that robust in a safe environment etc
Currently, most people race or track cars without any ABS, and as such they have no "support" from a dynamic electronic system in extremis (i.e. they are already driving with zero yaw damping for example in their brake system). As such, bringing even a basic "tyre friction optimiser" to the party will bring advantages to ultimate stopping distances with no loss of controlability etc.
Certainly what i am not about to do is attempt to re-engineer an OEM level of system capability, as that would really put the system calibration outside the capability of the average user. I also want to establish what is the limiting factor for OEM ABS hardware, such as solenoid response vs drive current etc as this could open up some performance benefit also.
However, starting with an "overkill" main processor, does leave a lot of headroom for the addition of extra control strategies at a later date, without a major re-write of the low level code, which by that point, will have a lot of validation invested within it.
Luckily, the default passive error condition of "power off" on a simple 8 sol ABS system just leaves the driver with their original passive brake system, so as long as this condition is clearly telegraphed to the driver(see note) then i see no real issues with a track based implementation.
(** i am also working on a audio Annunciator system for my rally car, that uses warning tones and basic speech "sound bites" injected onto the driver/navigator coms system to provide additional system condition alerts. (similar to aircraft 'Master Warn/Caution" type systems)
One of the reasons i am building the HIL test rig is to allow me to play around with the basic low level h/w driving code first, and to make that robust in a safe environment etc
Currently, most people race or track cars without any ABS, and as such they have no "support" from a dynamic electronic system in extremis (i.e. they are already driving with zero yaw damping for example in their brake system). As such, bringing even a basic "tyre friction optimiser" to the party will bring advantages to ultimate stopping distances with no loss of controlability etc.
Certainly what i am not about to do is attempt to re-engineer an OEM level of system capability, as that would really put the system calibration outside the capability of the average user. I also want to establish what is the limiting factor for OEM ABS hardware, such as solenoid response vs drive current etc as this could open up some performance benefit also.
However, starting with an "overkill" main processor, does leave a lot of headroom for the addition of extra control strategies at a later date, without a major re-write of the low level code, which by that point, will have a lot of validation invested within it.
Luckily, the default passive error condition of "power off" on a simple 8 sol ABS system just leaves the driver with their original passive brake system, so as long as this condition is clearly telegraphed to the driver(see note) then i see no real issues with a track based implementation.
(** i am also working on a audio Annunciator system for my rally car, that uses warning tones and basic speech "sound bites" injected onto the driver/navigator coms system to provide additional system condition alerts. (similar to aircraft 'Master Warn/Caution" type systems)
A fascinating insight into how all this gumph works, cheers for an enlightening thread.
I have previously dissected various abs units, that comment about sealed boxes is rather laughable the Bosch ones are terrible for water ingress in my experience especially the main plug which is a crap design imho especially when the plug is mount vertically so any moisture simply collects in the plug top & works it way into the control box terminals. VW fitment applications are the worst!
I wonder if the the likes of BBA Reman the main fixers of all things ABS control might be able to assist with knowledge??
Re yaw sensors - Having played with these loose in cars they can make a DSC/ABS system do really weird things!!!
Happy to assist with real world testing, have a Millbrook licence if its any help
I have previously dissected various abs units, that comment about sealed boxes is rather laughable the Bosch ones are terrible for water ingress in my experience especially the main plug which is a crap design imho especially when the plug is mount vertically so any moisture simply collects in the plug top & works it way into the control box terminals. VW fitment applications are the worst!
I wonder if the the likes of BBA Reman the main fixers of all things ABS control might be able to assist with knowledge??
Re yaw sensors - Having played with these loose in cars they can make a DSC/ABS system do really weird things!!!
Happy to assist with real world testing, have a Millbrook licence if its any help
Finally got a chance to get back onto this project!
Here's the measured electromechanical response time of the solenoid valves in the ATE MK70 unit:
As you would expect it's highly voltage dependant, with obvious magnetic saturation effects starting about about 30V drive voltage. However, there looks to be at least a doubling of the potential control bandwidth available from using a voltage boosted drive technique, compared to driving them directly from normal vehicle battery voltage. If that response increase translates into an improved hydraulic response is of course the next question, so i've got a rig build underway to check that.
A bit of googling has uncovered the interesting fact that some BMW ABS units used on M cars (MK60E5) actually measure caliper hydraulic pressure in near real time, offering the interesting possibility of using a closed loop pressure control strategy on each wheel (and providing much more accurate brake force distribution data for the stability model). I guess, having to have 5 pressure sensors (the E5 bit of the designation) was an expensive and potentially low reliability issue, as no other system seems to use this approach (and the pressure sensors are known failure items)
Here's the measured electromechanical response time of the solenoid valves in the ATE MK70 unit:
As you would expect it's highly voltage dependant, with obvious magnetic saturation effects starting about about 30V drive voltage. However, there looks to be at least a doubling of the potential control bandwidth available from using a voltage boosted drive technique, compared to driving them directly from normal vehicle battery voltage. If that response increase translates into an improved hydraulic response is of course the next question, so i've got a rig build underway to check that.
A bit of googling has uncovered the interesting fact that some BMW ABS units used on M cars (MK60E5) actually measure caliper hydraulic pressure in near real time, offering the interesting possibility of using a closed loop pressure control strategy on each wheel (and providing much more accurate brake force distribution data for the stability model). I guess, having to have 5 pressure sensors (the E5 bit of the designation) was an expensive and potentially low reliability issue, as no other system seems to use this approach (and the pressure sensors are known failure items)
Here the Mk70 inlet solenoid response at around 14v supply:
The classic solenoid change of inductance (as the core moves) is clearly evident, between 2 and 4 mS after the voltage was applied across the device. Taking 2mS to start moving, and a similar amount of time to move fully.
And here's the progress on the HIL test rig:
;-)
The classic solenoid change of inductance (as the core moves) is clearly evident, between 2 and 4 mS after the voltage was applied across the device. Taking 2mS to start moving, and a similar amount of time to move fully.
And here's the progress on the HIL test rig:
;-)
No clever drive strategy is used by the Mk70 controller. It just switches battery voltage (around 13v probably by the time it's at the solenoid) across the solenoids. It uses both "high" and "low" side switching to ensure positive safety (i.e two component failures required to get unexpected drive of solenoids) and to allow in-circuit diagnostics of the solenoids and wiring integrity etc.
I'm not sure what the voltage rating of the low side switches in the std ASIC that actuate the solenoids is, but i suspect, probably around 45V (enough voltage headroom, good avalanche resistance and yet low enough RDSon).
That means the minimum solenoid switching cycle will be around 2.8 mS minimum. (357 Hz)
I'm not sure what the voltage rating of the low side switches in the std ASIC that actuate the solenoids is, but i suspect, probably around 45V (enough voltage headroom, good avalanche resistance and yet low enough RDSon).
That means the minimum solenoid switching cycle will be around 2.8 mS minimum. (357 Hz)
After a few hrs plumbing and wiring, the HIL rig is almost ready to run:
Pnuematics are all plumbed in, with pressure sensors as necessary, to provide pressure feedback for bulk accumulator pressure and the actuator ram pressure. The control box houses a 400W SMPS and control electronics to activate the rig over either USB or CAN. ABS modulator is mounted and ready for inital valve characterisation testing etc ;-)
Pnuematics are all plumbed in, with pressure sensors as necessary, to provide pressure feedback for bulk accumulator pressure and the actuator ram pressure. The control box houses a 400W SMPS and control electronics to activate the rig over either USB or CAN. ABS modulator is mounted and ready for inital valve characterisation testing etc ;-)
Although I have extensive programming experience (C/C++), but I have no experience whatsoever with programming this kind of h/w. So I was trying very hard to follow your posts on this subject. My understanding is that you want to keep all the basic low-level functions (coding) intact and rewrite the algorithms on how to handle the core ABS function (thresh hold braking) under track/racing conditions.
If that's the case, this means you can reverse engineer the imbedded code? If so, is it possible to just modify the factory algorithms instead? It would be faster to implement.
If that's the case, this means you can reverse engineer the imbedded code? If so, is it possible to just modify the factory algorithms instead? It would be faster to implement.
I considered reverse engineering the existing units, but the effort to do that is actually more effort than to start from scratch with my own controller platform. The later the ABS system the more "integrated" the control is and the harder it is to reverse engineer.
So, i'm going to spin my own hardware control level, using the existing control solenoids, but with my own drivers etc. Then i plan to run a real time vehicle dynamics model that will provide the necessary control commands to the low level drivers and to the ABS hardware. Even 5 years ago, that would have pushed the limits of embedded processing power, but these days, thanks to the ubiquitous ARM chip, you can buy massive processing power for under a tenner!
So, i'm going to spin my own hardware control level, using the existing control solenoids, but with my own drivers etc. Then i plan to run a real time vehicle dynamics model that will provide the necessary control commands to the low level drivers and to the ABS hardware. Even 5 years ago, that would have pushed the limits of embedded processing power, but these days, thanks to the ubiquitous ARM chip, you can buy massive processing power for under a tenner!
My understanding is that the latest generation ABS solenoids can cycle within 5 ms, so with adequate computing power that means it can modulate up to 200 times per minute in theory?
It would be a tremendously impressive accomplishment if you could come up with a good control system. How long do you think it's going to take for a prototype? Do you have any plans other than using it for your own? You see where I am going...LOL
It would be a tremendously impressive accomplishment if you could come up with a good control system. How long do you think it's going to take for a prototype? Do you have any plans other than using it for your own? You see where I am going...LOL
Indeed, the inductance of the solenoids i have measured means that a 5ms cycle would just be possible, but the effective open time in that cycle would be as little as 1.5 to 2ms. Reducing solenoid cycle time is possible using a higher voltage 'peak and hold' driver. In reality it looks like cycle time will actually be limited by effects such as rotational inertia of the wheel/tyre etc in most cases.
At the moment i don't really have any fixed time scales for the project, as it is sort of jiust trickling along on the back burner behind other 'better paying' work ;-)
In terms of making my system commercially available, then there are also questions i need to answer surrounding liability and limitation of damages etc.........
At the moment i don't really have any fixed time scales for the project, as it is sort of jiust trickling along on the back burner behind other 'better paying' work ;-)
In terms of making my system commercially available, then there are also questions i need to answer surrounding liability and limitation of damages etc.........
I heard from a Bosch chap that the latest ESP systems fitted to many cars is pretty much the same, there is very little "if any" calibration between systems fitted to various cars & differing manufacturers.
Having seen & tested just how good some of the systems are these days I can certainly see it being an advantage on a track or race car. If it was allowed. I think the Porsche PSM system is good example of this & or torque vectoring allowing an amount of controlled torque steer to aid a car through a corner.
Having seen & tested just how good some of the systems are these days I can certainly see it being an advantage on a track or race car. If it was allowed. I think the Porsche PSM system is good example of this & or torque vectoring allowing an amount of controlled torque steer to aid a car through a corner.
Since processing power got cheap, and OEM controllers moved over to "model based" strategies, there are less individual parameters to calibrate on a typical automotive control system. Basically, you set the "physics", ie masses, inertias, frictions, lever ratios, that sort of thing, and then really you are just left to calibrate the tuning of the system to give the response for any given platform. IE a boggo passenger car ABS will priorities yaw stability over ultimate stopping distance a bit more than say a sports car implementation of the same hardware.
For me, i'm really interested to see what a "max stop" ABS system performs like, ie one with little or no yaw intervention or deliberate yaw damping, one that just aims to keep each tyre at max longitudinal load at all times..............
For me, i'm really interested to see what a "max stop" ABS system performs like, ie one with little or no yaw intervention or deliberate yaw damping, one that just aims to keep each tyre at max longitudinal load at all times..............
I can understand the concern regarding liability in a commercial setting. But it can be done with proper legal protection. A system like this would be strictly for off-road use only and only if buyer signs liability waivers etc.
What you're doing is hugely impressive and a difficult task. There happens to be a genuine demand for a reasonably priced effective ABS system for track use on this side of the Atlantic. It would be a win-win situation.
Anyway, it may be a long shot, but I'd be very interested in exploring options with you if you're interested.
What you're doing is hugely impressive and a difficult task. There happens to be a genuine demand for a reasonably priced effective ABS system for track use on this side of the Atlantic. It would be a win-win situation.
Anyway, it may be a long shot, but I'd be very interested in exploring options with you if you're interested.
Gassing Station | Engines & Drivetrain | Top of Page | What's New | My Stuff