Calculating Car Engine RPM for Game

I am trying to make an advanced car physics simulation for a game. What I need to do now is to calculate engine RPM in quite an accurate way. As the timesteps between calculations are very small (60 frames per second or 0.166667 ms) I can afford to use old frame data in a new frame so that's not a problem.

What I want to do is to calculate engine RPM. The values that I can access are:

• Throttle $f_\mathrm{throttle}$ (a scalable float value between 0.0 and 1.0)
• Clutch $f_\mathrm{clutch}$ (just like throttle - a scalable float)
• Engine torque output $T_\mathrm{engine}$ based on torque curve (torque curve is lineary interpolated curve between RPM and Torque axis using RPM as input which returns torque as float output).
• Wheel angular velocity $\omega_\mathrm{wheels}$ (a float value in rad/s, for drive wheels it is $T / I$, for free-rolling wheels it is $V/r$).

I need to calculate the engine rotation speed in revolutions per minute.

• Ignoring slipping of the clutch, you seem to be missing the most important part: gears. The wheels and engine will be mechanically locked together. The only difference in wheel RPM and engine RPM will be the gear ratio. – hazzey Mar 1 '16 at 17:27
• I have gears. However, when using wheel velocity multiplied by differential ratio, multiplied by gear ratio, multiplied by 60 and dividen by 2$\pi$ it seems to not to have any support for clutch. Also, obtaining wheel angular velocity in my current approach doesn't work in case of impact. It means that whenever car crahshes the wheels keep turning fast and there is no way to reduce their rotation sleep and leave just a little slip impact which quickly ends due to friction. So the problem seems to be deeper than I thought. – Adrians Netlis Mar 1 '16 at 17:31
• I have found out that: $\alpha = \tau / I$. So basicly I need to know the engine moment of inertia. However, I don't know where to find this value. I also don't know if it is constant or if I need a curve. – Adrians Netlis Mar 16 '16 at 16:34

There are many variables, but much of your system can be measured empirically with a cars internal sensors and OBD-II system (or possibly manufactures data, but I wouldn't hold my breath). For RPM there are two scenarios you would have to independently model; clutch engaged and clutch disengaged.

Clutch engaged: As hazzey mentioned in the comments, the engine will turn at a gear ratio of the wheel speed. Take your RPM and put it into the torque curve(for your given throttle position) to give you torque. Torque times your gear ratio and tire radius gives you force. Then solve F=MA with the mass of the vehicle to give you acceleration. Then use the kinematic equation v=a*t+v0 to solve for your new velocity based on your current velocity and time step. Which then is used to calculate your new RPM... and so goes the iteration. Similarly you could solve it with kinetic energy equations instead.

Clutch disengaged: This case can be modeled by considering energy input and internal friction of the engine. When you stop pressing on the gas, even without the wheels on the ground, the system will slow down. You could measure this for a particular car empirically by graphing RPMs when throttle input is removed. The only difference between the wheels off the ground and the clutch disengaged is the amount of inertia or kinetic energy that is stored in the spinning system and additional friction imposed by the other spinning components. This could also be determined empirically.

Take RPM to the torque curve(for your given throttle position) which gives you torque.
Torque * RPM = power input to the free spinning engine.

Power input = internal friction + kinetic energy

Internal friction is calculated from an empirical curve based on RPM. Then solve for kinetic energy input. Then use the moment of inertia (found empirically for a specific engine) to solve for your new RPM... put that back in again and iterate.

Note that the engine friction is still obviously present in the clutch engaged model as well, but is probably insignificant compared to other forces and coefficients (drag for example). Its usually best to get the model running in a simple mode first. You can always increase the accuracy of your model later if necessary. Every where I say "empirically" can be replaced by a fudge factor(an assumed/guessed coefficient) for initial model testing. For a highly accurate model however you will need highly accurate data.

• Hm... OK!. About the: Then use the moment of inertia (found empirically for a specific engine) to solve for your new RPM... put that back in again and iterate. I thought it can only be used in equation $\alpha=T/I$, but maybe I was wrong. Would you say that in the beggining aquiring engine speed from drive wheels would work well? With that there is one problem. When crashing, my car doesn't receive huge torque input so the wheels keep turning very fast and brakes a bit only due to rolling resistance(which becomes very, very small at that speed) and engine braking. So I can't make them stop. – Adrians Netlis Mar 3 '16 at 5:55
• In a game where the physics is not accurate it will be very difficult/impossible to have an accurately simulated RPM. Probably what ever you come up with will be good enough. Perhaps pulling other data that would indicate if the car was on the ground or not(vertical acceleration from gravity) would be good enough for you to fudge some calculations. – ericnutsch Mar 3 '16 at 6:10
• Well, I use raycasting for wheels which allows to determine things like material or if wheel touches ground, that's not of a problem. More of problem is detecting if car has had impact(e.g. crashed in tree or in other car) and than calculate proper engine RPM and wheel angular velocity in that case. It ca be approximation, but it still must feel realistic. – Adrians Netlis Mar 3 '16 at 11:28