How close is close enough?

Happy new year everyone! Let’s start this 2014 well posting immediately something new here!

As you may have seen, driving simulation has become one of my main interests, in recent times. It allows to explore interesting possibilities regarding vehicle dynamics simulations, analyzing also driver influence and its perception of  vehicle balance and stability.

Anyway, there is still a point we didn’t explore into details in none of the posts I published till now: how close the performance and the behavior of a vehicle model built in rFactor (or, in general, in a commercial driving simulation software) can be to its real counterpart?

Let’s analyze how a Formula 3 vehicle model driven on the “virtual” Monza circuit given with rFactor package performs compared to the real car, a Formula 3 in 2008 FIA configuration driven by a real driver on the same circuit during a free practice session of the British Formula 3 Championship race held in May 2008 in Monza.
One of the reasons why I have chosen exactly this event to make this comparison, is that the car was used on track set in a way that was overall pretty close to the “Manufacturer delivery configuration”. For example, this was one of the few times where the team didn’t use bump stops: they can be designed into rFactor pretty flexibly but their real behavior is very much affected by usage and wear. Their absence has made the modeling and the data comparison much easier, allowing to concentrate on more sensible and easy-to-measure parameters.

The scope of this article isn’t to have a perfect matching between real car and simulated car output, no matter what it needs to reach this goal, although it could be pretty easy to do by “tricking” somehow the model until output data is matching perfectly to real car data logging. What I want to analyze here is how close the results we could obtain in a cheap driving simulation software could be to the real thing if we input data that we believe being trustable and accurate when building the model itself.

The model has been built into rFactor using all the knowledge I have grown regarding vehicle modeling in this environment and basing on data coming from direct car measuring (suspension kinematics, components weight, setup, brake system, etc) and from manufacturers data (engine torque curve, aerodynamic data, tire data, inertias, etc).
The “virtual” vehicle has then been set up with the same setup parameters used during the real test. The only two aspects which were not set to be exactly the same were downforce and drag: the value used in the model are reasonably close to the real ones and come from manufacturer data; anyway, some of the small aero ancillaries that were in Dallara F308 (located mainly in the underside and near the tires) were taken out to further reduce drag and to help to increase top speed. Unfortunately there is no available and trustable data about these changes.
It could be possible to empirically reproduce into the vehicle model both the real level of downforce and drag produced by the real car via “trial and error”, but I preferred to stick to the manufacturer data to also have a more reliable and repeatable set of information, a more trustable final model and to proceed in a more “scientific” way, using measured data instead of doing an estimation that could end up being not only wrong but also difficult to control.
Of course, also the manufacturer data could be somehow wrong, as far as I know. Anyway, I trust them more then how much I trust an aero measurement I could do on track without proper hardware.
As we will see, this had only a very small influence on vehicle performance.

During the race weekend I took this data the team had two cars on track. The data used as a reference here are coming from the fastest of the two cars: the driver at its wheel performed among the fastest pilots during the free practice sessions. Anyway, some small considerations must be done when looking to the performance:

• Although being overall faster, the driver using this car has always shown on data lower decelerations values in brakings and lower brake master cylinders pressures compare to his team mate.
• The car was run with nearly new tires, because the team only entered that appointment of the F3 British Championships and had no used tires to use for free practice.

The simulated vehicle model, on the other hand, has been driven by a real driver who uses driving simulation quite often and who has also driven F3 cars before. Unfortunately, I didn’t have the possibility to let the same driver to drive both real and virtual car. Life sometimes is hard!
Anyway, we will see that also this point is not compromising the general meaning of this investigation.

Last, the track model which was already included in the software, is something over which I had no control. Although it seems visually very close to the real track, I could not verify its accuracy. Looking to the data output, it seems reasonable to believe that some zones of the “virtual” track are slightly different than the real counterpart.
Unfortunately, since this study is mainly a private initiative (mine!), the use of a more detailed track model, for example built basing on more advanced and accurate technologies like laser scanning, was, of course, out of scope. Let’s wait (and pray) for some new products coming on the market soon, which should have some very accurate track models included.

The first metric that we will analyze is the speed (data acquisition) trace of both the simulated and the real car.

A general look shows the two traces are pretty similar. The straight performances of the real and the simulated car are very close, with small differences coming mainly from the mentioned discrepancy in the aero configuration and from a slip stream that the real driver managed to take before the “Ascari” corner (third long straight in the picture above). It can be seen that the real car tends to have a slightly higher top speed, probably coming from the slightly different drag.
Corners speed are pretty close; in general there are only small differences connected to the driving style and, in Lesmo corners, probably also to a different track layout, as we will see later.
Also track lengths shown in the simulated and in the real data acquisition files were slightly different (5840 m ca. for the real car data vs. 5785 ca. for the simulated ones). Regarding this point, we should keep in mind that the real car speed trace comes from a wheel speed sensor signal, which measures the angular velocity of a wheel (front right wheel in our case) and then the actual car speed is calculated using a fixed wheel circumference. The reality is that the wheel circumference changes during motion (because of loads and centrifugal forces) and that we cannot trace exactly the path of the wheel during a lap.  On the other hand, the simulated data refers to a “vehicle” speed measurement (in virtual environment, we don’t have the problems we have with a real car and all the measurement are “real”, with no errors coming from sensors accuracy and from measurement process: of course, the trick is that this data is not really measured, but only calculated by the software).
In general, it is pretty difficult to properly align the two files and, as a consequence, to be sure that the two cars were passing on the same track spot when we look to a certain x-value of the plot, since the two tracks are effectively a bit different. Moreover, to refer to small track bumps to align graphs (normal procedure with real data), is not the right way to go here, because the virtual track model is not accurately reproducing also surface roughness and bumps.

Regarding the braking points, it is not easy to do an objective evaluation, because of the mentioned problems with track length and traces alignment. What we see is that there are some small differences between the two cases. We can better analyze this aspect also looking to the following picture showing the Longitudinal Acceleration traces.

Here we see that, probably because of the “real driver” way of braking and also because of the slightly lower downforce level compared to the simulated one, the braking points are slightly different in the two cases, as well as the maximum longitudinal accelerations levels. We are anyway talking about a performance difference of less than 5% (I cannot include the numerical values here, sorry; I guess you have to trust what I say).
Moreover, we have also to consider that the other team driver was able to go up to around the same amount of  g produced by the virtual car in the same session and that, anyway, in a simulated environment a driver is normally taking more risks, knowing that in case of mistakes there are nearly no consequences.  Anyway, if we consider the second driver braking performance (this is the value used to model the braking system: to “trick” the model so to have a perfect matching in the above picture could be easy, but this is not the scope of this work: I tried to reproduce as close as possible the real car performance basing on real data), the difference between real and simulated model drop to less than 1%.
The same picture shows that also in corner exit accelerations the two traces are practically identical, above all not considering the measuring noise.
It is interesting to see that not only the general shape of the curve is similar in the two cases, but also that the absolute Longitudinal Acceleration values are very close to each other, with differences only where the simulated car was carrying a slightly different speed and was then accelerating from a different RPM level.

This is further confirmed also looking to the Throttle trace, below and to the RPM picture, immediately after.

The goodness of the simulation output is also confirmed looking to the Lateral Acceleration trace that, together with the Longitudinal Acceleration one, is probably the metric that gives more information about the car handling and vehicle dynamics maximum performance (see picture below).

Here we can see that the maximum g levels of the simulated and the real vehicle are pretty close together at more or less at all speed (downforce) levels.
It is anyway interesting to notice how, also if the speed trace was showing a sensible difference in Lesmo 2 corner (with the vehicle model being slower than the real car), the g trace tells us that the simulated car is reaching the same g level as the real one; this means that the driver is using a different line or that the track model is not perfect in this zone (which is the most realistic scenario, in my opinion).
It’s also interesting to see that where there are discrepancies between simulated and real data, (although, as said, we would expect the driver to take more risks in the simulated environment and so slightly higher g values in this case) it is sometimes the real car to perform better and sometimes the simulated one. This tells, together with the track model accuracy problem said above, that in general the performance envelope of the two vehicle is pretty similar (differences around 4% in the maximum values).

Moreover, if we also take a look to the following steer trace picture, we can see that not only the overall car performance is similar in the simulated and in the real case, but also vehicle balance seems to be very close.
As we said, both models are using the same setup (at least from a mechanical point of view, while we can anyway expect that the differences in the aero configuration are not altering downforce distribution front to rear); having as a result a similar handling balance, means that not only the car itself is behaving in a similar way to the real one, but also that the tire model does his job well, compared to the real tires.
Tires data and tire modeling are probably the most difficult and sensible aspect in vehicle modeling; in driving simulations they have not only the effect of producing the right forces in the interaction between ground and vehicles, but have to also communicate to the driver the right “feeling” about car behavior and its balance.
The tire model used by rFactor has shown to be pretty flexible and allows to reproduce some features that even  common automotive standard model don’t always depict.
Using real data coming from Avon (and although lacking detailed info about the longitudinal forces), it has been possible to create a pretty good and reliable tire model for this simulation.
A quick note, out of the scope of this paper, is that also the driver feedback about car behavior and performance was very good, once again confirming the goodness of the model and, more in general, of the simulation environment.

Finally, a very important point to evaluate the mechanical side of the model relies on suspension behavior, since they are one the of most important elements to tune vehicle balance and to adapt it to the driver needs.
The pictures below show the traces of spring/damper unit movement, again simulated vs. real car.
Once more, it is clear that the general trends are showing a very good match between the two cases, for all of the 4 corners.
Looking to the front first, we can see that, although being the simulated maximum deflection values very close to the real one, at the end of the straights there is a small difference (around 6%) on the average amount of displacement.

This is probably in part connected to the said difference in downforce between real and simulated vehicle and also to how we reproduced motion ratio inside the simulation: we have in fact assumed Motion Ratio to be constant, while no real suspension respect this condition strictly. Moreover rFactor doesn’t reproduce suspension friction or hysteresis anyhow. They are normally low in race car suspensions, but still not absent. Also, F3 dampers have some internal pressure that creates an effect similar to spring preload, again not simulated in rFactor. Finally, although this probably produce a lower effect, all chassis and suspensions have some compliance, above all at the link attachments to chassis or at damper connections to rocker or tube. Again this is something rFactor dosn’t simulate, as also some of the most professional simulation packages don’t do.
Finally, the data acquisition system in use on the real car allowed to calibrate suspension potentiometers only through two calibration points (and so applying a linearization on the whole movement range); this aspect and the position of the sensor, which was not mounted on the damper body, although being calibrated on damper movement, could have also driven some very small measurement errors.

The real dampers traces show a similar behavior, with a similar behavior to the one described at the front and which is probably connected to the same causes.

The overall behavior of the simulated spring/damper units in his whole is anyway very similar to the real counterparts, with consequently also similar amounts of  body roll and antiroll bar deflection.

To sum up, all what we saw proves that, when real and accurate input are used to model vehicles in rFactor, a very good correlation between real car vs. simulated car output data can be achieved.
There are of course some small differences, as we have seen, that are difficult to eliminate without artificially “tricking” the data, but they are in general very small and sometimes not directly connected to the vehicle model, but to the track or to the driver.
Some more investments in track modeling could easily reduce these effects, but it was out of the scope of this for me!
Considering the overall expense requested to buy a similar software (between 30 and 50 euro), it could be seen that the performance vs. cost ratio is still extremely appealing.
Another interesting conclusion is the also the objective and the perceived balance of the simulated car vs. the real one is very close, when accurate data is used (of course here I am not going into the very difficult field of motion platforms and driver cueing, I only talk about driver feeling at the wheel). This has two very useful effect: on one side, it pushes the pilot to drive the vehicle in a very similar way to what he would do on track, enforcing the reliability of the final results; on the other side, it makes in theory possible to evaluate also setup parameters through a driving simulator using rFactor as a software, at least if we know and carefully evaluate the effects of all the assumption done by the code or by ourselves when modeling the vehicle. This is a very important point not to be underestimated, but still something that could be overcome.

By the way, real car lap time: 1.47.3; simulated car lap time 1.47.1.
Although this is not that important, in my opinion