Race Sim Central
Rec.Autos.Simulators Archive

Car Physics: slip ratio at time=0?

16 posts by 6 people · 02 Nov 2001 21:54 UTC - 08 Nov 2001 11:35 UTC

J. Perkins 02 Nov 2001 21:54 UTC#154639
Hey folks, two questions... If slip ratio is defined as: Va / Vf - 1 where Va = angular velocity of wheel under acceleration and Vf = angular velocity of free rolling wheel, what is the value when Vf=0? That is, in the first timestep that the wheel receives torque from the drivetrain, what is the slip ratio considered to be? I have s feeling the answer to this is obvious and it's my perception of the problem that's wrong. Second, how do you pronounce "Pacejka"? God forbid it ever should come up in conversation... ;) Thanks for your help, including all of the stuff in the archives. Great, great stuff. Jason 379
In the first time step, you'll have 0 slip ratio since the tire and car have no velocity (the tire hasn't flexed yet, so it won't produce a force). This slip ratio stuff is a real pain in the patooty when the car is moving slowly because you wind up dividing by a tiny number (Vf), resulting in huge slip ratios that jerk the tires forward and backwards. That's another subject though. I think Pacejka is pronounced PasEEjka, but I don't know for sure. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com
J. Todd Wasson <[email hidden]> wrote in message news:[email hidden]...
Quoted text (8 lines)> In the first time step, you'll have 0 slip ratio since the tire and car have > no velocity (the tire hasn't flexed yet, so it won't produce a force). This > slip ratio stuff is a real pain in the patooty when the car is moving slowly > because you wind up dividing by a tiny number (Vf), resulting in huge slip > ratios that jerk the tires forward and backwards. That's another subject > though. > > I think Pacejka is pronounced PasEEjka, but I don't know for sure.
PaJAYka is close to the way we were taught ;-) Jonny
On 2 Nov 2001 13:54:27 -0800, [email hidden] (J. Perkins) wrote:
Quoted text (8 lines)>Hey folks, two questions... > >If slip ratio is defined as: > > Va / Vf - 1 > >where Va = angular velocity of wheel under acceleration and Vf = angular >velocity of free rolling wheel, what is the value when Vf=0?
Try getting some info on document SAE950311. A method by Barnard IIRC, which is mentioned in other papers as well. In short, an extra indirection is used to indicate slipratio, and it only changes when the wheel starts rotating. It's delta is based on the relaxation length of the tire. It also has some low-speed trouble, but less so than applying a direct SR formula like above. It is mentioned briefly in the thesis of Erik Lowndes. Links on my page (at the 'links' page ;-)) to several of these. I think some papers of Michael Sayers also talk about it. But take care, it's only a couple of lines mostly. :) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/
[email hidden] (J. Todd Wasson) wrote in message news:<[email hidden]>... > In the first time step, you'll have 0 slip ratio since the tire and car have > no velocity (the tire hasn't flexed yet, so it won't produce a force). Yes I understand that. But it seems that there must be some (short) period of time where the axle is starting to spin but the wheel has no forward velocity -- the rubber "winding up" as it were -- until the tire starts to slip and a forward force is generated. I guess I'm confused about how the slip ratio gets from zero to not-zero. I see from the archives that the Genta book seems to be the introduction to this subject, so I have placed my order. I see that Ruud has also mentioned a couple of SAE papers that I will try to check out. Jason
On 5 Nov 2001 07:42:18 -0800, [email hidden] (J. Perkins) wrote:
Quoted text (9 lines)>[email hidden] (J. Todd Wasson) wrote in message news:<[email hidden]>... >> In the first time step, you'll have 0 slip ratio since the tire and car have >> no velocity (the tire hasn't flexed yet, so it won't produce a force). > >Yes I understand that. But it seems that there must be some (short) period >of time where the axle is starting to spin but the wheel has no forward >velocity -- the rubber "winding up" as it were -- until the tire starts >to slip and a forward force is generated. I guess I'm confused about how >the slip ratio gets from zero to not-zero.
Right. 3 approaches can be taken (probably a dozen more, but anyway): 1. The Barnard way of indirecting SR. (so SR gets updated using an indirect tan(SR) based on the wheel spin velocity). This gets the feel of 'rubber building up'. 2. Just ignore the (quick) rubber force buildup and accelerate the wheel. With SR=0 at the first timestep, no counterforce will be present. The NEXT step though, SR will be >0 (probably even infinite) and a force will push from the road back onto the tire. Eventually, you'll reach a balance. If your timestep is small enough, it will bounce back & forth but look good onscreen. 3. Another SAE paper (98-something) looks at the tire as a 3D spring. So longitudinally, you let the wheel spin and this creates a force because the tire ofcourse also works as a spring in longitudinal direction. When that is found, it is verified against the friction circle, and if the force is really not possible (too much amplitude), then the force is reduced to the edge of the circle and the spring offset is adjusted (shifted) accordingly (it's a predictor-corrector method). I would suggest starting with #2. I think #3, despite it's easy understanding, is problematic because I think the spring are too stiff and you'll have trouble with the integrations. After you get #2 to work, you can add #1 without too much hassle (extend it). There's some pretty damping trouble you may have to go through there. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/
Quoted text (10 lines)>>> In the first time step, you'll have 0 slip ratio since the tire and car >have >>> no velocity (the tire hasn't flexed yet, so it won't produce a force). >> >>Yes I understand that. But it seems that there must be some (short) period >>of time where the axle is starting to spin but the wheel has no forward >>velocity -- the rubber "winding up" as it were -- until the tire starts >>to slip and a forward force is generated. I guess I'm confused about how >>the slip ratio gets from zero to not-zero. >
Whoops, my AOL newsreader didn't show your reply here, sorry about that. Like Ruud said, it's easiest to ignore this and just let the wheel accelerate at the first time step. Physically, what's really happening is, the wheel hub rotates a little, causing the tire to wind up slightly before the car moves. Right then, you've got a slip ratio, even if the tire wasn't really slipping because there is a velocity, and theoretical free rolling velocity is still 0 (infinite slip ratio, or undefined slip ratio). However, some portion of the rear of the contact patch slips during this wind up (the load approaches 0 at the rear of the contact patch, so any wind up in the tire at all will cause some slippage). With any slippage at all, the hub is rotating at a different speed than theoretical free rolling, so there's suddenly a slip ratio as soon as a torque is applied to the wheel. In the case where the car is stationary, even without any slippage though, the wheel hub gains some rotational velocity before the car moves, so there's still a slip ratio the instant the wheel gets a torque applied to it. It would be infinite of course, since you're dividing by the car's velocity of 0. In reality, the hub can rotate a small amount while only generating a small force, so slip ratio can be kind of a wierd concept when the car is stationary. I switch to a different model at low speed that treats the tire and hub as a torsion spring so the problem doesn't surface, but method #1 that Ruud mentioned is probably better: >1. The Barnard way of indirecting SR. (so SR gets updated using an >indirect tan(SR) based on the wheel spin velocity). This gets the feel >of 'rubber building up'. Although I haven't seen it working yet though. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com
On 05 Nov 2001 22:42:41 GMT, [email hidden] (J. Todd Wasson) wrote: ... >so slip ratio can be kind of a wierd concept when the car is stationary. I >switch to a different model at low speed that treats the tire and hub as a >torsion spring so the problem doesn't surface, but method #1 that Ruud >mentioned is probably better: With all the cars out there for Racer, I think the problem with switching to a spring model is smoothly going from one method to the other. Ofcourse you can calculate both and mix the results of both (so it gradually becomes the slipratio calculation once the car gets some velocity). Mind you, I think some commercial carsims do this, or at least switch to another model at low speed. In the end, low speed is not of the greatest importance in a *racing* sim, where you're generally topping 200 km/h. >>1. The Barnard way of indirecting SR. (so SR gets updated using an >>indirect tan(SR) based on the wheel spin velocity). This gets the feel >>of 'rubber building up'. > > Although I haven't seen it working yet though. I'm still going to retry this one with the damping force that gets negated at every timestep (not mentioned in the SAE950311 document itself, but it IS in the Lowndes thesis). It worked reasonably in my sim, EXCEPT at low speeds, lol. But as Gregor mentioned, above a certain speed you can ignore relaxation length anyway as it has a negligable influence then (he even stated a formula for the exact velocity which I casually forgot ofcourse). I think either the SA or SR approach is still used even in my sim. Hehe, I don't even know anymore myself. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/
Quoted text (8 lines)>>so slip ratio can be kind of a wierd concept when the car is stationary. I >>switch to a different model at low speed that treats the tire and hub as a >>torsion spring so the problem doesn't surface, but method #1 that Ruud >>mentioned is probably better: > >With all the cars out there for Racer, I think the problem with >switching to a spring model is smoothly going from one method to the >other.
Yes, that is a problem :0) I need to really tweak my torsion "spring and damper" rates to keep it smooth, and even then sometimes there's a noticeable jerk and odd behavior... My current open differential model doesn't like it when the car is moving slowly. I switch to this at the lowest possible speed, but would rather use the method you were after. However, the torsion thing does let me stop on hills though :-) > Ofcourse you can calculate both and mix the results of both (so >it gradually becomes the slipratio calculation once the car gets some >velocity). Mind you, I think some commercial carsims do this, or at >least switch to another model at low speed. > Yikes, I don't know about getting my system to do that as it is now! :0) Very tough. Wouldn't even know where to start. >I'm still going to retry this one with the damping force that gets >negated at every timestep (not mentioned in the SAE950311 document >itself, but it IS in the Lowndes thesis). > Please let me know how it goes. >It worked reasonably in my sim, EXCEPT at low speeds, lol. But as >Gregor mentioned, above a certain speed you can ignore relaxation >length anyway as it has a negligable influence then (he even stated a >formula for the exact velocity which I casually forgot ofcourse). > Yeah, I remember that discussion, and forgot the formula too :0) >I think either the SA or SR approach is still used even in my sim. >Hehe, I don't even know anymore myself. lol. I know how that goes. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com
On 06 Nov 2001 22:38:31 GMT, [email hidden] (J. Todd Wasson) wrote:
Quoted text (10 lines)>>With all the cars out there for Racer, I think the problem with >>switching to a spring model is smoothly going from one method to the >>other. > > Yes, that is a problem :0) I need to really tweak my torsion "spring and >damper" rates to keep it smooth, and even then sometimes there's a noticeable >jerk and odd behavior... My current open differential model doesn't like it >when the car is moving slowly. I switch to this at the lowest possible speed, >but would rather use the method you were after. However, the torsion thing >does let me stop on hills though :-)
The Barnard method will do that too; it will keep the SR balanced so that the forces cancel eachother out, IIRC (a big IIRC! ;-)).
Quoted text (8 lines)> > Ofcourse you can calculate both and mix the results of both (so >>it gradually becomes the slipratio calculation once the car gets some >>velocity). Mind you, I think some commercial carsims do this, or at >>least switch to another model at low speed. >> > > Yikes, I don't know about getting my system to do that as it is now! :0) >Very tough. Wouldn't even know where to start.
Hm, if both methods are in separate functions, it would be like: NOW: - if v<thresHold then CalcForcesSpringModel() else CalcForcesSR() FUTURE: - CalcForcesSpringModel() SaveForces(forceInfoStructure) CalcForcesSR() if v<thresHold then scale=v/thresHold else scale=1 AverageForcesWith(forceInfoStructure,scale) But I know; my system is as uncontrolled as well so I can't just plug in an RK4 integrator or undo a physics step (as Baraff tends to do when penetration occurs; btw I like the FastCar approach where penetrations are resolved not by recalculating all forces with a smaller timestep, but slightly translating all penetrating objects along the collision normal so they don't penetrate anymore; not too accurate but with small translations I don't think anyone'd see the difference). > >I'm still going to retry this one with the damping force that gets >>negated at every timestep (not mentioned in the SAE950311 document >>itself, but it IS in the Lowndes thesis). > > Please let me know how it goes. I will. It's not on the planning for anytime soon though. >>It worked reasonably in my sim, EXCEPT at low speeds, lol. But as >>Gregor mentioned, above a certain speed you can ignore relaxation >>length anyway as it has a negligable influence then (he even stated a >>formula for the exact velocity which I casually forgot ofcourse). > > Yeah, I remember that discussion, and forgot the formula too :0) Lol. I checked, and it turns out I took out the slipAngle relaxation stuff (SAE950311), but I do use it longitudinally, SR. Without the damping though, hm?! (damping is #ifdef'd out) Amazing. So the SR route works, somehow. The formula to discard relaxation length is: if u*timeStep/B > 0.5 then SR=<direct calculation> else <SAE950311 differential stuff> Where u is the wheel spin velocity, and B is the longitudinal relaxation length. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/
Ruud van Gaal wrote:
Quoted text (10 lines)> > Yes, that is a problem :0) I need to really tweak my torsion "spring and > >damper" rates to keep it smooth, and even then sometimes there's a noticeable > >jerk and odd behavior... My current open differential model doesn't like it > >when the car is moving slowly. I switch to this at the lowest possible speed, > >but would rather use the method you were after. However, the torsion thing > >does let me stop on hills though :-) > > The Barnard method will do that too; it will keep the SR balanced so > that the forces cancel eachother out, IIRC (a big IIRC! ;-)). >
YRC! > > > > Yeah, I remember that discussion, and forgot the formula too :0) Guys, guys, keep those notes handy at all times :).
Quoted text (7 lines)> > if u*timeStep/B > 0.5 then SR=<direct calculation> > else <SAE950311 differential stuff> > > Where u is the wheel spin velocity, and B is the longitudinal > relaxation length. >
By the wheel spin velocity, you mean the translational velocity in the longitudinal direction, right :). Indeed, the criterion above is what is needed for the approach to work, otherwise you get an instability in your calcs (in principle you can let the inequality to go to > 1, but it's better to be on the safe side). -Gregor
On Wed, 07 Nov 2001 14:02:01 +0100, Gregor Veble <[email hidden]> wrote:
Quoted text (12 lines)>Ruud van Gaal wrote: >> > Yes, that is a problem :0) I need to really tweak my torsion "spring and >> >damper" rates to keep it smooth, and even then sometimes there's a noticeable >> >jerk and odd behavior... My current open differential model doesn't like it >> >when the car is moving slowly. I switch to this at the lowest possible speed, >> >but would rather use the method you were after. However, the torsion thing >> >does let me stop on hills though :-) >> >> The Barnard method will do that too; it will keep the SR balanced so >> that the forces cancel eachother out, IIRC (a big IIRC! ;-)). > >YRC!
Hehe, NAA! (not ANOTHER acronym) ;-) >> > Yeah, I remember that discussion, and forgot the formula too :0) > >Guys, guys, keep those notes handy at all times :). When is your book of 'All the things you always wanted to remember about carsims but we're unable to cope with?' out? ;-)
Quoted text (9 lines)>> if u*timeStep/B > 0.5 then SR=<direct calculation> >> else <SAE950311 differential stuff> >> >> Where u is the wheel spin velocity, and B is the longitudinal >> relaxation length. >> > >By the wheel spin velocity, you mean the translational velocity in the >longitudinal direction, right :).
Ah yes, that's what I meant! I saw 'wheelVel.x' and slammed down an inaccurately converted phrase (I was so happy I had a word for the wheel's rotational velocity along the X axis, well, Z axis in OpenGL, X in SAE, so confusing). Sorry about raising some confusion there perhaps. (is anybody still listening but us and Heisenberg to check whether his compensators get invented?) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/
Quoted text (9 lines)> But I know; my system is as uncontrolled as well so I can't just plug > in an RK4 integrator or undo a physics step (as Baraff tends to do > when penetration occurs; btw I like the FastCar approach where > penetrations are resolved not by recalculating all forces with a > smaller timestep, but slightly translating all penetrating objects > along the collision normal so they don't penetrate anymore; not too > accurate but with small translations I don't think anyone'd see the > difference). >
I've tried both of these techniques in my sim. The time reversal approach is very accurate and looks correct, but can be quite expensive if you're colliding with a dense patch of polygons, so I eventuually discarded this one. I'm currently using the second approach, which is simple to implement and not too expensive. However it's not without its problems. The main one is that there's no guarentee that by pushing an object along the collision normal, you're not pushing it inside other polygons. The result of this is that you can either get an object still penetrating after the timestep, or blipping between positions on alternate timesteps. You can avoid this by trying up to (eg) 5 movements, and if it's still penetrating after this, move it back to it's position at the beginning of the timestep, but this can result in "sticky" cars. It really depends on the nature of the geometry though, and as you pointed out, the size of your timestep. I'm currently looking into an approach which is about halfway between these two. It's very similar to the fastcar approach, except that I move an object out of the geometry along the direction it came in (ie if a point is penetrating, get the vector from its old position to its new position, and move it out along this line). This won't take it back to the exact position it entered (since it may be moving in an arc), but it should be pretty accurate. You can then estimate the portion of the timestep elapsed until collision (using the the ratio of the length of the vector just calculated and its corrected position), give it a collision impulse, and move it along its new path. Again there will be potential sticky problems with this, but I'll see how it pans out. Mike.
> However, the torsion thing >>does let me stop on hills though :-) > >The Barnard method will do that too; it will keep the SR balanced so >that the forces cancel eachother out, IIRC (a big IIRC! ;-)). > Yeah, the one paper did that, I remember. That's why I'd rather use it instead of the torsion/ring type low speed model (once you figure it out, of course ;0))
Quoted text (15 lines) >> Yikes, I don't know about getting my system to do that as it is now! :0) >>Very tough. Wouldn't even know where to start. > >Hm, if both methods are in separate functions, it would be like: >NOW: >- if v<thresHold then CalcForcesSpringModel() > else CalcForcesSR() >FUTURE: >- CalcForcesSpringModel() > SaveForces(forceInfoStructure) > CalcForcesSR() > if v<thresHold then scale=v/thresHold > else scale=1 > AverageForcesWith(forceInfoStructure,scale)
Ah, good idea :0) I do the NOW part, but hadn't though of scaling and averaging things that way. Will give it a try sometime and let you know how it works, thanks.
Quoted text (9 lines)>But I know; my system is as uncontrolled as well so I can't just plug >in an RK4 integrator or undo a physics step (as Baraff tends to do >when penetration occurs; btw I like the FastCar approach where >penetrations are resolved not by recalculating all forces with a >smaller timestep, but slightly translating all penetrating objects >along the collision normal so they don't penetrate anymore; not too >accurate but with small translations I don't think anyone'd see the >difference). >
You mentioned Baraff's stuff before. I've got the papers but don't want to look right now so I'll just ask you :0) Does he undo the whole time step and then keep readjusting it and recalculating the result until it's close enough? The FastCar approach sounds good too. I've done absolutely 0 collision detection yet, so... Will just absorb for now :-) I know I can't see any problems with FastCar's collision detection.
Quoted text (13 lines)>Lol. I checked, and it turns out I took out the slipAngle relaxation >stuff (SAE950311), but I do use it longitudinally, SR. Without the >damping though, hm?! (damping is #ifdef'd out) Amazing. >So the SR route works, somehow. The formula to discard relaxation >length is: > > if u*timeStep/B > 0.5 then SR=<direct calculation> > else <SAE950311 differential stuff> > >Where u is the wheel spin velocity, and B is the longitudinal >relaxation length. > >
Will keep that in mind. I need to get the diff code up to par, then I think it's time to tackle the tire model, finally :0) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com
On 08 Nov 2001 00:36:11 GMT, [email hidden] (J. Todd Wasson) wrote: >>The Barnard method will do that too; it will keep the SR balanced so >>that the forces cancel eachother out, IIRC (a big IIRC! ;-)). > > Yeah, the one paper did that, I remember. That's why I'd rather use it >instead of the torsion/ring type low speed model (once you figure it out, of >course ;0)) Ok. :) It shouldn't be hard to retry, but I've got my hands full on jittering tire & suspensions right now. I think I'm going to try and combine the tire rate to the wheel rate (S1*S2/(S1+S2)), that should make it much better, but I don't really know if I'll miss out on great tire rate effects. Anyway, there's a big thread on that on the Racer forum, and damn, a Champcar is really a springy thing right now. :( >> AverageForcesWith(forceInfoStructure,scale) > > Ah, good idea :0) I do the NOW part, but hadn't though of scaling and >averaging things that way. Will give it a try sometime and let you know how it >works, thanks. You're welcome. Make sure if scale=1 not to mix but to just copy ofcourse. ;-)
Quoted text (13 lines)>>But I know; my system is as uncontrolled as well so I can't just plug >>in an RK4 integrator or undo a physics step (as Baraff tends to do >>when penetration occurs; btw I like the FastCar approach where >>penetrations are resolved not by recalculating all forces with a >>smaller timestep, but slightly translating all penetrating objects >>along the collision normal so they don't penetrate anymore; not too >>accurate but with small translations I don't think anyone'd see the >>difference). >> > > You mentioned Baraff's stuff before. I've got the papers but don't want to >look right now so I'll just ask you :0) Does he undo the whole time step and >then keep readjusting it and recalculating the result until it's close enough?
Yes, he does. Like a binary search for the time. Start with t+dt, if penetration exists, undo all and try t+0.5*dt and binary searching on and on. Ofcourse, you could do things more intelligently and check the distance of the penetrating objects at time t, then at time t+dt, then weigh that to come up with a much better try. > The FastCar approach sounds good too. I've done absolutely 0 collision >detection yet, so... Will just absorb for now :-) I know I can't see any >problems with FastCar's collision detection. Yes, I'll run the 1000 cars demo again (which btw only has 100 cars?!). The problem I think is with lots of stacked objects (in FastCar). Baraff wrote a SIG paper in '94, which includes a new method to calculate restraint forces, saying it is much simpler and easier to implement. But ofcourse I'm stuck at page 3 already. ;-) All these 'A is semi-posi-definite?!' things, man, I need a linear algebra book. Too bad no code was included. It seems to improve on his original papers, Unconstrained Rigid Body Dynamics and the Constrained (part II) followup, where quadratic programming is used. The '94 method seems to use a similar method to FastCar's, but only wrt forces, where FastCar uses translation.
Quoted text (8 lines)>> if u*timeStep/B > 0.5 then SR=<direct calculation> >> else <SAE950311 differential stuff> >> >>Where u is the wheel spin velocity, and B is the longitudinal >>relaxation length. > > Will keep that in mind. I need to get the diff code up to par, then I think >it's time to tackle the tire model, finally :0)
Wow, finally. :) And note that 'u' wasn't wheel spin velocity, but the translational velocity, as Gregor corrected me. Read his post, it will have the definite correct terms. ;-) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

Sponsors

Affiliate Links

Sim Gaming Expo MOZA Racing Sim-Lab Fanatec TrakRacer Asetek Internet Privacy From NordVPN Dreamhost Capital One Credit Card Application Fanatical CDKeys Amazon Amazon UK Project Motor Racing iRacing Get your racing gloves, boots and more from Demon Tweeks. Enlist at Roberts Space Industries, developers of Star Citizen and Squadron 42


Back from the ashes since July, 2019. First created in 2001 with the merger of Legends Central (founded 1999) and simracing.dk.

A site by a sort of sim racer, for sim racers, about racing sims. News and information on both modern and historic sim racing software titles.

All products and licenses property of their respective owners.


Facebook Threads Bluesky Twitter Mastodon Instagram YouTube Tiktok Twitch Reddit Google News Apple News Subscribe via WordPress Flipboard eBay

Race Sim Central © 1999-2026 | Some links pay RSC a commission. Advertising does not equal endorsement.Cookie Policy