ABS on track / competition car?
Discussion
Max_Torque said:
That^^^ box will basically just act as a CAN gateway module for the yaw/long accel sensor (they are combined on BOSCH systems into the box that looks like this:
In effect it will recieve the CAN data for yaw and long accel on one CAN bus (with the original CAN ID being broadcast by the module) and then multiply / divide the signal magnitudes (depending on the effect you want to have) and re-transmit that data onto the 2nd CAN bus (which will be connected to the ABS/ASR module) with the same ID. That way the modifying effect of the box is disguised from the stability module.
No its not CAN In effect it will recieve the CAN data for yaw and long accel on one CAN bus (with the original CAN ID being broadcast by the module) and then multiply / divide the signal magnitudes (depending on the effect you want to have) and re-transmit that data onto the 2nd CAN bus (which will be connected to the ABS/ASR module) with the same ID. That way the modifying effect of the box is disguised from the stability module.
The combined sensor in a Bosch ABS5.7 system is a plain analog device (in a ABS5.3 it's two separate sensors but functionally identical). I don't have detail for ABS8
The sensor contains an internal oscillating cylinder which is excited by various piezo elements to an oscillation frequency of 14KHz. This puts the cylinder in a free floating neutral state. (zero point)
When driving, the cylinder is deflected (rotated) by the effect of the forces from the vehicle cornering - this produces the torsional "twist" on the cylinder.
The sensor counteracts the "twist" of the cylinder by increasing the pulse frequency of the piezo elements to deflect the cylinder back to its zero point.
The pulse frequency increase is measured an represents the real time vehicle rotation rate. Based on the measurement, the sensor produced a linear DC voltage that the DSC III control module uses to determine yaw angle.
The DSC III control module provides the rotation rate sensor with 12 volts operating power and ground. In return the sensor provides:
- A standing 2.5 volt reference voltage signal (Pin 4 of sensor)
- A linear voltage signal ranging from 0.7 to 4.3 volts (Pin 3 of sensor)
For continual plausibility testing, the DSC control module sends a predetermined test voltage signal to the rotation rate sensor (pin 5 of sensor). The sensor calculated the voltage value and sends feedback to the DSC III control module over the signal line (Pin 2) every other 20ms signal cycle. If the feedback is out of plausible range the DSC III module sets a fault.
The lateral acceleration sensor <snip> provides a linear voltage signal which is a measurement of "side to side" G-force acceleration
- The voltage range is from 0.5 to 4.5 volts which corresponds to a G force range of -1.5 to 3.5g
- With the vehicle stationary on a level surface, approximately 1.7 volts is present on the signal line. This is indicative of the nominal value of 0.0g.
Indeed, the first generation Bosch Yaw/Accel sensors did have an analogue output, so that's easy to spoof (although subject to noise etc, which would be a bit of a worry) and i wonder how they deal with the BIT (Built In test) requirement?
Anyway, back to the ABS modulator:
I have measured the activation solenoids at 8.2Ohm and 13mH, so that suggests the limiting factor for control is in fact the response time of the solenoid itself>>>
Using just battery voltage (at a nominal 13.7v) gives a first order response somewhere between 1 and 0.5Khz, so i guess having a faster control loop that that is not necessary. It would be interesting also to do a mechanical simulation of the wheel/tyre/disc/caliper, and see what the basic fundamental response frequency of that system was. The latest systems seem to claim "10 to 15" cycles per second, so, something like 75ms duration (hold/release/rebuild). With a 1KHz control bandwidth that's nearly 2 decades of headroom, so i suspect the limiting factor will be mechanical rather than electronic.
Also, the yaw and accel sensors are low pass filtered on their outputs, so there is no point running the dynamics model much faster than that (say 2Khz). An STMF104 processor @ 2MIPs is going to be sitting around and twiddling its thumbs quite a lot ;-)
I've also managed to hook up to the K line diagnostics on the MK20 device, and from that i can see that its diagnostics capabilities are very limited really, just basic "are sensors connected" std stuff (no id-ing of wires shorted to bat or gnd etc like newer stuff)
Probably the next step is to setup a dummy brake rig, with a master cyl, ABS unit and a wheel cylinder, instrument it for system pressure, and drive the MK70 solenoid block via my own "bodged up" controller and low lever driver. If that works as planned, then the route forward will be to buy the cheapest car i can find with a mk70 controller (prob an old polo or something) build my controller into a "car" version (probably not integral with the ABS unit to start with) and get to Millbrook for some skidding around to get some baseline performance data! (with a nice big "ESTOP" button mounted in easy reach of the driver......... ;-)
Anyway, back to the ABS modulator:
I have measured the activation solenoids at 8.2Ohm and 13mH, so that suggests the limiting factor for control is in fact the response time of the solenoid itself>>>
Using just battery voltage (at a nominal 13.7v) gives a first order response somewhere between 1 and 0.5Khz, so i guess having a faster control loop that that is not necessary. It would be interesting also to do a mechanical simulation of the wheel/tyre/disc/caliper, and see what the basic fundamental response frequency of that system was. The latest systems seem to claim "10 to 15" cycles per second, so, something like 75ms duration (hold/release/rebuild). With a 1KHz control bandwidth that's nearly 2 decades of headroom, so i suspect the limiting factor will be mechanical rather than electronic.
Also, the yaw and accel sensors are low pass filtered on their outputs, so there is no point running the dynamics model much faster than that (say 2Khz). An STMF104 processor @ 2MIPs is going to be sitting around and twiddling its thumbs quite a lot ;-)
I've also managed to hook up to the K line diagnostics on the MK20 device, and from that i can see that its diagnostics capabilities are very limited really, just basic "are sensors connected" std stuff (no id-ing of wires shorted to bat or gnd etc like newer stuff)
Probably the next step is to setup a dummy brake rig, with a master cyl, ABS unit and a wheel cylinder, instrument it for system pressure, and drive the MK70 solenoid block via my own "bodged up" controller and low lever driver. If that works as planned, then the route forward will be to buy the cheapest car i can find with a mk70 controller (prob an old polo or something) build my controller into a "car" version (probably not integral with the ABS unit to start with) and get to Millbrook for some skidding around to get some baseline performance data! (with a nice big "ESTOP" button mounted in easy reach of the driver......... ;-)
In order to really understand how ABS works, and to explore different control strategies from the comfort of my own home (and with less chance of a sudden and un-intended stop or trajectory change!) i have built a 1/4 car simulation model ;-)
It's a descrete stepping successive iteration model, that calculates the major chassis dynamics parameters and allows me to determine the effect of different methods and strategies for brake pressure control quickly and accurately. At the moment, to avoid having to do loads of really detailed low level system definition the model just runs at 100Hz, and although of course the absolute output values will not entirely reflect reality, they should act as a decent comparitor.
Here's some of the models output with 3 different types of brake pressure control, for a 100-0kph stop, with the added fun of a step change in surface friction (drops from 1 to 0.6, 25m down the virtual "test strip".
So, first, no ABS, just an input by the drive to build and hold a 54kg brake pedal load:
Pretty much immediately the surface changes, the wheel locks, and the car skids to a halt 49.7m down the track
Now, an (nearly)"ideal" ABS controller, that can control brake pressure with no bandwidth or noise restrictions:
Same pedal load, same surface change, but system controls tyre slip well, and stops 42.9m down the track
And finally, a more realistic 3 mode descrete controller:
Same conditions, and in fact even this basic control stragety doesn't do too badly, finishing up somewhere between the other two, at 45.4m stopping distance
This is all well and interesting i hear you say (ok, you're probably either watching Eastenders or asleep by now actually ;-) but what does it all mean?
Well, the good news is that because this model has been built as a descretised stepping model, that has a basic calculation path, it can be very simply converted into C code to run on a real time simulator (hurray!). So, that means i can build an ABS system test rig, where the physics of the car are being simulated in near real time (will probably run @ ~2Khz) meaning that i can use the actual ABS hardware within the test loop. This Hardware in the loop (HIL) test method is good because i captures the subtleties of the system. For example, rather than have to exactly model how any particular ABS component responds, i will actually just use that very component. It also means that the testing can be very repeatable, unlike in real brake test work, and avoids dangerous early code development life er, issues!
Inital HIL will be just a 1/4 car model, but if that works well it is a quite easy step to expand that out to a 1/2 or full vehicle simulation.
It's a descrete stepping successive iteration model, that calculates the major chassis dynamics parameters and allows me to determine the effect of different methods and strategies for brake pressure control quickly and accurately. At the moment, to avoid having to do loads of really detailed low level system definition the model just runs at 100Hz, and although of course the absolute output values will not entirely reflect reality, they should act as a decent comparitor.
Here's some of the models output with 3 different types of brake pressure control, for a 100-0kph stop, with the added fun of a step change in surface friction (drops from 1 to 0.6, 25m down the virtual "test strip".
So, first, no ABS, just an input by the drive to build and hold a 54kg brake pedal load:
Pretty much immediately the surface changes, the wheel locks, and the car skids to a halt 49.7m down the track
Now, an (nearly)"ideal" ABS controller, that can control brake pressure with no bandwidth or noise restrictions:
Same pedal load, same surface change, but system controls tyre slip well, and stops 42.9m down the track
And finally, a more realistic 3 mode descrete controller:
Same conditions, and in fact even this basic control stragety doesn't do too badly, finishing up somewhere between the other two, at 45.4m stopping distance
This is all well and interesting i hear you say (ok, you're probably either watching Eastenders or asleep by now actually ;-) but what does it all mean?
Well, the good news is that because this model has been built as a descretised stepping model, that has a basic calculation path, it can be very simply converted into C code to run on a real time simulator (hurray!). So, that means i can build an ABS system test rig, where the physics of the car are being simulated in near real time (will probably run @ ~2Khz) meaning that i can use the actual ABS hardware within the test loop. This Hardware in the loop (HIL) test method is good because i captures the subtleties of the system. For example, rather than have to exactly model how any particular ABS component responds, i will actually just use that very component. It also means that the testing can be very repeatable, unlike in real brake test work, and avoids dangerous early code development life er, issues!
Inital HIL will be just a 1/4 car model, but if that works well it is a quite easy step to expand that out to a 1/2 or full vehicle simulation.
BTW, to anyone saying "ABS does't make that much difference" if i re-run those same tests, under the same conditons, but with the entire "track" on wet concrete (0.6 co-efficient) the stopping distances become:
NO ABS (immediately wheel lock) = 86m
Ultimate ABS = 59m
Typical ABS = 63m
Yup, locking wheels can be bad for your health! (especially if the cliff edge was only 65m from where you started to brake........ ;-)
NO ABS (immediately wheel lock) = 86m
Ultimate ABS = 59m
Typical ABS = 63m
Yup, locking wheels can be bad for your health! (especially if the cliff edge was only 65m from where you started to brake........ ;-)
Interesting project. I've been looking at trying something similar, the Bosch M4 seems a lot of money for what it is given there isn't much of a change from the production version at 10% of the price.
It might be worth grabbing a basic MK25 too, the MK70 might be a little small for some applications?
As a reference this might be of some use:
www.dke.de/de/Wirueberuns/MitteilungenderDKEGescha...
There are some schematics and block diagrams in there that clarify what is where, in particular in the ASICs.
I would think there is some value in trying to reuse the existing PCU ('3' on the MK70 picture) as that contains all the useful drivers and interfacing. There should be an SPi bus on there & I would hope it would be possible to map out the functionality once you have a rig to exercise the system?
Also wondering what (if any) JTAG is on the board as it looks like a classic example of something that would use it.
The MCU might be tougher to crack, the standard Freescale products in this line have debug ports but also sufficient security (if enabled) to prevent casual prodding. I wonder if it is a write-once version or not; I personally wouldn't like to build something in volume that couldn't be updated if there was an error in the cal.
I also wonder exactly what hardware variations exist - there seem to be quite a few options that can be put on the MK70 but I don't see any that would need more than software adjustments?
How exactly is the calibration process normally carried out? Is it on a dedicated version of the hardware, or production hardware with custom software to allow calibration upload, or is it production hardware & software but with a coding to allow calibration to be altered?
The M4 seems relatively simple software wise in terms of having standardised models where you alter the key parameters to match the platform. Are the production versions similar (i.e standardised model plus parameter table) or is it autogen code so the parameters are an integral part of the model?
I would think that the best option ultimately would be something similar to the M4 approach with a basic feature set enabled and the ability to set up the key parameters, rather than re-engineering the control side completely? I'd be wary of trying to recreate the redundant self checking and the model interactions.
Have you made any enquiries with RacerMike? I seem to remember he specialises in calibrating this sort of thing so there might be some clues to be had.
Either way it will be interesting to see the results.
It might be worth grabbing a basic MK25 too, the MK70 might be a little small for some applications?
As a reference this might be of some use:
www.dke.de/de/Wirueberuns/MitteilungenderDKEGescha...
There are some schematics and block diagrams in there that clarify what is where, in particular in the ASICs.
I would think there is some value in trying to reuse the existing PCU ('3' on the MK70 picture) as that contains all the useful drivers and interfacing. There should be an SPi bus on there & I would hope it would be possible to map out the functionality once you have a rig to exercise the system?
Also wondering what (if any) JTAG is on the board as it looks like a classic example of something that would use it.
The MCU might be tougher to crack, the standard Freescale products in this line have debug ports but also sufficient security (if enabled) to prevent casual prodding. I wonder if it is a write-once version or not; I personally wouldn't like to build something in volume that couldn't be updated if there was an error in the cal.
I also wonder exactly what hardware variations exist - there seem to be quite a few options that can be put on the MK70 but I don't see any that would need more than software adjustments?
How exactly is the calibration process normally carried out? Is it on a dedicated version of the hardware, or production hardware with custom software to allow calibration upload, or is it production hardware & software but with a coding to allow calibration to be altered?
The M4 seems relatively simple software wise in terms of having standardised models where you alter the key parameters to match the platform. Are the production versions similar (i.e standardised model plus parameter table) or is it autogen code so the parameters are an integral part of the model?
I would think that the best option ultimately would be something similar to the M4 approach with a basic feature set enabled and the ability to set up the key parameters, rather than re-engineering the control side completely? I'd be wary of trying to recreate the redundant self checking and the model interactions.
Have you made any enquiries with RacerMike? I seem to remember he specialises in calibrating this sort of thing so there might be some clues to be had.
Either way it will be interesting to see the results.
Edited by Jonesy23 on Monday 20th May 23:06
Mr2Mike said:
PhillipM said:
Provided the driver locks the wheels 
For 86 meters as well 
It would be ammusing to put in a "human" abs control case, say an expert driver having a good stab at cadence braking and see what the results were?
Jonesy23 said:
lots of interesting and useful stuff
Thanks for that document regarding Continentals ABS systems, it confirms at lot of what i had found/guessed about the two controllers i have looked at!Regarding trying to use the PC ASIC (Periferal Controller), well it would be good to leverage all the "on one chip" capabilities, but i'm not sure that it would be possible to fully reverse engineer the device from the SPI bus. Yes, most of the comands and responses can be easily interogated, but there is so much more on there (Like CAN trancievers, PSUs, Lines, WSinterfaces etc) that you could spend a very long time indeed trying to work out what was going on. And the last thing you need on a failure critical system is some unexplained / unexplored event occuring!
There are plenty of comercially availible smart driver IC's around, that are fully documented. Something like the Freescale Octal switch mc33879:
Octal SPi switch
Also, by having more descrete parts the design is more flexible (at the expense of more cost and possibly a higher failure rate.
Some simplification can also be gained by limiting the operating range of the device. Normal Automotive things are rated -40 to 125degC, so your ABS works underbonnet from Sweeden to Death Valley. Well, for 99% of people that's a bit of an overkill
Regarding the processor internal safety watchdogs, there are plenty of things you can do to provide a basic but robust level of code execution checking. For example, it is common to have a sub routine who's only purpose is to toggle an output pin. You AC couple that pin to a charge pump circuit (capacitors and a couple of diodes) so whilst it is toggling the output of that pump is "high". If the processor falls into an random state (such as an unexpected jump to a blank ISR) then the pin doesn't get toggled, the charge pump doesn't pump charge, the voltage on the output falls to zero, and you use that to say disable the main power switch to the solenoids (ie system hard off). Now of course, there is some chance (v small) that the processor might get stuck in just the "toggling" routine, so to avoid this case you turn the pin "on" in one routine, and "off" in another. No way can it get stuck in TWO seperate sub routines, so that gives you a very simple, very low code line count watchdog for your code execution.
Another trick is to have a global value, to which you simply add 1 at the start (and exit if you like) of every critical subrountine. Then you have a diagnostic routine that runs say every 100ms, in which you check how large the value of that global counter has got to. If your system is executing in a properly deterministic fashion, that value should not vary. To check for memory errors, you can store say 10 of these counters across the memory space, and any error or accidental overwriting will get caught too. Finally, i would send the value of these counters over say an internal USART link to another processor, that also checks the value is as expected.
Max_Torque said:
Of course, completely locked wheels is worst case. but tell me that if you were driving our virtual car, at 60mph, and only 65m away from the edge of a 1000m cliff you had to do an all out stop without ABS you could calmly limit brake the car to a halt? As countless numbers of people have found out, the brain saying "lift off your foot the wheels are locked" and your leg actually doing it at moments of "terror" are two very different things! ;-)
That's what the steering wheel is for Or hit the accelerator and make it a good one
PhillipM said:
Max_Torque said:
Of course, completely locked wheels is worst case. but tell me that if you were driving our virtual car, at 60mph, and only 65m away from the edge of a 1000m cliff you had to do an all out stop without ABS you could calmly limit brake the car to a halt? As countless numbers of people have found out, the brain saying "lift off your foot the wheels are locked" and your leg actually doing it at moments of "terror" are two very different things! ;-)
That's what the steering wheel is for Or hit the accelerator and make it a good one
PhillipM = Evil Kenevil??? ;-)
(mind you, your buggy probably has enough suspension travel to pull off the landing at the bottom!)
So are you planning to add extra sensors (steering angle, X/Y accel, etc) or just leave it with the bare minimum? I know that you don't really need them but on the other hand it does give you a better idea of what is actually happening/intended vs. relying on estimations.
Also what sort of algorithms are you looking at? There are some interesting ones for the wheel sensor data for getting the surface friction at constant speed and for tyre pressure estimation. I assume you'll be adding the channel interactions to cope with things like split mu?
Hopefully the test process won't get too entertaining; I once had a car with a MK60E that despite all the self checks etc. etc. would spontaneously decide it needed to intervene & (for example) attempt to correct for severe understeer that wasn't actually happening, which makes life interesting when you're initially doing 70mph in a straight line. Cue some discussion, 'it can't do that', 'try it for a day or two', 'oops'. Never did find out what was wrong as I never saw that car again.
Also what sort of algorithms are you looking at? There are some interesting ones for the wheel sensor data for getting the surface friction at constant speed and for tyre pressure estimation. I assume you'll be adding the channel interactions to cope with things like split mu?
Hopefully the test process won't get too entertaining; I once had a car with a MK60E that despite all the self checks etc. etc. would spontaneously decide it needed to intervene & (for example) attempt to correct for severe understeer that wasn't actually happening, which makes life interesting when you're initially doing 70mph in a straight line. Cue some discussion, 'it can't do that', 'try it for a day or two', 'oops'. Never did find out what was wrong as I never saw that car again.
RE:sensor pack. I'm planning on definitely having MasterCyl hydraulic pressure, Steering Angle(SAS), YAW and Longitudinal Accel. (Possibly Lateral Accel too)
System I/O is going to be roughly speaking:
1) 12v BattV+ (KL30) (two, input pins = pump 20A fused + system pwr 5A fused)
2) 12v Ign+ (KL15) wakeup - ignition feed to power up system on key-on
3) 4 x wheelspeed sensor inputs (7/14mA two wire type sensors)
4) CAN1 bus to talk to SAS,YAW,ACCEL sensors and anything else additional (ECU, Datalogger,Dash etc)
5) CAN2 bus optional system calibration/setup bus, using CCP / UDS protocols (probably separate connector)
6) ABS system warning lamp input (low side driven dash mounted system fail indicator)
7) Brake reservoir LOW fluid level switch input
8) Brake pedal pressed input (from brake lamp switch on pedal)
9) Master cylinder Hydraulic pressure sensor input
10) ABS 'MODE' selection switch input (dash mounted rotary switch for operation mode, inc OFF)
11) Chassis Earth
12) Emergency Stop switch input (Optional and maybe only on DEV systems)
Things like the dash warning lamp will be actively "turned off" by the ABS module, so faults should definitely illuminate the lamp (will do a 5sec bulb check on key-on)
System I/O is going to be roughly speaking:
1) 12v BattV+ (KL30) (two, input pins = pump 20A fused + system pwr 5A fused)
2) 12v Ign+ (KL15) wakeup - ignition feed to power up system on key-on
3) 4 x wheelspeed sensor inputs (7/14mA two wire type sensors)
4) CAN1 bus to talk to SAS,YAW,ACCEL sensors and anything else additional (ECU, Datalogger,Dash etc)
5) CAN2 bus optional system calibration/setup bus, using CCP / UDS protocols (probably separate connector)
6) ABS system warning lamp input (low side driven dash mounted system fail indicator)
7) Brake reservoir LOW fluid level switch input
8) Brake pedal pressed input (from brake lamp switch on pedal)
9) Master cylinder Hydraulic pressure sensor input
10) ABS 'MODE' selection switch input (dash mounted rotary switch for operation mode, inc OFF)
11) Chassis Earth
12) Emergency Stop switch input (Optional and maybe only on DEV systems)
Things like the dash warning lamp will be actively "turned off" by the ABS module, so faults should definitely illuminate the lamp (will do a 5sec bulb check on key-on)
one eyed mick said:
Is it honestly worth the agravation never mind the cost ? just learn to cadence brake
And of course fit another three brake pedals and grow a couple of extra feet so you can operate them all simultaneously. Easy! I can see why you wouldn't bother with ABS........ ;-)
Gassing Station | Engines & Drivetrain | Top of Page | What's New | My Stuff