Stability methods
| Exploding cars, and it's not even Grand Theft Auto. |
|
Every simulation of any system quickly encounters places where numerical stability becomes an issue. Integrating discrete steps always will have this problem.
Racer internally runs at 1000Hz, but still, some physics processes tend to cause overshoots when integration. There's a multitude of stability issues, which will be touched on, sometimes briefly, sometimes with a better explanation.
The clutch can be a high-friction device. When just looking at the engine, a 450Nm clutch gives high frequencies when synchronising the clutch rotational velocity with that of the engine.
Racer adds a 'locked' state to the clutch whenever velocity reversal (a term that is applicable to many parts of the simulation) takes place; when integrating (apply the clutch torque over 1 timestep) makes the clutch crossover the engine velocity, the clutch is set into locked state. Only when the engine torque tops the clutch torque will the unlocked state be entered.
Note that the clutch pedal influences the clutch torque. Effectively, the clutch torque is clutchPedal*clutchTorque. So when depressing the clutch pedal, the engine is more likely to go into unlocked state (slipping clutch).
Some cars, especially race cars, have high-rate suspension & tire characteristics. Some forces can be limited by predicting their influence over the next timestep. Damper forces are one such force; they can never increase the amplitude of the wheel. Racer v0.6.3-v0.8.4 used the following method:
- Check the wheel vertical change in velocity: deltaVelocity=totalVerticalForce*dt/wheelMass
- If deltaVelocity means the wheel vertical velocity changes sign, the force is too high. It must be corrected.
- For the correction, calculate the force at which the velocity would become 0: newForce=-wheelVerticalVelocity*wheelMass/dt.
- The change in force is newForce-totalVerticalForce. If this force would be completely applied, the wheel would come to a perfect stop. However, that means the next step, the damper force is 0, giving no resistance. This would mean a step-stop-step-stop situation.
There, multiple deltaForce by some value. 0.5 was chosen since it looked to work ok.
- Apply the force change to the physics system (body force, wheel force).
v0.8.5 tried to improve on this:
- Calculate the damping and non-damping forces (forceNonDamper=totalVerticalForce-forceDamper).
- Get the suspension instantenous rate, 'c'.
- The steady state suspension/wheel velocity would appear when the external (non-damper) forces match the damper forces exactly. This is because a damping force is defined as F_damp=coeff*velocity. So as soon as the 2 forces match, the acceleration would be 0, meaning the velocity remains stable.
This equilibrium state can be calculated for this timestep by taking the next few steps.
- Calculate the balance velocity: velDesired=forceNonDamper/c.
- Calculate how much we're about to change velocity now: acc=totalForce/wheelMass, and futureVelocity=curVelocity+acc*dt.
- If this crosses the desired velocity, we're overshooting (changing from a lower velocity than velDesired to a higher velocity, or vice versa).
- For an overshoot, we calculate what velocity change we'd need to get at precisely the balance velocity: dv=velDesired-curVelocity. The acceleration then becomes: acc=dv/dt, and so the force should be: forceNewTotal=mass*acc.
- Still in the overshoot compensation, calculate the new damper force: forceDamperNew=forceNewTotal-forceNonDamper. Apply the changed force to the physics system (chassis/wheel).
- Optionally verify that we're no longer overshooting by calculating: acc=totalVerticalForce/wheelMass, velNext=curVelocity+acc*dt and check that 'velNext' is about the same as 'velDesired'.
The anti-rollbar can also go quite stiff. However, we can avoid it overshooting, although not entirely physically correct perhaps.
The braking force is a problematic area.
(last
updated
November 13, 2012
)
