ABS on track / competition car?
Discussion
A bit of a treasure hunt around various boxes in my Man Cave turned up some usefully parts to start constructing my ABS module test rig:
12V air compressor, large air tank (13l,rated to 18bar) couple of Audi master cylinders (with brake system pressure sensors) a nice large Pneumatic ram, various pressure sensors, a Linear position sensor, and a couple of 2/3 12v air solenoids! (what was the Game show where you had to memorise random items on the conveyor called again??)
12V air compressor, large air tank (13l,rated to 18bar) couple of Audi master cylinders (with brake system pressure sensors) a nice large Pneumatic ram, various pressure sensors, a Linear position sensor, and a couple of 2/3 12v air solenoids! (what was the Game show where you had to memorise random items on the conveyor called again??)
What would be interesting to know is exactly which parameters are changed by the 12 position "ABS Mapping" rotary switch on the Bosch Msport M4 system? It seems to pretty much go from a "full wet" selection to "OFF".
The great thing about my simulation model is that i can quickly change parameters and get an idea for how they change the dynamic balance:
Take the classic "Magic Tyre" graph:
There is one small zone of tyre slip magnitude that delivers maximum retardation. So clearly the system has to "decide" how much slip it is going to target and control too. But depending on the surface conditions that could be different for each tyre (not just oil or ice, but also "lofting a kerb" on a track for example). And whilst the system can control individual brake torque for every wheel, if the frictional (or vertical loading) conditions are different, this will introduce a yawing moment into the chassis. And then you need a decision of "stability Vs retardation".
The main parameters seem to be:
1) Average slip value: what % of slip to target as an average for all 4 wheels
2) Front to rear slip ratio: How much less slip do you allow on the rear to maintain lateral stability
3) Cross axle brake torque imbalance: The balance between getting the car stopped in the shortest distance, but preferably facing the right way when it does so! ;-)
For 1), the average slip value, this can easily be calculated from an integrated value of longitudinal g during the braking event, but i can still imagine a lot of drivers wanting to be able to affect how much the ABS seems to be doing etc.
For 2) this i can definitely see needing to be adjustable to taste, as one persons "unstable" is another ones "fun"
For 3) having a SAS and yaw sensor means the system can be self balancing to a large degree. i.e. pick max deccel until excessive un-commanded yaw is determined.
For development i think i'll make a 4 channel CAN "pot box" that allows the easy modification of any particular variable on-the-fly for R&D purposes. These settings can then perhaps be boiled down to a single pot for most installations etc
The great thing about my simulation model is that i can quickly change parameters and get an idea for how they change the dynamic balance:
Take the classic "Magic Tyre" graph:
There is one small zone of tyre slip magnitude that delivers maximum retardation. So clearly the system has to "decide" how much slip it is going to target and control too. But depending on the surface conditions that could be different for each tyre (not just oil or ice, but also "lofting a kerb" on a track for example). And whilst the system can control individual brake torque for every wheel, if the frictional (or vertical loading) conditions are different, this will introduce a yawing moment into the chassis. And then you need a decision of "stability Vs retardation".
The main parameters seem to be:
1) Average slip value: what % of slip to target as an average for all 4 wheels
2) Front to rear slip ratio: How much less slip do you allow on the rear to maintain lateral stability
3) Cross axle brake torque imbalance: The balance between getting the car stopped in the shortest distance, but preferably facing the right way when it does so! ;-)
For 1), the average slip value, this can easily be calculated from an integrated value of longitudinal g during the braking event, but i can still imagine a lot of drivers wanting to be able to affect how much the ABS seems to be doing etc.
For 2) this i can definitely see needing to be adjustable to taste, as one persons "unstable" is another ones "fun"
For 3) having a SAS and yaw sensor means the system can be self balancing to a large degree. i.e. pick max deccel until excessive un-commanded yaw is determined.
For development i think i'll make a 4 channel CAN "pot box" that allows the easy modification of any particular variable on-the-fly for R&D purposes. These settings can then perhaps be boiled down to a single pot for most installations etc
Max_Torque said:
1) Average slip value: what % of slip to target as an average for all 4 wheels
2) Front to rear slip ratio: How much less slip do you allow on the rear to maintain lateral stability
3) Cross axle brake torque imbalance: The balance between getting the car stopped in the shortest distance, but preferably facing the right way when it does so! ;-)
1. Lots.2) Front to rear slip ratio: How much less slip do you allow on the rear to maintain lateral stability
3) Cross axle brake torque imbalance: The balance between getting the car stopped in the shortest distance, but preferably facing the right way when it does so! ;-)
2. Lots.
3. Lots, I have a steering wheel.
I'm an easy man to please.
Re. the mapping switch, I suspect the best way to find out what it does is to follow the manual and get in contact with Bosch Motorsport about what the 'custom map' settings can do for you as a customer. The published manual is very short on performance data but I would expect more to be available. For comparison the engine management manuals give quite a lot of internal functional information.
The other thing I find interesting is the large number of excess CAN messages the M4 chucks out. Poking into the matching .dbc file shows the 'M4 specific' database is actually a major fragment of the Porsche 987/997 generic. Which makes me wonder if the M4 is even closer to the production 8.0 ABS than expected, as I'd have thought if it was a 'special' that all the excess functions and messages would have been knocked out? This feels more like a particular coding is applied to a normal production model to put it into development mode. Would also explain why an expensive vendor specific interface is needed to configure it rather than allowing something generic as the M4 probably has exactly the same security access controls on the configuration as any other version.
This also reminds me that the manual indicates the mapping control was a late addition to the M4 but can be retrofitted to earlier models, which makes me think it was a generic development feature in the baseline production version but inactive? (If it was active it would have thrown out errors about the analog controls)
The other thing I find interesting is the large number of excess CAN messages the M4 chucks out. Poking into the matching .dbc file shows the 'M4 specific' database is actually a major fragment of the Porsche 987/997 generic. Which makes me wonder if the M4 is even closer to the production 8.0 ABS than expected, as I'd have thought if it was a 'special' that all the excess functions and messages would have been knocked out? This feels more like a particular coding is applied to a normal production model to put it into development mode. Would also explain why an expensive vendor specific interface is needed to configure it rather than allowing something generic as the M4 probably has exactly the same security access controls on the configuration as any other version.
This also reminds me that the manual indicates the mapping control was a late addition to the M4 but can be retrofitted to earlier models, which makes me think it was a generic development feature in the baseline production version but inactive? (If it was active it would have thrown out errors about the analog controls)
From a safety perspective, it is not unlikely that BOSCH have used the complete "road car" control code in it's entirety in the M$ system. Afterall, that will have thousands of hrs of validation behind it, so they can't really change any of it (deleting sub functions or any code alteration will negate that validation)
It's not surprising they picked a "track" biased road car strategy like from a Porsche etc either!
This also comes through in "non activated" inputs used for development purposes. For example most engine ECU's have a second CAN bus that is often not used (loom isn't populated in ECU connector) but has been used for development activities.
For sure the M4 system will need an OEM style "calibration application" with data transmission over CAN to tune it. (I'd bet £100 they use ETAS INCA over XCP btw ;-)
It's not surprising they picked a "track" biased road car strategy like from a Porsche etc either!
This also comes through in "non activated" inputs used for development purposes. For example most engine ECU's have a second CAN bus that is often not used (loom isn't populated in ECU connector) but has been used for development activities.
For sure the M4 system will need an OEM style "calibration application" with data transmission over CAN to tune it. (I'd bet £100 they use ETAS INCA over XCP btw ;-)
Where I was really coming from was that it looked like to create an 'M4' might not actually take too much effort beyond finding a module from a Boxster and putting the right model coding into it. The coding process itself seems straightforward. I guess there could be a zero ohm config link or similar on the control board too but not necessarily.
After all if the M4 seems similar to a particular version for an OEM, it probably *is* that version. If there are risks and costs in revalidating for what is a tiny market then there probably aren't any changes beyond model coding as when installing the module between 987/997 and the various sub-models.
I had originally thought the M4 might have been developed based on the generic 8.0 module, with only the most basic functionality compiled in. After all the basic module would have to be validated in itself and there are no claims around the M4 about it being safe or suited to a specific vehicle. But apparently not.
The things that would stop people trying to adapt a standard module into an M4 (even if simple) would be:
- the effort involved would be expensive compared to just buying an M4
- you still need a really expensive config cable to do the basic setup
- you still need an M4 for reference to find out what changes you'd need to make
- the prospect of fiddling with a safety critical component like this requires more bravery/stupidity than most people possess!
- if it went wrong you'd have a lot of problems that you couldn't deflect to a supplier & the liability situation would be interesting compared to having the 'proper' version.
I think for getting into actual calibration maps things would get complicated, as I understand it any custom maps for the M4 are handled entirely by Bosch staff (or subbies) and they wouldn't disclose any detail. And it wouldn't really matter what the original settings were in this case, 997 derived or otherwise.
But the basic platform specific settings (eg. weights & dimensions) are probably enough alongside the map selector & that only needs the COTS config tool.
Anyway building something up from scratch is more interesting and gives more options for playing with the data. So stick with that idea!
After all if the M4 seems similar to a particular version for an OEM, it probably *is* that version. If there are risks and costs in revalidating for what is a tiny market then there probably aren't any changes beyond model coding as when installing the module between 987/997 and the various sub-models.
I had originally thought the M4 might have been developed based on the generic 8.0 module, with only the most basic functionality compiled in. After all the basic module would have to be validated in itself and there are no claims around the M4 about it being safe or suited to a specific vehicle. But apparently not.
The things that would stop people trying to adapt a standard module into an M4 (even if simple) would be:
- the effort involved would be expensive compared to just buying an M4
- you still need a really expensive config cable to do the basic setup
- you still need an M4 for reference to find out what changes you'd need to make
- the prospect of fiddling with a safety critical component like this requires more bravery/stupidity than most people possess!
- if it went wrong you'd have a lot of problems that you couldn't deflect to a supplier & the liability situation would be interesting compared to having the 'proper' version.
I think for getting into actual calibration maps things would get complicated, as I understand it any custom maps for the M4 are handled entirely by Bosch staff (or subbies) and they wouldn't disclose any detail. And it wouldn't really matter what the original settings were in this case, 997 derived or otherwise.
But the basic platform specific settings (eg. weights & dimensions) are probably enough alongside the map selector & that only needs the COTS config tool.
Anyway building something up from scratch is more interesting and gives more options for playing with the data. So stick with that idea!
Max_Torque said:
For sure the M4 system will need an OEM style "calibration application" with data transmission over CAN to tune it. (I'd bet £100 they use ETAS INCA over XCP btw ;-)
Free download matey. Along with firmware (althought that might not be for the M4)http://www.bosch-motorsport.de/content/language2/h...
Jonesy23 said:
Where I was really coming from was that it looked like to create an 'M4' might not actually take too much effort beyond finding a module from a Boxster and putting the right model coding into it. The coding process itself seems straightforward. I guess there could be a zero ohm config link or similar on the control board too but not necessarily.
After all if the M4 seems similar to a particular version for an OEM, it probably *is* that version. If there are risks and costs in revalidating for what is a tiny market then there probably aren't any changes beyond model coding as when installing the module between 987/997 and the various sub-models.
Interestingly there is a DBC file for the ABS M4 supplied, within there there are the following linesAfter all if the M4 seems similar to a particular version for an OEM, it probably *is* that version. If there are risks and costs in revalidating for what is a tiny market then there probably aren't any changes beyond model coding as when installing the module between 987/997 and the various sub-models.
VAL_TABLE_ LSS_Ident 1 "Sportwagen" 0 "Cayenne" ;
VAL_TABLE_ MOTOR_CODE 7 "GT2" 6 "GT3" 5 "3.6l" 4 "2.7l" 3 "Turbo" 2 "3.8l" 1 "3.2l" 0 "3.4l" ;
VAL_TABLE_ Fzg_Typ 3 "Rennversion" 2 "Targa" 1 "Cabrio" 0 "Coupe" ;
VAL_TABLE_ Fzg_Modell 4 "997 C4 / C4S" 3 "Turbo" 2 "987S" 1 "987" 0 "997 C2 / C2S" ;
I can't find any other makes referenced in there apart from Porsche so you might well not be far off the mark.
I think we need to understand the distinction between coded "strategy" and coded "calibration".
The strategy bit is the complied machine code instructions that control the processing actions of the microprocessor used. This includes things like memory allocations, peripherals (Timers, CounterCompares, DMA etc etc), and directly coded control algorythms (probably autocoded using AutoSars into C from a Simulink model for example). This machine code is critical, and must be used in it's entirety, and without change, because the Optimiser function in the Complier will change the execution path, order, and Stack layout if functions are removed or modified. For a safety critical application, you rely on your T&D and validation programs running the exact same processor environment as for production.
Secondary is the Calibration data. These tables of numbers CAN be changed without significant issue to the safety case. There still needs to be suitable memory validation (checksums, access counters etc) to be sure that these data tables contain the numbers you think they do. For example, imagine the calibration value for "min speed for ABS", set to say 7mph, and what would happen if they got corrupted to 70mph.
So, whilst i suspect the M4 system does use production strategy, i'm sure that a lot of the calibration data will be unique to each application, and as you say, requires Bosch engineering effort to optimise it for the particular application.
Generally speaking, a typical CCP based calibration tool will allow data transfer (for both datalogging and calibration purposes) over the CAN bus, using a .A2l file to "map" the values to physical memory locations within the running processor. Unfortunately, pretty much without exception, this data exchange is prohibited until a secure handshake has occurred between the Calibration application and the embedded processor. This "seed and key" data exchange on the CAN bus is easy to snoop on (as CAN is not a secure network) but difficult to reverse engineer. With access to an M4 system and cal tool running on a laptop, it would probably be possible to hack the handshake (or you would need a "source" inside Bosch itself), however the effort expended to do that will i agree be better spent on just developing a separate and fully configurable alternative control pcb that can be installed in a cheaply bought road system.
Most of the basic "coding" information contained within a modern controller is actually used for diagnostic purposes. On key-on, all the modules on the CAN bus exchange coding "Model" info to determine if they are all from the same car. This is required by EU mandate, as there was a concern that emissions regulations /safety stds could be bypassed if owners fitted the control modules from another model of car mistakenly etc. of course, some of this coding info will be used operationally, for example to tell the traction control system if the model is front or rear wheel drive etc, or to enable feature sets such as cruise control, or lane guidance etc etc which are model specific. All major control units introduced since EU5 regulations will also be "field flashable", in that their calibration data memory can be modified (again using XCP/CCP) without physical access to the module. This again stems from EU law, where they require the control system to be easily updateable if issues are found over the platforms life time (safety updates, failure of "in-use" emissions compliance etc)
The strategy bit is the complied machine code instructions that control the processing actions of the microprocessor used. This includes things like memory allocations, peripherals (Timers, CounterCompares, DMA etc etc), and directly coded control algorythms (probably autocoded using AutoSars into C from a Simulink model for example). This machine code is critical, and must be used in it's entirety, and without change, because the Optimiser function in the Complier will change the execution path, order, and Stack layout if functions are removed or modified. For a safety critical application, you rely on your T&D and validation programs running the exact same processor environment as for production.
Secondary is the Calibration data. These tables of numbers CAN be changed without significant issue to the safety case. There still needs to be suitable memory validation (checksums, access counters etc) to be sure that these data tables contain the numbers you think they do. For example, imagine the calibration value for "min speed for ABS", set to say 7mph, and what would happen if they got corrupted to 70mph.
So, whilst i suspect the M4 system does use production strategy, i'm sure that a lot of the calibration data will be unique to each application, and as you say, requires Bosch engineering effort to optimise it for the particular application.
Generally speaking, a typical CCP based calibration tool will allow data transfer (for both datalogging and calibration purposes) over the CAN bus, using a .A2l file to "map" the values to physical memory locations within the running processor. Unfortunately, pretty much without exception, this data exchange is prohibited until a secure handshake has occurred between the Calibration application and the embedded processor. This "seed and key" data exchange on the CAN bus is easy to snoop on (as CAN is not a secure network) but difficult to reverse engineer. With access to an M4 system and cal tool running on a laptop, it would probably be possible to hack the handshake (or you would need a "source" inside Bosch itself), however the effort expended to do that will i agree be better spent on just developing a separate and fully configurable alternative control pcb that can be installed in a cheaply bought road system.
Most of the basic "coding" information contained within a modern controller is actually used for diagnostic purposes. On key-on, all the modules on the CAN bus exchange coding "Model" info to determine if they are all from the same car. This is required by EU mandate, as there was a concern that emissions regulations /safety stds could be bypassed if owners fitted the control modules from another model of car mistakenly etc. of course, some of this coding info will be used operationally, for example to tell the traction control system if the model is front or rear wheel drive etc, or to enable feature sets such as cruise control, or lane guidance etc etc which are model specific. All major control units introduced since EU5 regulations will also be "field flashable", in that their calibration data memory can be modified (again using XCP/CCP) without physical access to the module. This again stems from EU law, where they require the control system to be easily updateable if issues are found over the platforms life time (safety updates, failure of "in-use" emissions compliance etc)
Sad thing is that even though it's got easier to reflash modules this has made the actual data security that much harder to crack. It used to be that it you knew the access key then it was just a matter of knowing the right locations to toggle features on and off and maybe setting the checksum(s) (on body control stuff at least!), these days you're more likely to find you need a complete encrypted configuration package with the right digital certificate or you'll get nowhere.
On a personal level it would be interesting to have a proper poke at an M4 with the supplied tools and see what happens. Just enough to see exactly where the wheel mass and other data goes, which is enough for the basic adaptation. Full calibration seems strictly optional & is the part the end user really can't get at. But the cost of getting the hardware to investigate isn't justifiable.
But as a project a 'new' controller (compared to cracking the existing one) does have the advantage that you don't run any risk of the trouble that would come if you worked out the access keys & configuration map then disclosed it. Some people can get a bit funny about that kind of thing.
Anyway, getting back to the new controller... re. the hydraulic control are you planning to do some live measurement of how the existing controller drives the valves? I know you have calculated the theoretical response rate of the solenoid but I wouldn't rule out there being some interesting games with pulse control or modulation to boost response time or to give more control options. It would also be interesting to see how much (if at all) the system pressure measurement is involved in the valve control strategy.
And re. the wheel sensors, I know that the required sampling rate for the data seems quite low based on the tooth count and rotation rate, but there is a lot to be gained from sampling at a higher rate. At a basic level you will only get wheel rotation rate and direction from the sensor, but if you look more closely at the sensor you can extract the rotational vibration data from the wheel from which you can derive the instantaneous tyre/road friction which is useful stuff to have. Have a look at this http://www.tytlabs.com/english/review/rev373epdf/e...
On a personal level it would be interesting to have a proper poke at an M4 with the supplied tools and see what happens. Just enough to see exactly where the wheel mass and other data goes, which is enough for the basic adaptation. Full calibration seems strictly optional & is the part the end user really can't get at. But the cost of getting the hardware to investigate isn't justifiable.
But as a project a 'new' controller (compared to cracking the existing one) does have the advantage that you don't run any risk of the trouble that would come if you worked out the access keys & configuration map then disclosed it. Some people can get a bit funny about that kind of thing.
Anyway, getting back to the new controller... re. the hydraulic control are you planning to do some live measurement of how the existing controller drives the valves? I know you have calculated the theoretical response rate of the solenoid but I wouldn't rule out there being some interesting games with pulse control or modulation to boost response time or to give more control options. It would also be interesting to see how much (if at all) the system pressure measurement is involved in the valve control strategy.
And re. the wheel sensors, I know that the required sampling rate for the data seems quite low based on the tooth count and rotation rate, but there is a lot to be gained from sampling at a higher rate. At a basic level you will only get wheel rotation rate and direction from the sensor, but if you look more closely at the sensor you can extract the rotational vibration data from the wheel from which you can derive the instantaneous tyre/road friction which is useful stuff to have. Have a look at this http://www.tytlabs.com/english/review/rev373epdf/e...
I'm sure the wheel inertia (and the referenced inertia of the drivetrain if you haven't got the clutch down) will just be used to modify the feedfoward system response terms. i.e. the rate at which it attempts to pressure cycle (because the more inertia, the longer it takes for the wheel to decelerate (under excess brake torque) and re-accelerate (driven by the tyre friction). On low Mu surfaces, accurate setting of these values will limit the control error and make a bit difference to the systems performance.
For a basic "max retard" system, brake pressure can be ignored, as the system can just respond to the actual measured tyre slip rate at each corner, and control each brake as appropriate (you don't care what the pressure is, just that you want less if the wheel decelerates too fast, and more if it doesn't)
However, the calculation of actual brake torque is very useful, as this allows for the calculation of longitudinal and lateral brake forces and the resultant direction of the force vector. The road systems boost rear brake pressure Above that applied by the driver if the front wheels are being modulated, to get the best possible stop (racing drivers are much much more likely to be already braking as hard as possible!) Direct measurement of brake pressure however allows the system to calculate the vehicles deceleration vs brake torque curve, and from that adapt and react to estimate surface friction (which they then use to select an appopriate mean slip percentage).
The simple systems that just run 8 solenoids (4 isolators, 4 reliefs) seem to just use "on-off) control, and the solenoids are powered directly from the battery voltage (Mk70 sols measure at 8.6ohms and 13mH). A faster response could be returned from either boosting battery voltage, or rewinding those solenoids for a lower series resistance / series inductance, and using a "peak - hold" driving technique. However, i don't think this is used by the simple systems. The latest DSC enabled systems do seem to drive the pressure build solenoids with an analogue control term, this i guess is to apply the hydraulic pressure generated by the ABS motor/pump with some subtlety, rather than just bang on full brake if the system senses a tiny amount of wheelspin or yaw!
For a basic "max retard" system, brake pressure can be ignored, as the system can just respond to the actual measured tyre slip rate at each corner, and control each brake as appropriate (you don't care what the pressure is, just that you want less if the wheel decelerates too fast, and more if it doesn't)
However, the calculation of actual brake torque is very useful, as this allows for the calculation of longitudinal and lateral brake forces and the resultant direction of the force vector. The road systems boost rear brake pressure Above that applied by the driver if the front wheels are being modulated, to get the best possible stop (racing drivers are much much more likely to be already braking as hard as possible!) Direct measurement of brake pressure however allows the system to calculate the vehicles deceleration vs brake torque curve, and from that adapt and react to estimate surface friction (which they then use to select an appopriate mean slip percentage).
The simple systems that just run 8 solenoids (4 isolators, 4 reliefs) seem to just use "on-off) control, and the solenoids are powered directly from the battery voltage (Mk70 sols measure at 8.6ohms and 13mH). A faster response could be returned from either boosting battery voltage, or rewinding those solenoids for a lower series resistance / series inductance, and using a "peak - hold" driving technique. However, i don't think this is used by the simple systems. The latest DSC enabled systems do seem to drive the pressure build solenoids with an analogue control term, this i guess is to apply the hydraulic pressure generated by the ABS motor/pump with some subtlety, rather than just bang on full brake if the system senses a tiny amount of wheelspin or yaw!
Something that would be worth the effort is a trawl though the patents covering these systems, there is some good information to be had which gives a view of where recent development has gone in the control side to extract more performance.
For example https://www.google.com/patents/EP1065678A1?cl=en is worth a read. Not just for the solenoid measurement & characterisation parts but also covers a lot of aspects of how the system operates.
For example https://www.google.com/patents/EP1065678A1?cl=en is worth a read. Not just for the solenoid measurement & characterisation parts but also covers a lot of aspects of how the system operates.
Cheers for that link, there is a LOT of good info around on the subject in one for or another. When i'm back to work i must also do a trawl through the SAE paper library to see what's been published etc.
I currently wondering how the systems estimate actual brake torque? Assuming it measures input hydraulic pressure from the master cylinder, during none ABS braking then using a sliding friction model of the caliper/pad/disc will get pretty close. But during ABS operation, the system is modifying the caliper pressures to meet the wheel accel setpoints, but this downstream (of the ABS module) pressure isn't measured. So, the current caliper pressure will depend both on the current solenoid mode and the time since that mode changed (in effect, the valves and system have a "time constant" for building or dropping pressure, which depends on the valves orrifice characteristic, the volume of fluid downstream (changes with brake system type/size) and the systems compressability (how much rubber hose, mech flex etc).
Hopefully rig tests will quickly demonstrate how critical that sort of estimation is for accurate pressure control. (again, not needed for pure "max stopping" ABS as that can be done entirely in the "slip control" domain)
I could imagine a fairly generic calibration, set for certain car types (say a Caterham, and ultima/noble, a scooby, and even a "aero" Single seater perhaps). From those basic setups, which work well enough to just "Bolt on" for say most applications, people could then chose if they want to spend the extra to further optimise there particular system. It also would be possible to use my test rig to characterise the basic braking hardware for any given application. I.e. kit car builder sends me their brake master cyl and calipers, and i use the rig to optimise the pressure control loops etc)?
I currently wondering how the systems estimate actual brake torque? Assuming it measures input hydraulic pressure from the master cylinder, during none ABS braking then using a sliding friction model of the caliper/pad/disc will get pretty close. But during ABS operation, the system is modifying the caliper pressures to meet the wheel accel setpoints, but this downstream (of the ABS module) pressure isn't measured. So, the current caliper pressure will depend both on the current solenoid mode and the time since that mode changed (in effect, the valves and system have a "time constant" for building or dropping pressure, which depends on the valves orrifice characteristic, the volume of fluid downstream (changes with brake system type/size) and the systems compressability (how much rubber hose, mech flex etc).
Hopefully rig tests will quickly demonstrate how critical that sort of estimation is for accurate pressure control. (again, not needed for pure "max stopping" ABS as that can be done entirely in the "slip control" domain)
I could imagine a fairly generic calibration, set for certain car types (say a Caterham, and ultima/noble, a scooby, and even a "aero" Single seater perhaps). From those basic setups, which work well enough to just "Bolt on" for say most applications, people could then chose if they want to spend the extra to further optimise there particular system. It also would be possible to use my test rig to characterise the basic braking hardware for any given application. I.e. kit car builder sends me their brake master cyl and calipers, and i use the rig to optimise the pressure control loops etc)?
My assumption was that this was where the calibration started to come in.
If you know the fluid volume, starting pressure, the flow rate of the valve and how long it takes to get from 0->100% open/closed you can make a good stab at working out what caliper pressures you'll achieve and when in response to your control inputs. This is fixed as a characteristic of the valve block and of the calipers you've configured the system for. You probably also chuck in a standard figure for any compressibility (as unlikely to vary too much between any installations) or assume this is low enough to be dealt with by adaptation either though feedback during operation or in a learning period during startup? (As there will probably be a test cycle of pump & valves & some response characteristics might be discoverable at this point)
You also need to model how the pump builds pressure under different amounts of load. And there might be some interaction in the hydraulic circuits when multiple channels are active.
At least this is all predictable and simple to model!
The relationship between caliper pressure & pad/disc friction can surely also be preconfigured to a good extent then trimmed for best performance during operation; at 10-15 cycles per second there should be some scope to measure and adapt for any difference between predicted and actual values. From the wheel sensor data you'll quickly be able to estimate the road/tyre friction (especially if you have a likely starting value from vibration measurement), and you'll already know the wheel & related inertia so next time the brakes apply you should be able to see if the contribution from the brake torque to the change in angular velocity is what you expect & trim up or down.
There must be a lot of scope built into the standard systems for adjustment for variable friction/torque in the brake itself given the way this is likely to change with temperature, wear and different pad materials.
It would be interesting to see exactly how much of the system behaviour is trimmed with feedback vs. shifting to different preconfigured strategies. I assume the system always starts with a particular strategy informed with some starting parameters (like the initial deceleration of the locking wheel), looks for the difference between predicted and actual behaviour when the system starts to cycle then either shifts wholesale to a new strategy (like from tarmac to oil/ice) if there is a gross error in response, attempts to trim for an error below threshold, or just sticks with what works if it's good enough.
If you know the fluid volume, starting pressure, the flow rate of the valve and how long it takes to get from 0->100% open/closed you can make a good stab at working out what caliper pressures you'll achieve and when in response to your control inputs. This is fixed as a characteristic of the valve block and of the calipers you've configured the system for. You probably also chuck in a standard figure for any compressibility (as unlikely to vary too much between any installations) or assume this is low enough to be dealt with by adaptation either though feedback during operation or in a learning period during startup? (As there will probably be a test cycle of pump & valves & some response characteristics might be discoverable at this point)
You also need to model how the pump builds pressure under different amounts of load. And there might be some interaction in the hydraulic circuits when multiple channels are active.
At least this is all predictable and simple to model!
The relationship between caliper pressure & pad/disc friction can surely also be preconfigured to a good extent then trimmed for best performance during operation; at 10-15 cycles per second there should be some scope to measure and adapt for any difference between predicted and actual values. From the wheel sensor data you'll quickly be able to estimate the road/tyre friction (especially if you have a likely starting value from vibration measurement), and you'll already know the wheel & related inertia so next time the brakes apply you should be able to see if the contribution from the brake torque to the change in angular velocity is what you expect & trim up or down.
There must be a lot of scope built into the standard systems for adjustment for variable friction/torque in the brake itself given the way this is likely to change with temperature, wear and different pad materials.
It would be interesting to see exactly how much of the system behaviour is trimmed with feedback vs. shifting to different preconfigured strategies. I assume the system always starts with a particular strategy informed with some starting parameters (like the initial deceleration of the locking wheel), looks for the difference between predicted and actual behaviour when the system starts to cycle then either shifts wholesale to a new strategy (like from tarmac to oil/ice) if there is a gross error in response, attempts to trim for an error below threshold, or just sticks with what works if it's good enough.
Just for info re. adapting for different applications, the M4 setup software covers the following to adjust for a particular installation:
Brake caliper displacement (front/rear)
Brake self amplification value (front/rear)
(these seem obvious for the hydraulic adaptation)
Wheel circumference
Trigger wheel count
(for speed measurement)
Vehicle weight
Wheel base
Front/rear track
(for modelling platform for comparison to sensor inputs)
Drive modus (FWD/RWD/AWD)
(for working out where there will be interactions on an axle)
Wheel weight (front/rear)
(for modelling wheel behaviour)
So my guess would be that it should be possible to build a basic strategy with these as the configurable inputs and this would be adequate for 3rd party use.
Brake caliper displacement (front/rear)
Brake self amplification value (front/rear)
(these seem obvious for the hydraulic adaptation)
Wheel circumference
Trigger wheel count
(for speed measurement)
Vehicle weight
Wheel base
Front/rear track
(for modelling platform for comparison to sensor inputs)
Drive modus (FWD/RWD/AWD)
(for working out where there will be interactions on an axle)
Wheel weight (front/rear)
(for modelling wheel behaviour)
So my guess would be that it should be possible to build a basic strategy with these as the configurable inputs and this would be adequate for 3rd party use.
^^^ that seems like a pretty basic list tbh. Interesting they don't ask for wheel inertia but calc some sort of estimate of it from wheel mass. They also look to calc a basic "fluid stiffness" characteristic from the caliper displacement value perhaps.
Hopefully next week as my (currently rather broken) wrist improves i can get a start on building the test rig, which will answer a lot of questions on just what is needed!
Hopefully next week as my (currently rather broken) wrist improves i can get a start on building the test rig, which will answer a lot of questions on just what is needed!
It may be that the configuration is based around the items an end user is likely know? I.e with the wheels it's easy to get weight & diameter values but harder to get a proper set of data for inertia.
Most likely they chuck a good guess at the likely distribution of mass within the wheel (eg. 85% at 50mm in from the outer surface) and use that to derive inertia.
A little surprised they don't have anything to account for the brake disc mass/inertia, might become a notable part of the assembly if large iron disc with a lightweight wheel. Not vital but more error than I'd like.
You'd also think there would be some way of putting in a representative value for brake performance (friction, torque or whatever).
Most likely they chuck a good guess at the likely distribution of mass within the wheel (eg. 85% at 50mm in from the outer surface) and use that to derive inertia.
A little surprised they don't have anything to account for the brake disc mass/inertia, might become a notable part of the assembly if large iron disc with a lightweight wheel. Not vital but more error than I'd like.
You'd also think there would be some way of putting in a representative value for brake performance (friction, torque or whatever).
Max_Torque said:
^^^ that seems like a pretty basic list tbh. Interesting they don't ask for wheel inertia but calc some sort of estimate of it from wheel mass. They also look to calc a basic "fluid stiffness" characteristic from the caliper displacement value perhaps.
Hopefully next week as my (currently rather broken) wrist improves i can get a start on building the test rig, which will answer a lot of questions on just what is needed!
I'd have thought some kind of COG height figure would be important for weight shift during braking? Maybe it doesn't vary enough on typical applications to matter?Hopefully next week as my (currently rather broken) wrist improves i can get a start on building the test rig, which will answer a lot of questions on just what is needed!
Gassing Station | Engines & Drivetrain | Top of Page | What's New | My Stuff