My Sim: Accelerating from rest probs

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. Has anyone else experienced this and how can it be overcome? Thanks!

Alex Smith wrote: > > 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 ;)

Quoted text (8 lines)

> 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 dominant 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 dominant 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.millikenresearch.com On Sun, 7 Apr 2002, Matthew V. Jessick wrote:

Quoted text (114 lines)

> Alex Smith wrote: > > > > 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 dominant 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 dominant 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 > >

On Sun, 7 Apr 2002 14:05:48 +0000 (UTC), "Alex Smith" <[email hidden]> wrote:

Quoted text (9 lines)

>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/

I've kind of fixed it. Since I'm not (currently) implementing a reverse gear i'm just doing a special case on the wheels 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.

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. "Ruud van Gaal" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (7 lines)

> On Sun, 7 Apr 2002 14:05:48 +0000 (UTC), "Alex Smith" > <[email hidden]> wrote: > > >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

Quoted text (29 lines)

> >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/

>The great bulk of researchers >do "performance" simulations modeling motion >problems, not stopping problems. 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

On Mon, 8 Apr 2002 18:39:30 -0500, "Dave Pollatsek" <[email hidden]> wrote:

Quoted text (8 lines)

>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/

>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). Yes, its most because wheels joints are not very rigid on cars, and more generaly all the rubber on the links. Sebastien TIXIER - Game Developer Dynamics and Car Physics http://www.eden-studios.fr GPLRank Normal:-44.24 Monster:-124.44

I guess with so many squishy bits flexing in so many ways it's hard to really know who's causing the behavior--probably a good high-speed filming of a sedan braking to a stop from the side would reveal all--the only reason I felt like the longitudinal tire flex was involved is that to me if I do the "whiplash stop" (I normally avoid this, of course), it feels to me like the car is actually rolling slightly backwards at the end of the stop, but this could be just an illusion caused by where the pitch center is for the car's suspension geometry, etc. I guess the most important change for me was with the Viper method, the tire forces "fade out" as you approach zero velocity, whereas getting the instantaneous transition from Fmax to 0 (or -foo for tire flex) is really the important difference for getting the right behavior. I didn't look at the tire relaxation stuff until I had already found my own solution, so I didn't check it out in detail, although it looks like they have somewhat similar "lag" properties (I have a sidewall spring that gets "dissipated" as the tire rolls, which could probably be evolved into a stand-alone brush model) It wasn't obvious to me that the relaxation method would completely solve the "parking on a hill" case, and I needed a method that could handle the very large steps of the integrator that was used. And, of course, the fact that very low speed behavior isn't super important when racing. "Ruud van Gaal" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (7 lines)

> On Mon, 8 Apr 2002 18:39:30 -0500, "Dave Pollatsek" > <[email hidden]> wrote: > > >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 tosidewall > >flex) which allow the cars to actually park; the a nice side-effect ofthis > >method is that when you brake hard to a stop you get the "whiplash"effect

Quoted text (19 lines)

> >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/