Car physics: weight transfer exactly 50/50?

Hi all, I'm going through some extensive testing of the weight transfer in my vehicle model. I'm finding that when the car accelerates, the weight transfer (frontload vs. rearload) isn't exactly split in half. So for example (with a 50/50 weight balanced car): acc=0.5g weight difference in front: -250N weight difference in rear: 220N theoretical weight difference front: -230N theoretical weight difference rear: 230N Fx on rear wheels: 1400N Fx on front wheels: -100N CG height: about 0.2m Note that this gives a perceived weight change of (-250+220)=-30N, meaning the car gets 30N lighter. I have an idea that since the car is pitching, there is a force (Fx*sin(pitchAngle), where Fx=driving force on rear wheels) that is pushing the car up a bit. This would result in the slightly lighter car. I'm applying the Fx (road reaction forces) of the wheels at the car's side instant center, which currently is conveniently constant. The car's weight balance is 50/50, no jacking forces or anything to complicate things. Could the perceived lift be what is happening due to the pitch angle? Or will the Fx's from the wheels be reduced as viewed from the side view instant center? (Fx_ic=Fx*cos(pitchAngle)). If so, where does the other part of Fx go? (Fx*sin(pitchAngle)) Just wondering whether the car will lift indeed a bit when it has a pitching angle (AND is accelerating). Thanks, Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

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

Quoted text (42 lines)

> Hi all, > > I'm going through some extensive testing of the weight transfer in my > vehicle model. I'm finding that when the car accelerates, the weight > transfer (frontload vs. rearload) isn't exactly split in half. > > So for example (with a 50/50 weight balanced car): > acc=0.5g > weight difference in front: -250N > weight difference in rear: 220N > theoretical weight difference front: -230N > theoretical weight difference rear: 230N > Fx on rear wheels: 1400N > Fx on front wheels: -100N > CG height: about 0.2m > > Note that this gives a perceived weight change of (-250+220)=-30N, > meaning the car gets 30N lighter. > > I have an idea that since the car is pitching, there is a force > (Fx*sin(pitchAngle), where Fx=driving force on rear wheels) that is > pushing the car up a bit. This would result in the slightly lighter > car. > > I'm applying the Fx (road reaction forces) of the wheels at the car's > side instant center, which currently is conveniently constant. The > car's weight balance is 50/50, no jacking forces or anything to > complicate things. > > Could the perceived lift be what is happening due to the pitch angle? > Or will the Fx's from the wheels be reduced as viewed from the side > view instant center? (Fx_ic=Fx*cos(pitchAngle)). If so, where does the > other part of Fx go? (Fx*sin(pitchAngle)) > > Just wondering whether the car will lift indeed a bit when it has a > pitching angle (AND is accelerating). > > Thanks, > > Ruud van Gaal > Free car sim: http://www.racer.nl/ > Pencil art : http://www.marketgraph.nl/gallery/

I'm largely ignorant about physics, but isn't this line of thought proved by vehicles doing wheelies? Seems to me that if the increased weight on the rear matched the reduced weight on the front, all the wheels would stay on the ground. For a vehicle to lift from a flat surface, the sum of the weight on the four wheels would have to be less than the vehicle weight. Back to my cave... SB

Actually it would be the opposite. In order to do a wheelie the car's CG has to move upward, which is a vertical acceleration, which would increase the apparent weight of the car until it reached it's maximum upward velocity, after which the weight would decrease. "Steve Blankenship" <[email hidden]> wrote in message news:[email hidden]... > I'm largely ignorant about physics, but isn't this line of thought provedby

Quoted text (10 lines)

> vehicles doing wheelies? Seems to me that if the increased weight on the > rear matched the reduced weight on the front, all the wheels would stay on > the ground. For a vehicle to lift from a flat surface, the sum of the > weight on the four wheels would have to be less than the vehicle weight. > > Back to my cave... > > SB > >

Ruud, Are your tire forces projected onto the surface or do they operate in vehicle coords? There should not be a vertical component to the longitudinal force at all if you temporarily get rid of the anti-squat/dive jacking forces. The forward force on the tire is local to the tire/road local coordinate system, not the car's. If you're getting this as a function of pitch (try softer springs and see if it increases the effect) than perhaps the tire forces aren't being projected to the ground plane, but instead act along the car's forward vector. Otherwise it might be from anti-squat. In that case, yes, the CG should rise under acceleration if the side view instant center is above ground level. I'm not sure if that would directly equate to a variation from the theoretical weight transfer calculation or not off the top of my head. > >Just wondering whether the car will lift indeed a bit when it has a >pitching angle (AND is accelerating). > If it's from anti-squat, then this shouldn't be related to pitch unless the side view instant center moves with pitch (yours are fixed, right?). With your approach, make sure the jacking force is applied along the surface normal, not the vertical axis of the car. The quickest way to get at this would be to disable anti-effects entirely. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

Did I say largely ignorant? I meant to say Largely Ignorant... ;-) "Haqsau" <[email hidden]> wrote in message news:b3jpi4$1nqr26$[email hidden]...

Quoted text (9 lines)

> Actually it would be the opposite. In order to do a wheelie the car's CG > has to move upward, which is a vertical acceleration, which would increase > the apparent weight of the car until it reached it's maximum upward > velocity, after which the weight would decrease. > > "Steve Blankenship" <[email hidden]> wrote in message > news:[email hidden]... > > > I'm largely ignorant about physics, but isn't this line of thought

proved > by > > vehicles doing wheelies? Seems to me that if the increased weight onthe > > rear matched the reduced weight on the front, all the wheels would stayon

Quoted text (10 lines)

> > the ground. For a vehicle to lift from a flat surface, the sum of the > > weight on the four wheels would have to be less than the vehicle weight. > > > > Back to my cave... > > > > SB > > > > > >

On 27 Feb 2003 05:20:09 GMT, [email hidden] (J. Todd Wasson) wrote: >Are your tire forces projected onto the surface or do they operate in vehicle >coords? They're in vehicle coordinates.

Quoted text (8 lines)

>There should not be a vertical component to the longitudinal force at all if >you temporarily get rid of the anti-squat/dive jacking forces. The forward >force on the tire is local to the tire/road local coordinate system, not the >car's. > >If you're getting this as a function of pitch (try softer springs and see if it >increases the effect) than perhaps the tire forces aren't being projected to >the ground plane, but instead act along the car's forward vector.

I think that's the problem; I do indeed apply Fx directly, without any projecting/rotating. So probably after calculating Fx (long. force) for a tire, I'll have to project it on the car forward vector then; anyway to this this quickly? My first though would be to: - assuming car_forward_vector is normalized; can be taken directly from its rotation matrix - make a vector v that is Fx*(car_forward_vector) - project v onto a (flat) surface: y=0, so v'=(v.x,0,v.z) - find the projected Fx_body using: Fx_body=v' dot car_forward_vector This only works for a flat underlying road; any ideas on a quick and always-working projection? Lastly; with a pitched car, Fx as acting on the body then gets reduced (Fx_body=Fx*cos(pitch)), but what happens then with the other part (that just got cut off from Fx)? What does it act on? >>Just wondering whether the car will lift indeed a bit when it has a >>pitching angle (AND is accelerating). > >If it's from anti-squat, then this shouldn't be related to pitch unless the >side view instant center moves with pitch (yours are fixed, right?). Mine are fixed still, right. I was not clear probably; my 'perceived mass' reduces (the sum of the wheel loads gets smaller than the weight of the car itself; this in a steady state acceleration). Like the car is pushed upwards and therefore appears to lose weight when you look at the wheel loads. >With your approach, make sure the jacking force is applied along the surface >normal, not the vertical axis of the car. Also a nice one. :) Thanks, Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

Quoted text (30 lines)

> >>Are your tire forces projected onto the surface or do they operate in >vehicle >>coords? > >They're in vehicle coordinates. > >>There should not be a vertical component to the longitudinal force at all if >>you temporarily get rid of the anti-squat/dive jacking forces. The forward >>force on the tire is local to the tire/road local coordinate system, not the >>car's. >> >>If you're getting this as a function of pitch (try softer springs and see if >it >>increases the effect) than perhaps the tire forces aren't being projected to >>the ground plane, but instead act along the car's forward vector. > >I think that's the problem; I do indeed apply Fx directly, without any >projecting/rotating. So probably after calculating Fx (long. force) >for a tire, I'll have to project it on the car forward vector then; >anyway to this this quickly? >My first though would be to: >- assuming car_forward_vector is normalized; can be taken directly > from its rotation matrix >- make a vector v that is Fx*(car_forward_vector) >- project v onto a (flat) surface: y=0, so v'=(v.x,0,v.z) >- find the projected Fx_body using: Fx_body=v' dot car_forward_vector > >This only works for a flat underlying road; any ideas on a quick and >always-working projection?

At one time I did it similar to how you're describing (using the car forward vector). Now, however, I ignore the car vectors entirely when working with the tires. Note that if you're doing this with longitudinal forces, chances are the same thing is happening laterally as well (roll angle is probably effecting both total cornering force as well as artificially lifting the car and lowering its weight.) I now do a cross product op with the tire side vector and the track surface normal vector. That gives the forward vector of the tire projected onto the surface (this is the direction the longitudinal force acts in Pacejka). Then I cross that forward vector with the surface normal to get the side vector as it is projected onto the plane. You now have two new tire vectors: 1) Side vector projected to plane 2) Forward vector projected to plane This is nice because it might get rid of one of Racer's camber bugs, among other problems. I'm pretty sure camber will be messing things up the same way, but rotated 90 degrees. Make sure you're calculating slip angle using the velocity vector of the tire projected onto the surface the same way with a dot product between vector (1) and the projected velocity vector. The idea here is to look at all this in the road triangle's local coordinate system, hence all the projections. Slip ratio should be calculated in a similar fashion. Next, run through Pacejka's tire model to get Fx and Fy using slip angle and ratio, then multiply those forces by vectors (1) and (2) above. That will give two forces at each tire in world coordinates. To make things easy, add the two forces together to get one resultant force. Add this resultant force to the car in world coordinates, and voila. The problem should go away. After all that, you could check to see if things are working. In the absence of camber effects in Pacejka, the car should corner at the same lateral acceleration (producing the same tire forces) regardless of the body's roll angle, and of course the car should not lose or gain any weight in the process. I had this problem too and it was a bugger to figure out :-) The same thing can be done in the fore/aft direction of course. >Lastly; with a pitched car, Fx as acting on the body then gets reduced >(Fx_body=Fx*cos(pitch)), but what happens then with the other part >(that just got cut off from Fx)? What does it act on? > Don't do that :-) If you do you will reduce the forward force acting on the car while eliminating the vertical component (cos(pitch) < 1 most of the time). The car will stop losing weight, but now it will accelerate differently depending on pitch angle. Instead, it's best to convert forces into their components or resultants in whatever coordinate system you want and use them directly.

Quoted text (12 lines)

>>>Just wondering whether the car will lift indeed a bit when it has a >>>pitching angle (AND is accelerating). >> >>If it's from anti-squat, then this shouldn't be related to pitch unless the >>side view instant center moves with pitch (yours are fixed, right?). > >Mine are fixed still, right. I was not clear probably; my 'perceived >mass' reduces (the sum of the wheel loads gets smaller than the weight >of the car itself; this in a steady state acceleration). Like the car >is pushed upwards and therefore appears to lose weight when you look >at the wheel loads. >

Oh, ok. I see what you mean. You might still want to take a closer look at your anti stuff too because it's very likely that a similar problem exists there, even though it might be covered up at the moment by the other. Your jacking forces should be determined by the angle between the IC and contact patch (or wheel center for whichever brake that is) and the triangle surface normal (minus 90 degrees so it's really the angle between the road and the IC). The jacking force can then be applied along the triangle normal. My gut tells me this isn't quite how it works in Racer, so you'll start to see similar problems pop up later. Todd Wasson Racing Software http://PerformanceSimulations.com My car sim http://performancesimulations.com/scnshot4.htm

On 02 Mar 2003 23:12:53 GMT, [email hidden] (J. Todd Wasson) wrote: ...

Quoted text (9 lines)

>I now do a cross product op with the tire side vector and the >track surface normal vector. That gives the forward vector of the tire >projected onto the surface (this is the direction the longitudinal force acts >in Pacejka). Then I cross that forward vector with the surface normal to get >the side vector as it is projected onto the plane. You now have two new tire >vectors: > >1) Side vector projected to plane >2) Forward vector projected to plane

Hm, interesting. Thanks Todd. Actually I'm testing even without Fx/Fy forces now, to check out the weight balancing at a standstill (which is still a bit off). I thought of the fact today that my wheels have mass; that may introduce some rotated (jacking-like) forces as well. Although tests follow-up quickly, a 40%-60% car didn't really come out as such in a standstill. First it started to roll by itself due to wrongly pointed forces (at a wgt% of about 40.9% at front), then after adding forces along the surface normal the car would stand still, but the WT got worse (41.1%). Still lots of drawings to make... :) However, it's already a lot better; it just takes so much time and looking at numbers to get it right. Wish the weekend had about 10 days. ;-) >This is nice because it might get rid of one of Racer's camber bugs, among >other problems. Which bug are you referring to here? Ok, on to more general vectorized application of the forces then! Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

>However, it's already a lot >better; it just takes so much time and looking at numbers to get it >right. Wish the weekend had about 10 days. ;-) > I feel ya ;-) >>This is nice because it might get rid of one of Racer's camber bugs, among >>other problems. > >Which bug are you referring to here? From reading the forum, I was under the impression folks were having strange results when using camber. I'm not referring to anything specific and haven't experienced it myself of course. Todd Wasson Racing Software http://PerformanceSimulations.com My car sim http://performancesimulations.com/scnshot4.htm

On 05 Mar 2003 00:29:18 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (8 lines)

>>>This is nice because it might get rid of one of Racer's camber bugs, among >>>other problems. >> >>Which bug are you referring to here? > >From reading the forum, I was under the impression folks were having strange >results when using camber. I'm not referring to anything specific and haven't >experienced it myself of course.

Ah yes; might be caused because some Pacejka sets use varying coordinate systems (not SAE, but TNO or some other mystical 'looks-better-in-a-picture' system), so I'm told. So the need for a coefficient check is definitely in order; checking whether camber thrust points in the right direction (and warning/correcting if not). The camber angles actually seems ok from the looks of it. About the weight transfer; it's much better now, and I'm close to getting it all fixed. A reason for trouble was the mass of the wheels; my 'theoretical weight transfer' was calculated using the sum of the sprung and unsprung mass. I shouldn't have included the wheels in weight transfer formula though (W_front=W_total*b/L), but instead taken it apart: W_front=W_sprung*b/L+W_frontwheels. This actually resulted in the 'Actual weight transfer' (wheel loads as they come out of the sim) figures I saw were really close to what it should be (good news). There are some fine bits now; the wheel load pointing up is currently used as-is as the wheel vertical force. Which isn't correct; I now will decompose the Fz (wheel load) force into the force which points along the vertical direction (my springs are all vertical), as F_vertical=Fz dot carUpVector, and then leave Fz-F_vertical as a remaing force which acts directly on the chassis (not unlike jacking forces). Only now I see why most of you use massless wheels. :) Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

On 02 Mar 2003 23:12:53 GMT, [email hidden] (J. Todd Wasson) wrote: ...

Quoted text (14 lines)

>At one time I did it similar to how you're describing (using the car forward >vector). Now, however, I ignore the car vectors entirely when working with the >tires. Note that if you're doing this with longitudinal forces, chances are >the same thing is happening laterally as well (roll angle is probably effecting >both total cornering force as well as artificially lifting the car and lowering >its weight.) I now do a cross product op with the tire side vector and the >track surface normal vector. That gives the forward vector of the tire >projected onto the surface (this is the direction the longitudinal force acts >in Pacejka). Then I cross that forward vector with the surface normal to get >the side vector as it is projected onto the plane. You now have two new tire >vectors: > >1) Side vector projected to plane >2) Forward vector projected to plane

As a sidenote, even though this method gives you the forward vector, a direct projection onto the plane might work too (and be faster?): - the plane is described by: n.x*x+n.y*y+n.z*z+d=0, where n=surface normal - to project the sidevector you can just do: d=v dot n v_projected = v-d*n Haven't tested this in practice, but if you don't use the forward vector, you could use this. If you don't already. ;-) Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

Quoted text (12 lines)

> >As a sidenote, even though this method gives you the forward vector, a >direct projection onto the plane might work too (and be faster?): >- the plane is described by: n.x*x+n.y*y+n.z*z+d=0, where n=surface >normal >- to project the sidevector you can just do: > d=v dot n > v_projected = v-d*n > >Haven't tested this in practice, but if you don't use the forward >vector, you could use this. If you don't already. ;-) >

Thanks for the suggestion. I have tried this in a couple areas before, but for some reason it didn't work as planned. Of course, with my brilliant sign conventions, that should be no surprise :-) I just stick to cross products for most things. For some reason projecting via dots usually gets me in trouble. Maybe I just think in right angles better :-) Todd Wasson Racing Software http://PerformanceSimulations.com My car sim http://performancesimulations.com/scnshot4.htm

On 06 Mar 2003 23:11:10 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (16 lines)

>> >>As a sidenote, even though this method gives you the forward vector, a >>direct projection onto the plane might work too (and be faster?): >>- the plane is described by: n.x*x+n.y*y+n.z*z+d=0, where n=surface >>normal >>- to project the sidevector you can just do: >> d=v dot n >> v_projected = v-d*n >> >>Haven't tested this in practice, but if you don't use the forward >>vector, you could use this. If you don't already. ;-) >> > >Thanks for the suggestion. I have tried this in a couple areas before, but for >some reason it didn't work as planned. Of course, with my brilliant sign >conventions, that should be no surprise :-)

Ah, I know. Although after long debugging runs, you always end up removing a couple of '-' signs. ;-) Therefore my first tries these are always just with a '+'. Somehow in the end it all fits better. Pure voodoo sometimes, programming. I'm glad the computer knows what it's doing. >I just stick to cross products for most things. For some reason projecting via >dots usually gets me in trouble. Maybe I just think in right angles better :-) Hehe, that may be true. Still, the dot product is the best invention since sliced bread. A matrix conversion is for example just a bunch of dot products (projections on the other coord system's axes). Thinking of a dot product as the length of one vector projected onto the other has made it visually feasible for me to grasp what it will do. It's just taking care that one of the two vectors is unit length that might be tricky. Ah well, the forward tire vector is useful anyway for applying Fx I guess. :) Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/