As described in that post, there are 2 ways to get your acceleration values: one is through accelerometer's signal ("Proper Acceleration"), and another, through taking a second order derivative of your movement along or across your direction of travel ("GPS Acceleration", for the lack of a better term). As demonstrated in that post, "GPS Acceleration" can only be considered an approximation of what is actually going on. In most cases, very poor approximation indeed, requiring heavy post processing to result in anything resembling actual acceleration, as experienced by your race car and yourself or your driver.
"Proper Acceleration" measurement can have its own problems, it turns out. Here are 2 race cars. In the one on the left, accelerometer is positioned "square" with Longitudinal and Lateral axis of the car (yellow and white axis are aligned). Life is good.
In the one on the right, the accelerometer is rotated (yellow and white axis are not aligned) Now, when the car experiences Longitudinal acceleration, some component of it gets picked up by accelerometer's Longitudinal axis, and some - by its Lateral axis! Same for Lateral acceleration.
So, when you go and examine your data after the fact, you now see that your car has non-zero lateral acceleration when it is driving down the straight!
Here's an example:
Something is clearly not right. The car is driving down the straight yet it shows up to 0.1 G of Proper Lateral acceleration.
Of course, you can add an offset, of, say, -0.1 G, but now it's off in other sections. And, this also means that Longitudinal acceleration is off as well, without any clear indications of how much.
Your logger may offer a tool to calibrate itself to re-align the axis. To be honest, I have seen more cases where it did not work, than the ones where it did, so this is not my preferred way of resolving this issue.
By the way, you may ask, what's the big deal?
Well. I am glad you asked.
If we are talking about basic data logger that only records GPS and accelerometer data, and your Longitudinal and Lateral acceleration data is skewed - even by few degrees - here are types of analysis you cannot do, since your results will range from meaningless to dangerously misleading:
Everything except staring at GPS Speed trace and your lap/segment times.
And here are types of analysis you can still do with skewed accelerometer data:
Staring at your GPS Speed trace
Lap/Segment times
I hope you enjoy staring at your GPS Trace... You can actually get a lot of useful info out of Segment times analysis, so there's that.
Do you want to look at brake application profile? Engine performance? Cornering grip? Sorry, your results will be off, possibly to the point your analysis is hurting more than helping. Garbage in, garbage out, and all that.
Luckily, this is fairly straightforward problem to fix
We will be using math channels, and applying some high school geometry.(https://en.wikipedia.org/wiki/Rotation_(mathematics) - see "two dimensions section"). You remember your two dimensional vector rotations, don't you?
OK, here's how to set it up.
Let's use AiM Race Analysis. After all, AiM solo is nearly 100% likely to be mis-oriented to the axis of the car it is mounted on... When you make something too easy, you run the risk of making it too easy to get it wrong.
By the way, this assumes that the accelerometer is, at least, aligned vertically (i.e. not tilted up/down, or, Euclid forbid, is lying down "on its face").
If not, the principles are similar, but you will have to correct in 3 dimension. Easy, right?
So, here we go.
Step 1.
Load up the session and create 2 “X-Y Plots”: Click “X-Y Plot” button, then select
“create new”, instead of “activate existing”. Do it twice.
Step 2.
Now, click on the windows resize button, to make the UI allow you
to lay out all windows (instead of default single-tabbed-window view). For reasons we will never understand, that button is called "Restore-Down"...
Step 3.
Now, it will look like RA just had a stroke. Don't panic, and calmly arrange 2 XY plot windows next to each other, don't worry about anything that may be hiding under them (don't worry if what's in the actual plot windows looks different, at this point)
Step 4.
Right click on the right plot, and go to "Plot Settings" (NOT "Settings"!)
Step 5.
Select "GPS_LatAcc", or whatever it is called on your AiM logger as X axis.
Step 6.
Make sure you have same X-Y Plot selected (click anywhere within plot area). Now, in the "Measure list", on the left, select "GPS_LonAcc", and un-select everything else.
Now, the right hand plot should look like this:
If it does not, and you are not able to make it look similar to this, I would recommend that you look through AiM tutorial/help files on X-Y Plots or call your AiM dealer and ask for help. I personally find that UI bewildering and illogical, not to mention outdated by about 30 years (just an opinion, ya'll), so I am not the best person to explain the basics of it to others...Err. Good luck. If you are REALLY stuck on this, email me.
OK, now we are going to create some math channels. If you never created AiM math channel, I highly recommend that you watch this video first, which walks through the basics of creating a calculated gear math channel:
Anyway, we are going to create 3 channels:
A. "G Angle Correction"
Set it as per this screenshot, I highlighted fields you will need to configure:
In "Formula", enter "0" instead of "-9", for now. everything else as shown.
Note: If your accelerometer has Longitudinal and Lateral acceleration values named differently than "Longitudinal_a" and "Lateral_acc", you will have to update those names, obviously. Use whichever ones you see in the "Identifier" list on the right (what, you mean it was not obvious that "IDENTIFIER" means "LOGGED OR CALCULATED CHANNEL in Italian?!" Jeez...)
OK. Now you can leave math menu and finally configure X-Y plot on the left.
Basically, you are doing same exact thing as steps 4,5, and 6 above, but now use Corrected_lat_acc as X axis value, and Corrected_long_acc as the ONLY selected measure for the left hand plot.
Whew. If you had done everything right, and Pinocchio did not play any tricks on you along the way, you are going to see 2 "Friction Circle" plots, one of which is "rotated":
In the other post, I mentioned that GPS Acceleration values should not be trusted. Well, I was not entirely correct there. They can be trusted in terms of generalizes trends/distribution - i.e. as a baseline to understand how much "skew" we have in our accelerometer data. I am sorry, Pinocchio. I hope you can find it in your hard, wooden heart to forgive me.
Where was I? Ah OK. If you entered "0" in the G Angle Correction math formula, AND the left friction circle plot is not rotated relative to the right one, you are all set. You do not have any skew in your accelerometer data. Don't be mad at me for wasting your time, you have 2 new shiny friction circle plots to play with!
If the left one IS rotated, now comes the fun part. Go back to Maths menu, and enter a different value into G Angle Correction formula. Let's say, -20!
Well?
Oops, too much. Go back and back that value off a bit. It may take a few tries. Eventually, you should get something that looks like this:
Sweet!
All you have to do now, is use Corrected_long_acc and Corrected_lat_acc in your analysis!
By the way, before you do anything else, go back to Maths, copy all 3 channels to "General" tab, and set checkbox for all of them to be inserted into new files automatically. This way, you will not have to repeat all this for every log file. Obviously, if you change orientation of your logger, or load someone else's file, you will need to go and adjust that value. Use "double friction circle" view to check alignment in new files and you should be golden.
Oh, to go back to "classic" RA view, just hit "Maximize" button on any of the windows...
Here's how much difference this can make:
Highlighted are the sections where data skew was creating a pattern that was outright wrong for what was actually going on with the car. This was about 9 degree rotation of the logger relative to the car.
Here's more extreme example, where the logger is rotated nearly 20 degrees:
Hopefully, these examples drive the point home, regarding how critical it is to
1. Check if your accelerometer is aligned with car's axis
2. Create corrected channels if it is not, and use ONLY those channels for your analysis.
(originally posted on facebooks, this is edited/updated version)
I know that most of you pick your data system based on cost and "peer pressure". Let me make a case for the importance of choosing a system that gives you access to real analysis capabilities, for example, basic statistical analysis. This could mean that you may need to go outside of software package provided by the manufacturer of your data logging device.
Today, even Excel gives you tools for fairly advanced statistical analysis and visualizations - so if your "racing" data logger software suite does not, and you do want to unlock the miracles of modern data analysis and visualization technologies, you can export your data to a different analysis package. For example, Microsoft Excel! Or, if you want to really impress your friends, MATLAB...
OK, so let's consider specific example having to do with section times and "fastest laps". If you ever switched back and forth between your segment time charts and trace views, trying to figure out if your best lap still "left some time on the table", perhaps in specific sections, you may find it easy to relate to this example.
If, on the other hand, you are not sure what's the deal with delta/lamda/variance/diff traces, or segment/split reports, you can start by watching James Colborn's video about driver/lap comparison:
Watch the video for an example of how both difference/variance trace and segment time reports can be used for the analysis, and how valuable the data encoded in both of those views can be - as a very nice bonus, it also has an example of how exporting data into Excel for analysis can help you get around limitations of "native" analysis software.
Anyhow, onward to the example.
So, the Variance trace (or "Delta") trace can be used to compare laps (again, if you are not sure how, check out the video above). Orange highlight in the screenshot shows pretty typical one.
While occasionally, those traces are straightforward, if you look at enough of them, especially from the same car, you will come across many that go up, then down, then up, then down, etc., when comparing 2 or more laps, likely creating somewhat mixed and confusing picture.
Maybe it goes down sharply, then gradually rises? And then does the reverse? Does it go down in the corners, then up on the straights? Up in left handers, down in right handers? Up under braking, down on turn-ins? Up when your spotter is keying the radio accidentally, down when you remember about that cold beer you stashed in the cooler?
In fact, I am willing to bet that most drivers or aspiring race engineers, who give up on going deeper into data analysis (and/or on applying it to better their racing program), do so after seeing really bewildering things that such trace can do... We hear a lot about importance of variance/delta traces - but aside from a views like the one above, there are not really any tools or examples on how to "un-confuse" what real world data often looks like.
Of course, you can flip to section/segment time view (or put it on the second monitor, etc):
while it does allow you to review all of the data at once, unfortunately, this is really good way to overload your brain when you switch to, and away from this view, repeatedly.
"Wait, was I looking for times in Turn 5 or 6? Is difference between 7.995 and 8.071 more important than difference between 5.841 and 5.728? Let me flip back to trace view... Then back again. Where was I?"
For whatever reason, our brains do not work well when trying to put together tables of numbers with a bunch of squiggly lines, to form a comprehensive answer to a complex question. I guess that's what happens when your brain evolves as a result of chasing venison across grassy plains. Bummer. Why couldn't cavemen spend more time on maths, statistics and race cars? Oh, right...
Well, since we already have the concept of track segments, why not make the Variance trace run "per-segment". After all, really interesting questions are not "How this lap came to be this much faster than that one" or "Which car/driver is faster", but the ones like:
"Where can I do something differently as far as my driving technique, to improve my time, and what exactly should it be?"
"Which specific segment/transition should I optimize my setup for?
"Which section may be exposing a mechanical problem, holding me back"?
"How can I do all this in 10 minutes I have before the car goes to the grid for the next race/session"?
The idea is that if you can, at a glance, see where there is significant gain/loss between two laps, instead of dicking around with comparison cursor (drawing even more lines - ugh) or introducing another view of data (segment tables) - if you can do that in the same view you do most of your analysis in, you get to important insights faster, meaning that you will find more of them in the time you have. Perhaps, more than your competitors will, given the same time!
Well, such view is quite possible, and here it is:
Is that easier to read? I highlighted some obvious patterns. This view , actually, turns out to have sort of a language of it's own:
"Shallow slope" triangles (i.e. green highlights above): acceleration/drag differences, or grip in sustained load/sweeping corners - see green highlighted sections
"Steep slope" triangles: throttle or brake application differences - see beginning and middle of first red highlighted section)
"Very steep slop" triangles, nearly rectangular in shape: difference resulting from brake applications - see second red highlighted section
"Up-and-down/sine wave" shapes (in the same corner-straight sequence) - these are usually trade-offs between entry speeds and early/mid corner grip and throttle application - see last red highlighted section
While it may take a little getting used to, this view has proven very effective at not only identifying significant/important areas of the track, or aspects of tuning changes that go in the right or wrong direction, but also at classifying them quickly, which focuses more detailed level of analysis on areas likely to produce useful, actionable insights.
Real analysis software makes it relatively simple to set up. I added some information of how such view can be created in MoTeC software, at the end on this article.
Another idea - what if, looking at traces of your "best" lap, you could add a trace that tells you which sections of it are not actually "best" - and, by how much. Perhaps, best lap has 8 sections, which, on 2 other laps, had better times (and 3 of those sections had significantly better times), even though those other 2 laps were not faster overall?
With the approach commonly taught/practiced (and the only one possible with more basic analysis software), you will need to look through segment time table OR go through variance traces for at least 2 more laps. See how long it takes you to find 3 sections on laps other than 1.46.9 lap, which are significantly faster (at least 0.1s)?
Are you SURE you found the right 3? Maybe there are 4 of those! 2? Better check again...
And this is just 6 laps! What if your data set has 40 laps? How about 400?
Why not have a trace that simply tells you how far each section time is from your "best" time for that section?
Ah, so there are only 2 sections that have times faster by at least 0.1 sec on other laps, not 3! The third one is only 0.096s faster :)
How long did it take you to find 3 sections that are "not like the others" on this last view?
I really love this view - it allows me to see right away, how much important information there is in the "fastest lap", vs other laps in the session. And, there is no need to go to section time tables, or to spend hours of my life untangling endless variance/delta squiggles, until I know exactly which section of which lap I want to look at.
It also makes it easy to see that even though the reference lap was the fastest in session, it left about 0.3 sec on the table, based on section times collected from ALL laps - again, without any need to switch the view away from trace view.
Now, imagine how powerful this method is, if you are looking at data from endurance race, with possibly hundreds of laps..
Well, congratulations if you have gotten to this point :)
Here's how by-section Variance can be set up in MoTeC I2 Pro:
(This is where AiM stuff chokes, as it doesn't seem to allow a way to reference data by-segment. It could do some stuff by lap, but it does not expose ability to create and manipulate ranges/segments inside laps without some serious hacking that would need to be replicated for each track - if you can figure out reasonably portable way how to do that - let me know)
Next, we need to take care of timing "jumps" around edges of segments, otherwise the chart looks a little insane.
For this, I create function called DeltaSectionSmoothness:
Think of it as "alarm" that goes off when there is a sudden "jump" between running total for a section distance across 2 laps - which is what happens when the transition between 2 segments n 2 laps is slightly shifted in relation to each other (you can search for "GPS Drift" if you are interested in underlying reasons for why that happens, sometimes)
Now, we can write a formula for our section-specific Variance:
What it says, is: Calculate by-distance Variance, between 'SectionRunningTime' values of two laps, EXCEPT when 'DeltaSectionSmoothness' has triggered the "un-smoothness" condition.
If we were to remove that condition, we'd get some ugly vertical lines between some sections, here's example of both un-smoothed, and "smoothed" versions:
Well, that's it. Building "Delta with Session Best" trace is a little more complicated, so I will leave that out.
OK, if you have ever taken a performance driving class, or club HPDE ground school, or read anything at all about race track driving, you heard all about "weight transfer". Well, guess what. Weight transfer is just like bank transfer, with the money that you borrowed!
You have to pay interest, and they only accept grip as payment. Not fair. But what can you do? Well. Borrow only what you absolutely need!
This analogy is becoming silly. Or - maybe - not so silly! See the video for a practical demonstration:
Your most basic racing data logger has 2 main components: GPS unit and accelerometer. It is helpful to understand what each does, what are the limitations of their signals, and how accurate are the measurements which are derived from their signals.
To simplify things somewhat, GPS unit records current time (as received from the satellites above you), as well as your location in reference to some satellites above you, while accelerometer records forces acting on your car in 1, 2 or 3 dimensions.
Most useful pieces of information that GPS unit will record, will be your position on the track, as well as your speed along the track's direction, calculated from 2 or more of your positions and associated times (first order derivative). If your data analysis software has some level of sophistication, it could also calculate your accelerations as derivatives of such speeds (second order derivative). We'll refer to such measurements as "GPS Acceleration".
Accelerometer will record "Proper Acceleration" - yes - that's the actual term for that, specifically "instantaneous" effects of forces acting on the car, along up to 3 axis. Of these, most interesting are Longitudinal acceleration (acceleration along rear-to-front axis of your car) and Lateral acceleration (acceleration along left-to-right axis of your car). Longitudinal acceleration is a measure of how hard you brake and, well, accelerate, while Longitudinal acceleration reflects how hard you are cornering. This is somewhat of simplification, but it'll do. For now.
If I already lost you at this point, sorry. Didn't I say this will be tedious and boring?
GPS uses antenna and mini-microprocessor. Cool! Accelerometers use variety of technologies, most basic being a weight suspended on some springs. Leonardo Da Vinci would had been proud. Modern ones use piezoceramics and quantum tunneling. Now we're talking.
Here's an example:
Red line is speed recorded by a wheel sensor. Purple line is speed recorded by GPS microchip. Notice that GPS speed is not always accurate. Sometimes it "lags" sudden changes in "Actual" speed, sometimes it has weird fluctuations. If your software shows GPS Speed as perfectly smooth, with no artefacts like that, your software is lying to you! This is particularly a problem for "certain" software developed for karting, then finding its way into road racing by means of clever, and somewhat shameless, marketing.
But why? - you may ask. Why can't I have perfectly smooth, always accurate GPS Speed? Well, GPS signal does not work that way. It is, at best, an approximation of reality when it comes to speed, and speed senor measuring revolutions of your speed or your driveshaft will almost always have higher precision, especially during acceleration/deceleration.
What? Well, remember that what GPS is really good at - what it is designed to do, in fact, is determining your time and position. That's how you get a bomb to land in a back of a Toyota pickup.
Speed is a "first order derivative". Without going into too much math, it's basically a calculation with an order of accuracy sacrificed, to get more data. Basically, it would be like watching someone eat 3 pounds of ice cream, then "deriving" a conclusion that this person will be 3 pounds heavier for the next 2 hours. You may be a little off. It may end up being 2.7lbs for the next 2.8 hours. But you "derived" more information about the situation. This is not the greatest analogy, I must admit.
Anyway. (nearly) Every time you take a real world derivative, you sacrifice some precision.
So, if you take a derivative from speed, you get acceleration (Physics and Math magic, just trust me on this). That is the green trace above. Notice, that while it generally follows yellow trace (direct measurement of proper acceleration, from accelerometer), it is sort of all over the place. That's normal and expected. It can be smoothed and filtered, of course - but then it may not be as accurate at any given point. Tough choice.
Here's how you spot when your software is "massaging" the data behind the scenes, to make those 1st and 2nd order derivatives look smooth and neat (which can easily mislead, or, at least, misinform your data analysis):
Ah, those wonderful, smooth curves, sweeping peaks and valleys. Lies, all lies. Pink line is GPS Speed (first order derivative). Can it be more precise than speed measured by the wheel rotation (light blue line)? Nope. Not possible. Even if it was measured by a military grade GPS chip, and not $400 pocket lap timer, it would still not be as precise measuring speed, as wheel speed signal. So, Pinocchio is pulling the fast one on you.
Now, check out green trace. This is a second order derivative, "GPS Acceleration" (Lateral, in this case). Compare it to the brown Lateral trace from actual accelerometer (which, by the way, is also smoothed and "fixed" by the software - thanks, I guess). Is it possible that 2nd order derivative is more accurate than direct, "proper" measurement? Nope. Can you eyeball how much ice cream your friend ate, and then tell precisely how much heavier he (or she!) is? Nah-ah. So, how can it be so smooth and neat? Only as a result of doctoring, approximating, and smoothing the values to the point where they are so off from the actual measurement, they become close to meaningless. Shame on you, Pinocchio. Back to your go-kart, stay away from my race car!
OK. But is this all important? Well, that depends. When you use your racing data, do you want to be sort of in the ballpark, or dead on?
Is it important that your data traces make for nice, good looking curves, with simple messages about your (or your competitors) driving, or do you want to have access to all the complexities and nuances of hardware signal resolutions, sampling rates, GPS drift and signal strength?
Priorities will, of course, vary, but at the very least, the choices should be informed.
I am starting this as somewhat of a permanent place to record various bits and pieces of information that materialized around requests for advice or opinion, as well as unsolicited messages to the racing community I interact with. Most of it will have to do with collecting and understanding racing data, as well as practical applications of insights gained that way. Some may have deal with my personal racing experiences.
Some of you may find this stuff interesting, useful, or amusing. Most will find this boring and overly technical.
That's too bad.
Modern civilization owes little to great politicians, generals, musicians, or poets (or racing drivers) of the past. Nearly every benefit of modern world we have at our disposal, is a result of work of scientists and engineers (rarely appreciated or even remembered), tirelessly applying methods that most find boring, in search of advances in our understanding of ourselves and the world around us.
Also, race cars.
In the last few month, some people asked me for a reference to a place to look up information about my team, and what we do. I suppose this would be it. Do not expect PR-polished messages, or praises in support of our sponsors. There are other places for that. This is simply about information and a place to share comments and opinions.
Every time I describe this side of my life on the Internets, I inevitably receive questions from strangers about how to become a racing driver. I suppose that's inevitable that this will generate a few more of those. While I will continue to answer such questions, you'd have to contact me through some other means for that, this place is for different kind of subjects.
Igor
P.S. Here is one of my most favorite race car development pictures. I call it "Reflections".
