Hi,
I’ve been reading articles about car mechanical physic and comparing them to Unity’s standard asset car. In the standard asset the 2 front wheels steer at the same angle, which I suppose is not how a real car would do. In real cars there would be something called Ackermann Steering Geometry, in which the inner wheel is turning at larger angle (in regard to the forward direction) and help reduce tire wear and turn the car better. In nVidia’s PhysX NxWheelShape, which is what Unity’s WheelCollider is based on, there is actually an option for Ackermann Steering, but WheelCollider doesn’t have this. Is there a way to figure out the amount of difference in steering angles of the inner wheel and outer wheel to simulate Ackermann Steering?
Next is the differential. In my understanding, differential helps car turn by making the outer wheel spins faster than the inner wheel. Also in limited slip differential, in case when one wheel is on less traction track, the torque will be send to the wheel with more traction (spinning slower). Now the thing is I don’t know what amount of torque will be send to each wheel when one wheel is slipping, and how to “detect” if one wheel is losing traction and should that wheel be receiving less torque if it’s slipping at that amount.
Last is about the clutch. NxWheelShape is modeled around clutch strength that separate the engine and the drive train. According to Nvidia, assume that the engine is connected to only one wheel, then the torque at the clutch is
clutchTorque = clutchStrength * (engineRPM - GearRatio * WheelRPM)
The clutchTorque is then delivered to the engine and the wheel
twe get the net torque of the engine
engineTorque = driveTorque - clutchTorque
and the torque the wheel will be received is
wheelTorque = brakeTorque + handBrakeTorque + tireTorque + Gear * clutchTorque
So the engine will be spinning on its own. When the engine is spinning faster than the wheel, clutch torque is positive, then wheel torque increase. When engine is spinning slower than the wheel, clutch torque is negative, engine torque decrease, wheelTorque decrease (sometimes negative).
From the model above, I can’t see how engineTorque is used to power the wheel, since wheelTorque doesn’t have engineTorque in the equation. From my observation, the engineTorque is used only to spin the engine and get the engineRPM. That engineRPM is then translated to wheelRPM. WheelCollider in Unity is powered by motorTorque (which I don’t know what its counterpart is in NxWheelShape) and wheelColliderRPM is read-only. To implement NxWheelShape original model to WheelCollider, the only way I can think of is to only focus on the engine, figure out the engineRPM at a given moment, look up the torque curve at that RPM, send that torque to the wheel through the transmission and the clutchStrength, get wheelRPM and start again. What I need help on is to actually figure out the engineRPM through the clutchTorque and the wheelRPM.
I know it’s a wall of text but I haven’t found any topic on these in the community, and I hope that everyone who has the same problem or idea can gather here and put up a tutorial and implement wheelCollider better.
I really wish WheelCollider has all the exposed attributes from NxWheelShape because it would help a lot in actual vehicle simulation. WheelCollider.motorTorque in my opinion is too vague and not enough. We have nearly no control over WheelCollider.
A simulation will never be perfect. PhysX Wheel implementation is Far from perfect.
Have a look in Edy’s projects / assets (@VehiclePhysics), his know how with Wheel Colliders is superb…
F1 cars, for example have -based on the setup- ‘inverted’ ackermann steering!
If you want simple Ackermann steering, the math behind seems to be simple.
Seems like you could do some math and calculate the wanted turning radius (well, 2 radii inner and outer wheels…) based on the wheelbase and other parameters et voila. That shouldn’t be a problem.
In fact, for most cases the wheel collider (implementation) works with trial and error. As I said before it’s far from perfect and also (as I said before) you should consider buying a product from Edy
Thanks for the reply. I actually contacting @Edy about his vehicle physic asset because I have some extra stuffs in my project that I want to implement and I want to make sure that those stuffs can be implemented successfully before buying the asset.
You can simply calculate the front wheel angles and assign them to the corresponding WheelCollider.steerAngle properties.
Differentials are very, very difficult to implement properly. There are several kinds of limited slip differentials (LSD). Typical LSDs transfer torque among wheels based on the friction and the load. This means, for example, than if one wheel is in the air the LSD differential will behave as an open differential, with no torque transfer and the grounded wheel losing all the torque.
Equations are relatively simple but the implementation is very difficult to addressing all the correct behaviors and side effects. It’s not only about differentials alone but about the entire drivetrain model. Understandably, most differential implementations I’ve seen just split the torque 50%-50% among the wheels and then apply some “if-then” tricks for addressing specific side cases.
Vehicle Physics Pro implements most types of differentials correctly, including open, locked, limited slip, torque bias, epicyclic and viscous differentials. Moreover, the drivetrain model in VPP allows many differentials to be connected together in any number and combination, with all the side effects correctly simulated (Example: AWD vehicle with 7 differentials).
Thanks so much @Edy . That solved my problem with Ackermann and steered me to the correct direction with differential.
About my theory of PhysX NxWheelShape clutchStrength, I’m reading PhysX source code and trying to understand the model.
According to the answer from nVidia that I quoted above, it seems that only the torque of the engine is calculated, and that torque is used to power both the engine and the drive train system (including wheel) based on the strength of the clutch. From there the engine RPM is calculated and translated to the RPM of the wheel after factoring in brakeTorque and wheelFriction.
Based on this model, Unity WheelCollider skips everything (engineMOI, clutchStrength, etc. ) and just have motorTorque, which then is used to translate to read-only wheel RPM
Is my theory correct?
If that’s correct then is there a way I can “reverse” Unity’s process to calculate engine RPM just like NxWheelShape implementation?
And also @Edy I looked at Vehicle Physic Pro and it seems that you are using both WheelColliders and your own tire friction model. I’m curious how you can skip WheelCollider’s friction curve and implement your own and how WheelCollider would react to that.
I’m afraid I cannot help you on nVidia models and code. I had tried to understand them as well but found so much incoherence and nonsense that I abandoned the idea.
This denotes a profound ignorance on how car mechanics in general, and clutch in particular, work.
Anyone with small knowledge in mechanics knows that if the clutch slips without the clutch pedal being pressed the car has a real problem. When the car is driving normally both plates are coupled and rotating at the same exact speed. Pressing the clutch pedal reliefs the pressure among both plates allowing them to slip, regulating the actual torque that passes through the clutch. This is used for starting the drive and switching gears. Still, anyone with a bit knowledge on mechanics knows that using the clutch too much (i.e. by driving very slow at a pronounced slope) can end overheating the clutch and causing a terminal damage to it.
Worth mentioning that the same guy (gyeoman) had tried to convince me that the WheelCollider suspension works perfectly, that the nVidia suspension model is perfectly correct, and that I was wrong on my arguments about the opposite.
Just set all the friction parameters to zero, then apply your own forces to the rigidbody:
