Race Physics: Understanding combined Pacejka

I've been working on a driving related sim for a few days now and, although it's not as hardcore as Racer, I want to get the physics to be as good as possible. I'vev now gotten to the tire model (ugh!) and need help with the combined Pacejka formula. I've been studying The Physics of Racing series (great stuff!!!), specifically Part 25 (http://phors.locost7.info/phors25.htm) and the later part 29 and I really don't understand exactly what is being done. I realize that the goal is to get the total force on the tire, which can be compared to the total force the tire can handle (to determine if there is a skid), but I don't understand the final three formulas that are given in part 25 as the solution. Can anyone explain them in slightly plainer style (I can handle some physics, I just need help relating it to code) or even better with pseudocode? I appreciate the help! Aaron Liebling -- "You're the worst thing to happen to musicals since Andrew Lloyd Webber!" - Stewie from The Family Guy

On Fri, 12 Jul 2002 15:28:31 GMT, Aaron Liebling <[email hidden]> wrote: ...

Quoted text (11 lines)

>I've been studying The Physics of Racing series (great stuff!!!), >specifically Part 25 (http://phors.locost7.info/phors25.htm) and the later >part 29 and I really don't understand exactly what is being done. I >realize that the goal is to get the total force on the tire, which can >be compared to the total force the tire can handle (to determine if >there is a skid), but I don't understand the final three formulas that >are given in part 25 as the solution. > >Can anyone explain them in slightly plainer style (I can handle some >physics, I just need help relating it to code) or even better with >pseudocode?

It looks like a friction circle cutoff. You take the original Pacejka results, but as (when combined) they can exceed the maximum friction force (mu*F_load) they are 'contained'. Didn't read the complete article, but s and a are probably normalized (otherwise the sqrt() wouldn't work as you'd have an ellipse). Then you look at the contribution of s versus total slip and a versus total slip. Say, if s=0.5, a=0.25, then 's' contributes more to the force than 'a' does. This is expressed in the formulae of the new Fx and Fy, where the contributions of s and a are done mathematically. Note the vector (s,a) that moves within a circle with radius 1 and note that s/rho and a/rho look like cosines/sines. It may be a bit more deep, as the way I put it above looks like you could do something like: v2d = (Fx,Fy) // Fx, Fy original Pacejka outcome maxForce=mu*F_load; if(v2d.length()>maxForce) { v2d=maxForce*Normalize(v2d); } Fx'=v2d.x; Fy'=v2d.y; (capping the force vector at the friction circle with radius mu*F_load). Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

Ruud, Thanks for taking the time to respond. Your Racer is a great inspiration! I'm fine with programming and vector/3d math, but am fairly new tocomplex physics (I'm really enjoying it though!). I'm afraid your answer went right over my head, as I need an even simpler explanation than what you gave. If you think I'm biting off more than I can chew, is there a simpler (but still effective) tire model? Or is there a better (more conventional) wayx to combine the effects of the two Pacejka's algorithims? Assuming you're willing to answer my dummy questions, please read on! Unfortunately, I don't even understand the signifigance of the 3 equations derived at the bottom of part 25 (http://phors.locost7.info/phors25.htm). In rho = +sqrt( squ(s) + squ(a) ), what does the rho actually mean? I'm assuming s is the output from the longitudinal pacejka algorithm and a that from the lateral. Is this correct? Given these three algorthims, how do I go about applying them to a programmatical tire model? I.e., given the algorithims and the whatr is known about the tires (dimensions, load, speed, etc...), how do I go about figuring if a given tire is locked up skidding and what rate it is rotating at? I apologize if this question seems silly, but as I said, I'm pretty new to physics. I've gotten load shifting and things like that down just fine (lots of good general physics tutorials), but I'm a bit lost when it comes to the tire model and trying to apply Pacejka algorithims to my program. Any helpyou can give is very much appreciated! Aaron Ruud van Gaal <[email hidden]> wrote: : It looks like a friction circle cutoff. You take the original Pacejka : results, but as (when combined) they can exceed the maximum friction : force (mu*F_load) they are 'contained'. : Didn't read the complete article, but s and a are probably normalized : (otherwise the sqrt() wouldn't work as you'd have an ellipse). Then : you look at the contribution of s versus total slip and a versus total : slip. Say, if s=0.5, a=0.25, then 's' contributes more to the force : than 'a' does. : This is expressed in the formulae of the new Fx and Fy, where the : contributions of s and a are done mathematically. : Note the vector (s,a) that moves within a circle with radius 1 and : note that s/rho and a/rho look like cosines/sines. : It may be a bit more deep, as the way I put it above looks like you : could do something like: : v2d = (Fx,Fy) // Fx, Fy original Pacejka outcome : maxForce=mu*F_load; : if(v2d.length()>maxForce) : { : v2d=maxForce*Normalize(v2d); : } : Fx'=v2d.x; : Fy'=v2d.y; : (capping the force vector at the friction circle with radius : mu*F_load). : Ruud van Gaal : Free car sim: http://www.racer.nl/ : Pencil art : http://www.marketgraph.nl/gallery/ -- "You're the worst thing to happen to musicals since Andrew Lloyd Webber!" - Stewie from The Family Guy

Ruud, Thanks so much for your response. your Racer is a great inspiration! While I have no problem with programming or vector/3d math, I'm a bit of a newbie to hardcore physics. Unfortunately, your reply went right over my head. :-( I've had no problem with getting my physics working up to this point (lots of good tutorials), but the tire model and how to apply Pacejka's algorithims has baffled me. I have no idea how to apply the three algorithims found at the bottom of part 25 (http://phors.locost7.info/phors25.htm) to a programmatical tire model. For example, in the equation rho = + sqrt( squ(s) + squ(a) ), what is the rho that is being calculated? I'm assuming s is the output from the longitudinal Pacejka algorithim and a = the lateral, but I have no idea what the output means or how to use the second twoalgorithims. Using these queries, how do I figure out (given the information I have about a tire..dimensions, load, torque, etc...) if a given tire is locked, skidding, or what rate it is rotating at? If these questions are too dumb, is there somewhere simpler to start for a tire model, or a good example of how Pacejka's algorithims can be used in a real program? I'm just not able to connect the material I've found on it to what I need to be doing. :-( While there are lots of other good physics tutorials for toher parts of car related motion, I'm lost on the Pacejka stuff. Any help you can lend is deeply appreciated! Aaron Ruud van Gaal <[email hidden]> wrote: : It looks like a friction circle cutoff. You take the original Pacejka : results, but as (when combined) they can exceed the maximum friction : force (mu*F_load) they are 'contained'. : Didn't read the complete article, but s and a are probably normalized : (otherwise the sqrt() wouldn't work as you'd have an ellipse). Then : you look at the contribution of s versus total slip and a versus total : slip. Say, if s=0.5, a=0.25, then 's' contributes more to the force : than 'a' does. : This is expressed in the formulae of the new Fx and Fy, where the : contributions of s and a are done mathematically. : Note the vector (s,a) that moves within a circle with radius 1 and : note that s/rho and a/rho look like cosines/sines. : It may be a bit more deep, as the way I put it above looks like you : could do something like: : v2d = (Fx,Fy) // Fx, Fy original Pacejka outcome : maxForce=mu*F_load; : if(v2d.length()>maxForce) : { : v2d=maxForce*Normalize(v2d); : } : Fx'=v2d.x; : Fy'=v2d.y; : (capping the force vector at the friction circle with radius : mu*F_load). : Ruud van Gaal : Free car sim: http://www.racer.nl/ : Pencil art : http://www.marketgraph.nl/gallery/ -- "You're the worst thing to happen to musicals since Andrew Lloyd Webber!" - Stewie from The Family Guy

Ruud, Thanks so much for your response. your Racer is a great inspiration! While I have no problem with programming or vector/3d math, I'm a bit of a newbie to hardcore physics. Unfortunately, your reply went right over my head. :-( I've had no problem with getting my physics working up to this point (lots of good tutorials), but the tire model and how to apply Pacejka's algorithims has baffled me. I have no idea how to apply the three algorithims found at the bottom of part 25 (http://phors.locost7.info/phors25.htm) to a programmatical tire model. For example, in the equation rho = + sqrt( squ(s) + squ(a) ), what is the rho that is being calculated? I'm assuming s is the output from the longitudinal Pacejka algorithim and a = the lateral, but I have no idea what the output means or how to use the second twoalgorithims. Using these queries, how do I figure out (given the information I have about a tire..dimensions, load, torque, etc...) if a given tire is locked, skidding, or what rate it is rotating at? If these questions are too dumb, is there somewhere simpler to start for a tire model, or a good example of how Pacejka's algorithims can be used in a real program? I'm just not able to connect the material I've found on it to what I need to be doing. :-( While there are lots of other good physics tutorials for toher parts of car related motion, I'm lost on the Pacejka stuff. Any help you can lend is deeply appreciated! Aaron Ruud van Gaal <[email hidden]> wrote: : It looks like a friction circle cutoff. You take the original Pacejka : results, but as (when combined) they can exceed the maximum friction : force (mu*F_load) they are 'contained'. : Didn't read the complete article, but s and a are probably normalized : (otherwise the sqrt() wouldn't work as you'd have an ellipse). Then : you look at the contribution of s versus total slip and a versus total : slip. Say, if s=0.5, a=0.25, then 's' contributes more to the force : than 'a' does. : This is expressed in the formulae of the new Fx and Fy, where the : contributions of s and a are done mathematically. : Note the vector (s,a) that moves within a circle with radius 1 and : note that s/rho and a/rho look like cosines/sines. : It may be a bit more deep, as the way I put it above looks like you : could do something like: : v2d = (Fx,Fy) // Fx, Fy original Pacejka outcome : maxForce=mu*F_load; : if(v2d.length()>maxForce) : { : v2d=maxForce*Normalize(v2d); : } : Fx'=v2d.x; : Fy'=v2d.y; : (capping the force vector at the friction circle with radius : mu*F_load). : Ruud van Gaal : Free car sim: http://www.racer.nl/ : Pencil art : http://www.marketgraph.nl/gallery/ -- "You're the worst thing to happen to musicals since Andrew Lloyd Webber!" - Stewie from The Family Guy

Ruud, I hadn't realized the source of Racer was available. It is a great help in understanding how the tire model goes together! Your code is very readable and well commented (despite the plethora of #ifdefs) :-) I think I'll probably be able to get the explanations I need from following it (I can read code much more easily than physics texts). If you have any further advice or thoughts, I'd love to hear them. thanks, Aaron

On Fri, 12 Jul 2002 20:05:02 GMT, Aaron Liebling <[email hidden]> wrote: >Thanks for taking the time to respond. Your Racer is a great >inspiration! You're welcome. :) >I'm afraid your answer went right over my head, as I need an even >simpler explanation than what you gave. If you think I'm biting off >more than I can chew, is there a simpler (but still effective) tire >model? Or is there a better (more conventional) wayx to combine the >effects of the two Pacejka's algorithims? So you do have the original Pacejka formula's in your source? A simpler system would be to just cut off the force. You know about the friction circle? Basically the tire can't generate more than some amount of force. From the Pacejka formula, you get a D (the one that multiplies your sin(), so D is also the maximum force you're ever going to get). D is then the maximum longitudinal force you'll ever get. To make things simple, you can take the 2D vector (Fx,Fy), where Fx=PacejkaLongitudinal() and Fy is lateral. If both Fx and Fy are large, the combined force (the length of vector (Fx,Fy)) is bigger than the tire can actually handle. So then you can also just apply a friction circle and do: Vector2D v(Fx,Fy); float len=v.Length(); if(len>maxForce) v.Scale(maxForce/len); >Unfortunately, I don't even understand the signifigance of the 3 >equations derived at the bottom of part 25 >(http://phors.locost7.info/phors25.htm). In rho = +sqrt( squ(s) + >squ(a) ), what does the rho actually mean? That is the length of the vector (s,a), used to determine whether the combined forces go outside the friction circle (in which case the vector needs to be capped). > I'm assuming s is the output >from the longitudinal pacejka algorithm and a that from the lateral. Is >this correct? I'd say s=slipRatio and a=slipAngle, so not really the forces themselves, but the article might explain that better. >Given these three algorthims, how do I go about applying them to a >programmatical tire model? I.e., given the algorithims and the >whatr is known about the tires (dimensions, load, speed, etc...), how do >I go about figuring if a given tire is locked up skidding and what rate >it is rotating at? Locked up is more a question of slip ratio. Nothing to do with combined slip. See the formulae of slip ratio: once the velocity of the wheel becomes 0, the slip ratio becomes -1, which is locking. But you don't deal with that directly, you just keep the wheel's speed by rotational acceleration: once the forces are worked out you accelerate the wheel by using F_engine-Fx (the road reaction force, Fx from Pacejka, fights the will of the engine, F_engine as calculated from engine_torque*gearboxRatio*differentialRatio/wheelRadius). That's like: wheelAcc=(F_engine-Fx)/spinInertiaOfWheel >I apologize if this question seems silly, but as I said, I'm pretty new >to physics. In the end most of it is F=m*a or the torque variant (T=I*w, torque=inertia*angularAcceleration). Pacejka is just a way to describe how the forces vary when the wheel doesn't roll exactly the same as the road below it. A Google search on 'Car physics' in this group will also dig up a lot of previous discussions! Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

Another place to look is Race Car Vehicle Dynamics (Doug Milliken, one of the authors, posts on this forum now and then) which is a good "one-stop shopping mall" for vehicle dynamics. The chapter on "tire data treatment" has equations for combined slip-angle/slip-ratio/camber behavior (both tire force and pneumatic trail for force feedback) using Pacejka-style magic formulae that are very easy to plug into a simulator, assuming you already have some sort of rigid-body and suspension model. Also, there is enough sample data in the book to get you started with some baseline numbers, plus a lot of other good stuff. I haven't looked at Racer's source code though, so you might find everything you want there. -Dave P. "Aaron Liebling" <[email hidden]> wrote in message news:5mIX8.13883$[email hidden]...

Quoted text (15 lines)

> > Ruud, > > I hadn't realized the source of Racer was available. It is a great help > in understanding how the tire model goes together! Your code is very > readable and well commented (despite the plethora of #ifdefs) :-) > > I think I'll probably be able to get the explanations I need from > following it (I can read code much more easily than physics texts). > > If you have any further advice or thoughts, I'd love to hear them. > > thanks, > > Aaron

First, sorry for the multiple posts. My news reader was acting up. Thansk for the clear explanation. Between that and some hints from the racer source I think I understand enough to muddle my way forward. I'm sure I'll be back with more dumb questions soon. I'll also check out the book that was recommended as it sounds perfect! Aaron [email hidden] (Ruud van Gaal) wrote in message news:<[email hidden]>...

Quoted text (81 lines)

> On Fri, 12 Jul 2002 20:05:02 GMT, Aaron Liebling > <[email hidden]> wrote: > > >Thanks for taking the time to respond. Your Racer is a great > >inspiration! > > You're welcome. :) > > >I'm afraid your answer went right over my head, as I need an even > >simpler explanation than what you gave. If you think I'm biting off > >more than I can chew, is there a simpler (but still effective) tire > >model? Or is there a better (more conventional) wayx to combine the > >effects of the two Pacejka's algorithims? > > So you do have the original Pacejka formula's in your source? > > A simpler system would be to just cut off the force. You know about > the friction circle? > Basically the tire can't generate more than some amount of force. From > the Pacejka formula, you get a D (the one that multiplies your sin(), > so D is also the maximum force you're ever going to get). D is then > the maximum longitudinal force you'll ever get. > > To make things simple, you can take the 2D vector (Fx,Fy), where > Fx=PacejkaLongitudinal() and Fy is lateral. If both Fx and Fy are > large, the combined force (the length of vector (Fx,Fy)) is bigger > than the tire can actually handle. > So then you can also just apply a friction circle and do: > Vector2D v(Fx,Fy); > float len=v.Length(); > if(len>maxForce) > v.Scale(maxForce/len); > > >Unfortunately, I don't even understand the signifigance of the 3 > >equations derived at the bottom of part 25 > >(http://phors.locost7.info/phors25.htm). In rho = +sqrt( squ(s) + > >squ(a) ), what does the rho actually mean? > > That is the length of the vector (s,a), used to determine whether the > combined forces go outside the friction circle (in which case the > vector needs to be capped). > > > I'm assuming s is the output > >from the longitudinal pacejka algorithm and a that from the lateral. Is > >this correct? > > I'd say s=slipRatio and a=slipAngle, so not really the forces > themselves, but the article might explain that better. > > >Given these three algorthims, how do I go about applying them to a > >programmatical tire model? I.e., given the algorithims and the > >whatr is known about the tires (dimensions, load, speed, etc...), how do > >I go about figuring if a given tire is locked up skidding and what rate > >it is rotating at? > > Locked up is more a question of slip ratio. Nothing to do with > combined slip. See the formulae of slip ratio: once the velocity of > the wheel becomes 0, the slip ratio becomes -1, which is locking. But > you don't deal with that directly, you just keep the wheel's speed by > rotational acceleration: once the forces are worked out you accelerate > the wheel by using F_engine-Fx (the road reaction force, Fx from > Pacejka, fights the will of the engine, F_engine as calculated from > engine_torque*gearboxRatio*differentialRatio/wheelRadius). > That's like: > wheelAcc=(F_engine-Fx)/spinInertiaOfWheel > > >I apologize if this question seems silly, but as I said, I'm pretty new > >to physics. > > In the end most of it is F=m*a or the torque variant (T=I*w, > torque=inertia*angularAcceleration). > Pacejka is just a way to describe how the forces vary when the wheel > doesn't roll exactly the same as the road below it. > > A Google search on 'Car physics' in this group will also dig up a lot > of previous discussions! > > > Ruud van Gaal > Free car sim: http://www.racer.nl/ > Pencil art : http://www.marketgraph.nl/gallery/

Keep the extreme conditions in mind. For example, what happens when the wheel is locked? (That is straight forward, but may not fall out of the equations properly.) And when the wheel spins what do you do then... ;)

One more time now... Best place to buy our books is SAE -- they have it in stock and ship right away (unlike Amazon who don't stock). We keep a link updated to the SAE bookstore from our site (since SAE often re-organize their site): http://www.millikenresearch.com/rcvd.html Thanks for the compliment, first time I've heard RCVD called a "shopping mall"<grin>. We use an advanced version of the non-dimensional (or normalized) tire formulation discussed in Chapter 14 in several of our models. It has a lot of advantages for simulation, for example it is very easy to change the peak mu in an organized manner. -- Doug Milliken Milliken Research Associates Inc. On Fri, 12 Jul 2002, Dave Pollatsek wrote:

Quoted text (33 lines)

> Another place to look is Race Car Vehicle Dynamics (Doug Milliken, one of > the authors, posts on this forum now and then) which is a good "one-stop > shopping mall" for vehicle dynamics. The chapter on "tire data treatment" > has equations for combined slip-angle/slip-ratio/camber behavior (both tire > force and pneumatic trail for force feedback) using Pacejka-style magic > formulae that are very easy to plug into a simulator, assuming you already > have some sort of rigid-body and suspension model. Also, there is enough > sample data in the book to get you started with some baseline numbers, plus > a lot of other good stuff. I haven't looked at Racer's source code though, > so you might find everything you want there. > -Dave P. > > "Aaron Liebling" <[email hidden]> wrote in message > news:5mIX8.13883$[email hidden]... > > > > Ruud, > > > > I hadn't realized the source of Racer was available. It is a great help > > in understanding how the tire model goes together! Your code is very > > readable and well commented (despite the plethora of #ifdefs) :-) > > > > I think I'll probably be able to get the explanations I need from > > following it (I can read code much more easily than physics texts). > > > > If you have any further advice or thoughts, I'd love to hear them. > > > > thanks, > > > > Aaron > > > >

Ruud, A followup Racer question (the source code has been a great help in filling in some of the blank spots in my code (like the frixction circle). In RBody::ApplyRotations, you do the following: for(i=0;i<car->GetWheels();i++) { w=car->GetWheel(i); forceCar=*w->GetForceBodyCC(); torque.y+=forceCar.x*w->GetSuspension()->GetZ(); torque.y+=-forceCar.z*w->GetSuspension()->GetX(); ... } I must be missing something, but this means seems to imply that you're going to apply a torque on the y axis based on forward or lateral movement. Looking through your code, though, I could find no where that the suspension positions are set (used here via the GetZ() and GetX()). I assume this suspension position is supposed to reflect rotation of the attached wheel, or is that accounted in to the body's torque elsewhere? Where in Racer are the suspension positions modified? I assumed it should have something to do with wheel rotation, but could find nothing. Thanks again for making your source available. It pointed out a number of fundamental errors I had made and serves as a great guide when I get stuck! Aaron

Yeah, the ability to easily modify the tire curve is a good feature for us for things like different compounds, heat, etc. Is this "advanced version" described in any papers, or is it hush hush? ;) Also, if you ever do another edition, something about low-speed cases might be handy to those starting out... (although I'm sure everyone would have a wishlist!) -Dave "Doug Milliken" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (20 lines)

> > One more time now... Best place to buy our books is SAE -- they > have it in stock and ship right away (unlike Amazon who don't stock). > We keep a link updated to the SAE bookstore from our site (since SAE > often re-organize their site): > http://www.millikenresearch.com/rcvd.html > > Thanks for the compliment, first time I've heard RCVD called a "shopping > mall"<grin>. We use an advanced version of the non-dimensional (or > normalized) tire formulation discussed in Chapter 14 in several of our > models. It has a lot of advantages for simulation, for example it is very > easy to change the peak mu in an organized manner. > > -- Doug Milliken > Milliken Research Associates Inc. > > > On Fri, 12 Jul 2002, Dave Pollatsek wrote: > > > Another place to look is Race Car Vehicle Dynamics (Doug Milliken, one

of > > the authors, posts on this forum now and then) which is a good "one-stop > > shopping mall" for vehicle dynamics. The chapter on "tire datatreatment" > > has equations for combined slip-angle/slip-ratio/camber behavior (bothtire > > force and pneumatic trail for force feedback) using Pacejka-style magic > > formulae that are very easy to plug into a simulator, assuming youalready > > have some sort of rigid-body and suspension model. Also, there isenough > > sample data in the book to get you started with some baseline numbers,plus > > a lot of other good stuff. I haven't looked at Racer's source codethough,

Quoted text (9 lines)

> > so you might find everything you want there. > > -Dave P. > > > > "Aaron Liebling" <[email hidden]> wrote in message > > news:5mIX8.13883$[email hidden]... > > > > > > Ruud, > > > > > > I hadn't realized the source of Racer was available. It is a great

help

Quoted text (16 lines)

> > > in understanding how the tire model goes together! Your code is very > > > readable and well commented (despite the plethora of #ifdefs) :-) > > > > > > I think I'll probably be able to get the explanations I need from > > > following it (I can read code much more easily than physics texts). > > > > > > If you have any further advice or thoughts, I'd love to hear them. > > > > > > thanks, > > > > > > Aaron > > > > > > > > >

Sorry, no papers yet on our internal tire stuff, but maybe someday. Since we primarily write "engineering simulations", we have only a little need for low speed solutions...different set of problems than writing "driving simulators". But I agree that if there is ever a second edition of RCVD this would be a good topic to add. So far we have been just trying to patch the current edition, every printing has more bug fixes, mostly pointed out by professors that use it for college courses in vehicle dynamics. The publishers allow us to make changes, as long as the pagination doesn't change. -- Doug Milliken Milliken Research Associates Inc. On Sun, 14 Jul 2002, Dave Pollatsek wrote:

Quoted text (74 lines)

> Yeah, the ability to easily modify the tire curve is a good feature for us > for things like different compounds, heat, etc. Is this "advanced version" > described in any papers, or is it hush hush? ;) Also, if you ever do > another edition, something about low-speed cases might be handy to those > starting out... (although I'm sure everyone would have a wishlist!) > -Dave > > "Doug Milliken" <[email hidden]> wrote in message > news:[email hidden]... > > > > One more time now... Best place to buy our books is SAE -- they > > have it in stock and ship right away (unlike Amazon who don't stock). > > We keep a link updated to the SAE bookstore from our site (since SAE > > often re-organize their site): > > http://www.millikenresearch.com/rcvd.html > > > > Thanks for the compliment, first time I've heard RCVD called a "shopping > > mall"<grin>. We use an advanced version of the non-dimensional (or > > normalized) tire formulation discussed in Chapter 14 in several of our > > models. It has a lot of advantages for simulation, for example it is very > > easy to change the peak mu in an organized manner. > > > > -- Doug Milliken > > Milliken Research Associates Inc. > > > > > > On Fri, 12 Jul 2002, Dave Pollatsek wrote: > > > > > Another place to look is Race Car Vehicle Dynamics (Doug Milliken, one > of > > > the authors, posts on this forum now and then) which is a good "one-stop > > > shopping mall" for vehicle dynamics. The chapter on "tire data > treatment" > > > has equations for combined slip-angle/slip-ratio/camber behavior (both > tire > > > force and pneumatic trail for force feedback) using Pacejka-style magic > > > formulae that are very easy to plug into a simulator, assuming you > already > > > have some sort of rigid-body and suspension model. Also, there is > enough > > > sample data in the book to get you started with some baseline numbers, > plus > > > a lot of other good stuff. I haven't looked at Racer's source code > though, > > > so you might find everything you want there. > > > -Dave P. > > > > > > "Aaron Liebling" <[email hidden]> wrote in message > > > news:5mIX8.13883$[email hidden]... > > > > > > > > Ruud, > > > > > > > > I hadn't realized the source of Racer was available. It is a great > help > > > > in understanding how the tire model goes together! Your code is very > > > > readable and well commented (despite the plethora of #ifdefs) :-) > > > > > > > > I think I'll probably be able to get the explanations I need from > > > > following it (I can read code much more easily than physics texts). > > > > > > > > If you have any further advice or thoughts, I'd love to hear them. > > > > > > > > thanks, > > > > > > > > Aaron > > > > > > > > > > > > > > > > > >

On Sun, 14 Jul 2002 22:34:08 GMT, Aaron Liebling <[email hidden]> wrote: (emailed separately) Hi Aaron, Glad to see the source is actually of help. Might be cluttering at times. :)

Quoted text (14 lines)

> In RBody::ApplyRotations, you do the following: > > for(i=0;i<car->GetWheels();i++) { > w=car->GetWheel(i); > forceCar=*w->GetForceBodyCC(); > > torque.y+=forceCar.x*w->GetSuspension()->GetZ(); > torque.y+=-forceCar.z*w->GetSuspension()->GetX(); > ... > } > > I must be missing something, but this seems to imply that you're > going to apply a torque on the y axis of the body based on forward > or lateral movement.

Not movement, but force. As a lateral force builds up at a tire, it is applied to the body as a rotational torque. As T=F*r, the above code converts the lateral force (forceCar.x) as a torque around the body's CG. The arm ('r') is taken as the suspension Z location. Same for longitudinal forces (Fx in Pacejka/SAE, forceCar.z in Racer, which uses the OpenGL axis system). This time the arm is the horizontal position: forceCar.z | V O-----O | | | | | x | x=CG | | | | O-----O <--> susp.x > Looking through your code, though, I could find no where that the > suspension positions are set (used here via the GetZ() and GetX()). It probably is in rsusp.cpp: RSuspension::Load(). > I > assume this suspension position is supposed to reflect rotation of the > attached wheel, or is the effect of the wheels turning accounted in to > the body's torque elsewhere? It is just the wheel position; no wheel turning itself. Wheel turning is only used in determining slip angle. If the wheel is turned because of the steering wheel, lateral (Fy) forces will be generated, which are used in the above code in the same way. After all, the forces are transmitted to the body through the suspension; doesn't matter if the wheel is being turned or not. Cheers, Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

DOH..I figured out my problem in the shower this morning (funny how that happens). I was thinking that the suspension x,y,z were dynamic variables influenced by the wheels (so the wheels were passing their effects back to the body through the suspension). Instead, the suspension position is a static variable used purely as a modifier for the dynamic tire forces. Should have been obvious in retrospect! Thanks! Aaron Ruud van Gaal <[email hidden]> wrote: : On Sun, 14 Jul 2002 22:34:08 GMT, Aaron Liebling : <[email hidden]> wrote: : (emailed separately) : Hi Aaron, : Glad to see the source is actually of help. Might be cluttering at : times. :) :> In RBody::ApplyRotations, you do the following: :> :> for(i=0;i<car->GetWheels();i++) { :> w=car->GetWheel(i); :> forceCar=*w->GetForceBodyCC(); :> :> torque.y+=forceCar.x*w->GetSuspension()->GetZ(); :> torque.y+=-forceCar.z*w->GetSuspension()->GetX(); :> ... :> } :> :> I must be missing something, but this seems to imply that you're :> going to apply a torque on the y axis of the body based on forward :> or lateral movement. : Not movement, but force. As a lateral force builds up at a tire, it is : applied to the body as a rotational torque. As T=F*r, the above code : converts the lateral force (forceCar.x) as a torque around the body's : CG. The arm ('r') is taken as the suspension Z location. : Same for longitudinal forces (Fx in Pacejka/SAE, forceCar.z in Racer, : which uses the OpenGL axis system). This time the arm is the : horizontal position: : forceCar.z : | : V : O-----O : | | : | | : | x | x=CG : | | : | | : O-----O : <--> : susp.x :> Looking through your code, though, I could find no where that the :> suspension positions are set (used here via the GetZ() and GetX()). : It probably is in rsusp.cpp: RSuspension::Load(). :> I :> assume this suspension position is supposed to reflect rotation of the :> attached wheel, or is the effect of the wheels turning accounted in to :> the body's torque elsewhere? : It is just the wheel position; no wheel turning itself. Wheel turning : is only used in determining slip angle. If the wheel is turned because : of the steering wheel, lateral (Fy) forces will be generated, which : are used in the above code in the same way. After all, the forces are : transmitted to the body through the suspension; doesn't matter if the : wheel is being turned or not. : Cheers, : Ruud van Gaal : Free car sim: http://www.racer.nl/ : Pencil art : http://www.marketgraph.nl/gallery/ -- "You're the worst thing to happen to musicals since Andrew Lloyd Webber!" - Stewie from The Family Guy