What is a problem however, is that if I accelerate, sometimes the car will
reverse, sometimes go forward.
I think it is due to the slip ratio of the wheels. I.e. they are not
spinning fast enough when initially launching,
so the pacejka formula returns a -ve forward force due to it having a -ve
slip ratio.
Has anyone else experienced this and how can it be overcome?
Thanks!
> When at rest, my car oscillates in the longitudinal direction, but its
> oscillation is so small that it is not a problem
(See above ;)
Look at what is happening with the longitudinal forces on a frame
by frame basis. (Very detailed) You will probably notice that
you have oscillating forces generated. (Example: -1000,+1000,
-1000,+1000...)
You are probably getting at least three types of problems.
If you allow a lot of traction capability, the "stiffness"
of the system is probably high. This is the force per change
in wheel rotational rate (or the derivative of the force
with change in velocity.) The dynamics are similar to a
spring. The stiffer the spring, the faster the system will
want to oscillate. You need to perform your numerical
integration many times faster than the oscillation frequency to
not have the numerical integration become unstable or lose
all the dynamics you are trying to integrate. A rule of
thumb for very simple integrators
(example: x = x + xDot * deltaTime)
is you need 100 times the *** dynamics frequency.
This has been discussed a lot here, check old threads.
Some people use frequencies of several hundred and even
toward 1000 cycles per second or more.
The better your integration scheme is tailored toward
operation in this regime where its frequency response
is critical to stability, the larger steps you can run.
Even with a second order integrator, you will need
around 30 times the *** dynamics frequency for
stability in trying circumstances. Beware of simplistic
test cases, things work better when you don't push them
hard ;)
Then, calculate the derivative of force versus velocity
of your system of equations for the longitudinal
force. It may go to infinity near zero speed.
(Because of a division by zero in the longitudinal
slip ratio calculations.) This means your "spring"
gets extremely stiff and you should expect your
digital system to go unstable near zero speed.
Again, ways around this have been discussed here.
Including at least one current thread which gives
an SAE technical paper describing a workable system
for solving it.
Another serious problem is the sign reversal of
the velocity near zero that causes all sorts of trouble.
We call it "Friction Reversal" at my shop, and have
specific methods of treating it. (If the velocity changes
sign we change the equations of motion, recalculate
and hold it at zero for that frame.)
This is time consuming and messy but saves a
lot of trouble in the long run. Since anything that
uses friction equations will eventually need
protection from this effect.
Finally, you will find when you get to three dimensional
problems that a 4 wheeled car is a "redundant" problem.
For instance, with a car with it's center of gravity
in the center of the wheels weighting 3000 pounds
and static (all motion and oscillations stopped)
you would expect 750 pounds on each wheel.
Without specifically imposing this condition however,
this solution is not unique (there are others which
meet all the usual constraints.) For example,
LF: 1000 RF: 500
LR: 500 RR: 1000 (here, LF = left front, etc.)
Would also meet all the constraints.
These problems all feed off of one another when the
car is "stopped". Rapid force oscillations from tire
model problems and friction reversal combined with the
redundancy can lead to a situation where the car is
never really still.
I worked with digital vehicle simulations at an
large aerospace contractor for 14 years and only
in the last 2 years did we actually simulate a "stop."
(Stopped airplanes and spacecraft aren't all that
interesting ;). And even in that case, when the simulation
went unstable we just stopped it early (before the final
stop.)
Stopping and starting are extremely complicated.
And are only of interest to those few doing manned or
similar type "simulators". The great bulk of researchers
do "performance" simulations modeling motion
problems, not stopping problems. Unfortunately,
in video games, this is exactly our problem ;)
- Matt
Nothing much to add to Matt's post except to note that the same problems
occurred during the development of Hard Drivin' -- stop/start/reverse took
a lot of work. This Atari coin-op from late 1980's was probably the first
game (not counting large driving simulators at car companies) with a decent
car math model and force feedback.
Our in-house car simulations (see site below) rarely need to run at zero
speed. These are "engineering simulations" not "driving simulators". We
are usually interested in the car performance as seen on various plots.
-- Doug Milliken
http://www.racesimcentral.net/
> > When at rest, my car oscillates in the longitudinal direction, but its
> > oscillation is so small that it is not a problem
> You will find that unstable oscillations are ALWAYS a problem.
> Just because the gun hasn't yet fired is no reason to schedule
> another round of Russion Roulette ;)
> > What is a problem however, is that if I accelerate, sometimes the car will
> > reverse, sometimes go forward.
> (See above ;)
> > I think it is due to the slip ratio of the wheels. I.e. they are not
> > spinning fast enough when initially launching,
> > so the pacejka formula returns a -ve forward force due to it having a -ve
> > slip ratio.
> > Has anyone else experienced this and how can it be overcome?
> > Thanks!
> Look at what is happening with the longitudinal forces on a frame
> by frame basis. (Very detailed) You will probably notice that
> you have oscillating forces generated. (Example: -1000,+1000,
> -1000,+1000...)
> You are probably getting at least three types of problems.
> If you allow a lot of traction capability, the "stiffness"
> of the system is probably high. This is the force per change
> in wheel rotational rate (or the derivative of the force
> with change in velocity.) The dynamics are similar to a
> spring. The stiffer the spring, the faster the system will
> want to oscillate. You need to perform your numerical
> integration many times faster than the oscillation frequency to
> not have the numerical integration become unstable or lose
> all the dynamics you are trying to integrate. A rule of
> thumb for very simple integrators
> (example: x = x + xDot * deltaTime)
> is you need 100 times the *** dynamics frequency.
> This has been discussed a lot here, check old threads.
> Some people use frequencies of several hundred and even
> toward 1000 cycles per second or more.
> The better your integration scheme is tailored toward
> operation in this regime where its frequency response
> is critical to stability, the larger steps you can run.
> Even with a second order integrator, you will need
> around 30 times the *** dynamics frequency for
> stability in trying circumstances. Beware of simplistic
> test cases, things work better when you don't push them
> hard ;)
> Then, calculate the derivative of force versus velocity
> of your system of equations for the longitudinal
> force. It may go to infinity near zero speed.
> (Because of a division by zero in the longitudinal
> slip ratio calculations.) This means your "spring"
> gets extremely stiff and you should expect your
> digital system to go unstable near zero speed.
> Again, ways around this have been discussed here.
> Including at least one current thread which gives
> an SAE technical paper describing a workable system
> for solving it.
> Another serious problem is the sign reversal of
> the velocity near zero that causes all sorts of trouble.
> We call it "Friction Reversal" at my shop, and have
> specific methods of treating it. (If the velocity changes
> sign we change the equations of motion, recalculate
> and hold it at zero for that frame.)
> This is time consuming and messy but saves a
> lot of trouble in the long run. Since anything that
> uses friction equations will eventually need
> protection from this effect.
> Finally, you will find when you get to three dimensional
> problems that a 4 wheeled car is a "redundant" problem.
> For instance, with a car with it's center of gravity
> in the center of the wheels weighting 3000 pounds
> and static (all motion and oscillations stopped)
> you would expect 750 pounds on each wheel.
> Without specifically imposing this condition however,
> this solution is not unique (there are others which
> meet all the usual constraints.) For example,
> LF: 1000 RF: 500
> LR: 500 RR: 1000 (here, LF = left front, etc.)
> Would also meet all the constraints.
> These problems all feed off of one another when the
> car is "stopped". Rapid force oscillations from tire
> model problems and friction reversal combined with the
> redundancy can lead to a situation where the car is
> never really still.
> I worked with digital vehicle simulations at an
> large aerospace contractor for 14 years and only
> in the last 2 years did we actually simulate a "stop."
> (Stopped airplanes and spacecraft aren't all that
> interesting ;). And even in that case, when the simulation
> went unstable we just stopped it early (before the final
> stop.)
> Stopping and starting are extremely complicated.
> And are only of interest to those few doing manned or
> similar type "simulators". The great bulk of researchers
> do "performance" simulations modeling motion
> problems, not stopping problems. Unfortunately,
> in video games, this is exactly our problem ;)
> - Matt
>What is a problem however, is that if I accelerate, sometimes the car will
>reverse, sometimes go forward.
>I think it is due to the slip ratio of the wheels. I.e. they are not
>spinning fast enough when initially launching,
>so the pacejka formula returns a -ve forward force due to it having a -ve
>slip ratio.
Apart from Matts/Dougs reply, you might also at low speed look at RARS
physics system: it just does F=frictionCoeff*slipVelocity*load.
If you use Pacejka, frictionCoeff is just D/1000.
I used that in my first Racer version, and only later found out that
the system had no low-speed instabilities. So at low speed
(v<threshold) you might switch to such a system.
Some people also switch to springs, which may require some tweaking to
match the tire model at speed. I'd suggest using Barnard's relaxation
length though.
Everybody's experienced this. :) And it remains a creative deep end.
Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art : http://www.marketgraph.nl/gallery/
if (car.velocity < 0 and wheel(i).slipratio < 0) wheel(i).slipratio *= -1
so if the car is reversing, and the wheels are going the opposite way,
reverse the slipratio.
This only affects the car the first few cycles after launching.
that fixes it (for now), though I'm sure its not a very good way of doing it
in terms of forces.
> >When at rest, my car oscillates in the longitudinal direction, but its
> >oscillation is so small that it is not a problem
> >What is a problem however, is that if I accelerate, sometimes the car
will
> >reverse, sometimes go forward.
> >I think it is due to the slip ratio of the wheels. I.e. they are not
> >spinning fast enough when initially launching,
> >so the pacejka formula returns a -ve forward force due to it having a -ve
> >slip ratio.
> If the sim frequency is fast enough, you won't notice the small push
> backwards, as the wheel would still continue to accelerate and quickly
> generate forward forces.
> Apart from Matts/Dougs reply, you might also at low speed look at RARS
> physics system: it just does F=frictionCoeff*slipVelocity*load.
> If you use Pacejka, frictionCoeff is just D/1000.
> I used that in my first Racer version, and only later found out that
> the system had no low-speed instabilities. So at low speed
> (v<threshold) you might switch to such a system.
> Some people also switch to springs, which may require some tweaking to
> match the tire model at speed. I'd suggest using Barnard's relaxation
> length though.
> >Has anyone else experienced this and how can it be overcome?
> Everybody's experienced this. :) And it remains a creative deep end.
> Ruud van Gaal
> Free car sim: http://www.racer.nl/
> Pencil art : http://www.marketgraph.nl/gallery/
Heh, that phrase has a nice ring to it.. ;-)
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm
Note that when parking my car sideways on a hill (the Carrera bridge),
the car keeps standing still, but this is more because of serious
jittering (not really clean).
The whiplash effect is very cool though, and I *think* it could be
done with the relaxation length method as well, although it might be
more because the suspension moves back up after a firm brake, and
makes the car pitch and move back (instead of the tire spin spring).
Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art : http://www.marketgraph.nl/gallery/
Yes, its most because wheels joints are not very rigid on cars,
and more generaly all the *** on the links.
Sebastien TIXIER - Game Developer
Dynamics and Car Physics
http://www.racesimcentral.net/
GPLRank Normal:-44.24 Monster:-124.44
> >Yes, the old "low-to-zero speed" case seems to throw a monkey wrench in
> >everyone's tire model. For Viper I just clamped the denominator to avoid
> >dividing by zero when calculating slip angle/ratio. This worked okay,
> >except the cars would slide downhill when parked. For Heat I switched to
a
> >planar spring-damper model at low speeds (roughly corresponding to
sidewall
> >flex) which allow the cars to actually park; the a nice side-effect of
this
> >method is that when you brake hard to a stop you get the "whiplash"
effect
> >like in real life.
> Dave, did you ever try/consider the relaxation length method?
> (changing SR and SA only as the wheel rotates, as per
> Barnard/SAE950311)?
> Note that when parking my car sideways on a hill (the Carrera bridge),
> the car keeps standing still, but this is more because of serious
> jittering (not really clean).
> The whiplash effect is very cool though, and I *think* it could be
> done with the relaxation length method as well, although it might be
> more because the suspension moves back up after a firm brake, and
> makes the car pitch and move back (instead of the tire spin spring).
> Ruud van Gaal
> Free car sim: http://www.racer.nl/
> Pencil art : http://www.marketgraph.nl/gallery/
