Car physics - anti-dive and out/inboard brakes

Hi there, I'm a little confused in implementing anti-pitch/drive/squat. The problem I have currently is that braking the Ferrari in Racer makes it spin almost always; it's too hard to handle. I believe this is because of the lack of anti-* modeling in my physics model. If it helps, I'm reading RCVD on pages 617-619 (suspension geometry). First of all, I see anti-lift, anti-drive and anti-squat. It seems to me like anti-squat is the same as anti-lift, only at the rear wheels, right? 2nd, RCVD talks about inboard and outboard brakes. The result is that the angles that are used in %anti-x calculates are based on the height of the instant center from either the ground, or from the center height of the wheel. What is the difference between the 2 types of brakes, and what type is typically used? (in for example F1 and Sports Cars) If I'm correct, the torque around the center of gravity (My in SAE terms) that pitches the car is calculated by applying the road force through or torque arm that goes from the CG height to the (sideview) instant center height. Right? In other words, the closer the instant center's height comes to the center of gravity height, the less pitch moment you will get (when accelerating/braking). 3rd, there are 2 approaches to handling anti-lift/dive that I consider: 1 is applying the force (Fx) of the tire to the torque arm as describe above. The other one is, if you know the suspension's anti-lift percentage, is to just calculate a torque from the arm of tire patch (or wheel center height) to CG height, and instead of applying that, I apply only AntiLiftPercentage*ThatTorque to the actual torque around the CG. That *is* the meaning of the percentage, in a way, right? I think, at this time, specifying the instant centers of the suspensions (side and front view) is the way to go, and that calculating the resulting torques will effectively do, without the explicit need for an anti-dive/lift/squat number. (it's all done using the side view instant center's height) As a last thing I don't quite follow, is the statement on page 617, which says: "Suspension anti's do not change the steady-state load transfer at the tire patch." It seems to me though that by having the car pitch less when having anti-dive, this results in less weight being put on the front wheels and more left for the rears. The problem in Racer is namely that when braking, all weight is shifted forwards, so the rear wheels give no stabilizing force (as the carry nearly 0% weight while braking). I also btw have to do a quick brake-balance parameter, set to the front by 58% for example (it's now fixed at 50%/50% front/rear), but I don't think that ultimately decides that my car spins when braking hard. Ofcourse, there's always jacking and scrubbing still, but I have a hunch that their effect is mostly of a 2nd order degree. Thanks for any clarifications, Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

Hi Ruud, sorry I can't help with the anti-dive problem, but I found some other things you might want to know about Racer v0.39.1, which I just tried tonight.... hope this helps! 1. the "bouncing thing" - I know you know about this one already, but I just thought I'd remind you :p 2. the dials - your revcounter and speedo look really good. Really *really* good. The nicest instruments I've ever seen in a driving game. Nice one! :0) 3. Start menu shortcuts: the reason all six of these don't work is that they point to, e.g: "C:\SIMS\racer.exe" rather than "C:\SIMS\Racer\racer.exe". An easy one to fix I should think! The "Start In" directories are all correct, just the target paths are wrong. I'm on Win98 by the way. 4. In "env.ini" there's a discussion of drag due to air - the simple formula I used at university when some "near enough" numbers were needed was Drag = 0.5 * CD * RHO * A * (V*V) CD is the drag coefficient, which is around 0.25 to 0.4 for a road-going saloon car [note that race cars tend to have slightly higher CDs as wings etc sacrifice "slipperiness" for downforce, sorry but I can't find any example numbers for race cars]. RHO is the density of air, which is taken to be 1.29 kg per m^3 at standard temp and pressure. A is frontal cross-sectional area. V is velocity relative to air. 5. I get a file called "QLOG.txt" in the Racer directory, which is 30k in size and consists of many many lines (at least 50, probably more) such as: Wed Mar 07 22:20:45 (WARN) : [racer/-211417] Can't load material texture image 'images/POSTA.BMP' I also get "Wed Mar 07 22:21:05 (WARN) : [racer/-211417] Can't import 'wheel.dof'" and then finally my sidewinder wheel is detected OK. I'll mail you this text file separately if you want it, incidentally the only file in my data/images/ directory is "racer512.tga". That's all I can think of at the moment, keep at it Ruud because I think you're doing a real nice job of things there! Hope this helps, Jim "Ruud van Gaal" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (66 lines)

> Hi there, > > I'm a little confused in implementing anti-pitch/drive/squat. The > problem I have currently is that braking the Ferrari in Racer makes it > spin almost always; it's too hard to handle. I believe this is because > of the lack of anti-* modeling in my physics model. > If it helps, I'm reading RCVD on pages 617-619 (suspension geometry). > > First of all, I see anti-lift, anti-drive and anti-squat. It seems to > me like anti-squat is the same as anti-lift, only at the rear wheels, > right? > > 2nd, RCVD talks about inboard and outboard brakes. The result is that > the angles that are used in %anti-x calculates are based on the height > of the instant center from either the ground, or from the center > height of the wheel. What is the difference between the 2 types of > brakes, and what type is typically used? (in for example F1 and Sports > Cars) > > If I'm correct, the torque around the center of gravity (My in SAE > terms) that pitches the car is calculated by applying the road force > through or torque arm that goes from the CG height to the (sideview) > instant center height. Right? > In other words, the closer the instant center's height comes to the > center of gravity height, the less pitch moment you will get (when > accelerating/braking). > > 3rd, there are 2 approaches to handling anti-lift/dive that I > consider: 1 is applying the force (Fx) of the tire to the torque arm > as describe above. > The other one is, if you know the suspension's anti-lift percentage, > is to just calculate a torque from the arm of tire patch (or wheel > center height) to CG height, and instead of applying that, I apply > only AntiLiftPercentage*ThatTorque to the actual torque around the CG. > That *is* the meaning of the percentage, in a way, right? > > I think, at this time, specifying the instant centers of the > suspensions (side and front view) is the way to go, and that > calculating the resulting torques will effectively do, without the > explicit need for an anti-dive/lift/squat number. (it's all done using > the side view instant center's height) > > As a last thing I don't quite follow, is the statement on page 617, > which says: > "Suspension anti's do not change the steady-state load transfer at the > tire patch." > > It seems to me though that by having the car pitch less when having > anti-dive, this results in less weight being put on the front wheels > and more left for the rears. > The problem in Racer is namely that when braking, all weight is > shifted forwards, so the rear wheels give no stabilizing force (as the > carry nearly 0% weight while braking). > I also btw have to do a quick brake-balance parameter, set to the > front by 58% for example (it's now fixed at 50%/50% front/rear), but I > don't think that ultimately decides that my car spins when braking > hard. > > Ofcourse, there's always jacking and scrubbing still, but I have a > hunch that their effect is mostly of a 2nd order degree. > > Thanks for any clarifications, > > Ruud van Gaal, GPL Rank +53.25 > Pencil art : http://www.marketgraph.nl/gallery/ > Car simulation: http://www.marketgraph.nl/gallery/racer/

sorry forgot one - when I press escape to quit Racer I'm returned to my desktop with commendable speed :) Unfortunately my original resolution and colour depth doesn't get restored and I have to do it myself in Display Properties..... that's it, good luck with it Ruud! Jim "Jim L" <[email hidden]> wrote in message news:hgzp6.3023$[email hidden]... > Hi Ruud, sorry I can't help with the anti-dive problem, but I found some > other things you might want to know about Racer v0.39.1, which I justtried > tonight.... hope this helps! > > 1. the "bouncing thing" - I know you know about this one already, but Ijust > thought I'd remind you :p > > 2. the dials - your revcounter and speedo look really good. Really*really* > good. The nicest instruments I've ever seen in a driving game. Nice one!:0) > > 3. Start menu shortcuts: the reason all six of these don't work is thatthey > point to, e.g: > "C:\SIMS\racer.exe" rather than "C:\SIMS\Racer\racer.exe". An easy one to > fix I should think! The "Start In" directories are all correct, just the > target paths are wrong. I'm on Win98 by the way. > > 4. In "env.ini" there's a discussion of drag due to air - the simpleformula > I used at university when some "near enough" numbers were needed was Drag=

Quoted text (8 lines)

> 0.5 * CD * RHO * A * (V*V) > > CD is the drag coefficient, which is around 0.25 to 0.4 for a road-going > saloon car [note that race cars tend to have slightly higher CDs as wings > etc sacrifice "slipperiness" for downforce, sorry but I can't find any > example numbers for race cars]. > > RHO is the density of air, which is taken to be 1.29 kg per m^3 at

standard

Quoted text (12 lines)

> temp and pressure. > A is frontal cross-sectional area. > V is velocity relative to air. > > 5. I get a file called "QLOG.txt" in the Racer directory, which is 30k in > size and consists of many many lines (at least 50, probably more) such as: > > Wed Mar 07 22:20:45 (WARN) : [racer/-211417] Can't load material texture > image 'images/POSTA.BMP' > > I also get "Wed Mar 07 22:21:05 (WARN) : [racer/-211417] Can't import > 'wheel.dof'" and then finally my sidewinder wheel is detected OK. I'll

mail > you this text file separately if you want it, incidentally the only filein

Quoted text (82 lines)

> my data/images/ directory is "racer512.tga". > > That's all I can think of at the moment, keep at it Ruud because I think > you're doing a real nice job of things there! > > Hope this helps, > > Jim > > > > > "Ruud van Gaal" <[email hidden]> wrote in message > news:[email hidden]... > > Hi there, > > > > I'm a little confused in implementing anti-pitch/drive/squat. The > > problem I have currently is that braking the Ferrari in Racer makes it > > spin almost always; it's too hard to handle. I believe this is because > > of the lack of anti-* modeling in my physics model. > > If it helps, I'm reading RCVD on pages 617-619 (suspension geometry). > > > > First of all, I see anti-lift, anti-drive and anti-squat. It seems to > > me like anti-squat is the same as anti-lift, only at the rear wheels, > > right? > > > > 2nd, RCVD talks about inboard and outboard brakes. The result is that > > the angles that are used in %anti-x calculates are based on the height > > of the instant center from either the ground, or from the center > > height of the wheel. What is the difference between the 2 types of > > brakes, and what type is typically used? (in for example F1 and Sports > > Cars) > > > > If I'm correct, the torque around the center of gravity (My in SAE > > terms) that pitches the car is calculated by applying the road force > > through or torque arm that goes from the CG height to the (sideview) > > instant center height. Right? > > In other words, the closer the instant center's height comes to the > > center of gravity height, the less pitch moment you will get (when > > accelerating/braking). > > > > 3rd, there are 2 approaches to handling anti-lift/dive that I > > consider: 1 is applying the force (Fx) of the tire to the torque arm > > as describe above. > > The other one is, if you know the suspension's anti-lift percentage, > > is to just calculate a torque from the arm of tire patch (or wheel > > center height) to CG height, and instead of applying that, I apply > > only AntiLiftPercentage*ThatTorque to the actual torque around the CG. > > That *is* the meaning of the percentage, in a way, right? > > > > I think, at this time, specifying the instant centers of the > > suspensions (side and front view) is the way to go, and that > > calculating the resulting torques will effectively do, without the > > explicit need for an anti-dive/lift/squat number. (it's all done using > > the side view instant center's height) > > > > As a last thing I don't quite follow, is the statement on page 617, > > which says: > > "Suspension anti's do not change the steady-state load transfer at the > > tire patch." > > > > It seems to me though that by having the car pitch less when having > > anti-dive, this results in less weight being put on the front wheels > > and more left for the rears. > > The problem in Racer is namely that when braking, all weight is > > shifted forwards, so the rear wheels give no stabilizing force (as the > > carry nearly 0% weight while braking). > > I also btw have to do a quick brake-balance parameter, set to the > > front by 58% for example (it's now fixed at 50%/50% front/rear), but I > > don't think that ultimately decides that my car spins when braking > > hard. > > > > Ofcourse, there's always jacking and scrubbing still, but I have a > > hunch that their effect is mostly of a 2nd order degree. > > > > Thanks for any clarifications, > > > > Ruud van Gaal, GPL Rank +53.25 > > Pencil art : http://www.marketgraph.nl/gallery/ > > Car simulation: http://www.marketgraph.nl/gallery/racer/ > >

Hi Ruud, I haven't done the anti-xx suspension yet, so can't help you on the specifics there. I suspect that if you could take the tire forces and react them through the linkages themselves, all this stuff would work itself out just fine. Of course, I don't know how to do this yet, soooooo..... :0)

Quoted text (8 lines)

>As a last thing I don't quite follow, is the statement on page 617, >which says: >"Suspension anti's do not change the steady-state load transfer at the >tire patch." > >It seems to me though that by having the car pitch less when having >anti-dive, this results in less weight being put on the front wheels >and more left for the rears.

Pitch won't change total weight transfer. Anti dive/squat will, however, change the *portion* of total weight transfer, mainly, the part caused by spring compression due to pitch. A car with no suspension will still transfer the same total weight under a given acceleration. Total fore/aft weight transfer is a function of wheelbase, center of mass height, and acceleration *only.* If the torques upwards at the front and rear wheels don't equal the torque caused by longitudinal tire forces (across the ground), the car would rotate nose first into the ground under braking.

Quoted text (7 lines)

>The problem in Racer is namely that when braking, all weight is >shifted forwards, so the rear wheels give no stabilizing force (as the >carry nearly 0% weight while braking). >I also btw have to do a quick brake-balance parameter, set to the >front by 58% for example (it's now fixed at 50%/50% front/rear), but I >don't think that ultimately decides that my car spins when braking >hard.

Make sure the weight transfer is correct first, then, get that brake bias in. My model will spin around in a real hurry too if 50/50 bias is used. With the new driveline model, I can move the bias more rearward than before because it now fights driveline inertia more accurately, but 50/50 will still cause a spin in most cases. One other thing, the anti-pitch according to "Tune to Win" is usually about 0% in road race cars anyway, while usually remaining below 30% on front engine vehicles. As far as the rest goes, I'm all ears (eyes?) too :0) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Ruud van Gaal wrote: > Hi there, > > I'm a little confused in implementing anti-pitch/drive/squat. The > problem I have currently is that braking the Ferrari in Racer makes it > spin almost always; it's too hard to handle. If you are unstable in yaw, are you certain that it's not a brake bias problem? Also, even if the fronts lock prior to the rears, if your brake bias is near "optimum" (for max force) such that both fronts and rears are near locking, the fronts may be locking and then the rears also with some more brake torque. Locking the fronts first only keeps you stable if you don't continue pushing harder on the brakes and go on to also lock the rears ;) It's my feeling that in a PC sim where you can't count as much on the driver not doing something stupid (because of the reduced sensory feedback and loss of fear of death ;) that the maximum braking torque is almost as important as the brake bias. They both together determine when, which axle first, and how easy it is to lock up either or both front and rears. A real driver senses yaw acceleration when the car get's squirrely because the rears are locking or otherwise losing capability. The PC driver has to wait through 90 or 180 degrees of additional phase lag before he can sense yaw rate or yaw position disturbances. By then, it can be too late.

Quoted text (12 lines)

> I believe this is because > of the lack of anti-* modeling in my physics model. > If it helps, I'm reading RCVD on pages 617-619 (suspension geometry). > > First of all, I see anti-lift, anti-drive and anti-squat. It seems to > me like anti-squat is the same as anti-lift, only at the rear wheels, > right? > As a last thing I don't quite follow, is the statement on page 617, > which says: > "Suspension anti's do not change the steady-state load transfer at the > tire patch."

What the suspension geometry does in acceleration is transfer the forward or backward force to the sprung mass through the suspension links. If the links don't combine to "point" the total force of the links onto the sprung mass from the contact patches directly through the CG, there will be a pitching moment generated. The "Suspension anti's" change the strength of that moment and also any component of the forward/aft force that the upward pointing suspension links bring with them. (The forward or aft force (Fx) has to balance the tire forces, but because the links are inclined they also pass Fx tan(theta) upward. (Simplistically.)) Looking at it from the other direction, from sprung mass down: more anti-squat means the sprung mass pushes more directly down on the tires through the links and less through the springs. With 100% anti-squat the body doesn't pitch, and the extra force on the rear tires through longitudinal weight transfer is carried through the suspension links, not the springs. I happen to be playing around with how this affects a high acceleration drag race launch at the moment. Although anti-squat doesn't affect the static weight transfer for a steady acceleration, it does affect the timing of the weight transfer in the launch transient because the part that comes through the springs takes awhile to appear because the sprung mass has to physically move relative to the unsprunng mass to generate it and that takes a bit of time. Like the book says, however, none of this affects the overall amount of the weight transfer. (These are all internal forces within the overall multibody system. If you draw a "control volume" around the entire car, you will still have upward and longitudinal forces at the tires, and weight down, and forward/aft acceleration at the CG that all have to balance.) This is similar to how anti-roll bars don't cause more or less overall lateral weight transfer for a given acceleration. They reduce the body roll angle, but even with zero body roll, the same overall lateral weight transfer still occurs. (Because the CG is above the ground, it _has_ to. One just has to draw and ponder the free body diagram until it blurs ;) So you can include a lot of anti-dive and still unload the rear tires. The amount of anti-dive will affect the cars pitch that will affect the camber change since you will have different suspension travel, but it means you are transferring more of the weight directly through the suspension links rather than through the springs and dampers. And there was a reason you put those springs and dampers on the car ;) But, the weight is still being transferred (normal forces on the tires changing). Otherwise the car would flip end for end because the pitch moments wouldn't balance. > It seems to me though that by having the car pitch less when having > anti-dive, this results in less weight being put on the front wheels > and more left for the rears. To summarize what I reported above, and as RCVD etc. explains, this statement is incorrect. > > The problem in Racer is namely that when braking, all weight is > shifted forwards, so the rear wheels give no stabilizing force (as the > carry nearly 0% weight while braking). Move the CG down magically, or increase the wheelbase ;), or just don't brake as hard. Otherwise you will have to approach 100% front brake bias as the rears approach being entirely unloaded. And at that point, brake bias won't help anymore;) , you have lost all the stabilizing effect of the rear tires lateral force capability anyway, as you say. Do one of those plots of front brake torque on the vertical axis and rear brake torque on the lateral axis and plot the torque boundaries where the fronts and rears will lock. Gillespie discusses it in his "Fundamentals of Vehicle Dynamics" in the braking proportioning section. Be sure to include any friction or motoring torques in the analysis because if you try to put the brake bias too close, those will cause you to lock the rears if they aren't included. Also don't forget to include the effect of the longitudinal load transfer on the tire maximum friction coefficients, if you include that. Draw some lines of constant vehicle deceleration on the plot, and the straight lines that show the locus of solutions for several brake bias setttings. Then draw the plot for full and also for empty tanks. ;) If you slog through all that, you will fully understand how your car operates under braking. Running some steady deceleration tests and plotting the front and rear tire normal force fractions and comparing it to the simple longitudinal equations in Gillespie, etc., will also be a good test (essential, rather) to show that your suspension dynamics are correct. Given your CG location within the wheelbase and it's height, you can easily calculate what the weight transfer forward should be. If it doesn't do this properly, something is wrong. If the basic weight transfer isn't correct, you are wasting a lot of work on ARBs, tire models for friction coefficient change with normal force, suspension geometry and camber change, etc., etc.

Quoted text (7 lines)

> I also btw have to do a quick brake-balance parameter, set to the > front by 58% for example (it's now fixed at 50%/50% front/rear), but I > don't think that ultimately decides that my car spins when braking > hard. > > Ofcourse, there's always jacking and scrubbing still, but I have a > hunch that their effect is mostly of a 2nd order degree.

Ruud, Anti-dive/squat was tried extensively in the early '60s and basically abandoned for a reason that wasn't obvious in theory, but which became quickly onerous in practice: the more you dial in, the more it tends to lock-up the suspension. That is, if you rotate the upper A-arm pick-up points at the front, when the car pitches forward, the anti-dive stiffens up the front suspension, with an effect similar to hitting the bump rubbers. Very unpleasant. Spike outside the traction circle. Ditto the rear: apply power, and the rear end goes rigid, causing wheelspin. In those days, there was plenty of ride height and plenty of suspension travel available (like off-road racers today), so you didn't really *need* anti-dive/squat; it was better just to let the chassis pitch (and roll). Of course, with the introduction of aero, all that went out the window, and spring rates soared. --Steve Ruud van Gaal <[email hidden]> wrote in message news:[email hidden]...

Quoted text (66 lines)

> Hi there, > > I'm a little confused in implementing anti-pitch/drive/squat. The > problem I have currently is that braking the Ferrari in Racer makes it > spin almost always; it's too hard to handle. I believe this is because > of the lack of anti-* modeling in my physics model. > If it helps, I'm reading RCVD on pages 617-619 (suspension geometry). > > First of all, I see anti-lift, anti-drive and anti-squat. It seems to > me like anti-squat is the same as anti-lift, only at the rear wheels, > right? > > 2nd, RCVD talks about inboard and outboard brakes. The result is that > the angles that are used in %anti-x calculates are based on the height > of the instant center from either the ground, or from the center > height of the wheel. What is the difference between the 2 types of > brakes, and what type is typically used? (in for example F1 and Sports > Cars) > > If I'm correct, the torque around the center of gravity (My in SAE > terms) that pitches the car is calculated by applying the road force > through or torque arm that goes from the CG height to the (sideview) > instant center height. Right? > In other words, the closer the instant center's height comes to the > center of gravity height, the less pitch moment you will get (when > accelerating/braking). > > 3rd, there are 2 approaches to handling anti-lift/dive that I > consider: 1 is applying the force (Fx) of the tire to the torque arm > as describe above. > The other one is, if you know the suspension's anti-lift percentage, > is to just calculate a torque from the arm of tire patch (or wheel > center height) to CG height, and instead of applying that, I apply > only AntiLiftPercentage*ThatTorque to the actual torque around the CG. > That *is* the meaning of the percentage, in a way, right? > > I think, at this time, specifying the instant centers of the > suspensions (side and front view) is the way to go, and that > calculating the resulting torques will effectively do, without the > explicit need for an anti-dive/lift/squat number. (it's all done using > the side view instant center's height) > > As a last thing I don't quite follow, is the statement on page 617, > which says: > "Suspension anti's do not change the steady-state load transfer at the > tire patch." > > It seems to me though that by having the car pitch less when having > anti-dive, this results in less weight being put on the front wheels > and more left for the rears. > The problem in Racer is namely that when braking, all weight is > shifted forwards, so the rear wheels give no stabilizing force (as the > carry nearly 0% weight while braking). > I also btw have to do a quick brake-balance parameter, set to the > front by 58% for example (it's now fixed at 50%/50% front/rear), but I > don't think that ultimately decides that my car spins when braking > hard. > > Ofcourse, there's always jacking and scrubbing still, but I have a > hunch that their effect is mostly of a 2nd order degree. > > Thanks for any clarifications, > > Ruud van Gaal, GPL Rank +53.25 > Pencil art : http://www.marketgraph.nl/gallery/ > Car simulation: http://www.marketgraph.nl/gallery/racer/

On Thu, 8 Mar 2001, Matthew V. Jessick wrote: > Ruud van Gaal wrote: > > I'm a little confused in implementing anti-pitch/drive/squat. The > > problem I have currently is that braking the Ferrari in Racer makes it > > spin almost always; it's too hard to handle. > > If you are unstable in yaw, are you certain that it's not a brake bias Try 100% brakes on the front -- not a bad approximation for many cars. 50-50 brake distribution is a common mistake made by programmers who haven't worked on cars... (you are not the first!!) .......

Quoted text (7 lines)

> I happen to be playing around with how this affects a high acceleration > drag race launch at the moment. Although anti-squat doesn't affect the > static weight transfer for a steady acceleration, it does affect the timing > of the weight transfer in the launch transient because the part that comes > through the springs takes awhile to appear because the sprung mass has > to physically move relative to the unsprunng mass to generate it and > that takes a bit of time.

Bill Shope (one of the original Chrysler Ramchargers drag race team from the 1960's) did some nice work that models this -- the result turned into several of the problems for Chapter 17 (pages 32+) in the companion book, "RCVD Workbook" -- where there is a nice figure that defines the problem. Our next publishing project is a new version of the Workbook, _with_ _answers_...hopefully this will be out by the end of 2001. Dragster launch is not a trivial problem, but Bill worked a closed-form solution that seems to be correct, at least for the basic situation. -- Doug Douglas Milliken <[email hidden]> Milliken Research Associates Inc. PS. This should be a link to the Workbook, but this version only has the problems (and some new figures & data), not the answers! <http://www.sae.org/servlets/productDetail?PROD_TYP=BOOK&PROD_CD=R-212>

Doug Milliken wrote: > PS. This should be a link to the Workbook, but this version only has > the problems (and some new figures & data), not the answers! > <http://www.sae.org/servlets/productDetail?PROD_TYP=BOOK&PROD_CD=R-212> Thanks, I'll dig out my copy of the workbook! -- Matthew V. Jessick Motorsims [email hidden] http://www.motorsims.com Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216

On Wed, 7 Mar 2001 23:14:47 -0000, "Jim L" <[email hidden]> wrote: >Hi Ruud, sorry I can't help with the anti-dive problem, but I found some >other things you might want to know about Racer v0.39.1, which I just tried >tonight.... hope this helps! Thanks for the feedback. :) >1. the "bouncing thing" - I know you know about this one already, but I just >thought I'd remind you :p Yep, is solved. The suspension could lock when it hit the max. Corrected and now also reset with Shift-R/P as well. >2. the dials - your revcounter and speedo look really good. Really *really* >good. The nicest instruments I've ever seen in a driving game. Nice one! :0) Thanks! It's just a speedy TV-Painted dial and a lathe in Max, but it looks ok. I still find the Nascar dials nicer though. :) >3. Start menu shortcuts: the reason all six of these don't work is that they >point to, e.g: >"C:\SIMS\racer.exe" rather than "C:\SIMS\Racer\racer.exe". An easy one to >fix I should think! The "Start In" directories are all correct, just the >target paths are wrong. I'm on Win98 by the way. Ah thanks! In Win2K it worked; in my Win95 it didn't indeed. Fixed it by appending a '\' at the end of the path. Can you believe it! :) >4. In "env.ini" there's a discussion of drag due to air - the simple formula >I used at university when some "near enough" numbers were needed was Drag = >0.5 * CD * RHO * A * (V*V) Yep thanks, one of the near-future things; drag and wings. ... >RHO is the density of air, which is taken to be 1.29 kg per m^3 at standard >temp and pressure. Ah that's nice, the number in SI. :) >5. I get a file called "QLOG.txt" in the Racer directory, which is 30k in >size and consists of many many lines (at least 50, probably more) such as: > >Wed Mar 07 22:20:45 (WARN) : [racer/-211417] Can't load material texture >image 'images/POSTA.BMP' No need to worry; a lot of the BMPs are not present actually and generate these warnings. They show up as red textures in the track. >I also get "Wed Mar 07 22:21:05 (WARN) : [racer/-211417] Can't import >'wheel.dof'" and then finally my sidewinder wheel is detected OK. Phew. :) Well, wheel.dof was a model that just isn't present. I corrected it by supplying 4 wheel models. Looks much nicer now! > I'll mail >you this text file separately if you want it, incidentally the only file in >my data/images/ directory is "racer512.tga". No need to, I know the messages by heart. ;-) Proceed to the page; v0.39.2 is there NOW! (better braking too) Thanks, Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

Thanks for the feedback. :) Yep, is solved. The suspension could lock when it hit the max. Corrected and now also reset with Shift-R/P as well. Thanks! It's just a speedy TV-Painted dial and a lathe in Max, but it looks ok. I still find the Nascar dials nicer though. :) Ah thanks! In Win2K it worked; in my Win95 it didn't indeed. Fixed it by appending a '\' at the end of the path. Can you believe it! :) Yep thanks, one of the near-future things; drag and wings. ... Ah that's nice, the number in SI. :) No need to worry; a lot of the BMPs are not present actually and generate these warnings. They show up as red textures in the track. Phew. :) Well, wheel.dof was a model that just isn't present. I corrected it by supplying 4 wheel models. Looks much nicer now! No need to, I know the messages by heart. ;-) Proceed to the page; v0.39.2 is there NOW! (better braking too) Thanks, Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

On Wed, 7 Mar 2001 23:24:20 -0000, "Jim L" <[email hidden]> wrote: > >sorry forgot one - when I press escape to quit Racer I'm returned to my >desktop with commendable speed :) Unfortunately my original resolution and >colour depth doesn't get restored and I have to do it myself in Display >Properties..... Yes, sorry about that one! In Win2K this is ok. But I saw it in Win95 too. It's on the task list... Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

On 07 Mar 2001 23:33:35 GMT, [email hidden] (J. Todd Wasson) wrote: > Hi Ruud, > > I haven't done the anti-xx suspension yet, so can't help you on the specifics >there. I suspect that if you could take the tire forces and react them through >the linkages themselves, all this stuff would work itself out just fine. Of >course, I don't know how to do this yet, soooooo..... :0) It seems it's more a problem of braking torque, CG height and wheelbase. Well, wheelbase I can't adjust (otherwise the model would not look correct). I've adjusted the CG hgt and braking torque and will await messages like 'the thing hardly brakes!'. ;-) ... > One other thing, the anti-pitch according to "Tune to Win" is usually about >0% in road race cars anyway, while usually remaining below 30% on front engine >vehicles. Thanks for the explanation. I now see that anti-pitch just changes the speed/timing at which the pitching occurs, but that's it. And introduces unresponsiveness in actual cars. I'll keep it at 0 and use a percentage; it doesn't seem to be that important for the drivability. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

On Thu, 08 Mar 2001 07:34:03 GMT, "Matthew V. Jessick" <[email hidden]> wrote: ... >If you are unstable in yaw, are you certain that it's not a brake bias >problem? Also, even if the fronts lock prior to the rears, if your brake >bias >is near "optimum" (for max force) such that both fronts and rears are >near locking, the fronts may be locking and then the rears also >with some more brake torque. Now, the rears lock first (ofcourse; the front are being pushed hard). I've tried 100% front brake bias yesterday (or was it the day before?); that worked quite ok-ish as well!

Quoted text (7 lines)

>It's my feeling that in a PC sim where you can't count as much >on the driver not doing something stupid (because of the reduced >sensory feedback and loss of fear of death ;) >that the maximum braking torque is almost >as important as the brake bias. They both together determine >when, which axle first, and how easy it is to lock up either >or both front and rears.

You're absolutely right. It's better now that I've reduced braking torque. And reduced the grip coefficients of the tires from 2.4 (from the original FerP4 file) to 1.7 (more realistic, I'd say). So the brakes don't grip soooo much that you are thrown forward. On the top 10 of my task list is generating slip sounds according to slip ratio, which will make much more realistic slip volumes (it's now using slipvelocity length). ... >Like the book says, however, none of this affects the overall amount of >the weight transfer. Thanks for the elaborate reply, I think I understand things now (quickly turned it into a new release just 10 minutes ago). ... >> The problem in Racer is namely that when braking, all weight is >> shifted forwards, so the rear wheels give no stabilizing force (as the >> carry nearly 0% weight while braking). > >Move the CG down magically, or increase the wheelbase ;), >or just don't brake as hard. I did 2 of these 3. ;-) The CG is now at 35cm, which is ok. The wheelbase is locked because I have a 3D model which must fit. And I reduced braking torque. AND added a braking_factor to be able to achieve a brake balance. (I don't have a brake bias since I'm not limited to 4 wheels, but can do 2-8 wheels as well, though I never REALLY tried, so I have to keep factors apart for each wheel). ... >If you slog through all that, Phew, I'll check the g's and masses sometime when I have these nice visual feedback meters which indicate things so I don't have to do too much by hand. :) Thanks! It's great to get such good feedback, all of you. :) The result is on my site (fixed the bugs and some others) as v0.39.2. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

On Thu, 08 Mar 2001 07:34:03 GMT, "Matthew V. Jessick" ... Now, the rears lock first (ofcourse; the front are being pushed hard). I've tried 100% front brake bias yesterday (or was it the day before?); that worked quite ok-ish as well! You're absolutely right. It's better now that I've reduced braking torque. And reduced the grip coefficients of the tires from 2.4 (from the original FerP4 file) to 1.7 (more realistic, I'd say). So the brakes don't grip soooo much that you are thrown forward. On the top 10 of my task list is generating slip sounds according to slip ratio, which will make much more realistic slip volumes (it's now using slipvelocity length). ... Thanks for the elaborate reply, I think I understand things now (quickly turned it into a new release just 10 minutes ago). ... I did 2 of these 3. ;-) The CG is now at 35cm, which is ok. The wheelbase is locked because I have a 3D model which must fit. And I reduced braking torque. AND added a braking_factor to be able to achieve a brake balance. (I don't have a brake bias since I'm not limited to 4 wheels, but can do 2-8 wheels as well, though I never REALLY tried, so I have to keep factors apart for each wheel). ... Phew, I'll check the g's and masses sometime when I have these nice visual feedback meters which indicate things so I don't have to do too much by hand. :) Thanks! It's great to get such good feedback, all of you. :) The result is on my site (fixed the bugs and some others) as v0.39.2. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

On Thu, 8 Mar 2001 18:01:23 GMT, Doug Milliken <[email hidden]> wrote:

Quoted text (10 lines)

> >On Thu, 8 Mar 2001, Matthew V. Jessick wrote: >> Ruud van Gaal wrote: >> > I'm a little confused in implementing anti-pitch/drive/squat. The >> > problem I have currently is that braking the Ferrari in Racer makes it >> > spin almost always; it's too hard to handle. >> >> If you are unstable in yaw, are you certain that it's not a brake bias > >Try 100% brakes on the front -- not a bad approximation for many cars.

Really? I tried it and it worked reasonably well. :) Just seems odd since in GPL I'm used to ~52% to 58% front bias. But I must say, the rears still lock up very quickly in relation to the fronts. >50-50 brake distribution is a common mistake made by programmers who >haven't worked on cars... (you are not the first!!) Hehe, I'll bet. But it's nice to see it looks a bit covered now. ... >Our next publishing project is a new version of the Workbook, _with_ >_answers_...hopefully this will be out by the end of 2001. Dragster launch >is not a trivial problem, but Bill worked a closed-form solution that seems >to be correct, at least for the basic situation. Sounds very interesting. And if I'm not mistaken, you were working on a book with a suspension model from Olley? (lots of nice workable formula's to deal with suspensions) How's that coming along? >PS. This should be a link to the Workbook, but this version only has >the problems (and some new figures & data), not the answers! Ah, a shame. :) I have the workbook, I'll take a look at it. Thanks, Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

On Thu, 08 Mar 2001 13:24:56 GMT, "Stephen Smith" <[email hidden]> wrote: >Ruud, > >Anti-dive/squat was tried extensively in the early '60s and basically >abandoned for a reason that wasn't obvious in theory,... How great, I can actually probably leave it out and not notice too much. :) However, ofcourse, I'll put it in just for the heck of it (and for the purists and marketing). Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

Olley book is nearly ready for the editor/publisher -- the last photos just arrived and need to be worked in. I don't know how long the process will take before release. -- Doug Douglas Milliken <[email hidden]> Milliken Research Associates Inc. On Fri, 9 Mar 2001, Ruud van Gaal wrote: ....

Quoted text (23 lines)

> >Our next publishing project is a new version of the Workbook, _with_ > >_answers_...hopefully this will be out by the end of 2001. Dragster launch > >is not a trivial problem, but Bill worked a closed-form solution that seems > >to be correct, at least for the basic situation. > > Sounds very interesting. And if I'm not mistaken, you were working on > a book with a suspension model from Olley? (lots of nice workable > formula's to deal with suspensions) > How's that coming along? > > >PS. This should be a link to the Workbook, but this version only has > >the problems (and some new figures & data), not the answers! > > Ah, a shame. :) > I have the workbook, I'll take a look at it. > > Thanks, > > Ruud van Gaal, GPL Rank +53.25 > Pencil art : http://www.marketgraph.nl/gallery/ > Car simulation: http://www.marketgraph.nl/gallery/racer/ > >

>You're absolutely right. It's better now that I've reduced braking >torque. And reduced the grip coefficients of the tires from 2.4 (from >the original FerP4 file) to 1.7 (more realistic, I'd say). I hope you won't mind me picking on the numbers a bit here :0) Some Nascar slick data shows a grip coefficient of about 1.2 at typical loads. Decent street tires run around .75-.85, with some good performance street tires up around 1-1.1 or so. 1.7 would be on par with a lightly loaded F-1 or Indycar tire probably (as you know from RCVD), still way too high for a Ferrari IMO, but fun to drive anyway I'm sure. When you get into numbers like 2.5 and up, you're into 10 inch drag racing slicks (they don't work laterally that well though, I don't think.) >The CG is now at 35cm, which is ok. My guess for a Ferrari like this would be 45-55 cm. Just for comparison, I'm testing mostly with a 1590 Kg (3500 lb) car, with approximately 60 cm center of mass height (depending on spring rate and travel), and use front max brake torque of about 1600 N*m (each tire) and rear max at about 1000 N*m (about 60/40% f/r split) This is with the new driveline model (locked diff, but it's working with a simulated clutch now, yipee!) so the rear settings might be too high if driveline inertia isn't included. These brake torques increase linearly from 0 to their respective max as brake input is increased. Tires are usually 1.2 coefficient front and rear, although sometimes I drop the front to 1.1 or so. This lets the car brake hard at about 1.2g, locking the fronts at the limit. Have to still be a bit careful not to spin, but it's manageble. Anyway, it's some data you might have fun with :0P Of course, since you just released v0.39.2, maybe this is too late :-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Ruud van Gaal wrote: > Thanks for the explanation. I now see that anti-pitch just changes the > speed/timing at which the pitching occurs, but that's it. The anti-squat and anti-dive will indeed reduce the pitching. They don't reduce the weight transfer though, as has been discussed. Because those suspension geometries transfer more of the weight through the links bypassing the springs, the more anti- you have, the less the sprung mass moves relative to the unsprung mass. The springs compress less, but the weight (tire normal forces) is still transferred, just in greater proportion through the suspension links than through the springs. - Matt

On Sat, 10 Mar 2001 08:57:48 GMT, "Matthew V. Jessick" <[email hidden]> wrote:

Quoted text (9 lines)

> > >Ruud van Gaal wrote: > >> Thanks for the explanation. I now see that anti-pitch just changes the >> speed/timing at which the pitching occurs, but that's it. > >The anti-squat and anti-dive will indeed reduce the pitching. >They don't reduce the weight transfer though, as has been discussed.

Ah yes, so still nice to build in for the view, but I originally thought it was the problem of my loose car. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

On 10 Mar 2001 05:38:19 GMT, [email hidden] (J. Todd Wasson) wrote: >>torque. And reduced the grip coefficients of the tires from 2.4 (from >>the original FerP4 file) to 1.7 (more realistic, I'd say). > > I hope you won't mind me picking on the numbers a bit here :0) Well you little... oh ok then. Let's see. ;-) > Some Nascar >slick data shows a grip coefficient of about 1.2 at typical loads. Decent >street tires run around .75-.85, with some good performance street tires up >around 1-1.1 or so. 1.7 would be on par with a lightly loaded F-1 or Indycar >tire probably (as you know from RCVD), still way too high for a Ferrari IMO, >but fun to drive anyway I'm sure. Yes, probably. But as you explained with the F12K numbers (which start at 2.4 or something!) it might be the friction at 0 load, and you need to take the load sensitivity into account. I just moved up to Pacejka yesterday, and say these striking numbers: b1=0, b2=1688 for a typical Ferrari-like car b1=-7.6118, b2=1122.6 for a typical large front-wheel drive saloon car. Now when you look at the formula you see D=uP*Fz. And uP=b1*Fz+b2. D, as you probably know, is somewhat like the maximum force that the tire can generate (in the longitudinal direction). So, together with the greek character, it seems that uP *is* the friction coefficient. Strange that with the sport car, b1=0 so no loading sensitivy is stated. -7.6 looks way too high on the other hand, but Pacejka fools around with units a lot, unfortunately making things less clear by doing that (angles in degrees, Fz in kN). So they set the friction coefficient at ~1.7 for the sport car still. Weird. BTW IIRC Ashley had a problem with 180N sideforce at 0 slip angle. It doesn't seem I get this problem though. Will have to dig through my archives to find it again. Perhaps a problem of mixing radians and degrees. >>The CG is now at 35cm, which is ok. > > My guess for a Ferrari like this would be 45-55 cm. Right, the Genta book states a typical value of 42 cm. I'm using that now, including a weight of ~1500kg etc. ... >mass height (depending on spring rate and travel), and use front max brake >torque of about 1600 N*m (each tire) and rear max at about 1000 N*m (about >60/40% f/r split) Ah, interesting, as I'm searching for nice numbers like this because the car's still a bit loose (would you believe the Fx numbers from the original curves and Pacejka were only off about 10% or so!). > This is with the new driveline model (locked diff, but it's >working with a simulated clutch now, yipee!) so the rear settings might be too >high if driveline inertia isn't included. I don't have the driveline inertia yet. Will have to, or use near-100% front brake bias for now! ;-) > Of course, since you just released v0.39.2, maybe this is too late :-) Doesn't seem like it. :) It's nice, a have a very small but cute track which has a bridge. Also got it to work yesterday so I can drive both under and on the bridge. Cool! Suzuka here we come. ;-) Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/