I acquired some actual Miata Traqmate data, with the aim of improving the accuracy of the Miata simulation model. The track analyzed is MSR Houston. After doing some data processing, the real g-forces can be seen below in blue. When running the simulation on the line extracted from the Traqmate data, the g-forces are those shown in green.
Upon analyzing the results, it seems that the top speed, peak braking force and trail braking forces as modeled are too high. The actual power level, on the other hand, is slightly low. I still allowed for slightly higher peak braking than in the data, because an expert SM driver should be able to consistently brake at over 1g (including aero braking). With these changes, the new g-forces and velocities look like this:
The net change in lap time, from the original simulation to the new simulation, is +0.2 seconds. The original onboard lap time is 1’50.45, while the final simulation, running on the exact same line, is 2.7 seconds quicker. The surplus braking power only accounts for about 1/10th of a second. The rest of the advantage comes mostly from carrying more speed through the corners and getting on the gas earlier.
You can have this kind of analysis performed on your own data to find out how the computer would drive your car faster. Click the button to get started with a custom optimization!
Shout out to my friends at Track Junkies. It was suggested that the Mazda Miata lap times are a tad aggressive. I’d like the model to be as accurate as possible, so I asked for some GPS data to help fine-tune it. Track Junkie Robert Cope came through, sending me his Traqmate data for a couple laps at MSR Houston (CW), and when I proved inept at actually opening it, exported it to CSV for me. Thank you kind sir! Although it’s not technically a Spec Miata, it should be close enough to get a good handle on what the data should look like.
The general approach will be to take Robert’s line, then simulate the Race Optimal Miata running on the same line and compare the data between the two. We should expect the simulation to be faster, or else, what’s the point – it’s purpose is to take the line as efficiently as hypothetically possible. We should also expect the simulated lap using Robert’s line to be slower than the theoretical optimal lap published on Race Optimal, or else Robert Cope has discovered a more efficient line than our algorithm, which again would defeat the purpose of having a computer do it.
However, the acceleration levels should be similar, and the velocity plots shouldn’t look like one vehicle is significantly underpowered compared to the other. Examining the acceleration and velocity graphs will provide the most valuable information.
So let’s see what we have. Lap two of the data set is the quickest at 1’50.45. Here is the Traqmate GPS position data in feet:
Looks pretty good. Lateral and longitudinal Gs are also provided:
The solid line represents the most extreme points, i.e. the limits of acceleration in whatever given direction based on the data. Some of the edge values seem unrealistic, with many points well over 1.5g laterally in both directions. I’m also surprised to see no more than about 1g under braking.
Let’s try running the simulation on the GPS position data as given. In the figure below I offset the GPS data in the X and Y directions so that it lines up as nicely as possible with the digitized track boundaries we have for MSRH.
That looks pretty bad, and the lap time is a cool 3’39. Turns out this is because the GPS data isn’t actually as smooth as it looks – there’s too much jitter. The simulated speed at every point depends on the line’s local curvature, and there are tiny kinks all throughout, artificially reducing the allowable speed. Here’s what the kinks look like zoomed in around Diamond’s Edge.
This means that some smoothing is going to be necessary. Fortunately, the same algorithm used to create a smooth racing line in the optimization process can be used to create a smooth connected curve from the GPS data. Zooming in on an even smaller portion of track, you can see the smooth blue line versus the original.
Zoomed out, however, there’s no visual difference between the two lines, which is what we want.
Let’s try the simulated lap on the smoothed line.
Much better. The simulated lap time is 1’47.56, 2.9 seconds faster than the original. Now we need to figure out how much of that is due to an unrealistic advantage in the simulation.
It should also be noted that following this line, the simulated Miata is an additional 3.2 seconds slower than when following the calculated optimal line – yes, the published optimal lap for MSRH CW is 1’44.35. Here is Robert’s line and the ‘optimal’ line side-by-side. The optimal line is about 100 feet shorter, which saves 1.2 seconds at an average of 60 mph.
Since I don’t really trust the acceleration values provided in the dataset, I’d like to recalculate them using the raw position and speed data. Lateral Gs can be found from v2/r, where r is the local radius of curvature, and longitudinal Gs from v22 = v12 + 2ad, where a is the acceleration and d is the distance between two measurements. To avoid the measurement jitter issues described above we’ll use the smoothed position data, and also smooth the velocity as shown below in order to yield realistic longitudinal acceleration values.
The resulting g-forces are show below.
The g-forces calculated from the smoothed data are considerably more conservative than those provided by the Traqmate dataset, and I’m more inclined to trust those numbers, since they come directly from the corrected speed and position data.
It’s finally time to directly compare Robert’s lap to the simulated lap in the Race Optimal Miata. Remember, from this point on the simulated vehicle will be following the exact same line as the smoothed GPS position data.
As you can see, peak cornering loads are slightly lower in the simulation, but it has much higher braking and trail-braking forces, as well as higher peak acceleration in some places. The simulated Miata also appears to have a power advantage – it pulls slightly harder than Robert’s car everywhere except between points 1000-1300, where there is a slight uphill that the simulation does not capture (no elevation changes are modeled). The simulated lap time is 1’47.56, about 2.9 seconds faster than the actual lap.
I’m somewhat confused by the low peak braking – given cornering forces well in excess of 1g, when you factor in aerodynamic drag, we should be seeing in excess of at least 1.05g with regularity. The simulation is regularly above 1.2g braking, and it assumes only 90% braking efficiency, i.e. 90% of the available traction accessible under braking. Some of Robert’s hardest braking also occurs under 0.3-0.4 lateral Gs while turning right.
Another observation is that the original data is somewhat unbalanced, with generally more cornering and trail-braking forces while turning right, indicating a greater comfort level in that direction. The optimal simulation will not have that bias.
After looking into what power level would bring the simulation closer to the original data, I actually discovered that the reference acceleration value for the Miata of 6.7 ft/s2 is slightly too low, while the top speed of 130 mph; is too high. Spec Miatas vary significantly in power level, but since this is the optimal lap, the simulation should model the faster end of the spectrum. By increasing the acceleration to 7.0 ft/s2 and decreasing the top speed to 122 mph, the acceleration zones match up pretty well in the graph of velocity. The acceleration value is still below what I’ve seen in some Spec Miata videos, such as this qualifying run at MSRH, where you can see the car accelerate from 75 to 105 in under 12 seconds coming out of Diamond’s Edge. That would necessitate a reference acceleration level of around 8 ft/s2, so the current value of 7.0 ft/s2 should still be conservative.
Looking at the velocity plots, Robert is still overtaking the simulation in some places, particularly on the back straight, which runs slightly downhill. The lap time with the revised model is 1’47.67, or about one tenth of a second slower than the the original model.
Let’s see how the g-forces line up:
Peak cornering loads and braking loads look OK, but there’s a lot of area between the red and blue curves in the trail-braking zones. In the real world, a more perfect driver would probably be able to use a little more of those areas, especially while turning left, but it’s still too much of a gap.
Restricting the trail-braking behavior involved some significant changes to simulation algorithm, but I won’t delve into the details. After implementing the modifications, and increasing the braking efficiency to 70%, the revised lap time is 1’47.85, or 0.3 seconds slower than the original simulation. It’s suprising that such a decrease in area of the friction plot leads to such a small change in lap time, but remember, the power level increased by 4.5%, which makes quite a difference, especially at the Miata’s power level. The new g-forces are as shown below.
I think 1g is a little too low of a braking limit in an expertly set up and driven Miata, so I’m going to increase the braking efficiency to 80%, but also decrease the trail-braking slightly more to keep it in line with the data. These changes combined result in a lap time of 1’47.75 – 0.2 seconds slower than the original simulation – and the following g-force and velocity plots:
So in conclusion, after revising the model to incorporate higher power level but less peak braking and less trail-braking, the net change in lap time was +0.2 seconds. Running the final model with the original power level (6.7 ft/s2) gives a lap time of 1’48.28, which is 0.72 seconds slower than the original model. Running the published optimal racing line with the new Miata model increases the lap time to 1’45.24, about 0.9 seconds slower. Some of that may be made back up, however, when the optimization is conducted again using the new model.
Every vehicle and driver is different. For $99 you can have this same kind of analysis performed, and the optimal lap calculated and simulated. Please see our Services page to get started!