NVIDIAGameWorks/PhysX

Creating a Realistic PhysX Vehicle

jimmyw404 opened this issue · 5 comments

Hello PhysX team,

I'd like to create a PhysX vehicle whose vehicle physics are reasonably similar to its real-world model. I'm familiar with the instructions at https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Vehicles.html but am specifically looking at how to parameterize the vehicle such that it makes the best use of the PhysX model to provide realistic vehicle motion. I am familiar with the documentation and tuning guide at https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Vehicles.html#tuning-guide that describes the impact of the input parameters, however I have not seen any resources on how to parameterize the PhysX model to align with a specific vehicle using data backed method like manufacturer specifications, measurements or vehicle recordings. We have experience with using CarSim and are exploring using PhysX to accomplish realistic vehicle motion for this effort.

  • Are there any examples of parameterized PhysX vehicles that align with their real-world counterparts?
  • Are there any guides on how to parameterize a PhysX vehicle to approximate real-world motino?
  • Are there any pitfalls you've run into when using PhysX that create an upper-boundary on vehicle realism?

Hello,
As far as I'm aware, there is no such guide. I can only talk in general terms here.

Things that should be rather easy to map:

  • mass of vehicle, wheels
  • center of mass
  • moment of inertia
  • wheel radius
    etc.

If you know the natural frequency f and the damping ratio r of the suspension, then there are the formulas:
s = (f * 2 * pi)^2 * m (assuming f = (1 / (2pi)) * sqrt(s / m). Some use sqrt(s / m) only)
d = r * 2 * sqrt(s
m)

s = stiffness, d = damping, m = sprung mass

If you have means to measure how camber/toe angles or the suspension/tire force application points change with suspension jounce, then you can configure the simple tables in PxVehicleSuspensionComplianceParams to emulate/approximate a more complex suspension geometry.

For the tire I do not have any easy formula or similar available. The model used in PhysX is rather low fidelity, so mapping would largely have to be based on scenarios that you have real data for and then tune until they show similar behavior. Scenarios like accelerating from rest, braking at some speed, lane change maneuver etc.
If our schedule allows, we might provide a snippet in the next release (or the one after) to show how something like the magic formula tire model can be implemented and integrated into PhysX vehicles. For that tire model real world parameter values might be available.

About potential pitfalls:
Behavior at low speed is often problematic since the longitudinal slip computation can get unstable for small speeds. At the moment there is just some clamping happening but you might have to come up with your own low speed tire model if you deeply care about that. Running with smaller timesteps or more substeps usually reduces the problem and allows for smaller clamp thresholds. The same helps when using high stiffness values for things like the suspension spring or the tire (with too large timesteps, instability will build up for high stiffness values). Delays in steer, brake, accelerate commands are not modeled in PhysX but play an important role when comparing to a real car. You need to model latencies or non-linearity on those commands on top of PhysX (pressing the brake pedal might not map linearly to the brake value and there can be delays to build up to a certain value etc.). For detecting the road geometry under the wheels you might consider using sweeps instead of raycasts but that really depends on your timestep and whether you care at all about scenarios with small bumps etc. (scenarios where the ground changes with higher frequency than on usual flat roads).

"Are there any pitfalls you've run into when using PhysX that create an upper-boundary on vehicle realism?"

Decreasing timestep will result in better behaviour but this has a limit. We've assumed that the timestep is large enough that we can treat very high frequency behaviours as a constant. As a consequence, we do not model phenomena such as tyre vertical stiffness and deflection. We also don't model the pneumatic trail of the tyre. These kinds of phenomena require very small timesteps that are beyond the historically expected use cases of PhysX vehicles.

We have done some experiments with PhysX vehicles using reference data and found that above around 240Hz there wasn't much improvement. This is a consequence of the adiabatic approximations described above.

To go further, it would be necessary to introduce high frequency phenomena into the model ie tire deflection, pneumatic trail etc. A more detailed tyre model ought to be bring good results as well. If you have a Pacejka dataset that you can use that would be a good place to start. This kind of addition ought to yield results at timesteps shorter than 240Hz.

@msauter-nvidia and @gyeomannvidia thank you for your responses. They are super helpful and match my findings exceptionally well. I did have a couple of follow up question regarding the drivetrain model in PhysX:

about the forces that bring a vehicle to rest:
Considering the pure longitudinal/forward force only (no combined effect with lateral force), then it can be roughly described as: tireSliptireStiffness with an upper bound of frictiontireLoad (that's the friction force you pointed at).

Slightly more detailed:
longForce = F((tireSliptireStiffness) / (frictiontireLoad)) * (friction*tireLoad)

F is a function that is kind of linear near 0 and asymptotically goes to 1. If you can find the CarSim Educational Manual on the internet, then look at Appendix F, Static Tire Model.

The engine damping considered is one that is proportional to the angular velocity. So, torque=angularVel*dampingCoefficient and that's why the unit is (kg * m ^2) / sec

The drivetrain logic describes a system of linear equations (one for each wheel plus one for the engine) where you solve for the angular velocities of the wheels and engine

Looking at, let's say, the first wheel and it's rotational speed w0 and the engine speed we, then the left-hand side of one equation is of the form:

w0 + dw_clutch_gear(w0) + dw_damping(w0) - dw_clutch_engine(we)

and the right-hand side

w0 + dw_brake + dw_tireForce

dw denotes the delta velocities when integrating the various forces/torques. The left-hand sides looks at the delta velocities arising from the connection of the wheels with the engine, the right-hand side looks at the delta velocities arising from applying the brakes on the wheel and the friction related forces of tire and ground

dw_clutch_gear(w0) => torque when looking at current w0 and multiplying with clutch stiffness and gearing ratio
dw_damping(w0) => torque when looking at current w0 and multiplying with wheel damping ("stiffness")
dw_clutch_engine(we) => torque when looking at current we and multiplying with clutch stiffness and gearing ratio

dw_brake => brake torque
dw_tireForce => torque from longitudinal force discussed further above

the equation for the engine has the form:

left-hand side:

we - dw_clutch_gear(w0) + dw_damping(we) + dw_clutch_engine(we)

and the right-hand side

we + dw_engineTorque

dw_clutch_gear(w0) => torque when looking at current w0 and multiplying with clutch stiffness and gearing ratio
dw_damping(we) => torque when looking at current we and multiplying with engine damping ("stiffness")
dw_clutch_engine(we) => torque when looking at current we and multiplying with clutch stiffness and gearing ratio

dw_engineTorque => torque from engine

note that I described it here in a separated form. dw_clutch_gear(w0) and dw_clutch_engine(we) are separated out from something that is dependent on (w0 - we) actually. The torque from the clutch connecting the wheels and the engine operates on the delta between the two angular speeds

@msauter-nvidia thank you very much for the answer! I'm closing the ticket since all of my questions were addressed.

If NVIDIA ever gets the opportunity to create a PhysX Digital Twin of a production vehicle I think a publication of all the data that goes into it and the parameter tuning method would be really interesting from the automotive industry's perspective!