Fullscreen HTML5Med Res (??MB)HTML4

Making sense of all the information Part 2: by Julian Edgar Race Car Data Logging This data screen shows the car, a Formula Ford, half way through Turn 4 at the Philip Island circuit on Lap 5. (The map in the bottom right-hand corner shows this location.) From top to bottom, five parameters have been chosen for graphing. These are: engine speed (4814 RPM at this point); corrected speed (78.8km/h); throttle position (85.3 per cent); longitudinal acceleration (0.23g); and steering angle (1.7 degrees). In addition to the graphed information, the other logged parameters are also available in table form. They include engine oil pressure (32.63 psi); lateral acceleration -1.31g; suspension heights (front-left: -4.9mm, front-right: 11.3mm, rear-left: 11.9mm, rear-right: -1.1mm) and so on. Any of these parameters can be selected for graphing. By moving the vertical blue cursor to the left or right, the status of the car at any position on the track can be displayed. siliconchip.com.au siliconchip.com.au Staying on Turn 4, the race engineer can zoom in on the graphed data so that instead of looking at one complete lap, he or she is looking at only 10 seconds or so. The engineer can then overlay the logged data from another lap – here this other data is from Lap 1 and shown in black. This indicates that the driver on Lap 1 drove quite differently; exiting Turn 4 he was 12km/h quicker and the mid-corner steering input was dramatically changed. Note the throttle use – a racing car spends most of its time at either zero or 100 per cent throttle. The data in the right-hand column can be configured to show the absolute numbers or the relative difference between them; the latter has been done here. August ugust 2006  83 2006  83 A L ast month we looked at the data that is now routinely logged from sensors in racing cars. But when the car has come into the pits, what does the race engineer do with the logged information? It’s interpretation, rather than collection of information which is of the utmost importance in improving lap times. And this is where data analysis software like MoTeC’s i2 is used. When a drag run, such as that shown opposite, can be over in under five seconds, having the ability to carefully and slowly play back data log records is a huge advantage. The first stage in analysing the data is to put it into a frame of reference. It’s no good simply knowing that for Video footage can be synchronised with the data as it is played back real time, allowing observation of the driver or even such aspects as suspension deflection or anti-roll bar behaviour. Data can be logged to either a digital dash or the existing programmable engine management unit. example the peak engine speed was 6354 RPM and at one stage the car was travelling at 217.9km/h. That frame of reference is provided by the track map. Using the data collected by the lateral accelerometer and speed sensor or longitudinal accelerometer, the software is able to construct a virtual track map. The different sections of the track can then be automatically or manually Any of the logged parameters can be displayed in a ‘gauge’ format. The gauges are user-definable and can comprise circular bargraphs, traditional gauges with pointers, bar graphs, or on/off status blocks. In addition, a graphic showing the steering wheel position can be added and the track map can be used to show the location of the car when the data was collected. As with the graphing described above, when the position of the car on the track is altered, the gauges also change to show what is occurring. An animation function is also available where the car automatically ‘drives’ around the track, the gauges reflecting the changing status as it does so. This animation can occur at actual car speed or anywhere from 0.1 to 100 times real speed. More than one lap can be displayed simultaneously, with the second lap’s data displayed with black needles, bars and steering wheel. In addition to displaying the logged parameters, the MoTeC i2 software can also calculate data from the logged information. It does this by using maths expressions either supplied in the software or added by the user. For example, Oversteer (ie, the car yawing because the rear of the car is sliding laterally) is calculated using the following expression: Oversteer (rad) = smooth(choose(‘Corr Speed’[km/h]<50, 0, sgn(‘G Force Lat[m/s/s])*((‘Vehicle Wheelbase’[m]*’G Force Lat[m/s/s]/sqr(‘Corr Speed’[m/s])) – sgn(stat_mean(‘Steered Angle’[rad]*’G Force Lat’[m/s/s]))*’Steered angle’[rad])), 0.2) This calculated data can then be graphed along with the logged data. For example, here mid-corner the car is showing a calculated -3.9° of oversteer with a measured steering angle of 7.8°, a speed of 75.5km/h and a throttle position of 49.7%. 84  Silicon Chip siliconchip.com.au labelled (eg, “Turn 1” and “Straight 4-5”), allowing the analysis of data to proceed, based on where on the track the car was at the time. Other Functions In addition to the screens shown here, the i2 software can: • Draw scatter graphs (for example, graphing brake pressure versus front/rear brake bias - a technique that shows if the dual master cylinder brake pedal mechanism is flexing); • Correlate imported video imagery with the movement of the car around the track (in addition to showing the driver in action, video cameras can be used to examine suspension arm flexing and adjustable anti-roll bar behaviour); • Draw histograms for any of the logged parameters (eg showing the time the engine spends at different revs at full throttle, allowing optimisation of the shape of the engine power curve for that track). Conclusion The days of the driver down-changing too early, overreving the engine and then blaming something else for the engine failure are well and truly gone. In fact, one can almost feel pity for the driver who has every single one of their driving actions analysed in such detail! However, to be competitive in any high level motor sport, logging and analysis software has become vital. Another calculated value is damper (shock absorber) velocity expressed, in mm/s. This is calculated by the software on the basis of damper position and time and is most usually displayed in histogram form. The histogram bars correspond to 10 mm/s increments and both bump and rebound velocities are shown. A division between high speed and low speed damper movements is set that matches the damper valving characteristics (eg, 25 mm/s) and then analysis is possible of the proportion of time each damper spends moving at the different velocities in both low speed and high-speed bump and rebound. Specialist race car engineers suggest that symmetrical suspension damper velocity histograms (as here) show the correct bump and rebound damper settings are being used. This information is impossible to collect and view without sophisticated data logging and analysis software. siliconchip.com.au Data is logged and later analysed in all racing cars. Making sense of the collected information is the task of the race car engineer working with a dedicated analysis software package. The MoTeC I2 software shown here is available as a free download from http://software.motec.com.au/release/ The software comes with sample logs. MoTeC Pty Ltd. Phone: (03) 9761 5050. Website: www.motec.com The previous displays show a circuit racing car but data analysis is equally as important with a drag car. This screen grab shows data from a drag racing car at the Willowbank track in Queensland. Engine RPM and temperatures of the eight exhausts are shown on the graphs, while the righthand column again shows other data that was logged. This includes a longitudinal acceleration of over 4g(!), a supercharger boost pressure of 36 psi and a fuel flow of just under 44 US gallons/minute. (Note the facility of the software to mix and match units; purists may hate it but it’s the way of the racing world.) At this stage in the run wheel speed was only 33.5km/h; just over five seconds SC later it was 446km/h! August 2006  85