Programming a driving simulator, how hard can it be?

  • Thread starter eran0004
  • 53 comments
  • 26,888 views
eran0004
Some clutches also have damper springs to soften the response, so I just wanted to be clear about what kind of spring I was talking about :)
Click to expand...

I have got so much info going in at the moment mate i am forgetting things i used to know. And getting things confused all the time.

I think 5 hours sleep a night since Christmas haven't helped. Well remember a few post's i was on about syncing the Hertz? well i used the wrong term again i used old arcade pcb timing as in hertz to monitor. I think you need something like deltatime in unity, it smooths everything out there's example script's and video in the link that explain's better than i could.

https://unity3d.com/learn/tutorials/modules/beginner/scripting/delta-time

Maybe you could use it in your blender simulation
 
vasiliflame
I have got so much info going in at the moment mate i am forgetting things i used to know. And getting things confused all the time.

I think 5 hours sleep a night since Christmas haven't helped. Well remember a few post's i was on about syncing the Hertz? well i used the wrong term again i used old arcade pcb timing as in hertz to monitor. I think you need something like deltatime in unity, it smooths everything out there's example script's and video in the link that explain's better than i could.

https://unity3d.com/learn/tutorials/modules/beginner/scripting/delta-time

Maybe you could use it in your blender simulation
Click to expand...

I've found this as well, from the author of the car physics tutorial I'm using. The actual web site doesn't exist anymore, but fortunately it's still available through the internet archive.

http://web.archive.org/web/20050204163259/http://home.planet.nl/~monstrous/tutstab.html

Hopefully it will solve the issues.
 
eran0004
I've found this as well, from the author of the car physics tutorial I'm using. The actual web site doesn't exist anymore, but fortunately it's still available through the internet archive.

http://web.archive.org/web/20050204163259/http://home.planet.nl/~monstrous/tutstab.html

Hopefully it will solve the issues.
Click to expand...


That's full on, I glaze over at sites like that takes me a few hours to Google all the terms ☺. Driving sims are so demanding I take a step forward and 3 back it seem's.

Have you got your head around your bogging down yet or is it still a mystery ?
 
vasiliflame
That's full on, I glaze over at sites like that takes me a few hours to Google all the terms ☺. Driving sims are so demanding I take a step forward and 3 back it seem's.

Have you got your head around your bogging down yet or is it still a mystery ?
Click to expand...

Well, I think I know what I need to do. But I don't know how to do it. I need to learn more about python scripting before I can go any further.
 
Hi, just read a bit through, this is truly a great effort! :bowdown:

A quick tip with the bogging issue: You should try to get the physics simulation rate decoupled from the graphics frame rate. As you are integrating from acceleration to velocity and again from velocity to position, the integration is sensitive to the time step lengths, and can blow up if the the time steps get too long. A rough outline to do this would be:

Code: 
# constants
physics_time_step = 0.005 # sec, i.e. 200Hz
# you can tweak this for more accuracy (lower) or less CPU burden (higher)

# this has to be done every frame
dt = get_time_beween_last_frame_and_now()

psteps = floor(dt/physics_time_step) # find out how many physics steps we have to do
for i in range(psteps):
    a = Force()/Mass() # calculate accelerations
    alpha = Torque()/Inertia() # calculate angular accelerations

    # do physics integration with small time steps
    v += a * physics_time_step
    p += v * physics_time_step
    omega += alpha * physics_time_step
    phi_rad += omega * physics_time_step
# now you have to do the last time step
last_step = dt - psteps * physics_time_step
a = Force()/Mass() # calculate accelerations
alpha = Torque()/Inertia() # calculate angular accelerations

v += a * last_step
p += v * last_step
omega += alpha * last_step
phi_rad += omage * last_step

# now apply the position changes and rotations
body.applyRotation(phi_rad)
body.applyTranslation(p)

If the code in the loop doesn't take longer than the actual frame time, the whole thing runs in real time with a lag of one frame. If the graphics rendering takes a little longer for some frames, it doesn't bother the physics calculation.

Hope this helps! 👍 Will try this out too if i can find the time! :)
 
Last edited:
Hi again! Almost three years later, I decided to pick this up where I left it. I've learned a thing or two about programming and looking back on the code, it's pretty messy. I started to clean it up and figure out what each line of code is supposed to do, what it actually does, and if it makes sense mechanically.

It runs pretty stable now. The only issue is that the wheel tends to add negative torque to the drivetrain when it comes to a stop while connected to the engine, causing everything to start spinning in reverse. Other than that, it seems solid.

Here's a video of it in action. There is no user interface, so you'll just have to figure out when the gear changes come. But basically, it starts in neutral, then shifts up from 1st through 5th, then skips a gear down to 3rd and skips another one down to 1st, then neutral and finally the ignition is switched off.

 
AOS-
That *Broing* sound was not expected. :lol:
Click to expand...

I don’t know what you’re talking about, this is cutting edge sound tech! A single VW Polo sample: volume controlled by throttle and pitch by engine speed. Don’t understand why PD, SMS or T10 didn’t think about that :lol:
 
@eran0004 I have a PDF copy of Milliken and Milliken's Race Car Design which includes nearly all the vehicle dynamics equations you may need for such an undertaking, feel free send me a PM if you'd like a copy.
 
It's been a while, but here we go:



Seems pretty free from glitches, and the handling is great considering I'm driving this with a keyboard, so the inputs are either on or off. Clutch and transmission are both manual.

The only issue I need to fix is that braking is reduced when the clutch is engaged. I suspect that BGE's default vehicle constraints can't handle engine force and braking force at the same time (hard to say though since the documentation is really poor), so I might need to add an exception that says that if brakes are engaged, do not apply engine force (or perhaps, if engine force is negative, apply it as a braking force).

What I'm most proud of is the clutch script, because it's smart enough to handle all sorts of different situations, like when the car is stationary, when you're shifting at high speeds and went you want to start while facing uphill. Instead of directly modifying the clutch, the script sets a clutch target and then adds or subtracts from the clutch frame by frame until the target is met.

Code: 
    #clutch release 
    if logic.car['clutchPressed'] == False and logic.car['clutch'] > 0:
        x = logic.car['rpm']
        y = logic.car['clutch_rpm']

        if x > 2500:
            if x > y+1000:
                if x > 4000:
                    clutchtarget = 0
                else:
                    k = -1/3000
                    m = 4/3
                    clutchtarget = k*x+m
                cRelease = clutchDelta*0.5
            else:
                clutchtarget = 0
                cRelease = clutchDelta
        elif x > 800:
            # y = a(x-h)**2+k
            a = -1/1700**2
            k = 1
            clutchtarget = a*(x-800)**2+1
          
            k = (clutchDelta-clutchDelta*0.1)/1700
            m = clutchDelta-k*2500
            cRelease = k*x+m
        else:
            clutchtarget = 1
            cRelease = clutchDelta
          
        if logic.car['clutch'] > clutchtarget:
            logic.car['clutch'] -= cRelease
        if logic.car['clutch'] < clutchtarget:
            logic.car['clutch'] = clutchtarget
          
    if logic.car['clutch'] > 1:
        logic.car['clutch'] = 1
    elif logic.car['clutch'] < 0:
        logic.car['clutch'] = 0

driving_controls.png
 
Last edited:
After struggling to come up with a fairly decent driving model through Godot Game Engine, I have been looking for a few other ways to develop a proper racing/driving game model. So I must say I have been trying to get into Visual Studio and Blender Game Engine. So your work is inspiring me, @eran0004 . I been closely following some of your videos just to try to come up with some kind of prototyping of a racing/driving environment so I can further enhance my willingness to model locations and vehicles.

I am thinking mere basics rather than re-invent Gran Turismo or some more proper sim racer. Something a bit funny I kind of realize is that I don't need meshes of tires and wheels to simulate tires going to work driving. Though, of course, it's a good bit awkward to have a vehicle that somehow sticks on the road without any tires (unless it's some anti-gravity ship of course). There is still a lot for me to learn. One of the reasons why I liked Godot is because I had better progress developing material than I have with Unity, Unreal Engine 4, Löve2D, or doing programming from scratch. If need be, I'll try to learn Python just to make a decent 3D racing game.

As for this topic in general, I think programming a driving simulator is only as difficult as you make it and as complex as you want to make it. Attention to detail and things like that are always considerations and factors in this department. There's also the kind(s) of racing/driving you try to implement. Lots of factors to consider in regards to making the most complete driving sim you can.
 
JohnBM01
I am thinking mere basics rather than re-invent Gran Turismo or some more proper sim racer. Something a bit funny I kind of realize is that I don't need meshes of tires and wheels to simulate tires going to work driving. Though, of course, it's a good bit awkward to have a vehicle that somehow sticks on the road without any tires (unless it's some anti-gravity ship of course). There is still a lot for me to learn. One of the reasons why I liked Godot is because I had better progress developing material than I have with Unity, Unreal Engine 4, Löve2D, or doing programming from scratch. If need be, I'll try to learn Python just to make a decent 3D racing game.
Click to expand...

Technically you can run a simulation as text only, you don’t need any visual representation. The physics definition of the car is enough.

For an internal combustion engine you need to define:
  • Power curve
  • RPM operating range
  • What will happen when you leave the RPM range
  • Some kind of idling function, which can either be a fixed minimum throttle setting (which is used on simple engines) or an auto throttle (which is used on modern cars).
  • Resistances in the engine. Primarily friction and pressure (friction is constant and pressure depends on engine speed and throttle position).
  • Inertia of engine and flywheel.
  • Optional: starter engine.
Then you have the clutch, which is quite delicate (as everyone who drives a manual may know). For a simple clutch you just need to apply a factor to all the torques that are being transmitted through it and make that factor depend on the state of the clutch pedal.

For a more realistic clutch you should calculate the friction between the clutch plates and have the torques depend on that.

And if you don’t have an actual clutch pedal you need to simulate the operation of the clutch: how fast should it engage? How should engagement depend on engine speed and wheel speed? Think about what you’re doing when you drive a manual car and try to write down some rules that describes how you operate a clutch pedal.

Gearbox is fairly simple, just use the gear ratios to multiply torque and divide speed. Use negative ratio for reverse gear. Optional: define friction and inertia of gearbox.

The final drive is basically a gearbox with just a single gear ratio. For a simple drivetrain, just divide the torque equally between the powered wheels. For a more realistic approach, model a differential gear that distributes torque and speed based on the load on each wheel.

The wheel is technically a lever, meaning that its radius have the same impact on force and speed as a gear ratio. The radius of the wheel multiplies speed and divides force (torque = force * radius => Force = torque / radius).

Finally you need to calculate the friction / mechanical grip between the tyre and the road. In the vehicle handler I’m using in Blender it’s done automatically, which is both good and bad. Good because I don’t need to worry about it and bad because I can’t change it if I want to. Same with suspension.

A good idea is to use SI units throughout the physics simulation, it simplifies everything a lot and you don’t need to use any magical constants to convert between arbitrary units. The SI units are:


Mass: kg
Distance: m
Time: s
Speed: m/s
Acceleration: m/s^2 (Speed/time)
Force: N (mass*acceleration)
Angle: radians (360° = 2*pi*radians)
Angular velocity: radians/s
Torque: Nm (Force * radius)
Work: J (Force * distance)
Power: W (Work / time, or Force * speed, or Torque * speed)
 
I do find this interesting.

I'd love to attempt even a numerical simulation, but I'd like to start much further upstream, like with atmospheric air, and fuel, and end up with traction at a contact patch... simulating the input variables at each stage, and not just something that simulates the output alone.

Sadly neither my grasp on the wide array of Physics necessary, and the scripting skills necessary are up to scratch.
 
MatskiMonk
I do find this interesting.

I'd love to attempt even a numerical simulation, but I'd like to start much further upstream, like with atmospheric air, and fuel, and end up with traction at a contact patch... simulating the input variables at each stage, and not just something that simulates the output alone.

Sadly neither my grasp on the wide array of Physics necessary, and the scripting skills necessary are up to scratch.
Click to expand...

I had to study a lot of Wikipedia articles and YouTube videos on physics just to understand the difference between torque and power :P But in the end it was worth it, and it’s actually really simple once you understand how it’s all connected.

Theoretically you can simulate everything down to molecular level, but there are two problems:

1. The more variables you introduce, the greater the risk of bugs and the harder it is to troubleshoot problems with the simulation. You can end up with a tiny error high up in the chain (say that you forgot to define what happens when track temperature goes below freezing) that causes a massive explosion at the end (perhaps the drivetrain explodes due to sudden and massive blip in frictional forces).

2. The computer can only perform so many calculations per second. At some point you get a more accurate simulation by simply letting the physics run at a higher framerate than by introducing more variables.
 
Hi. Great work on your simulator. (This is also my first ever post! :D - Sorry if it's considered necroposting... :boggled:)

Some time ago I attempted my own simulation and I'm finally coming back and rewriting most of my code. So far, all is well, although I do need some clarification.

I'm mainly stumped on the topic of a transmission and getting my engine on some wheels, especially with your torque based approach. For my simulation I have chosen to use the friction based clutch system you proposed on the first page of the thread. I can't seem to wrap my head around how to calculate torque applied to my wheel in every frame - and would my initial clutch plate torque collected from my transmission (before calculating frictional forces) have anything to do with it?

My only solution has been treating the torque applied to the clutch as the torque applied to the wheel as well, just dividing it.
Running back over my code now with a slightly better understanding, this solution makes absolutely no sense, and I am thrown back to where I was.

I'm also very confused on if using a torque based model is a good idea in the first place, as the transmission to my understanding is almost entirely rigid.

I hope that all is well.
Even though it's most likely been a while since you've touched this project, I also hope you're able to provide me with some much needed help. Thank you!:cheers:
 
chedsapp
I'm mainly stumped on the topic of a transmission and getting my engine on some wheels, especially with your torque based approach. For my simulation I have chosen to use the friction based clutch system you proposed on the first page of the thread. I can't seem to wrap my head around how to calculate torque applied to my wheel in every frame - and would my initial clutch plate torque collected from my transmission (before calculating frictional forces) have anything to do with it?
Click to expand...
Assuming that the clutch is not slipping, the torque applied to the wheel is the same as the torque output of the differential. If you don’t have a differential then the wheel torque is the same as the output torque of the gearbox, divided by the number of powered wheels (and minus any frictional losses along the way). The output torque of the gearbox is the torque at the flywheel multiplied by the total gear ratio (gear ratio*final drive ratio).

If the clutch is slipping, then the torque transmitted between the flywheel and the gearbox is determined by the friction between the clutch plates.
chedsapp
I'm also very confused on if using a torque based model is a good idea in the first place, as the transmission to my understanding is almost entirely rigid
Click to expand...
It depends on what you want to do, I guess. A very simple vehicle model could just apply a force to the car that’s proportional to the power of the engine and inverse to the speed of the car:

If speed < x: Force = power/x
Else: Force = power/speed

x is some cutoff speed below which you want a constant force, otherwise you’ll get infinite acceleration when the speed is infinitely close to 0 and a division by zero error when the speed is zero.



chedsapp
I hope that all is well.
Even though it's most likely been a while since you've touched this project, I also hope you're able to provide me with some much needed help. Thank you!:cheers:
Click to expand...
Thanks! All is well :) The project is a few years old, not sure if I would use the exact same solutions now if I did it again, but I’ll be happy to help if you have any more questions!
 
Hey,

I hope you're doing well! I’ve been working on car simulation in Unity, and I’ve used your project as the starting point.

First, I created a torque curve generator that generates the torque curves:

image (2).png
image (3).png
image (4).png

1) wotTorqueCurve
2) idleTorqueCurve
3) noSparkTorqueCurve

I've also got the engine with the flywheel working! Here’s the code and a video showing it in action:
C#: 
private void SimulateEngine()
{
    flyInertia = 0.5f * flywheelMass * Mathf.Pow(flywheelRadius, 2);
    engInertia = crankInertia + flyInertia;

    Throttle = Mathf.Lerp(tMin,tMax,throttleInput);

    if(RevCutOff<RPM && RPM < RevLimit)
        spark = true;
    else
        spark = false;

    if(spark)
    {
        float wotTorque = wotTorqueCurve.Evaluate(RPM);
        float idleTorque = idleTorqueCurve.Evaluate(RPM);
        torque = Mathf.Lerp(idleTorque, wotTorque, Mathf.Pow(throttleInput, RPM / (RevLimit * Throttle)));
    }
    else
    {
        torque = noSparkTorqueCurve.Evaluate(RPM);
    }

    float BHP = (torque * RPM) / 7120.91f;            

    flywheelAcc = (torque / engInertia) * (60 / (2 * Mathf.PI));
    RPM += (flywheelAcc * Time.fixedDeltaTime);


    //Sound system and debugging
    currentRPM = RPM;
    load = Mathf.Lerp(-1, 1, throttleInput);
 
    Debug.Log($"Engine RPM: {RPM:F2}, Torque: {torque:F2}, BHP: {BHP:F2}");
}



To me, the engine RPM seems alright, but I'm not entirely sure about the torque output.

Right now, I'm stuck on implementing the transmission. As you mentioned: "There are forces from the crankshaft acting on the transmission, and forces from the transmission acting on the crankshaft."
I’ve spent hours trying to solve this, but none of my attempts have worked so far.

I have all the necessary things like gear ratios.
Additionally, Unity has something called a Wheel Collider, which simulates wheels and uses torque to propel the vehicle. These colliders have properties like:
  • motorTorque: used for propulsion
  • brakeTorque: used for braking
  • mass
  • forwardFriction
  • sidewaysFriction
  • rpm
  • rotationSpeed
I assume the torque at the wheels should be set like this:
C#: 
wheelCollider.motorTorque = gearRatios[currentGear] * finalDriveRatio * torque; // torque = engine torque
This should result in the car moving forward, but there is no correlation between the engine and the transmission, so, as expected, the engine RPM doesn’t respond to the car’s movement.

I’m struggling to figure out how to properly blend the forces from the crankshaft with those from the transmission.

Any advice would be greatly appreciated!

Thanks for your awesome work on the simulation — it’s been super helpful for my project!
 
Last edited:
ALXK
Hey,

I hope you're doing well! I’ve been working on car simulation in Unity, and I’ve used your project as the starting point.

First, I created a torque curve generator that generates the torque curves:

View attachment 1423848View attachment 1423849View attachment 1423850
1) wotTorqueCurve
2) idleTorqueCurve
3) noSparkTorqueCurve

I've also got the engine with the flywheel working! Here’s the code and a video showing it in action:
C#: 
private void SimulateEngine()
{
    flyInertia = 0.5f * flywheelMass * Mathf.Pow(flywheelRadius, 2);
    engInertia = crankInertia + flyInertia;

    Throttle = (tMax - tMin) * throttleInput + tMin;

    if(RevCutOff<RPM && RPM < RevLimit)
        spark = true;
    else
        spark = false;

    if(spark)
    {
        float wotTorque = wotTorqueCurve.Evaluate(currentRPM);
        float idleTorque = idleTorqueCurve.Evaluate(currentRPM);
        torque = Mathf.Lerp(idleTorque, wotTorque, Mathf.Pow(throttleInput, currentRPM / (RevLimit * Throttle)));
    }
    else
    {
        torque = noSparkTorqueCurve.Evaluate(currentRPM);
    }

    float BHP = (torque * RPM) / 7120.91f;             

    flywheelAcc = (torque / engInertia) * (60 / (2 * Mathf.PI));
    RPM += (flywheelAcc * Time.fixedDeltaTime);


    //Sound system and debugging
    currentRPM = RPM;
    if (throttleInput > 0)
        load = Mathf.Lerp(load, Mathf.Abs(throttleInput), throttleInput);
    else
        load = Mathf.Lerp(load, -1, 1-throttleInput);

    Debug.Log($"Engine RPM: {RPM:F2}, Torque: {torque:F2}, BHP: {BHP:F2}");
}



To me, the engine RPM seems alright, but I'm not entirely sure about the torque output.

Right now, I'm stuck on implementing the transmission. As you mentioned: "There are forces from the crankshaft acting on the transmission, and forces from the transmission acting on the crankshaft."
I’ve spent hours trying to solve this, but none of my attempts have worked so far.

I have all the necessary things like gear ratios.
Additionally, Unity has something called a Wheel Collider, which simulates wheels and uses torque to propel the vehicle. These colliders have properties like:
  • motorTorque: used for propulsion
  • brakeTorque: used for braking
  • mass
  • forwardFriction
  • sidewaysFriction
  • rpm
  • rotationSpeed
I assume the torque at the wheels should be set like this:
C#: 
wheelCollider.motorTorque = gearRatios[currentGear] * finalDriveRatio * torque; // torque = engine torque
This should result in the car moving forward, but there is no correlation between the engine and the transmission, so, as expected, the engine RPM doesn’t respond to the car’s movement.

I’m struggling to figure out how to properly blend the forces from the crankshaft with those from the transmission.

Any advice would be greatly appreciated!

Thanks for your awesome work on the simulation — it’s been super helpful for my project!
Click to expand...

The engine looks good from what I can see on the video. The torque output seems fine.

The coupling between engine and the rest of the drivetrain is tricky, I think the key there is to have a good clutch model. The clutch should have three states:

1. Disconnected. No torque transmitted between engine and gearbox.

2. Locked. Full torque transmission. The engine speed is locked to the speed of the drivetrain.

3. Slipping. The amount of torque transferred between engine and gearbox is proportional to the contact pressure between the clutch plates.

State 1 and 2 are pretty straightforward. The third requires modelling the frictional torque in the clutch. The net torque on the side of the engine is then engine torque - clutch friction torque, while the net torque on the side of the gearbox is clutch friction torque - wheel torque/(gear ratio × final drive ratio) . If the net torque is negative, engine speed and wheel speed decreases, and vice versa.

When the two clutch plates have similar (or similar enough) speed, the clutch goes from slipping to locked.
 
You could make a very simple model, which perfectly couples the engine to the wheels, by just using the gear ratio and final drive ratio to multiply the torque and divide the rpm from the engine to the prop shaft, and eventually, the roadwheels. Then you can get a force on the road from the torque at the rear wheels * the radius of the wheels.

Then F = m a gives F/m = a to give car body acceleration (m is mass of car)

But, as eran says, you need a clutch model as otherwise if you assume perfect coupling then you will get jerky behaviour when a clutch perfectly engages in one time step of your model. You'll either have the roadwheels going from zero to a few hundred rpm in a millisecond, or the engine bogging down to stall speed in a millisecond, whereas they should meet in the middle somewhere.

Regarding torques down the drivetrain, an important part you've modelled is moments of inertia. You could in theory model these for the gearbox, prop shaft, diff, axles, alloy wheels etc. The important take home is that some of the engine torque will have to be used into spinning up these MOI items, rather than just being delivered to the roadwheel and then contact patch.
T = I * alpha so for each component modelled you need to know its angular acceleration as well as MOI. If you know the angular velocity (i.e. rpm) for each component, then the change between model time steps gives you ang acceleration. The gear ratios and final drive will affect this i.e. an engine at 3000 rpm with a 1st gear of 3:1 and FD of 4:1 will have a prop shaft moving at 1000 rpm and axles moving at 250 rpm. Any angular accelerations will also follow this 12:4:1 ratio.

So T engine = (I1* alpha1) + (I2*alpha2) + ..... + roadwheel torque to contact patch

You should be able to rearrange algebraically and solve for roadwheel torque given to contact patch (I think).
 

Similar threads

Gio318is
  • Locked
"Critical Issue: Unrealistic Engine RPM Behavior Resembling Excessive Flywheel Weight in Gran Turismo 7 – Updated Findings and Test Method
Replies
2
Views
725
daan
daan
TumeK5
"The Real Driving Simulator"
Replies
12
Views
4K
shadow0460
S
MIE1992
Some thoughts on controls, assists, and transmissions.
Replies
0
Views
1K
MIE1992
MIE1992
T
  • Poll
We need a better clutch
Replies
21
Views
5K
Serum
Serum
G
BUG bring back engine braking to granturismo
Replies
9
Views
3K
giogoesinsane
G

Latest Posts

Back