Data Logging Metrics

[ubrben]

This is a bit of a general one, but I'd be interested in people's opinions.

Having done a reasonable bit of data analysis of racing cars and motorcycles in the past few years it's definitely clear that a metric driven approach is often the best way to genuinely learn something. Basic overlays comparing drivers, etc can be useful, but the examples in books often show glaring differences that are rare when dealing with two decent drivers in the same car.

I'd be interested to hear what sort of metrics people have used and opinions in this area.

From a tyre perspective I find slip energy quite useful in quantifying circuits and sometimes drivers. Things like integrating lat and long G seem popular to get a more statistically robust view of track grip level.

I heard a while back that Pi were considering a "metric driven" software tool to complement the more traditional data analysis software. Anyone using databases to record histories of metrics vs. conditions and setup?

Ben

[Jersey Tom]

I haven't been particularly impressed with Pi's software, but it's what I'm stuck with.

I'd be curious to discuss this though.. if you see him around, you should have Emmanuel get back to Andy!

[ubrben]

Ditto. The only thing I like over i2 is the data export to Excel.

My dongle expired and the update didn't work - really not impressed at the moment. Apparently there should be someone at the track next week who can sort it, but I'll believe it when I see it

Ben

[speedsense]

This is a bit of a general one, but I'd be interested in people's opinions.

Having done a reasonable bit of data analysis of racing cars and motorcycles in the past few years it's definitely clear that a metric driven approach is often the best way to genuinely learn something. Basic overlays comparing drivers, etc can be useful, but the examples in books often show glaring differences that are rare when dealing with two decent drivers in the same car.

I'd be interested to hear what sort of metrics people have used and opinions in this area.

From a tyre perspective I find slip energy quite useful in quantifying circuits and sometimes drivers. Things like integrating lat and long G seem popular to get a more statistically robust view of track grip level.

I heard a while back that Pi were considering a "metric driven" software tool to complement the more traditional data analysis software. Anyone using databases to record histories of metrics vs. conditions and setup?

Ben

Please explain further what you mean by metrics? Database of absolutes? database of compared multiple signals? "Peak and valley" compared?

And, are you speaking of Pi's tool box software?

"Things like integrating lat and long G seem popular to get a more statistically robust view of track grip level".

IMHO, The G circle measurement is one of several techniques at work to define grip, to refine it further, one would use combinations of steering and Lateral together with the steering signal mathmatically "speed adjusted" (laymans handling graph that is used in "relationship manner" and use of throttle and long G together to define entry (braking/turn in), apex and exit (throttle on) grip.
This is simplistic overview but generally used.
Within this complexity of signals lies, the handling of the car as defined by the limitations of oversteer (easily found and "easier" to be determined to an absolute number value) and understeer (extremely difficult to "hold" to an absolute number as this number varies from driver to driver... one driver's bad understeer is another's neutral, so to speak.

Quite a few data companies have math generated signals computed an IDEAL steering (individual left and right front tire paths) handling graph to further define a car's grip level and further put an absolute understeer number to it. What still makes this a "gray" area, is as mentioned above, as some driver's have abilities to make an ill handling car appear to be neutral and making the calculation no longer an absolute one.

A historical database beyond just absolute numbers and diverging on combinations of signals to achieve a "true" comparative result would definitely be the ticket.

The most powerful analysis is in comparative anaylsis not in absolute number analysis, yet the majority of the DAG's employed are "stuck" in absolute and only using a small percentage of a data system's capability.

Adding an absolute number database to this group will help them a lot.
Though it's the group that does comparitive analysis that will be on the sharp of the stick most of time, yet this group is a small group in number as it's not an easily acquired skill. It's not the absolute number that's important in how this analysis is done, yet it's most effective. I don't even know where to begin to define a database for this, or if it's possible, but it would be a huge database and if it could be done, would be most effective, in terms of helping along analysis.
Yet, there's even one more data technique that is by far the strongest one (that I'm aware of) and one that separates the driver input to the car, car's input to the driver, car's input to the track, the car's response from the track and finally the driver's input because of the track.
This technique is highly intensive in use of signals and combinations of them. Some data systems software programs are incapable of this type of analysis (due to their programming design) and actually I have used only three that are capable of it. It encompasses the above two techniques with a third, and you can imagine the results from this, by not being "blurred" by the combinations of the driver, the car and the race track. IMHO, this is the future of data acquisition and yes, as you mentioned, a historical database would fit this to a tee.

Now, if you can make a database that one could extract a similar type of corner in radius, incline, banking and grip level as a process input and snip the data from the lap in this way. And paste it together with another race tracks similar corner to form an imaginary track similar to the track your at, you would revelotionize the industry. But maybe that's asking too much.

[Jersey Tom]

A metric is just any way of boiling down a complex signal or curve and characterizing a system in a simple form. Linear understeer gradient is an example of a common vehicle dynamics metric. They're great when you can make sense of them or get them to work. Getting to that point in certain applications is... very difficult.

And yes, Pi Toolbox.. it's not my favorite. Not particularly powerful, the Matlab export is sketchy at best, and you have to use a USB key to unlock a lot of functionality. Given that it's not great at doing "simple" stuff I'd be surprised if they could come up with a powerful metric-driven analysis package.

[bajanf1]

I am now getting into data analysis and obviously most of my analysis has been by comparison. From the books I have read the situations are usually too simple as ubrben mentioned (although it worked for the simple driver analysis I did since it was a good driver and a bad driver). This metric driven approach is new to me so I am just curious as to some of the metrics that could be used. Also, since each driver has such a huge influence on the setup, would that leave the metric driven approach for back at the office or room etc for in-depth analysis?

[Jersey Tom]

In my experience, race engineers rarely give away their best methods, metrics, whatever even in a private sitting.. much less a public one.

You can derive your own as well, of course.

[bajanf1]

In my experience they wont even share the data with someone in the same team so I would never expect anyone to share their best analysis methods anyway.

[Belatti]

Im waiting for the dongle so I will see what I can add to the toolbox with that.
I have some lineal potenciometer data from the dampers and right now, without the dongle I cant export the data to excel or matlab. Im looking to do some FFT to it.

Regarding the metrics, till now I have only worked with one driver so I guess Ill have to take some time to build some metrics myself. I dont think I would use sombodyelses metrics.

I think its something that depends on the cars, the tracks, the sensors, the tyres and the drivers. Here tracks are way more bumpy than in Europe or the States. The also get dirty and grip may vary from day to day. Tyre suppliers sucks, so you wont have 2 similar tyres.

Its something to work on and discover what suits you as race engineer and the drivers.

[Jersey Tom]

Here tracks are way more bumpy than in Europe or the States.

Come up to Atlanta or Daytona...

In any event, I like Motec's i2 a lot better than Pi Toolbox.

[Belatti]

I was a race engineer substitute for 2 races in a team that used Motec´s I2Pro. I have the soft and some data in my PC but had not the time to discover the soft functions and potential, only did what I needed in those specific races.

Can you tell me what are the features that make it better, so I chek them out Tom?



About the bumpy tracks, I was talking in general: I have got the wheel freqs references from F3 and 1200KG Tin Top series.

[Belatti]

Tom?

[speedsense]

I am now getting into data analysis and obviously most of my analysis has been by comparison. From the books I have read the situations are usually too simple as ubrben mentioned (although it worked for the simple driver analysis I did since it was a good driver and a bad driver). This metric driven approach is new to me so I am just curious as to some of the metrics that could be used. Also, since each driver has such a huge influence on the setup, would that leave the metric driven approach for back at the office or room etc for in-depth analysis?

Here's a couple for you, as related to driver analysis and basic handling analysis.

The convention for the data is positive numbers for left hand turns for the lateral G and Long G is positive numbers under braking(Motec defaults to the opposite direction, so does PI in some cases I've seen).
Steering oriented/calibrated at the steering wheel (non-linear, 180,90,0,-90,-180 degrees) positive numbers are left hand turns (so that the steering follows the lateral g curve when over plotted on top of the lateral g)
This graph adjusts the steering for speed as a 1 g corner at 60 mph will have more steering input than a 1g corner at 120 mph. The metric will re adjust the steering with the "speed" effect and make it a constant, so the relationship to the lateral is the same at all speeds. This "relationship" in comparative analysis can show a car that is coming close to, or has arrived at understeer as the steering closes the gap to the lateral g. The smaller the gap the more the car has entered understeer. The further away the more the car is headed toward oversteer.


Relate corner radius (and steering angle) to speed

Radius = (1.467 x mph)2(squared) divided by 32.167 x Lateral G's

The above formula shows that by multiplying steering angle by the square of speed is effective in correction. Though you are conspiring against Ackerman with this formula and tends to indicate too much steering, so the following works better.

Adjusted Steer= steering angle x mph x (square root of MPH).

Excellent handling graph for judging understeer, though it's not an absolute number thing but comparing the "gap" of this signal to the lateral G and knowing what the gap "looks" like with a neutral car.

The second is an excellent judgement of braking by combining Lateral and Long G together (a form of the traction circle) and all of the G's head in a positive number. Once you have the signal, placing long G (as a separate signal as a overplot on top of the combined signal) shows whether the brakes are using to full braking potential. The combined G should come out of the top of long g signal, if the braking is done right. If the Long G Peak has a gap after max braking force and the Comb G signal starts it's upward slope off the back side of the peak, there's room left for better braking.

The Combined G signal= (the square root of) Lateral G's + Long G's

** see above for the convention of the long/lat G ...

[Jersey Tom]

Unfortunately methods like comparing the steering angle to the instantaneous Ackermann angle do not create as meaningful results on an asymmetric car.

I had an epiphany at work this week regarding data logging metrics, and some parameters that should be very good for indicating a range of stability and control attributes. There are some unique challenges to it. Wish I could post them up here for discussion.

Regarding i2 though...

1. You don't need a USB dongle to use it
2. You can overlay non-consecutive laps without having to load the outing file twice
3. The colormap overlays are nicer (3 color gradient instead of 2)
4. More ways of visualizing the data (bar graphs, steering displays, etc)
5. Math channels were easier to use IIRC
6. Track maps have a lot more functionality
7. Has pre-made math channels, including the OS angle calculation by instantaneous Ackermann angle

Etc...

[speedsense]

Unfortunately methods like comparing the steering angle to the instantaneous Ackermann angle do not create as meaningful results on an asymmetric car.

Absolutely, the steering path of an oval car, with asymetric: castor, corner weights and camber effects this graph. Still works, but not as well mainly due to the influences of these on steering input. Using radius as in I2's "handling signal" does work, but I have experienced assorted results with it, as Motec has (in the past, a year or so ago) had some fundamental problems with the equation and calibration issues- alternate Lf & Rf alignment calibrations issues in the equation.
There is one more issue, and that's a car riding on it's front bump stops and inducing "flex" of the front arms (as the spring rate becomes infinite at times) and altering the geometry at the upright and inboard due to this flex.. essentially the A Arms become a spring instead of a suspension piece.

I had an epiphany at work this week regarding data logging metrics, and some parameters that should be very good for indicating a range of stability and control attributes. There are some unique challenges to it. Wish I could post them up here for discussion.

An epiphany that I can speak about happened to me 10 years ago (I've been doing data for twenty years as a consultant)that was when the team I was working with hired an engineer who had a high command of the ADAMS auto simulation program. ADAMS was orginally and is a standard for airplane design with the ability to add subsets and subseting of the subsets in the modeling.It can do track surface changes and tire modeling, and does it quite well, though highly expensive program.
The data/sim combination of data analysis and the Adams program is deadly to your competition

Regarding i2 though...

1. You don't need a USB dongle to use it
2. You can overlay non-consecutive laps without having to load the outing file twice
3. The colormap overlays are nicer (3 color gradient instead of 2)
4. More ways of visualizing the data (bar graphs, steering displays, etc)
5. Math channels were easier to use IIRC
6. Track maps have a lot more functionality
7. Has pre-made math channels, including the OS angle calculation by instantaneous Ackermann angle

Etc...

Ever seen Competition Data System's (CDS) Trackmaster software? In my opinion trumps Motec and Pi...
Pi's Mapping graphics are very much like CDS's functionality (almost a copy), except Pi has very little of the flexibility of CDS's software. CDS is the company that was first with track maps and signal plotting on the map (as many overplots and unlike plots as you want), suspension plane graphics, driver control graphics,.
In my opinion, "rainbow" track map signals are almost useless and require way too much time to analyze if doing something as complicated as shock speeds,suspension travel.
CDS also has in bourne metrics (over a hundred equations) and was also the first company to ingrain the math channels into the programs
More analysis can be done in 20 minutes inside CDS that would take hours to do in Motec or Pi...
The program is not "free" (Motec really isn't really free either considering the cost of the system) And the funny thing is, CDS is half the price of Motec.

Though you may not like the dongle though Tom , as the program was so expensive to make, that they had to strongly protect it. Mainly due to the copying of program features by other companies...

Personally I feel that racing data companies have failed as a whole, in what I perceived 15 years ago, data analysis would look like today. I felt it should be able to analyze the data by itself and do most of the day to day "common" analysis all on it's own, so that team's wouldn't need to hire people like you and me. And I also felt the graphical interface would be way beyond what's out there now...(CDS is the closest that I know of)
IMHO, the "problem" is many companies have owners, programmers and engineers that have Zero racing experience and especially very little knowledge of possible analysis procedures that those in the trenches have knowledge of and aren't letting anyone know about. Many of the data companies have altered their data product mostly based on relatively "limited experience" input from their customers, as most teams have never tapped into the great power of data analysis...