Posted by: drracing | October 12, 2012

Vehicle dynamics

Again, a very long time i don’t write here.
Again, although it was already at a good point, the last project i started didn’t go to an end.
I guess that’s life.

During the last months, anyway, i’ve had the possibility to add beside my everyday work some good racecar weekends, working for an italian team mainly on sport prototypes (FIA CN race cars, Speed Euroseries) and on Formula 3 cars, my first and neverending love. Not many races to be honest, but better than nothing. Some good weekends anyway, not only for the results but also because i had the possibility to work together with a very good friend, a very smart and experienced guy who i really think is one of the best race engineers i have ever met. Some good locations too, as SPA, where in May we had a race during the WEC (World Endurace Championship) weekend.
CN cars are pretty interesting as well. Pretty free regulations have and the typipcal two seater closed wheels shape lead to quite aero efficient cars that, using very similar tyre to Formula 3, have also a pretty good grip. The engine is a Honda 2000 complying to group N regulation: around 255 HP with quite low costs. A very good thinkg in this series is a nice and genuine battle between different chassis manufacturers, with even some others that have recently entered the list or will do it next year (Ligier, Norma, Wolf, Juno and now Tatuus and maybe even a very important name as Oreca for 2013).

In the mean time i have taken again in my hand some vehicle dynamics activities. Mainly two things: Driving Simulation (mainly based on rFactor, i am concluding the modeling of a Formula 3 car which is giving me some real satisfaction!) and Lap Time simulation (on this side i am just starting something on my own, with pretty conventional tools, i will talk about that again in other posts).

I have been involved befor with Driving Simulator and i will never stop to believe they are not only interesting and funny to use, but also very useful from an engineering perspective (at least when the code works properly and the model i built with the right attention to details and starting from real data).

In my case, since i have some knowledge about vehicle dynamics and modeling but i don’t know anything about the 3d modeling and sound modeling required for this kind of simulators, i started from an already pretty good “MOD”, the “Japanese Formula 3 Mod” for rFactor.
I think these guys have done a pretty good job with graphics and sounds; the cars looks really nice and very similar to the real counterparts. While the physics, althoug not bad and with good basics, still had really big big room for improvement: that was my room!

An advantage when you work/have worked with real race cars is that sometimes you can access data and information that otherwise are very difficult to find. This is true both for data regarding the car itself (Masses, engine curves, suspension geometry, tyres data, aero data, gear ratios, rates…) and the possibility to then validate the model behaviour on the real counterpart through logged data analysis: a thing that make this simulations even more interesting is in fact the possibility to analyse your (or your driver’s) sessions with a real data logging software, Motec I2 in this case.

The modeling process itself can really teach a lot: you are of course forced to know your car very well, gathering as more data you can to insert them into the virtual model. At the same time, you need to “speak the software language”, to be able to give this data to the software in a way it can really use them, producing realistic results. Pratcially, each subgroup of the car is represented by some kind of mathematical model, so you must fit it with the data you have to reproduce the most realistically you can the behaviour of the real component. The base concept is very similar to multibody (see Adams) and although some of the things are made easier, some of them as really some complexity to face. Sometimes the problem is to really learn the language the programmer used to model each area of the car (sometimes you also ask yourself why they do it this way, but it’s not really useful, since normally you can’t change it!), so actually what is the meaning of each parameter you have in your list how which equations to use with them to model a physic behaviour/property/performance.
Finally, once your model has been validated against real data (and this could be a long process if you want to do it properly: tyres, aero, engine, suspensions…) you can not only wear the drivers shoes, to understand also how things work on the other side (learning tracks, trying different lines and seing the result, braking techniques, throttle and steer work, gear ratios, driving styiles, brake balance…), but you can also have your experiments and see, form an engineering perspective, what their effects are. Absolutely for free, of course! Of course, as i will explain later, i would be careful to use this kind of simulation as the final setup tool: also when you put your driver in front of a screen, it will never drive exactly as in the real car (of course, if you have the resources of Formula 1 teams, that could probably became true instead. Here we talk about “house simulators”) but, if the track is modeled properly (and this is often the case and it is geting better with the new products going out in the near future, with a wide use of laser scanning, see ASSETTO CORSA for example), you can anyway obtain useful informations and, anyway, at least relative trends.
The basic condition to make it happen is of course that your model is “reliable”, so that it really try to represent the real car at its (and your) best.
But as i said, if you look to trends and to relative changes, this kind of simulation can at least be a very teachingful tool.

Somebody would of course tell: hey, this is a game, you can’t expect to have totally trustable behaviour here…that’s probably true!
But which model is really behaving as the real counter part? And anyway, is it really useful? We could even question if some of the data we are puting in the model is really trustable: measurements are never 100% precise, you cannot aovoid to have some errors and some of them (like forces for example) are anyway often done in “lab conditions” that are never the same (or even close) to what you will find on the track.
I can tell you, these simulations have anyway a very good level of “useful complexity” and although the modeling techniques they use are somehow different from what we normally use in “proper simulations” (see tyre Pacejka models, that are not used in rF) they still give to the “modder”  the possibility to work on a huge number of parameters, allowing to simulate sometimes also very complex behaviours (like for aeromaps that include ride height, wing angle, pitch influence with also non linear trends and where you can model separately the aero contribution of body, wings and diffuser, or for tyres where, just as a basic example, you can model a non liner load sensitivity when even Pacejka Magic Formula don’t give this possibility).

The result? Amazing, in my opinion! And it’s of course funny as well! I am not a driver, or anyway not a good one both in the real or in the virtual world. But when you compare the logged data to the info you gather during a simulated test session (with the car maybe driven by proper drivers in both cases), you can be really surprised of how close the performance are. And i don’t talk only about speed or accelerations, but also about steering traces, suspension movements, loads, ride heights…

You want something more? In rF, your data logging system has “sensors” that probably 99% of the team managers you have ever met would never allow you to buy (they are not cheap…not at all) and that you have always dreamed to have! Tyre temps, ride heights, 4 speeds, tyre pressures, wheel loads, tyre forces….a lot of fun!

I will go back on this topic, describing more into details what and how i have modeled and showing some more data also some setup experiments.  Some more considerations will regard also a comparison between lap time simulation and driving simulation.



  1. Greetings. I liked your article; it gives out very similar information I got from working with real life motorsports professionals. But I have to correct something you stated. While Prof. Pacejka (et al) has worked on and published several tire models (from semi-empirical to simple physical and finally complex tire models (Advanced Brush model, for instance) and no racing simulation developer can use all of these models, the truth is ISI (the company that produced the physics engine behind rFactor (also an ISI creation)) formulated a complex tire model based on Pacejka MF 96 (they introduced some variations, such as incorporating speed, pressure and stiffness effects). So please correct that as it does not correspond to the information provided by ISI themselves.

  2. Hi Miguel,

    thanks for your comment and your interest in this post.

    Actually i don’t know the hardcode of the ISI physic engine, i have never worked on that directly.

    The model has several similarities with Pacejka’s one, but the way you are modeling tyre behaviour is IMHO not as you would do with a MF.

    Here the curve is described by a look up table, then you specify how it will change with load.

    You then define somehow “grip ellipse” boundaries and how they evolve with load, camber, temperature…so i agree it is somehow more sophisticated than than a normal Pacejka fitting. It actually allows to catch some features with more precision and with more “realism”.

    But the way you do the modeling itself is anyway different than what a final pacejka MF user would do. With MF you simply have an equation and you just need to insert the proper coefficients to have the right results.

    Actually, what you do in rF is probably closer to what you would do if you had to fit raw data to a pacejka magic formula than what you would do as a final user of a magic formula, when you simple receive a set of coefficients from a manufacturer (or a testing center) and use them for some kind of simulation.

    I think to work out a tyre model in rF (or in other driving simulators) is maybe even harder then to simply use a MF in ADAMS (for example), since you have to fit the data you have to the software and, to do it properly, you are forced to analyse them more into details and to catch all the trends they show.
    Then, you have to properly communicate this info to the software, so you also need to speek the proper language…and it is sometimes the most difficult part, in my humble opinion. And that’s true also for other things you need to model to complete a car in rF. Sometimes, you simply don’t know which meaning do the ISI intended to give to a certain coefficient and it’s not easy to find the right info to know these meanings.

    • If I may reply, I’d like to say that instead of using 15 a parameters, 13 b parameters and around 17 c parameters (Fy, Fx and Mz respectively), we can model tires the MF-Tyre way via a simple combination of 4 inputs: side slip angle variations, long. slip, camber angle and vertical load. We can easily extend this to include pressure and speed effects – it has been done before, and a variation of it was employed by ISI. While we lose flexibility with this modelling “technique” in comparison to “proper extensive MF”, we are spared the big trouble of having to find data for the 45 parameters or so (you know better than me how much each set of params from a tire manufacturer costs). I have modelled tires the “ISI WAY” and modelled them the MF way and the output is strikingly similar. We’re also obviously spared the trouble of combining slip (hidden in the code) and we also don’t have to deal with carcass effects (which, as you know, only advanced physical Pacejka models incorporate – truth be told, SWIFT also “has” it in the form of a rigid ring and flexible sidewalls). So, all in all, modelling tires for ISIMotor2 (pMotor2, the physics engine of rFactor) can produce results which, with some intelligence, can be used for prediction purposes. The difference is only in what type of interface to present to the end user (modder): an interface with 40-something params or one with 4 or 5 basic inputs (in the case of pMotor2, the 4 basic ones plus pressure, temperature (linear), wear (almost nonlinear), rolling resistance and speed).

      • Your comments are really interesting.

        I totally agree with you about the potential the ISI tyre modeling way has and that to treat the modeling phase with 4 main parameters (which can somehow be visulazed more easily by the end user) is somehow more effective than to do it with 17 parameters (only for the cornering force), above all for the end user or for somebody who doesn´t have all the data that, on the other hand, a manufacturer would have.

        I am not an expert in tyre modeling but i have used several times pacejka MF coefficients to build up my curves, anlayse and use them for vehicle dynamics simulations. That´s the core of my point: normally, you RECEIVE the data and you don´t go into modeling.
        On the other hand, when you build up an rF car, you MUST model the tyre: so actually you don´t simply analyze its behaviour, you are somehow defining its behaviour (not the real tyre behaviour, of course, but the way the simulated tyre will perform).

        That´s somehow different than what i have normally done in my simulations experience. And it has been extremely interesting to me, because it forces the user to really understand the tyre.

        It has been a very interesting and useful process to build up my knoledge on my own and to create my own tools to make my simulated tyre to perform as more as possible as the real one, but it has not been an easy task, since sometimes (and that´s true not only for tyre modeling) you have to go and test your model to be sure what you did was correct. I think the final user would have appreciated some more documentation about that.

        A similar tyre model is used, for example, by Bosch Lapsim, although the scope is of course different.
        In Lapsim there is a nice GUI where each number you are going to change is more or less explained and the final result can be visualized. You don´t need to create any tool, it´s all there.

        I agree with you on the effectiveness of the rF way of tyre modeling. As i said in my post, i think it has even something more than a normal MF approach (or at least, than a normal MF approach as i know it). Here you are somehow doing the process than normally the manufacturer does for you, when they give you pac coefficients.

        As a side i still think the whole process of modeling a tyre could have been made more effective with some more documentation available from the ISI themselves.

        You anyway seem to have a good knowldge about this topic, above all tyre models. What is your background?

    • Hi There,

      Is there any chance you could share how you managed to insert your tyre data to rFactor?
      I have located the file where the data needs to go and have Cornering force and SAT data vs Slip Angle data of specific tyres.

      I am now stuck and do not know how to use this data within the rFactor tyre data file.


  3. My background is Theoretical Physics. Professionally, I’m a computer programmer.

    I agree, ISI didn’t provide on release technical advices on modding physics. But through their interaction with a hard core group of simracers and modders (from 2004 till 2008) they managed to steer modding in the right direction. It is, and always will be, however, a matter of personal effort: those who studied and invested more time in it got the best results.

    I understand (re: receiving data vs modelling).

    But, as Prof. Pacejka himself and other scientists/engineers have stated, the MF-based tire modelling is not predictive but merely analytical. From the data collected (tire companies), forces and moments can be represented via sine functions, even under slip conditions (full or partial). So, when you deal with your data and input it into an engine with the MF formulas, you get a representation (faithful, the (many) authors claim) of those real life curves. But, in the end, a physics engine will have, based on this, a deterministic function, i.e., a modelling function as you are effectively dictating what the behaviour will be based on conditions set by (a) Pacejka parameters and (b) dynamic conditions on the simulated track.

    With ISIMotor2 as opposed to other physics engines (Racer, X-Motor Racing and a number of open source car simulations), you use 4 to 5 basic inputs to achieve slip curves, which you then tweak to match whatever real life data you have; but the physics engine will alter these curves (base curves, after all), based on dynamic conditions (load, grip, stiffness, slip, speed, pressure, temperature and wear) and a number of relevant parameters set in the tire file, so in essence you are effectively just designing base curves and deriving from it behaviour. Again, as with pure Pacejka 5.5x based physics engines, ISIMotor2 will perform its deterministic function in establishing tire/car behaviour based on the base curves and the dynamic conditions that alter them.

    In essence, differences aside, both approaches (pure MF or MF-based tire modelling) work the same way: analytically, non-predictive, deterministic. I am not, however, a race tire engineer or a race car engineer, therefore my opinion on this subject is somewhat limited to the approaches available to me and my experience.

    In regards to rF’s tire modelling effectiveness, I’d say the right balance was achieved between the granularity provided by 40-something Pacejka parameters and the ease of use by people who do not have the possibility of getting their hands on race tire data. Internally, the model would have benefited a lot from a non-linear approach to wear-temperature-grip and a few more parameters to work with – but that would have had its costs in terms of “gaming performance”. Sometimes, just upping the update rate of part of the engine physics translates into a significant drop in frame-rates, which is a sales killer.

    So, all in all, considering we (end users) do not have multi-million Euro clusters of 40 to 50 highly cooled cpu machines and developers don’t have budgets of 50 million Euros for physics alone, the accuracy/realism provided by a platform like ISIMotor2 is very impressive.

    This Bosch Lapsim you mentioned seems rather interesting and instructive. Software like that provides people with a rather technical approach to tire simulation and tire modding specifically, as opposed to modding via “feel”. As I said earlier, your article (and comments to my comments) is very interesting, it’s not often one reads feedback on modding from someone with actual race engineering experience. Articles like these tell me that my approach to modding is correct, but I also manage to learn something from them as well.

    So, my thanks for the article and comments.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: