Car Physics: Pacejka on non-powered wheels

It's been too long since there was a good physics thread on here. I'm trying to apply the Pacejka formula to the non-powered (not connected to the drivetrain) wheels on my car. During acceleration, the road speed increases quickly, a slip ratio builds up and forces are generated at the CP that make the wheel spin to catch up. The problem is that too much force is generated, and the wheel overshoots the road speed. Even larger forces are generated to bring the speed back down, causing the wheel to overshoot again - spinning the wrong way now - and so on and so on until the wheels are just spinning wildly back and forth. I'm considering locking the force applied at the CP to "reasonable" values; that is, I won't allow (roadVel-cpVel) to switch sign in a timestep. This should make things appear right visually, though it seems a little hacky. Does anyone have a better/more elegant solution for the problem? (Or is it just my problem?) Jason 379

What time is your integration step size for wheel speed? On 20 Dec 2001, J. Perkins wrote:

Quoted text (22 lines)

> It's been too long since there was a good physics thread on here. > > I'm trying to apply the Pacejka formula to the non-powered (not > connected to the drivetrain) wheels on my car. During acceleration, > the road speed increases quickly, a slip ratio builds up and > forces are generated at the CP that make the wheel spin to catch > up. The problem is that too much force is generated, and the > wheel overshoots the road speed. Even larger forces are generated > to bring the speed back down, causing the wheel to overshoot > again - spinning the wrong way now - and so on and so on until > the wheels are just spinning wildly back and forth. > > I'm considering locking the force applied at the CP to "reasonable" > values; that is, I won't allow (roadVel-cpVel) to switch sign in > a timestep. This should make things appear right visually, though > it seems a little hacky. Does anyone have a better/more elegant > solution for the problem? (Or is it just my problem?) > > Jason > 379 > >

On 20 Dec 2001 06:07:59 -0800, [email hidden] (J. Perkins) wrote:

Quoted text (11 lines)

>It's been too long since there was a good physics thread on here. > >I'm trying to apply the Pacejka formula to the non-powered (not >connected to the drivetrain) wheels on my car. During acceleration, >the road speed increases quickly, a slip ratio builds up and >forces are generated at the CP that make the wheel spin to catch >up. The problem is that too much force is generated, and the >wheel overshoots the road speed. Even larger forces are generated >to bring the speed back down, causing the wheel to overshoot >again - spinning the wrong way now - and so on and so on until >the wheels are just spinning wildly back and forth.

These are general low-speed problems. Several ways to approach the problem: 1. Use a larger physics frequency (so the jumps aren't that noticable visually). 2. Add SAE950311's way of indirecting slipratio. What you do is not calculate SR directly as SR=V_wheel/V_road-1 (or one of all the various variations), but update it slowly using an extra variable which accounts for relaxation length. 3. Predictor/corrector-like: predict what the generated force will do to the wheel. If it will cause velocity reversal (of the wheel spin), either set wheel velocity and acceleration to 0, or cut back the force so it just makes the wheel velocity 0 (there are subtle side-effects between these 2 if you're dealing with a drivetrain where everything is hooked together). >I'm considering locking the force applied at the CP to "reasonable" >values; that is, I won't allow (roadVel-cpVel) to switch sign in >a timestep. This should make things appear right visually, though >it seems a little hacky. Does anyone have a better/more elegant >solution for the problem? (Or is it just my problem?) I think a good enough physics frequency and using the SAE950311 is the most elegant solution I've seen yet. Although correcting the force seems to work ok for some, the SAE950311 method is good because it includes relaxation length, which is something happening physically anyway (and gives you 'standing still sideways on a bridge' for example). Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

Car Physics again! :) What you are experiencing is a typical instability of numerical computation. With the force vs. slip ratio/angle approach, this instability is always there at a sufficiently low speed due to the way slip ratio is calculated (it is divided by the size of the velocity), which means that the oscillation in the differential equations becomes very 'stiff'. For wheels, the best way to regularize this behaviour is to use the relaxation length approach at low speeds (Google masters, help us out here!). This will regularize behaviour at low speeds with the added benefit of the car being able to fully stop on an incline, while at high speeds you can (and indeed, need to!) still switch to the usual model. Keep in mind, though, that for realistic racing car parameters you may still end up with the required simulation frequencies well in hundreds (even thousands). Another way to do avoid excessively small timesteps is to use the implicit integration schemes as per Baraff (Google masters, again!). These, however, may become very complex to implement once differentials come into play, and may introduce artifacts and cannot completely guarantee stability for the typical overshoots that are present in the tyre/road system. But if you decide to go that way, I'd be delighted to hear about results! :) Cheers, -Gregor "J. Perkins" wrote:

Quoted text (21 lines)

> > It's been too long since there was a good physics thread on here. > > I'm trying to apply the Pacejka formula to the non-powered (not > connected to the drivetrain) wheels on my car. During acceleration, > the road speed increases quickly, a slip ratio builds up and > forces are generated at the CP that make the wheel spin to catch > up. The problem is that too much force is generated, and the > wheel overshoots the road speed. Even larger forces are generated > to bring the speed back down, causing the wheel to overshoot > again - spinning the wrong way now - and so on and so on until > the wheels are just spinning wildly back and forth. > > I'm considering locking the force applied at the CP to "reasonable" > values; that is, I won't allow (roadVel-cpVel) to switch sign in > a timestep. This should make things appear right visually, though > it seems a little hacky. Does anyone have a better/more elegant > solution for the problem? (Or is it just my problem?) > > Jason > 379

[email hidden] (Ruud van Gaal) wrote in message news:<[email hidden]>...

Quoted text (10 lines)

> On 20 Dec 2001 06:07:59 -0800, [email hidden] (J. Perkins) wrote: > >I'm trying to apply the Pacejka formula to the non-powered (not > >connected to the drivetrain) wheels on my car. The problem is > >that too much force is generated, and the wheel overshoots the > >road speed. > > These are general low-speed problems. Several ways to approach the > problem: > 1. Use a larger physics frequency (so the jumps aren't that noticable > visually).

My updates are tied to the framerate currently (I know, I know) but I'm getting a pretty steady 100fps (0.01-0.014 secs/frame). > 2. Add SAE950311's way of indirecting slipratio. I'm already doing this, but I think it might be making the problem worse, as it adds a latency into the SR response. It may be that I'm not flipping signs at the right time, and I am looking at that now. The drive wheels are working great, it's just the free rolling wheels that are giving me problems. Now that I know that other people are using the same approach with acceptable results, it seems likely I've a bug somewhere. > 3. Predictor/corrector-like: predict what the generated force will do > to the wheel. If it will cause velocity reversal (of the wheel spin), > either set wheel velocity and acceleration to 0, or cut back the force > so it just makes the wheel velocity 0 This is the approach (reducing the force to match the velocities) I am considering (if I can't find a problem in my SR calculations), but I am concerned about potential side effects. Mostly concerned that I don't know what the side effects might be. I suppose I could try cranking up the frequency on my tire code and see if the problem goes away. I've been meaning to switch to a fixed frequency anyway. Jason 379

On 20 Dec 2001 13:21:33 -0800, [email hidden] (J. Perkins) wrote:

Quoted text (14 lines)

>[email hidden] (Ruud van Gaal) wrote in message news:<[email hidden]>... >> On 20 Dec 2001 06:07:59 -0800, [email hidden] (J. Perkins) wrote: >> >I'm trying to apply the Pacejka formula to the non-powered (not >> >connected to the drivetrain) wheels on my car. The problem is >> >that too much force is generated, and the wheel overshoots the >> >road speed. >> >> These are general low-speed problems. Several ways to approach the >> problem: >> 1. Use a larger physics frequency (so the jumps aren't that noticable >> visually). > >My updates are tied to the framerate currently (I know, I know) but >I'm getting a pretty steady 100fps (0.01-0.014 secs/frame).

That's not a lot. I typically can't drive below 200 to 250Hz without things getting bad for most cars. The dampers were the worst part though, requiring about 500Hz if I would integrate explicitly (now it's fine, implicitly, at 200Hz and up). >> 2. Add SAE950311's way of indirecting slipratio. > >I'm already doing this, but I think it might be making the problem >worse, as it adds a latency into the SR response. That's the whole idea of relaxation length. ;-) Although longitudinally (SR-wise) it should be very small, as you can imagine the rubber not being that flexible around the spin axis). The lateral relaxation length is a part of the wheel circumference (mostly, say 0.9 for a start), and use 1/10th of that for longitudinally. So it (SR) should increase quickly. > It may be that >I'm not flipping signs at the right time, and I am looking at >that now. Flipping signs of what? > The drive wheels are working great, it's just the free >rolling wheels that are giving me problems. That's a little weird (although the 100Hz may explain that). I have about the same problems with both types of wheels. > Now that I know that >other people are using the same approach with acceptable results, >it seems likely I've a bug somewhere. Are you applying damping? Pedri had a nice comment about applying damping the other day; he always applied the damping in the reverse direction of the wheel velocity. Yes, duh. ;-) It seemed a periodic formula, in the SAE950311 document.

Quoted text (9 lines)

>> 3. Predictor/corrector-like: predict what the generated force will do >> to the wheel. If it will cause velocity reversal (of the wheel spin), >> either set wheel velocity and acceleration to 0, or cut back the force >> so it just makes the wheel velocity 0 > >This is the approach (reducing the force to match the velocities) >I am considering (if I can't find a problem in my SR calculations), >but I am concerned about potential side effects. Mostly concerned >that I don't know what the side effects might be.

Hehe, indeed. Better to just let it run free; you'll get into trouble later on with differentials anyway (probably) by doing this. >I suppose I could try cranking up the frequency on my tire code >and see if the problem goes away. I've been meaning to switch to >a fixed frequency anyway. Shouldn't be that hard, as you already use a framerate-derived frequency already. It's just timing when to paint that needs to be added. Hope a bit more frequency helps. Also, ofcourse, a bit more wheel inertia also does wonders. ;-) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

I haven't done the relaxation length stuff everyone is talking about just yet, but what I do do (do do??) is run the tire rotational frequency at a higher, adjustable frequency inside the main loop. I'm modelling (besides full sized cars), little radio controlled cars that have a peak grip coefficient of around 3.5-3.8 (from what we've been able to tell anyway), and very little rotational inertia.. I run these at several thousand hertz, which just wouldn't work if the whole system had to run that fast.. Adjustable split frequencies can do great things, although I'd love to hear about it if someone gets an implicit integrator working with wheel rotation and relaxation length :0) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

[email hidden] (J. Todd Wasson) wrote in message news:<[email hidden]>... > I haven't done the relaxation length stuff everyone is talking about just > yet, Out of curiosity, what do you do for a slip ratio when road speed is zero (the case where you would end up dividing by zero in the traditional slip ratio formula)? I think all the smart folks here are right and I need to up my simulation frequency. Hopefully I'll get a chance to try it out after the holidays. Jason 379

Quoted text (12 lines)

>> I haven't done the relaxation length stuff everyone is talking about just >> yet, > >Out of curiosity, what do you do for a slip ratio when road speed >is zero (the case where you would end up dividing by zero in the >traditional slip ratio formula)? > >I think all the smart folks here are right and I need to up my >simulation frequency. Hopefully I'll get a chance to try it out >after the holidays. > >Jason

I switch to a seperate model at low speed that basically acts like a torsion spring. It's good because you can stop on hills and it locates the rotational position really well, but it doesn't transition into the high speed model smoothly yet, and it doesn't care much for my differential model if it unlocks. I'd think a relaxation length approach would work better, but I haven't tried it yet. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

On 21 Dec 2001 23:35:34 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (7 lines)

> I haven't done the relaxation length stuff everyone is talking about just >yet, but what I do do (do do??) is run the tire rotational frequency at a >higher, adjustable frequency inside the main loop. I'm modelling (besides full >sized cars), little radio controlled cars that have a peak grip coefficient of >around 3.5-3.8 (from what we've been able to tell anyway), and very little >rotational inertia.. I run these at several thousand hertz, which just >wouldn't work if the whole system had to run that fast..

The idea behind the relaxation stuff is adding a filter to SR. This way it won't jitter as much. The filter is physically accurate, so that's a nice bonus. ;-) Something I once did was: if(spinVel<1)T_total*=spinVel; To reduce the torques at low spin velocity. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

Quoted text (10 lines)

>The idea behind the relaxation stuff is adding a filter to SR. This >way it won't jitter as much. The filter is physically accurate, so >that's a nice bonus. ;-) > >Something I once did was: > > if(spinVel<1)T_total*=spinVel; > >To reduce the torques at low spin velocity. >

Good tip, thanks :-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

[email hidden] (J. Todd Wasson) wrote in message news:<[email hidden]>... > I haven't done the relaxation length stuff everyone is talking about just > yet, but what I do do (do do??) is run the tire rotational frequency at a > higher, adjustable frequency inside the main loop. You know, this seemed to make perfect sense when I read it, until I started trying to work it out on paper. Where do you draw the line between the tire simulation and the chassis? That is, what are computing at the higher frequency? I suppose I could just compute the SR derivative at the smaller timestep, without actually changing the wheel velocities or applying any forces - is this what you're talking about? That said, I bumped up my physics to a fixed 500Hz and things are behaving considerably better, though not perfect, but my current implementation requires me to run the entire vehicle model at this frequency. There may still be a bug in here somewhere, of course. Jason 379

Quoted text (16 lines)

>> I haven't done the relaxation length stuff everyone is talking about just >> yet, but what I do do (do do??) is run the tire rotational frequency at a >> higher, adjustable frequency inside the main loop. > >You know, this seemed to make perfect sense when I read it, until I >started trying to work it out on paper. Where do you draw the line >between the tire simulation and the chassis? That is, what are computing >at the higher frequency? I suppose I could just compute the SR derivative >at the smaller timestep, without actually changing the wheel velocities >or applying any forces - is this what you're talking about? > >That said, I bumped up my physics to a fixed 500Hz and things are >behaving considerably better, though not perfect, but my current >implementation requires me to run the entire vehicle model at this >frequency. There may still be a bug in here somewhere, of course. >

I calculate slip ratio, tire torque (road reaction torque from slip ratio and load), and... (it's late...?), then I let the wheel accelerate several times within the main loop (at a decreased time step). The forces at the last step are used to move the car, although you could probably use the average of them instead I suppose.. This lets things stabilize much better and at far less cost than increasing the entire engine's frequency. With my little RC cars, before we had correct rotational inertia data, I was running the main engine frequency at 200-300Hz, but the tires needed about 20,000-30,000Hz to stay stable below around 8-10kph car speed. Now that we have good data, this can be reduced by a factor of 10 or so, probably. Still, it's probably better to use relaxation lengths. The differential gear systems run at the stepped up frequency too, although this could probably be cheated a bit for speed if it was allowable. You probably don't have a bug... This is just the nature of slip ratio modelling; all the SAE/other papers I've seen mention the same problem and have either a low speed "switch" approximation or get rid of it by treating slip ratio/angle as a state variable (relaxation length approach.) You may have noticed that your car won't stop on hills either... :0) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

[email hidden] (J. Todd Wasson) wrote: > I calculate slip ratio, tire torque (road reaction torque from slip ratio and > load), and... (it's late...?), then I let the wheel accelerate several times > within the main loop (at a decreased time step). The forces at the last step > are used to move the car, although you could probably use the average of them > instead I suppose.. Okay so you're just ignoring the forces generated at the "in-between" timesteps. I guess this makes sense since the chassis won't be moving either. > stable below around 8-10kph car speed. Now that we have good data, this can be > reduced by a factor of 10 or so, probably. Still, it's probably better to use > relaxation lengths. I am using the relaxation length stuff, and I'm still seeing this instability, so it's not a cure-all. Only on the free-rolling wheels though, there must be enough inertia/friction in the drivetrain to dampen the drive wheels. It looks like the problem goes away around 250-300Hz, which would be a better rate to run my collision/physics anyway. > You may have noticed that your car won't stop on hills either... :0) Yes, I fixed that by getting rid of the hills. ;) Jason 379

Quoted text (14 lines)

>> I calculate slip ratio, tire torque (road reaction torque from slip ratio >and >> load), and... (it's late...?), then I let the wheel accelerate several >times >> within the main loop (at a decreased time step). The forces at the last >step >> are used to move the car, although you could probably use the average of >them >> instead I suppose.. > >Okay so you're just ignoring the forces generated at the "in-between" >timesteps. I guess this makes sense since the chassis won't be moving >either. >

That's what I figure at least.. It keeps the wheels from overshooting the "correct" slip ratio a bit better.

Quoted text (13 lines)

>> stable below around 8-10kph car speed. Now that we have good data, this >can be >> reduced by a factor of 10 or so, probably. Still, it's probably better to >use >> relaxation lengths. > >I am using the relaxation length stuff, and I'm still seeing this >instability, so it's not a cure-all. Only on the free-rolling wheels >though, there must be enough inertia/friction in the drivetrain to >dampen the drive wheels. It looks like the problem goes away around >250-300Hz, which would be a better rate to run my collision/physics >anyway. >

I don't know what values you're using, but one measured moment of inertia for a wheel assembly was 8.97 ft*lbs^2 off a real car, quite a bit higher than I would have intuitively guessed. This was from a little racer in a suspension design/analysis program that weighed something like 1500-2000 lbs IIRC, rather light wheels in all likelihood Ruud and you other guys, you listening? I'll leave it up to you to convert to metric :-) I also don't deal with the wheel hop mode, so that's probably going to add some instability as well if you are doing that (if you have a tire "spring" somewhere). >> You may have noticed that your car won't stop on hills either... :0) > >Yes, I fixed that by getting rid of the hills. ;) > >Jason lol! A great solution! :0) 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 03 Jan 2002 03:42:27 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (9 lines)

>>It looks like the problem goes away around >>250-300Hz, which would be a better rate to run my collision/physics >>anyway. > > I don't know what values you're using, but one measured moment of inertia for >a wheel assembly was 8.97 ft*lbs^2 off a real car, quite a bit higher than I >would have intuitively guessed. This was from a little racer in a suspension >design/analysis program that weighed something like 1500-2000 lbs IIRC, rather >light wheels in all likelihood Ruud and you other guys, you listening?

Huh what? ;-) According to my own site the conversion factor from ft*lbs^2 -> kg*m^2 is 1.3557. That would give 12.160629 kg*m^2. My Ferrari 312 has... hm... 2.3. That does seem a bit low. Any idea how much that tire of yours weighed (in slugs for all I care, lol)? I think that number was once based on a formula for the inertia of a cylinder with all mass around at the edge. Can't find the URL of a great page on this I once used. > I also don't deal with the wheel hop mode, so that's probably going to add >some instability as well if you are doing that (if you have a tire "spring" >somewhere). I implicitly integrate my wheels, and that seems to kill some wheel hop effects. Or at least, I can run a 200,000 N/m suspension and 300,000 N/m tire spring combined at 250Hz and it's stable (haven't really dug too deep in the option I have to use suspension forces as load vs. using the real tire normal force).

Quoted text (7 lines)

>>> You may have noticed that your car won't stop on hills either... :0) >> >>Yes, I fixed that by getting rid of the hills. ;) >> >>Jason > > lol! A great solution! :0)

Hehe, in Holland, we have few hills. We don't need to relax tires here. ;-) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

On Thu, 03 Jan 2002 15:03:04 GMT, [email hidden] (Ruud van Gaal) wrote:

Quoted text (15 lines)

>On 03 Jan 2002 03:42:27 GMT, [email hidden] (J. Todd Wasson) wrote: > >>>It looks like the problem goes away around >>>250-300Hz, which would be a better rate to run my collision/physics >>>anyway. >> >> I don't know what values you're using, but one measured moment of inertia for >>a wheel assembly was 8.97 ft*lbs^2 off a real car, quite a bit higher than I >>would have intuitively guessed. This was from a little racer in a suspension >>design/analysis program that weighed something like 1500-2000 lbs IIRC, rather >>light wheels in all likelihood Ruud and you other guys, you listening? > >Huh what? ;-) >According to my own site the conversion factor from ft*lbs^2 -> kg*m^2 >is 1.3557. That would give 12.160629 kg*m^2.

To follow up on myself, that can't be right. Seems way too much (in kg*m^2). Anybody know the correct conversion? I guess I should fire up Google. But at least you know I don't trust that conversion factor anymore. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

> > > >Huh what? ;-) > >According to my own site the conversion factor from ft*lbs^2 -> kg*m^2 > >is 1.3557. That would give 12.160629 kg*m^2. Something's wrong Ruud - you can't convert ft*lbs^2 to kg*m^2 can you? Units are different. You'd need to convert from lb*ft^2...... Jim

Having thought a little harder....... 1 lb*ft^2 = 0.454kg x (0.3m)^2 = 0.04 kg*m^2. 8.97 lb*ft^2 is therefore around 0.36 kg*m^2, not 12.160629. I've not taken many significant figures through this, and I'm hoping my rather rusty maths is holding up! Cheers Jim "Jim Seamus" <[email hidden]> wrote in message news:XDjZ7.37751$[email hidden]...

Quoted text (8 lines)

> > > > > > >Huh what? ;-) > > >According to my own site the conversion factor from ft*lbs^2 -> kg*m^2 > > >is 1.3557. That would give 12.160629 kg*m^2. > > > Something's wrong Ruud - you can't convert ft*lbs^2 to kg*m^2 can you?

Units > are different. You'd need to convert from lb*ft^2...... > > Jim > >

On Fri, 04 Jan 2002 13:44:05 GMT, [email hidden] (Ruud van Gaal) wrote: >>On 03 Jan 2002 03:42:27 GMT, [email hidden] (J. Todd Wasson) wrote: >> >>> I don't know what values you're using, but one measured moment of inertia for >>>a wheel assembly was 8.97 ft*lbs^2 off a real car, quite a bit higher than I >>>would have intuitively guessed....

Quoted text (7 lines)

>>Huh what? ;-) >>According to my own site the conversion factor from ft*lbs^2 -> kg*m^2 >>is 1.3557. That would give 12.160629 kg*m^2. > >To follow up on myself, that can't be right. Seems way too much (in >kg*m^2). Anybody know the correct conversion? I guess I should fire up >Google.

And www.footrule.com gives a conversion factor of: 0.042 140 110 090 00 So that 8.97 would become ~ 0.378. But that uses lbs*ft^2, NOT ft*lbs^2, which would make more sense since that looks a lot more like kg*m^2. Still, 0.378 seems very LOW to me intuitively. ;-) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

[email hidden] (Ruud van Gaal) writes: > On Thu, 03 Jan 2002 15:03:04 GMT, [email hidden] (Ruud van Gaal) > wrote: > > >According to my own site the conversion factor from ft*lbs^2 -> kg*m^2 > >is 1.3557. That would give 12.160629 kg*m^2. this is obviously wrong. since both feet and pounds are less than their metric counterparts the conversion factor must be < 1. > To follow up on myself, that can't be right. Seems way too much (in > kg*m^2). Anybody know the correct conversion? I guess I should fire up > Google. 1 lb = 0.45359237 kg 1 ft = 0.3048 m lb * ft * ft = 0.042140110093804806 1.3557 seens frighteningly familar, though I can't remember why. 1.3557 * 2 = 2.7114 -- isn't that some sort of natural number? btw; aren't you a unix man, Ruud? Gunnar, hinting of man units -- Gunnar #31 SUCKS#015 Tupperware MC#002 DoD#0x1B DoDRT#003 DoD:CT#4,8 Kibo�: 2 "a poster is a human being or the software equivalent"

On Fri, 04 Jan 2002 16:28:21 GMT, Gunnar Horrigmo <[email hidden]> wrote:

Quoted text (9 lines)

>[email hidden] (Ruud van Gaal) writes: >> On Thu, 03 Jan 2002 15:03:04 GMT, [email hidden] (Ruud van Gaal) >> wrote: >> >> >According to my own site the conversion factor from ft*lbs^2 -> kg*m^2 >> >is 1.3557. That would give 12.160629 kg*m^2. > >this is obviously wrong. since both feet and pounds are less than >their metric counterparts the conversion factor must be < 1.

The problem was a bit that the 'lbs' was squared, and 'ft' wasn't. So that would give you: ft*lbs^2 := length * mass * mass, while kg*m^2 := mass * length * length. As some units have strange counterparts (a Joule has some funny representations) I became confused.

Quoted text (8 lines)

>> To follow up on myself, that can't be right. Seems way too much (in >> kg*m^2). Anybody know the correct conversion? I guess I should fire up >> Google. > >1 lb = 0.45359237 kg >1 ft = 0.3048 m > >lb * ft * ft = 0.042140110093804806

Yes, the original units given though were ft*lbs*lbs, and take with the fact that the US units don't use mass but weight preferably, this was enough to make me lose my balance. :) lbs and lbf are two different things, right; one is a weight, the other one a mass more (like slugs). Perhaps I'm just confusing things further here though by stating that. ;-) >1.3557 seens frighteningly familar, though I can't remember why. >1.3557 * 2 = 2.7114 -- isn't that some sort of natural number? > >btw; aren't you a unix man, Ruud? Mostly Unix, but also Windows, and a hint of the Amiga not too long ago. Is Unix 2.7114 as good as Windows? ;-) And as XP is really going the wrong route (IMHO), Linux and such get more and more interesting. The KISS principle is something which obviously hasn't been adapted by Microsoft's designers, when needed most. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

Believe me, it's true, I did estimates which gave me even lower numbers for certain wheels. Definitely the main cause of physics integration headaches :). -Gregor (who hasn't checked in for a while, but just might do so more regularly soon enough) Ruud van Gaal wrote: > > Still, 0.378 seems very LOW to me intuitively. ;-) >

Sigh, I venture onto a Car Physics thread and get totally ignored despite posting the correction several hours earlier than anyone else. Ah well I'll go back to loitering on the Racer forum then... <g> Jim "Jim Seamus" <[email hidden]> wrote in message news:oJjZ7.37762$[email hidden]...

Quoted text (21 lines)

> > Having thought a little harder....... > > 1 lb*ft^2 = 0.454kg x (0.3m)^2 = 0.04 kg*m^2. > > 8.97 lb*ft^2 is therefore around 0.36 kg*m^2, not 12.160629. > > I've not taken many significant figures through this, and I'm hoping my > rather rusty maths is holding up! > > Cheers > > Jim > > > "Jim Seamus" <[email hidden]> wrote in message > news:XDjZ7.37751$[email hidden]... > > > > > > > > > >Huh what? ;-) > > > >According to my own site the conversion factor from ft*lbs^2 ->

kg*m^2

Quoted text (12 lines)

> > > >is 1.3557. That would give 12.160629 kg*m^2. > > > > > > Something's wrong Ruud - you can't convert ft*lbs^2 to kg*m^2 can you? > Units > > are different. You'd need to convert from lb*ft^2...... > > > > Jim > > > > > >

On Fri, 04 Jan 2002 19:44:06 +0100, Gregor Veble <[email hidden]> wrote: >Believe me, it's true, I did estimates which gave me even lower numbers >for certain wheels. Definitely the main cause of physics integration >headaches :). Yes, I must how it holds against that 250Hz. :( >-Gregor (who hasn't checked in for a while, but just might do so more >regularly soon enough) You should. It's good to have you in here. :) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

On Fri, 4 Jan 2002 22:46:21 -0000, "Jim Seamus" <[email hidden]> wrote: > >Sigh, I venture onto a Car Physics thread and get totally ignored despite >posting the correction several hours earlier than anyone else. Ah well I'll >go back to loitering on the Racer forum then... I read your post. You just can reply to only one at a time. ;-) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

>Huh what? ;-) >According to my own site the conversion factor from ft*lbs^2 -> kg*m^2 >is 1.3557. That would give 12.160629 kg*m^2. >My Ferrari 312 has... hm... 2.3. That does seem a bit low. Any idea >how much that tire of yours weighed (in slugs for all I care, lol)? > Whoops! Sorry about the confusion, I meant lbs*ft^2, not ft*lbs^2... Or was it slugs? Hmm... Well, whatever polar moment of inertia is accelerated at 1 rad/sec/sec when 1 foot-pound of torque is applied to it anyway :0) I don't know how much the tire weighed, although it was from a small car... This should have been a rather low polar moment tire, but was still much higher than what I'd been using previously (by about 3-4 times usually.) >I implicitly integrate my wheels, and that seems to kill some wheel >hop effects. Or at least, I can run a 200,000 N/m suspension and >300,000 N/m tire spring combined at 250Hz and it's stable (haven't >really dug too deep in the option I have to use suspension forces as >load vs. using the real tire normal force). That's pretty good, what was it before you went to implicit integration? Have you tried this in the rotational direction yet?

Quoted text (11 lines)

>>>> You may have noticed that your car won't stop on hills either... :0) >>> >>>Yes, I fixed that by getting rid of the hills. ;) >>> >>>Jason >> >> lol! A great solution! :0) > >Hehe, in Holland, we have few hills. We don't need to relax tires >here. ;-) >

lol If you're a Racer driver, you never relax your tires either :0) 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 08 Jan 2002 23:35:41 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (9 lines)

>>According to my own site the conversion factor from ft*lbs^2 -> kg*m^2 >>is 1.3557. That would give 12.160629 kg*m^2. >>My Ferrari 312 has... hm... 2.3. That does seem a bit low. Any idea >>how much that tire of yours weighed (in slugs for all I care, lol)? >> > > Whoops! Sorry about the confusion, I meant lbs*ft^2, not ft*lbs^2... Or was >it slugs? Hmm... Well, whatever polar moment of inertia is accelerated at 1 >rad/sec/sec when 1 foot-pound of torque is applied to it anyway :0)

Must have been that yes. And the 12.16 isn't right; it's more like 0.4 in kg*m^2, it turned out. That's a blow for the sim frequency. ;-)

Quoted text (7 lines)

>>I implicitly integrate my wheels, and that seems to kill some wheel >>hop effects. Or at least, I can run a 200,000 N/m suspension and >>300,000 N/m tire spring combined at 250Hz and it's stable (haven't >>really dug too deep in the option I have to use suspension forces as >>load vs. using the real tire normal force). > > That's pretty good, what was it before you went to implicit integration?

Over a 1000Hz. Unfortunately my smallest timestep IS 1/1000s, so actually it just did not work, lol. >Have you tried this in the rotational direction yet? Nope. Might be an idea indeed for low-speed operation. Have to get a look at this one time. For low-speed only ofcourse; you quickly can move to the usual integration. >>Hehe, in Holland, we have few hills. We don't need to relax tires >>here. ;-) > > lol If you're a Racer driver, you never relax your tires either :0) So true. :) We had a kart race yesterday, with 8 karts, of which 4 were replaced during the qualifying sessions. Those tires also probably didn't have a relaxed time there. :) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

>Must have been that yes. And the 12.16 isn't right; it's more like 0.4 >in kg*m^2, it turned out. That's a blow for the sim frequency. ;-) Yes, it is.. It turned out to be a good thing for me though, since I underestimated the values by a factor of about 3. >>Have you tried this in the rotational direction yet? > >Nope. Might be an idea indeed for low-speed operation. Have to get a >look at this one time. For low-speed only ofcourse; you quickly can >move to the usual integration. > So.... How did you do the implicit integration, anyway? This was only for the vertical wheel motion, right? I am still fuzzy about how this works.. >So true. :) We had a kart race yesterday, with 8 karts, of which 4 >were replaced during the qualifying sessions. Those tires also >probably didn't have a relaxed time there. :) > Great fun! There's an indoor track nearby with carts that do about 70 kph.. Lots of fun on a tight concrete track. 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 13 Jan 2002 00:49:16 GMT, [email hidden] (J. Todd Wasson) wrote: ...

Quoted text (7 lines)

>>Nope. Might be an idea indeed for low-speed operation. Have to get a >>look at this one time. For low-speed only ofcourse; you quickly can >>move to the usual integration. >> > > So.... How did you do the implicit integration, anyway? This was only for >the vertical wheel motion, right? I am still fuzzy about how this works..

This is the formula from my wheel class (vertical motion integration): // Implicit integration (derived by using the future velocity in the // equations of motion instead of the current velocity). velocity.y=(velocity.y+RR_TIMESTEP*forceNonDamper.y/GetMass())/ (1.0+susp->GetBumpRate()/GetMass()*RR_TIMESTEP); (1) Yikes, this can be optimized quite a bit. Anyway, you split the easy-going forces (non-damper) and the damper forces. The non-damper forces are the suspension spring, and the tire spring. So you start out with (this is for a wheel's vertical motion): v'=v+acc*dt where normally: acc=F_total/mass But recognizing that F_total=F_nondamper+F_damper, you can more directly state for the damper: F_damper=damperCoeff*v Now writing this out you get: acc=F_nondamper/mass+damperCoeff*v/mass So: v'=v+(F_nondamper/mass+damperCoeff*v/mass) But since the damper explodes the system, why not try to use v' in the formula of the damper force; this would take the damping forces *as it will be in the future*. Yeah, I know, you faint, then try to think again, and well, just try it. That would give: v'=v+(F_nondamper/mass+damperCoeff*v'/mass) And somehow, no doubt, if you work this out (solving for v'), you should get eq. 1, but this is left as an exercise for the reader. ;-) >>So true. :) We had a kart race yesterday, with 8 karts, of which 4 >>were replaced during the qualifying sessions. Those tires also >>probably didn't have a relaxed time there. :) > > Great fun! There's an indoor track nearby with carts that do about 70 kph.. >Lots of fun on a tight concrete track. Indeed, these karts go 70kph as well. There's a yearly race nearby which I will attend. Sponsored by Playboy, so perhaps I'll win a nice prize. ;-) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

Quoted text (33 lines)

>This is the formula from my wheel class (vertical motion integration): > > // Implicit integration (derived by using the future velocity in the > // equations of motion instead of the current velocity). > velocity.y=(velocity.y+RR_TIMESTEP*forceNonDamper.y/GetMass())/ > (1.0+susp->GetBumpRate()/GetMass()*RR_TIMESTEP); (1) > >Yikes, this can be optimized quite a bit. Anyway, you split the >easy-going forces (non-damper) and the damper forces. The non-damper >forces are the suspension spring, and the tire spring. >So you start out with (this is for a wheel's vertical motion): > v'=v+acc*dt >where normally: > acc=F_total/mass >But recognizing that F_total=F_nondamper+F_damper, you can more >directly state for the damper: > F_damper=damperCoeff*v > >Now writing this out you get: > acc=F_nondamper/mass+damperCoeff*v/mass >So: > v'=v+(F_nondamper/mass+damperCoeff*v/mass) > >But since the damper explodes the system, why not try to use v' in the >formula of the damper force; this would take the damping forces *as it >will be in the future*. Yeah, I know, you faint, then try to think >again, and well, just try it. >That would give: > > v'=v+(F_nondamper/mass+damperCoeff*v'/mass) > >And somehow, no doubt, if you work this out (solving for v'), you >should get eq. 1, but this is left as an exercise for the reader. ;-)

Huh? Wha?? ?? GREGOR!!! You came up with this, didn't you!? How??? >v'=v+(F_nondamper/mass+damperCoeff*v'/mass) I'll take your word for it anyway 'cause I know it works, but my brain tells me you can't use the answer to the equation in the equation itself to find the answer to the equation... How in the world can use use v' in the equation you're using to find v' ?? Solving for it gives this as you said (I DO NOT know how to solve this one myself, thank you): >velocity.y=(velocity.y+RR_TIMESTEP*forceNonDamper.y/GetMass())/ > (1.0+susp->GetBumpRate()/GetMass()*RR_TIMESTEP); So, v' is the future velocity, right? This equation then would be like this in the other notation you used, right?: v' = (v' + RR_TIMESTEP*forceNonDamper.y / Mass) / (1+ forceDamper / Mass) That's crazy... Can someone explain how/why this can be done to a far-from-math-genious? My IQ just dropped 20% and now equals my shoe size... Somebody educate me here!

Quoted text (7 lines)

>> Great fun! There's an indoor track nearby with carts that do about 70 >kph.. >>Lots of fun on a tight concrete track. > >Indeed, these karts go 70kph as well. There's a yearly race nearby >which I will attend. Sponsored by Playboy, so perhaps I'll win a nice >prize. ;-)

As Yellow would say, "Oooooooh yeah." Good luck, send pictures of your prize wearing nothing but a race helmet too :0) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

Quoted text (8 lines)

>>Indeed, these karts go 70kph as well. There's a yearly race nearby >>which I will attend. Sponsored by Playboy, so perhaps I'll win a nice >>prize. ;-) >> > > As Yellow would say, "Oooooooh yeah." Good luck, send pictures of your prize > wearing nothing but a race helmet too :0) >

<beavis> heuh Heuh - he said helmet <g> </beavis>

Quoted text (7 lines)

><beavis> > > >heuh Heuh - he said helmet <g> > ></beavis> >

<butthead> ehhhh... Shut--up.. Beavis.. eh-hehe.. Uhhhh huh.. That was cool... Eeee-huh huh... huh. </butthead> <beavis> Yeah! Hehehehe-- Yeah! Yeah! Hey Butthead! I think he's gonna score! Yeah! Cool! Hehehe! HeheheheyaAAAAA!! </beavis> <SMACK!> :0P Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

"J. Todd Wasson" wrote:

Quoted text (22 lines)

> > > >But since the damper explodes the system, why not try to use v' in the > >formula of the damper force; this would take the damping forces *as it > >will be in the future*. Yeah, I know, you faint, then try to think > >again, and well, just try it. > >That would give: > > > > v'=v+(F_nondamper/mass+damperCoeff*v'/mass) > > > >And somehow, no doubt, if you work this out (solving for v'), you > >should get eq. 1, but this is left as an exercise for the reader. ;-) > > Huh? Wha?? ?? GREGOR!!! You came up with this, didn't you!? How??? > > > >v'=v+(F_nondamper/mass+damperCoeff*v'/mass) > > I'll take your word for it anyway 'cause I know it works, but my brain tells > me you can't use the answer to the equation in the equation itself to find the > answer to the equation... How in the world can use use v' in the equation > you're using to find v' ?? >

Uh, ahem, what? Who's waking me up from my winter hybernation? Nah, I didn't come up with that, I think it was Baraff and his implicit integration stuff. Anyway, as you say the above equation doesn't give you an explicit solution for v' as v' is also on the right hand side. This is why it's called implicit integration :). If you however reorder the terms so that you leave only v' on one side (solve for v'), you may get it explicitly but now the equation is a bit more involved, as you can see later. Anyway, the idea is that you don't know the average force on the damper well if your damping happens very fast within your time interval (as is the case with the wheel-damper system). The proper way would be knowing the average value of the damper force in this timestep. In the explicit scheme, you only use the value of the damper force at the beginning of the interval, while in the new implicit scheme you get it only at the end of this time interval, with the added bonus of high stability of calculation. You may also try with averages of these two values (i.e. (v+v')/2 instead of only v or v' on the right hand side) or any other combinations, I haven't realy tried to play with that. If you do, let us know how it works :). Greetings, -Gregor

On Fri, 18 Jan 2002 16:50:04 +0100, Gregor Veble <[email hidden]> wrote: >"J. Todd Wasson" wrote:...

Quoted text (7 lines)

>> > v'=v+(F_nondamper/mass+damperCoeff*v'/mass) >> > >> >And somehow, no doubt, if you work this out (solving for v'), you >> >should get eq. 1, but this is left as an exercise for the reader. ;-) >> >> Huh? Wha?? ?? GREGOR!!! You came up with this, didn't you!? How??? >>

... >Uh, ahem, what? Who's waking me up from my winter hybernation? :) There's work to do! >Nah, I didn't come up with that, I think it was Baraff and his implicit >integration stuff. Still, you suggested the above method to me. Works great for Cart cars and such. :)

Quoted text (11 lines)

>Anyway, the idea is that you don't know the average force on the damper >well if your damping happens very fast within your time interval (as is >the case with the wheel-damper system). The proper way would be knowing >the average value of the damper force in this timestep. In the explicit >scheme, you only use the value of the damper force at the beginning of >the interval, while in the new implicit scheme you get it only at the >end of this time interval, with the added bonus of high stability of >calculation. You may also try with averages of these two values (i.e. >(v+v')/2 instead of only v or v' on the right hand side) or any other >combinations, I haven't realy tried to play with that. If you do, let us >know how it works :).

It's in my code, so I could try it, but I like the stable one. :) I'll add it to the Racer v2.0 section, lol. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/