Last week (see MoTeC’s Race Car Data Logging,
Part 1) we looked at the data that’s now routinely logged from sensors in
racing cars. But when the car has pitted, what does the race engineer do with
the logged information? It’s the interpretation – rather than the collection –
of the information which is of the greatest importance in improving lap times.
And that’s where data analysis software like MoTeC’s i2 comes in.
The first stage in analysing the data is to put it
into a frame of reference: it’s no good simply knowing that for example the peak
engine speed was 6354 rpm and at one stage the car was travelling at 217.9 km/h.
That frame of reference is provided by the track map. From 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 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.
This data screen shows that the car – a Formula
Ford - was halfway 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.8 km/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 line to the left or
right, the status of the car at any position on the track can be displayed.
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 12 km/h quicker and the mid-corner steering input was dramatically changed.
Note also 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.
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 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. So for example, here mid-corner the car is showing a
calculated -3.9 degrees of oversteer with a measured steering angle of 7.8
degrees, a speed of 75.5 km/h and a throttle position of 49.7 per cent.
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 data is impossible to
collect and view without sophisticated data logging and analysis software.
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 exhaust gas temperatures
of the eight exhausts are shown on the graphs, while the right-hand 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. At this stage in the run wheelspeed was only 33.5
km/h; just over 5 seconds later it was 446 km/h!
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,
over-reving 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.
|