Ruud van Gaal wrote in message <[email hidden]>...
>Thanks to those who helped me in the start of my car simulator. Upon
>reading a LOT of information, it seems there is a LOT of simulating to
>do. I should read up on tensors I think. Don't know what they are yet,
>actually.
Tensors are what turn many people off from learning Einstein's general
theory of relativity. Or at least it's why they think it's hard. Tensors can
be thought of as the next step up from vectors, but they're a lot more than
that. In fact, vectors are 1st rank tensors, themselves, while matrices are
2nd rank tensors. In general, a tensor has a "rank" and an "order". The rank
tells you how many indices it has, and the order tells you how many
dimensions of space each index of the tensor resides in. Finally, like
vectors and matrices, tensors obey certain transformation rules.
But like most things in life, you won't get a gut feeling for tensors
until you spend some quality time solving tensor problems. :)
Bendito;
Notable threadHobbyist car physics: turning, slip angles and vectors
Ruud van Gaal continued developing his own car simulator, asking how a car rotates when turning. Todd Wasson and Matt Jessick of Motorsims advised computing each tyre's slip angle from the velocity at its contact patch, using vector maths and right-handed coordinates, and Doug Milliken pointed to the Millikens' Race Car Vehicle Dynamics book, which others also recommended.
With Matthew Jessick (Motorsims); Doug Milliken (Milliken Research Associates)
physics/realism debate
Automated summary.
Hi,
Thanks to those who helped me in the start of my car simulator. Upon
reading a LOT of information, it seems there is a LOT of simulating to
do. I should read up on tensors I think. Don't know what they are yet,
actually. And getting plagued by much work in my business life. ;-)
But ok, I've got a straightline acceleration model running, no wheel
spin yet (that would complicate understanding the sim now that I'm
still trying to do other basic stuff). I can shift gears (VERY basic;
no clutches or nothing), even have sound (on the SGI) with smoothly
varying frequencies (should have to implement some DirectAudio
functionality in my QAudioPort class to have it work on Win32).
Works nicely with forces pushing the car forward, the front wheels
rotating etc. Looks nice onscreen, because I paint the forces, so I
can see what my physics model is doing (only lateral and longitudinal
forces for now). I want to put up some .exe on my site or something
once I get the next thing a bit clean, and that is: turning.
I've tested some sideway throwing of the car, and it slows down nicely
when you have a velocity perpendicular to the heading of the car (say;
vx=-10, vz=-10 and heading 45 deg).
But when I just get a rolling car, and try to steer, I get a (probably
well-known first-timer) effect of the car rotating around its CM
(center of mass).
I'm generating lateral and longitudinal forces for the front
(steering) wheels according to the angle between the vehicle velocity
and the wheel heading. For tests, I can turn the wheel 90 degrees, so
I can totally change from a rolling wheel to a full blocking wheel.
The lateral/longitudinal forces I deduce using sin(angle); the more
turning, the more sin(a) generates both lat/long forces.
Now I've not done anything yet about the rear wheels actually. The
don't generate response forces (yet). But it seems to me the car will
always rotate around its CM (which it does now; only it doesn't stop
rotating since I haven't yet implemented the rear wheels velocity with
respect to the ground, which would lead to friction forces stopping
the rotation).
If I drive in my real car, it seems a bit as if I turn left, the pivot
point is more located at rear left wheel then the CM of my car.
Likewise, turning to right, the right rear wheel seems more the pivot
point. Suppose I have the wheels 90 degrees turned right (suppose!),
and I would put a bit of power on the front wheels; it would pivot
around the right wheel, mostly (a bit of an offset is probably the
result because the 2 front wheels are not both driving the rotation
circle if viewed from above).
Am I underimaginative if I fail to see how ANY forces at the rear
wheels would make it SEEM like the car is NOT pivoting around its CM,
but around a point more to the back of the car?
I know this thing is even a problem some people feel in some sims.
I can't see how apply forces on each of the 4 wheels will result in a
rotation about anything other than the CM. Please tell me why I'm
wrong. :)
Thanks for any ideas on the physics of turning. The last thread on
just plain forward physics has helped me a lot.
Ruud van Gaal, GPL Rank +53.53
MarketGraph / MachTech: http://www.marketgraph.nl
Pencil art: http://www.marketgraph.nl/gallery
Hi
i'm Not an engineer, but part of what you are saying was what i was going to
post a question about.
If i look at F12K, and SCGT and Rally2k i feel that instead of the wheels
moving as you describe, with the turning point being near or around the
inner rear wheel, it seems as if the inner rearwheel is moving backwards
while the outer rearwheel is moving forwards (like putting a card in front
of you, putting a finger in the middle to fix it and then turning it around)
dare i say that the only sim that doesn't suffer from this is ...wait for it
GPL.
BTW this is why i feel a bumper view in RC2k "feels" more right
Sudesh
"Ruud van Gaal" <[email hidden]> schreef in bericht
news:[email hidden]...
Quoted text (63 lines)
> Hi, > > Thanks to those who helped me in the start of my car simulator. Upon > reading a LOT of information, it seems there is a LOT of simulating to > do. I should read up on tensors I think. Don't know what they are yet, > actually. And getting plagued by much work in my business life. ;-) > > But ok, I've got a straightline acceleration model running, no wheel > spin yet (that would complicate understanding the sim now that I'm > still trying to do other basic stuff). I can shift gears (VERY basic; > no clutches or nothing), even have sound (on the SGI) with smoothly > varying frequencies (should have to implement some DirectAudio > functionality in my QAudioPort class to have it work on Win32). > Works nicely with forces pushing the car forward, the front wheels > rotating etc. Looks nice onscreen, because I paint the forces, so I > can see what my physics model is doing (only lateral and longitudinal > forces for now). I want to put up some .exe on my site or something > once I get the next thing a bit clean, and that is: turning. > > I've tested some sideway throwing of the car, and it slows down nicely > when you have a velocity perpendicular to the heading of the car (say; > vx=-10, vz=-10 and heading 45 deg). > > But when I just get a rolling car, and try to steer, I get a (probably > well-known first-timer) effect of the car rotating around its CM > (center of mass). > I'm generating lateral and longitudinal forces for the front > (steering) wheels according to the angle between the vehicle velocity > and the wheel heading. For tests, I can turn the wheel 90 degrees, so > I can totally change from a rolling wheel to a full blocking wheel. > The lateral/longitudinal forces I deduce using sin(angle); the more > turning, the more sin(a) generates both lat/long forces. > > Now I've not done anything yet about the rear wheels actually. The > don't generate response forces (yet). But it seems to me the car will > always rotate around its CM (which it does now; only it doesn't stop > rotating since I haven't yet implemented the rear wheels velocity with > respect to the ground, which would lead to friction forces stopping > the rotation). > If I drive in my real car, it seems a bit as if I turn left, the pivot > point is more located at rear left wheel then the CM of my car. > Likewise, turning to right, the right rear wheel seems more the pivot > point. Suppose I have the wheels 90 degrees turned right (suppose!), > and I would put a bit of power on the front wheels; it would pivot > around the right wheel, mostly (a bit of an offset is probably the > result because the 2 front wheels are not both driving the rotation > circle if viewed from above). > > Am I underimaginative if I fail to see how ANY forces at the rear > wheels would make it SEEM like the car is NOT pivoting around its CM, > but around a point more to the back of the car? > I know this thing is even a problem some people feel in some sims. > I can't see how apply forces on each of the 4 wheels will result in a > rotation about anything other than the CM. Please tell me why I'm > wrong. :) > > Thanks for any ideas on the physics of turning. The last thread on > just plain forward physics has helped me a lot. > > > Ruud van Gaal, GPL Rank +53.53 > MarketGraph / MachTech: http://www.marketgraph.nl > Pencil art: http://www.marketgraph.nl/gallery Ruud,
Here's why it works, even though you're calculating rotation around the CM:
The car starts with front (driving) wheels pointed 90 degrees to the right
with no velocity anywhere (dead stop).
Time step 1: Power is applied to front wheels. Torque around the vehicle
yaw axis will cause a tiny bit of rotation about the Center of Mass (CM, as you
indicated).
Time step 2: The rear tires have moved slightly to the left because of this
rotation. They now produce a force (the tire has stretched like a spring, or
developed a slip angle in your model) that pushes them back (or produces a
force) in the SAME DIRECTION the front tires are moving (and producing their
driving force). These combined forces move the CM to the right while the
vehicle is rotating.
Hope this helps.
Todd Wasson
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Quoted text (9 lines)
>If I drive in my real car, it seems a bit as if I turn left, the pivot >point is more located at rear left wheel then the CM of my car. >Likewise, turning to right, the right rear wheel seems more the pivot >point. Suppose I have the wheels 90 degrees turned right (suppose!), >and I would put a bit of power on the front wheels; it would pivot >around the right wheel, mostly (a bit of an offset is probably the >result because the 2 front wheels are not both driving the rotation >circle if viewed from above). > Ruud,
As Matt Jessick pointed out, trust the equations. What I recommend doing is
calculating each tire's slip angle seperately, rather than trying to use the
"vehicle direction" and "vehicle velocity vector". In other words, which
direction is each tire "facing" and which way is it "moving"? (There's a trick
to doing this correctly that took me a while to figure out, so I'll keep that a
secret until you get stumped or discover it yourself).
Generate your forces independently at all four corners from this "slip
angle", or difference between "facing" and "moving", and you'll indeed see the
car turn and pivot about the inside rear wheel as a real car does. I had the
same problem you have visualizing how the rotation would work correctly, but it
does.
When you see it happen, you'll say, "AHA!! Got it!"
Just break your primary lateral and longitudinal forces into the ground plane
components (x/y, or x/z, or whatever you're using), and break it into torque
components as you are already doing.
Once you do the same thing for the rear tires that you are doing for the
front, it'll work fine, even though it doesn't seem like it will right now.
Remember, the rear tires will make a torque about the vehicle's yaw axis in
the OPPOSITE direction from the fronts, even though all four slip angles are
positive (or negative), which as you said, tends to cancel out the car's
rotation. Keep going the way you're going, you'll see what I mean.
I'd forget about complex tire models for now and simply use an equation like
this to generate lateral forces:
---
Grip_Coef = Slip_Angle[Tire] * .25
If Grip_Coef > 1 then Grip_Coef = 1
If Grip_Coef < -1 then Grip_Coef = -1
---
This will let the Grip or Friction Coefficient (however you like to think of
it) increase to 1 at 4 degrees of slip angle (like a high cornering stiffness
F-1 or Indycar tire, perhaps). If you want something more like a street tire,
try multiplying by .1 or so. You'll get the same total grip, but at a higher
yaw angle. You can change the "Grip_Coef > 1" to whatever you like, of course.
Then you're multiplying this Grip_Coef by the load on the tire, which can be
damper and spring forces and unsprung weight all added together at each corner,
or just 1/4th the weight of the car for now, until you get past this stage.
Good luck! Keep us posted!
Todd Wasson
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
"Ruud van Gaal" <[email hidden]> wrote in message
news:[email hidden]...
I think you're basically on the right track. I think a neutrally handling
car will indeed rotate about it's center of gravity, an understeering car
will rotate about an axis closer to the rear axle, and an oversteering car
will rotate closer to the front axle. It all depends on the slip angle of
the front wheels compared to the rear. But that's all just my intuition- so
please don't flame me or nit-pick me to death. Maybe Dave Kaemmer will
chime in and give you a better response. ;o)
-A
Quoted text (63 lines)
> Hi, > > Thanks to those who helped me in the start of my car simulator. Upon > reading a LOT of information, it seems there is a LOT of simulating to > do. I should read up on tensors I think. Don't know what they are yet, > actually. And getting plagued by much work in my business life. ;-) > > But ok, I've got a straightline acceleration model running, no wheel > spin yet (that would complicate understanding the sim now that I'm > still trying to do other basic stuff). I can shift gears (VERY basic; > no clutches or nothing), even have sound (on the SGI) with smoothly > varying frequencies (should have to implement some DirectAudio > functionality in my QAudioPort class to have it work on Win32). > Works nicely with forces pushing the car forward, the front wheels > rotating etc. Looks nice onscreen, because I paint the forces, so I > can see what my physics model is doing (only lateral and longitudinal > forces for now). I want to put up some .exe on my site or something > once I get the next thing a bit clean, and that is: turning. > > I've tested some sideway throwing of the car, and it slows down nicely > when you have a velocity perpendicular to the heading of the car (say; > vx=-10, vz=-10 and heading 45 deg). > > But when I just get a rolling car, and try to steer, I get a (probably > well-known first-timer) effect of the car rotating around its CM > (center of mass). > I'm generating lateral and longitudinal forces for the front > (steering) wheels according to the angle between the vehicle velocity > and the wheel heading. For tests, I can turn the wheel 90 degrees, so > I can totally change from a rolling wheel to a full blocking wheel. > The lateral/longitudinal forces I deduce using sin(angle); the more > turning, the more sin(a) generates both lat/long forces. > > Now I've not done anything yet about the rear wheels actually. The > don't generate response forces (yet). But it seems to me the car will > always rotate around its CM (which it does now; only it doesn't stop > rotating since I haven't yet implemented the rear wheels velocity with > respect to the ground, which would lead to friction forces stopping > the rotation). > If I drive in my real car, it seems a bit as if I turn left, the pivot > point is more located at rear left wheel then the CM of my car. > Likewise, turning to right, the right rear wheel seems more the pivot > point. Suppose I have the wheels 90 degrees turned right (suppose!), > and I would put a bit of power on the front wheels; it would pivot > around the right wheel, mostly (a bit of an offset is probably the > result because the 2 front wheels are not both driving the rotation > circle if viewed from above). > > Am I underimaginative if I fail to see how ANY forces at the rear > wheels would make it SEEM like the car is NOT pivoting around its CM, > but around a point more to the back of the car? > I know this thing is even a problem some people feel in some sims. > I can't see how apply forces on each of the 4 wheels will result in a > rotation about anything other than the CM. Please tell me why I'm > wrong. :) > > Thanks for any ideas on the physics of turning. The last thread on > just plain forward physics has helped me a lot. > > > Ruud van Gaal, GPL Rank +53.53 > MarketGraph / MachTech: http://www.marketgraph.nl > Pencil art: http://www.marketgraph.nl/gallery
Ruud van Gaal wrote:
> But when I just get a rolling car, and try to steer, I get a (probably
> well-known first-timer) effect of the car rotating around its CM
> (center of mass).
This sounds fine to me. Keep up the good work ;)
> I'm generating lateral and longitudinal forces for the front
> (steering) wheels according to the angle between the vehicle velocity
> and the wheel heading.
You should eventually calculate the components of velocity at
each tire contact patch due to the sum of the center of mass
velocity and also the component due to rotation of the tire
about the center of mass when you calculate the
angle between the tires orientation and its velocity.
If you leave off the component from the rotation you will
lose an important "damping" term in the rotational
equations of motion. This is an interesting term for racing
because this damping effect varies with velocity such that
it is half as much at twice the speed. (So a car driven fast
has less damping than a car driven slower.)
This is something that makes me cringe each time an
empty pickup truck careens past me
making a wild lane change on a Texas freeway. ;)
If you have "Race Car Vehicle Dynamics", IIRC Chapter 5 covers
basic yaw stability and this effect is termed there
"Path Curvature Stiffness".
> For tests, I can turn the wheel 90 degrees, so
> I can totally change from a rolling wheel to a full blocking wheel.
> The lateral/longitudinal forces I deduce using sin(angle); the more
> turning, the more sin(a) generates both lat/long forces.
This is OK in the "linear regime" of tire behavior, but for modern
radials the force peaks at fairly low angles (10 degrees or less.)
So don't push it too far...
The effect of "lateral load transfer" on the way each tire acts
while turning hard is also a very important effect to include eventually.
This is what makes tire simulations "fun" ;)
Get Race Car Vehicle Dynamics. You can implement example tire
models like those described in Chapter 18 or so and have probably
more (correct) features than you will want for quite awhile.
> Now I've not done anything yet about the rear wheels actually. The
> don't generate response forces (yet). But it seems to me the car will
> always rotate around its CM (which it does now; only it doesn't stop
> rotating since I haven't yet implemented the rear wheels velocity with
> respect to the ground, which would lead to friction forces stopping
> the rotation).
As you say, the rear tires are stabilizing, just like the tail on
an aircraft or the fletching on an arrow. Things get more exciting
when you pass beyond the peak of their lateral capability, of course ;)
Whether this happens or not is how you get understeer or oversteeer
at the limit of maximum lateral acceleration.
Perhaps you drive a Porshe ;) (CG tends to be more aft)
> I know this thing is even a problem some people feel in some sims.
> I can't see how apply forces on each of the 4 wheels will result in a
> rotation about anything other than the CM. Please tell me why I'm
> wrong. :)
It really is the CM. You just have to trust your equations of
motion. ;) I can't think of a good way to motivate that result, ;(
except to say that the equations of rigid body motion have been
taught, built to and experimented on for hundreds of years.
My first simulation was of a spacecraft with a big long payload stuck
on top and all the attitude control thrusters near the bottom.
An unwieldy contraption like that helps one imagine how the
six degree of freedom equations work.
Of course, correct results depend on getting the tire forces correct
at all four corners, and thus we are back to good tire models ;)
Luck,
- Matt
--
Matthew V. Jessick Motorsims
[email hidden] http://www.moto1.net
Vehicle Dynamics Engineer (972)910-8866, Fax: (972)910-8216
Quoted text (8 lines)
> If I drive in my real car, it seems a bit as if I turn left, the pivot > point is more located at rear left wheel then the CM of my car. > Likewise, turning to right, the right rear wheel seems more the pivot > point. > Am I underimaginative if I fail to see how ANY forces at the rear > wheels would make it SEEM like the car is NOT pivoting around its CM, > but around a point more to the back of the car?Woops! I got that wrong. It should always rotate about the center of
gravity. For it to do otherwise would require a force pushing towards the
outside of the corner, and there is no such force. So sorry.
Your sim sounds good. :)
"Aubrey" <[email hidden]> wrote in message
news:AJ%o5.463$[email hidden]...
> I think you're basically on the right track. I think a neutrally handling
> car will indeed rotate about it's center of gravity, an understeering car
> will rotate about an axis closer to the rear axle, and an oversteering car
> will rotate closer to the front axle. It all depends on the slip angle of
> the front wheels compared to the rear. But that's all just my intuition-so
> please don't flame me or nit-pick me to death. Maybe Dave Kaemmer will
> chime in and give you a better response. ;o)
>
> -A
>
>
[email hidden] (Ruud van Gaal) wrote:
>Hi,
Hi!
Try this for a start:
http://x60.deja.com/getdoc.xp?AN=598870773&CONTEXT=967113940.417005588&hitnum=15
Remco
On Thu, 24 Aug 2000, Matthew V. Jessick wrote:
Matt, once again, thanks for the nice plug for our book.
Best place to buy is direct from the publisher, they even offer a good
price on overseas shipping: <http://www.sae.org/products/books/R-146.htm>
-- Doug
Douglas Milliken <[email hidden]>
Milliken Research Associates Inc.
<snipped>
> If you have "Race Car Vehicle Dynamics", IIRC Chapter 5 covers
> basic yaw stability and this effect is termed there
> "Path Curvature Stiffness"......
> Get Race Car Vehicle Dynamics. You can implement example tire
> models like those described in Chapter 18 or so and have probably
> more (correct) features than you will want for quite awhile.
--> Chapter 14
On Thu, 24 Aug 2000 03:02:12 GMT, "Matthew V. Jessick"
<[email hidden]> wrote:
...
>> But when I just get a rolling car, and try to steer, I get a (probably
>> well-known first-timer) effect of the car rotating around its CM
>> (center of mass).
>
>This sounds fine to me. Keep up the good work ;)
Good. So I actually WAS on the right track. Phew. ;-)
Yes, I already had a look into that. Shouldn't be too difficult in the
beginning, because the direction of the wheel velocity is
perpendicular to the car's CM, which is constant, and I have a
variable containing the angular velocity (around the yaw axis), so
|v|=ang.vel.*r (where r is distance from CM to wheel center).
>If you leave off the component from the rotation you will
>lose an important "damping" term in the rotational
>equations of motion.
Yes, that's probably why my car can keep on rotating when nothing's
happening. :)
> This is an interesting term for racing
>because this damping effect varies with velocity such that
>it is half as much at twice the speed. (So a car driven fast
>has less damping than a car driven slower.)
Ah, but this follows probably from all the force equations
automagically, I guess. I hope. ;)
...
>If you have "Race Car Vehicle Dynamics", IIRC Chapter 5 covers
>basic yaw stability and this effect is termed there
>"Path Curvature Stiffness".
I've heard about that book now for a couple of times, and had already
seen it at SAE. Just ordered it. Not cheap, and it will probably take
some time to get here, but it seems like the right buy (instead of
plucking bits & pieces from all over the place on the net).
...
>The effect of "lateral load transfer" on the way each tire acts
>while turning hard is also a very important effect to include eventually.
>This is what makes tire simulations "fun" ;)
Yep, but I am taking things step by step. However, I've already
thought about longitudinal torque, yes. My next step is getting the
steering a *bit* logical now. Without weight transfer. I'll try to
just give my car a yaw rotation and see how the wheel's friction
(using velocity=vehicle_velocity+wheel_velocity_from_vehicle_rotation)
will stop it rotating. That's my next thing. If I have that right, the
steering will probably be a lot better, eh, more like real life.
...
>As you say, the rear tires are stabilizing, just like the tail on
>an aircraft or the fletching on an arrow. Things get more exciting
>when you pass beyond the peak of their lateral capability, of course ;)
>Whether this happens or not is how you get understeer or oversteeer
>at the limit of maximum lateral acceleration.
Things will/should probably handle very neutral until I move on to
springs and weight transfer with a center of mass that isn't exactly
located in the geometrical center. (so front and rear wheels don't
deliver equal forces anymore)
...
>Perhaps you drive a Porshe ;) (CG tends to be more aft)
Unfortunately, no! ;)
Perhaps matching my private car with my sim works, rather than the
reverse, hehe.
>> I can't see how apply forces on each of the 4 wheels will result in a
>> rotation about anything other than the CM. Please tell me why I'm
>> wrong. :)
>
>It really is the CM. You just have to trust your equations of
>motion. ;)
I have faith. :)
...
>Of course, correct results depend on getting the tire forces correct
>at all four corners, and thus we are back to good tire models ;)
I'll use Todd's easy linear equations for now until I get the steering
to *look* a bit right.
Thanks for the tips, all of you btw, so nice to work on a problem that
many people have worked on and solved before. :)
I'll keep you updated...
Ruud van Gaal, GPL Rank +53.53
MarketGraph / MachTech: http://www.marketgraph.nl
Pencil art: http://www.marketgraph.nl/gallery
Quoted text (9 lines)
>> I'm generating lateral and longitudinal forces for the front >> (steering) wheels according to the angle between the vehicle velocity >> and the wheel heading. > >You should eventually calculate the components of velocity at >each tire contact patch due to the sum of the center of mass >velocity and also the component due to rotation of the tire >about the center of mass when you calculate the >angle between the tires orientation and its velocity.Allow me to second Matt Jessick's recommendation of Bill and Doug
Milliken's "Race Car Vehicle Dynamics" -- the Millikens' -- p�re et fils
-- credentials are about as impeccable as credentials get. Be aware,
however, that this is not a book like Colin Campbell's, or Herb Adams',
or even Paul van Valkenburgh's: this is deep, highly-technical stuff,
heavy on the math, and not what an aficianado of "Spiderman" or "The
Silver Surfer" is likely to consider "light reading". In fact, it's not
what an aficianado of "War and Peace" would consider light reading --
but if you want the straight goods on race car dynamics, this book is
the bible.
BB
On Fri, 25 Aug 2000 12:40:34 GMT, Barton Brown <[email hidden]>
wrote:
The book is on its way to my home, thanks for the recommendation.
A bible is what I need. Light reading material I can often come up
with myself. A book about things I know relatively little about should
go into more detail than I will be implementing in the near and
not-so-near future. I need facts & figures that go beyond which I'm
doing in my sim, so I can keep thinking ahead and never be really
satisfied with the physics/sim I've got.
However, once I get turning right, and a little springs (and weight
transfer to see the car edge over), I should do a tiny track creator
so I can actually drive around something nice. Just a square circle
would be nice. Eh, a square circle? Hm, you know:
+-+
| |+-+
:)
So I can get my first missed corner! ;-)
Ruud van Gaal, GPL Rank +53.53
MarketGraph / MachTech: http://www.marketgraph.nl
Pencil art: http://www.marketgraph.nl/gallery
Quoted text (10 lines)
>Allow me to second Matt Jessick's recommendation of Bill and Doug >Milliken's "Race Car Vehicle Dynamics" -- the Millikens' -- p�re et fils >-- credentials are about as impeccable as credentials get. Be aware, >however, that this is not a book like Colin Campbell's, or Herb Adams', >or even Paul van Valkenburgh's: this is deep, highly-technical stuff, >heavy on the math, and not what an aficianado of "Spiderman" or "The >Silver Surfer" is likely to consider "light reading". In fact, it's not >what an aficianado of "War and Peace" would consider light reading -- >but if you want the straight goods on race car dynamics, this book is >the bible.
Doug Milliken wrote:
> On Thu, 24 Aug 2000, Matthew V. Jessick wrote:
>
> Matt, once again, thanks for the nice plug for our book.
>
You have lots of nice pictures! ;)
- Matt
Ruud van Gaal wrote:
This is correct as a "scalar" (that is, non-vector) equation
and is useful if you already know the direction of the
velocity component. It's straight forward to calculate both the
size of the component and its direction using vector equations.
velocity_vector = angular_velocity_vector Cross_Product radius_vector
where Cross_Product is a common operation on two vectors
similar to multiplication of two scalars.
Basic dynamics texts will cover this technique and also usually give
a useful review of vector mathematics also.
> I'll try to
> just give my car a yaw rotation and see how the wheel's friction
> (using velocity=vehicle_velocity+wheel_velocity_from_vehicle_rotation)
Yes, that's it. But it will help a lot to express it as vectors as soon as
possible.
The wheel_velocity_from_vehicle_rotation will add damping
which will help oscillations die away. Stability (where the total
of all the torques is pointed in the correct diection so they tend to
resist motion rather than make it worse) is also important
(Maybe more so. Damping isn't generally all that helpful if it's unstable ;)
You can get extra stability by doing setup type things that make the car more
understeer. More weight on the rears (a bit aft CG) and/or
slightly better tires on the rear, that sort of thing.
- Matt
Quoted text (14 lines)
> On Thu, 24 Aug 2000 03:02:12 GMT, "Matthew V. Jessick" > <[email hidden]> wrote: > >You should eventually calculate the components of velocity at > >each tire contact patch due to the sum of the center of mass > >velocity and also the component due to rotation of the tire > >about the center of mass when you calculate the > >angle between the tires orientation and its velocity. > > Yes, I already had a look into that. Shouldn't be too difficult in the > beginning, because the direction of the wheel velocity is > perpendicular to the car's CM, which is constant, and I have a > variable containing the angular velocity (around the yaw axis), so > |v|=ang.vel.*r (where r is distance from CM to wheel center). >Quoted text (12 lines)
>I have: >- longitudinal/lateral ratio and the friction circle; now, I do: > - calculate velocity of wheel contact patch in world coords > - calculate slip angle (=wheel heading - velocity angle) > - calculate grip coefficient (simply as gripCoeff=gripAngle*0.1, >topping it off at +/- maxTireGripCoefficient, as per Todd Wasson's >suggestion) > - calculate resulting friction force; here I let the force point >perpendicular to the wheel heading, so if the left front (steering) >wheel is pointing to the right, the resulting force is inwards towards >the car's CM a bit. So: > totalForce=gripCoeff*normalForce (weight_of_car/4 for now)Quoted text (12 lines)
>My idea is to: > - Calculate all virtual friction forces; with virtual I mean pretend >the wheel has 100% grip; so totalForce would become >totalForce=maxGripCoeff*normalForce. I'll have to use vector calculus >so the direction is correct (although it will probably always remain >in the X/Z plane). > - After all forces are calculated, apply a 'friction cap', which >tops off the friction force to its maximum value for the surface >(rubber-road for example). For example, another force leading to >friction might be a (strong) wind. In fact, drag could/should be >implemented this way, I think.Quoted text (12 lines)
>Suppose I have the car in the air, the wheels spinning. I drop >the car onto the road. The car will begin to move forward in real >life, not in my sim yet. So calculating wheel velocity with >vehicle_velocity+wheel_rotation_velocity_around_car_CM is not enough >(that is 0 still upon touching the ground). I have to include the >rotation speed of the wheel itself (around the axle). >Now what I think is I can 'just' take the rotational velocity of the >wheel and calculate how much velocity that is in the X/Z plane of the >car (v_translational=v_angular*r) and add this velocity vector to the >equation to get the actual virtual contact path speed. >Hope this gets across. Seems to me like the way to do it, right? >On Sat, 26 Aug 2000 04:19:16 GMT, "Matthew V. Jessick"
<[email hidden]> wrote:
...
Yep. I'm currently still having vars named 'forceLat' and 'forceLong',
but I think I must pack the stuff into a Vector class and have only
vectors. The reason I had not done this yet is because a) it's easier
to read when first programming a 1-dimensional force/effect, b)
lateral/longitudinal reads a bit nicer instead of local-X-axis,
local-Z-axis and c) I did not have a vector class yet. :)
I have a small one now. I also have lots of vector info, so cross
products, dot products etc are no problem. (studied them at University
even a long time ago)
...
>> I'll try to
>> just give my car a yaw rotation and see how the wheel's friction
>> (using velocity=vehicle_velocity+wheel_velocity_from_vehicle_rotation)
>
>Yes, that's it. But it will help a lot to express it as vectors as soon as
>possible.
I will convert the lot to vectors before the conversion becomes too
big too handle easily.
>The wheel_velocity_from_vehicle_rotation will add damping
>which will help oscillations die away.
Yes! I have tried this Friday-evening and it worked! :)
The cornering now looks a lot more life-like. Even tried it with 1
missing (rear) wheel. That also works (the car turns a bit). Cool.
However, there are some concerns I have:
- longitudinal/lateral ratio and the friction circle; now, I do:
- calculate velocity of wheel contact patch in world coords
- calculate slip angle (=wheel heading - velocity angle)
- calculate grip coefficient (simply as gripCoeff=gripAngle*0.1,
topping it off at +/- maxTireGripCoefficient, as per Todd Wasson's
suggestion)
- calculate resulting friction force; here I let the force point
perpendicular to the wheel heading, so if the left front (steering)
wheel is pointing to the right, the resulting force is inwards towards
the car's CM a bit. So:
totalForce=gripCoeff*normalForce (weight_of_car/4 for now)
forceLat=cos(slipAngle)*totalForce
forceLong=sin(slipAngle)*totalForce
I think I should take up the vector version though, because other
forces come in later on, so I can NOT calculate the RESULTING friction
force just yet. My idea is to:
- Calculate all virtual friction forces; with virtual I mean pretend
the wheel has 100% grip; so totalForce would become
totalForce=maxGripCoeff*normalForce. I'll have to use vector calculus
so the direction is correct (although it will probably always remain
in the X/Z plane).
- After all forces are calculated, apply a 'friction cap', which
tops off the friction force to its maximum value for the surface
(rubber-road for example). For example, another force leading to
friction might be a (strong) wind. In fact, drag could/should be
implemented this way, I think.
What I'm not sure about is if I can just cap friction forces so they
stay within maxGripCoeff*normalForce length, or if I have to add each
friction force as it comes along. I'm afraid that might lead to errors
when two similar friction forces are generated in the same direction,
cause a friction force that could not exist in reality (namely a force
twice as long). I have seen ellipsoid friction forces namely, so
perhaps the friction circle is more a RESULT of different forces
playing, instead of just being the max force that a tire can generate
on a given surface.
Another concern, which is clearly there is the following:
- I can give the car initial speed/rotation with a small debug ini
file. Suppose I have the car in the air, the wheels spinning. I drop
the car onto the road. The car will begin to move forward in real
life, not in my sim yet. So calculating wheel velocity with
vehicle_velocity+wheel_rotation_velocity_around_car_CM is not enough
(that is 0 still upon touching the ground). I have to include the
rotation speed of the wheel itself (around the axle).
Now what I think is I can 'just' take the rotational velocity of the
wheel and calculate how much velocity that is in the X/Z plane of the
car (v_translational=v_angular*r) and add this velocity vector to the
equation to get the actual virtual contact path speed.
Hope this gets across. Seems to me like the way to do it, right?
I'll first port things to vectors, making sure I don't mix local-axis
vectors and global-axis (world-axis) vectors hopefully. Shouldn't be
difficult, mainly just conversion work. And then get the car moving
when starting it with spinning wheels.
But it's getting better. Nice thing to see is that I already have some
spinning and sliding, while not even really explicitly doing any
slipping calculations (except for the slip angle, which is more of a
sideway-force thing).
Thanks for all the help, much appreciated, hope to put up a
downloadable demo of the thing soon,
Ruud van Gaal, GPL Rank +53.53
MarketGraph / MachTech: http://www.marketgraph.nl
Pencil art: http://www.marketgraph.nl/gallery
Quoted text (10 lines)
>> Yes, I already had a look into that. Shouldn't be too difficult in the >> beginning, because the direction of the wheel velocity is >> perpendicular to the car's CM, which is constant, and I have a >> variable containing the angular velocity (around the yaw axis), so >> |v|=ang.vel.*r (where r is distance from CM to wheel center). > >This is correct as a "scalar" (that is, non-vector) equation >and is useful if you already know the direction of the >velocity component. It's straight forward to calculate both the >size of the component and its direction using vector equations.>Now I
>have the 3D vector 'force'. Where forceLat==force.x and
>forceLong==force.z.
Gotcha. I use x_force and y_force here. For me, forceLat is perpendicular
to the wheel heading, and forceLong is parallel to the wheel heading.
> I'll
>probably try a slip *vector* soon instead of merely a slip *angle*.
>It's easier with the vector because the friction force is then just
>-gripCoefficient*slipVector.
>Nice thing is I can include the wheel spinning velocity in
>'slipVector' too. Things are looking good.
Good enough! :-) You may want to keep the slip angle and slip ratio thing
in the back of your mind while you continue. If you decide to use real tire
data in your sim, this is how most of it is displayed. Good idea, though.
Hadn't thought of that!
Very good! I planned on just moving the CM if fuel loads or anything else
changed. I like the wheel breaking off idea :-)
<snip section on vectors>
Interesting. I still don't get it yet :-) What if there's a force pointing
at 45 degrees along your x/z plane? Magnitude 100? How does that show up in a
vector class? (1,1,0) ?
>Ah yes, haha, braking. Almost forgot about that ;-)
>Will have to do some DirectInput stuff soon. Have no braking yet.
>That's a future subject; how torque is related to braking power. So
>braking=0..100, torque=0..-T; how does the graph go? Is it linear?
>I have negative torque too to do drivetrain and mostly engine braking.
Linear was close enough. This is that graph again using the linear relation:
http://performancesimulations.com/partthrottle.htm
As far as brakes go, I define a total braking torque that's available for all
tires as of now, with a setting for front/rear brake bias that alters this.
You mean *your* version of forceLat and forceLong or mine?
>That makes sense. A profile in a tire will ofcourse have an impact on
>lateral vs. longitudinal frictions. I'll still keep it a circle for
>now. 1.2u vs. 1.15u doesn't seem much yet. Other things have
>precedence.
>
I agree.
You've got it! ;-)
If I'm not mistaken, simulating 4 spinning wheels adds 4 degrees (as long as
you are actually calculating rotational velocity/accel/position of each tire
independently).
>I'll try the slipVector approach, which sees force as having a
>magnitude (length) and a direction, so I don't have to worry even
>about long/lat. Except in some nifty subsituations.
>
Sounds good.
Geeze!! What an incredible error on my part! Of course, what I really meant
was 166 Hz, not Khz, and especially not Mhz!
<snip more on vectors>
>So I can just do:
> wheel.acceleration=wheel.force*gripCoeff;
>instead of splicing the vectors up in:
> wheel.accLat=wheel.forceLat*gripCoeff;
> wheel.accLong=wheel.forceLong*gripCoeff;
>
These are simply user defined types, right? I had no idea you could do
multiple operations in one statement this way. (I've been in a cave for a
while.) I'll have to start playing with these. Thanks!
<Snip more on vectors, cross products, and dot products>
This is great stuff! Thanks. I've got a couple 3-D books and get confused
how vectors and cross and dot products work, so I came up with my own way to do
3-D (probably first invented in 1720 or so). This is definately stuff I want
to learn. This link you posted :>http://www.ma.psu.edu/~herzog/em11/p04a.html
is great. I'll take a look at it now.
>I'll copy the source to my PC now and see if the sound code isn't
>bugging it too much and will try to put up a page tonight. Will post a
>message here if I succeed.
>
You will! Look forward to seeing it.
Thanks for your help also :-)
Todd Wasson
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Quoted text (10 lines)
>I was wondering about the centers of the car. I'll have a: >- CM; center of mass >- CD; center of drag (don't have it yet, but will use it to implement >drag) >- CG; bad name, but it is the center of geometry. Also don't use such >a value yet (CG==CM for now), but I want to define the position of the >wheels relative to the center of geometry, rather than relative to the >center of mass. The center of mass will change once a wheel breaks >off. :) >Quoted text (15 lines)
>> As you are apparently already doing, calculate the maximum force the tire >can >>generate. I check the longitudinal force first. If it's greater than the >>maximum tire force available, I limit it (longForce=maximum possible force). > >>If it is not greater, I leave longForce alone. >> >> Then, I use the Pythagorean theorem (I have no clue about vector calculus) >to >>limit the lateral force if necessary. > >The vector method would be easier (IMHO); normalizing not to 1, but to >gripCoeff*forceNormal. That keeps the ratio between forceLat and >forceLong constant. >Quoted text (12 lines)
>>>Now what I think is I can 'just' take the rotational velocity of the >>>wheel and calculate how much velocity that is in the X/Z plane of the >>>car (v_translational=v_angular*r) and add this velocity vector to the >>>equation to get the actual virtual contact path speed. >>>Hope this gets across. Seems to me like the way to do it, right? >>> >> >> Congratulations, you just reinvented what is called a "slip ratio". > >Cool :) Basically had this thought confirmed yesterday when looking at >the pictures from Brian Beckham that explains the RARS physics. >Quoted text (7 lines)
>> If you want to use "slip ratio" with rotating tires and go from a 6 degree >of >>freedom model to a 10 DOF, try using something like: > >10? What are the 4 extra degrees? My visualization centers in my brain >haven't been upgraded yet ;-) >Quoted text (9 lines)
>> If you go the "slip ratio" route, you'll need to increase your sampling >rate >>dramatically or the tires will be hoplessely unstable. I use 166Mhz to >300+Mhz >>in my model. > >I hope you mean 166kHz instead of 166Mhz?! >166Mhz would not be able to go realtime on my poor PII-400. I'll see >how the floating point functions work.On 28 Aug 2000 22:35:30 GMT, [email hidden] (JTW62074) wrote:
...
Hehe, right, but it was before I moved over to vectors (yesterday
evening), so forceLat would always point along the X-axis (the var is
'double forceLat'); so forceLat has a CONSTANT direction (otherwise I
shouldn't call it forceLAT). forceLong was along the Z-axis. Now I
have the 3D vector 'force'. Where forceLat==force.x and
forceLong==force.z.
I've read the one of the latest Brian Beckham articles (there are a
couple of new ones beyond article 12 since a few days), and it has a
nice vector picture of RARS, a car simulation thingy designed for car
robotics.
That gives a nice overview of some things I was asking for. I'll
probably try a slip *vector* soon instead of merely a slip *angle*.
It's easier with the vector because the friction force is then just
-gripCoefficient*slipVector.
Nice thing is I can include the wheel spinning velocity in
'slipVector' too. Things are looking good.
...
Right, I was trying to do this (using slipRatio for forceLong I mean).
I can turn the wheels 90 degrees so I can test for the forceLong that
is generated if the car is moving forward. Pushing all of that info
into the slipVector makes things easier. The torque that makes the car
rotate around its Y-axis (turning/heading) remains largely the same,
so I won't get into vector conversion trouble there.
> You might try implementing aerodynamic drag by applying the correct force to
>the CM of the car. It has nothing to do with the friction at the tires.
>Later, the force could be applied to a center of drag that would torque the
>body as well as slowing it down, causing the nose to lift at high speed. (I
>haven't used a center of drag yet myself, although I can put wings on the car
>and do fun things that way :-) )
I was wondering about the centers of the car. I'll have a:
- CM; center of mass
- CD; center of drag (don't have it yet, but will use it to implement
drag)
- CG; bad name, but it is the center of geometry. Also don't use such
a value yet (CG==CM for now), but I want to define the position of the
wheels relative to the center of geometry, rather than relative to the
center of mass. The center of mass will change once a wheel breaks
off. :)
I think I'll do drag (torque around the other 2 axes in fact) next,
instead of doing springs. First have to get the slipVector in, but
that shouldn't take more than an evening.
I meant braking forces, for example. First calculating slip ratio and
coming up with forceLong+=maxGripCoeff*forceNormal, then calculating
braking force in another function and AGAIN coming up with another
forceLong+=maxGripCoeff*forceNormal results in forceLong being twice
as big as the wheel is able to give.
(I set all force to 0 before beginning the round of forces around the
car, and all math after that does force+=...)
But with the vector method it becomes easier. You should really take a
look into that. In the end, you have a force with a direction, and you
can 'normalize' the vector to its maximum friction. I'll keep a
friction CIRCLE for now, ELLIPSES might come later.
About the vector thing; you should really look into it. Basically it's
just putting (x,y,z) values together into 1 structure and working with
that. Lots of standard vector classes on the net; created a QVector3
class yesterday in hour or two, based on some source on the net.
The force vector in my RWheel class then has the direction you are
already implicitly storing in your software, probably. The direction
IS (x,y,z). Normalizing normally means making the vector's length 1.
The length of a vector is Pythagorean, so l=|v|=sqrt(x*x+y*y+z*z). So
normalizing would mean doing v=v/l (where v is a vector, l is a
scalar). Which is just (x/l,y/l,z/l).
And lateral is the X, longitudinal is the Z, vertical is the Y
('vertical' is what I call it, perhaps there's another term that is
used more)
> I apply drivetrain or brake friction by
>using negative torque at the wheels. This causes a reduction in slip ratio and
>a change in longitudinal force.
Ah yes, haha, braking. Almost forgot about that ;-)
Will have to do some DirectInput stuff soon. Have no braking yet.
That's a future subject; how torque is related to braking power. So
braking=0..100, torque=0..-T; how does the graph go? Is it linear?
I have negative torque too to do drivetrain and mostly engine braking.
The vector method would be easier (IMHO); normalizing not to 1, but to
gripCoeff*forceNormal. That keeps the ratio between forceLat and
forceLong constant.
...
>>I have seen ellipsoid friction forces namely...
> These ellipsoid friction circles exist because some tires can generate more
>force longitudinally than laterally (or vice versa, perhaps). This (to my
>understanding) has nothing to do with complex combinations of friction forces
>at the tires. A tire may have 1.2u longitudinally, with only 1.15u laterally.
>The circle becomes an ellipse.
That makes sense. A profile in a tire will ofcourse have an impact on
lateral vs. longitudinal frictions. I'll still keep it a circle for
now. 1.2u vs. 1.15u doesn't seem much yet. Other things have
precedence.
...
Cool :) Basically had this thought confirmed yesterday when looking at
the pictures from Brian Beckham that explains the RARS physics.
...
> If you want to use "slip ratio" with rotating tires and go from a 6 degree of
>freedom model to a 10 DOF, try using something like:
10? What are the 4 extra degrees? My visualization centers in my brain
haven't been upgraded yet ;-)
> longGrip_Coef = Slip_Ratio * 12
> longForce = longGrip_Coef * normalForce
>
> Then cap the longGrip_Coef to a maximum.
I'll try the slipVector approach, which sees force as having a
magnitude (length) and a direction, so I don't have to worry even
about long/lat. Except in some nifty subsituations.
> The only problem I've had with this
>personally is low speed instability (the tire shakes forwards and backwards
>when the car is moving slowly because you're dividing by a number close to 0,
>generating huge slip ratios and torques that jolt the tire forwards and
>backwards).
I have this too. I am currently downsizing forces when velocities
become small, yes. The thresholds are a bit obscure though. Should put
'em in an ini file somewhere.
>To fix this, at some low speed where the problem becomes apparent,
>try subtracting the rotational velocities from each other and multiplying by a
>small number.
Yes, seems to work. As long as the car is nearly static, this error
isn't noticable and save us from having to increase the sampling rate.
> If you go the "slip ratio" route, you'll need to increase your sampling rate
>dramatically or the tires will be hoplessely unstable. I use 166Mhz to 300+Mhz
>in my model.
I hope you mean 166kHz instead of 166Mhz?!
166Mhz would not be able to go realtime on my poor PII-400. I'll see
how the floating point functions work.
> May I ask a question here? How do you port things to vectors and make/use
>these "vector classes"? I've heard of doing this, but have no idea how it
>works.
The vector class itself is relatively easy (well, there are some funny
friend functions). I'll try to get my SGI test ported tonight to the
PC and update my website to include the current state of affairs.
Just choose your X/Y/Z axes. I've used X as left/right, Y as up/down,
and Z as forward/backward. Then a righthanded coordinate system (so my
right hand can show positive angles). The port was easy to get working
again yesterday, for example:
class RWheel { double forceLat,forceLong; };
forceLat=...;
forceLong=...;
becomes:
class RWheel { QVector3 force; };
force.x=...;
force.z=...;
Because lateral is horizontal, X axis, and longitudinal (what a nasty
word to type!) is the Z axis.
Ofcourse, this is half the story; I need to use the ENTIRE vector
where possible. So I can just do:
wheel.acceleration=wheel.force*gripCoeff;
instead of splicing the vectors up in:
wheel.accLat=wheel.forceLat*gripCoeff;
wheel.accLong=wheel.forceLong*gripCoeff;
Vectors are mainly easy, and the only really funny things about them
are the dot product (which is used for a number of things) and the
cross product. The dot product gives a way to calculate the angle
between 2 vectors, and the cross product delivers a vector that is
perpendicular to both vectors, and has a direction is known (when
using a righthanded coordinate system it is along the axis if you
rotate your right hand from vector 1 to vector 2).
Normal vectors for polygons are created using the cross product, then
normalized to have length 1 (because of lighting calculations
actually).
I won't go into much detail because of the amount of info on the net;
use google (www.google.com) to get extended information. For example
at http://www.ma.psu.edu/~herzog/em11/p04a.html
I'll copy the source to my PC now and see if the sound code isn't
bugging it too much and will try to put up a page tonight. Will post a
message here if I succeed.
Thanks for the help,
Ruud van Gaal, GPL Rank +53.53
MarketGraph / MachTech: http://www.marketgraph.nl
Pencil art: http://www.marketgraph.nl/gallery
Quoted text (10 lines)
>> totalForce=gripCoeff*normalForce (weight_of_car/4 for now) > >** Exactly.. Up to this part:** > >> forceLat=cos(slipAngle)*totalForce >> forceLong=sin(slipAngle)*totalForce > > I wouldn't bother calculating forceLong to get induced drag unless you wanted >to display it for some reason. When forceLat is applied along the ground plane >in the proper direction, induced drag will happen by itself anyway.Quoted text (12 lines)
> Perhaps this is really more simple than you are thinking. There are >basically two forces at each tire you should be concerned with right now. >Longitudinal (throttling/braking/drivetrain friction), and lateral (developed >by slip angle). > > Force_Lat = Slip_Angle * .1 (for now) > Force_Long = Wheel Torque/Tire Radius > > Force_Long can be changed to use slip ratio instead of a straight calculation >like this. It's more realistic and it lets you spin the tires as well as lock >them up. You can even tell your sim to make skid marks once a certain slip >ratio has been exceeded.Quoted text (9 lines)
>>What I'm not sure about is if I can just cap friction forces so they >>stay within maxGripCoeff*normalForce length, or if I have to add each >>friction force as it comes along. I'm afraid that might lead to errors >>when two similar friction forces are generated in the same direction, >>cause a friction force that could not exist in reality (namely a force >>twice as long). > > I don't understand what other friction forces you are referring to here aside >from lateral and longitudinal force.Quoted text (7 lines)
> As you are apparently already doing, calculate the maximum force the tire can >generate. I check the longitudinal force first. If it's greater than the >maximum tire force available, I limit it (longForce=maximum possible force). >If it is not greater, I leave longForce alone. > > Then, I use the Pythagorean theorem (I have no clue about vector calculus) to >limit the lateral force if necessary.Quoted text (8 lines)
>>Now what I think is I can 'just' take the rotational velocity of the >>wheel and calculate how much velocity that is in the X/Z plane of the >>car (v_translational=v_angular*r) and add this velocity vector to the >>equation to get the actual virtual contact path speed. >>Hope this gets across. Seems to me like the way to do it, right? >> > > Congratulations, you just reinvented what is called a "slip ratio".
Ruud van Gaal wrote:
I expect he meant Hertz, not kiloHertz.
> Just choose your X/Y/Z axes. I've used X as left/right, Y as up/down,
> and Z as forward/backward. Then a righthanded coordinate system (so my
> right hand can show positive angles). The port was easy to get working
> again yesterday, for example:
Yes, please use right handed coordinates. Save a lot of trouble in the
end. Most algorithms you will find here and there
assume right handed coordinate frames. Vector cross product
routines, for example...
X right, Y up and Z forward is not right handed, BTW.
If you put Z backward you will be right handed and ready
for a career as a "Weights" engineer (They are the only discipline
that prefers to stand in front of the vehicle and look backward.
They aren't responsible for moving it around and not bumping into
things though. ;)
The SAE suggests using X forward, Y out the right side and Z down.
Preferred standards for axis orientation are generally a religious thing,
but there's no reason to be a heathen. ;) Seriously, the first time
you read a book and it uses the standard set you will be annoyed
that they don't use your set. The 2nd through 20th book that uses them,
you might start to consider using a standard set yourself so you
can understand the text directly without annoying mental gymnastics ;)
Of course the SAE also ends up supporting the wierd standard
convention for the sign of the tires slip angle, so what does one do? ;)
These are not trivial subjects. I've been asked in all seriousness
several times in the last several years: "The artists new tool uses
blah blah blah coordinate systems, is it a big deal to change all
your algorithms and code to use the new one?"
I just squint and ask whether Texas has a three day
waiting period to buy handguns.... ;)
This book, available online from the www.SAE.org/bookstore
is excellent, covers in good detail what I've seen discussed in this thread,
and includes the SAE Standard for vehicle coordinate suystems and
vehicle dynamics terminology.
�Fundamentals of Vehicle Dynamics,� Thomas Gillespie, SAE,
Danvers, MA, 1992. ISBN 1-56091-199-9
- Matt
Quoted text (7 lines)
> > If you go the "slip ratio" route, you'll need to increase your sampling rate > >dramatically or the tires will be hoplessely unstable. I use 166Mhz to 300+Mhz > >in my model. > > I hope you mean 166kHz instead of 166Mhz?! > 166Mhz would not be able to go realtime on my poor PII-400. I'll see > how the floating point functions work.On 29 Aug 2000 23:18:52 GMT, [email hidden] (JTW62074) wrote:
>>Now I
>>have the 3D vector 'force'. Where forceLat==force.x and
>>forceLong==force.z.
>
> Gotcha. I use x_force and y_force here. For me, forceLat is perpendicular
>to the wheel heading, and forceLong is parallel to the wheel heading.
Ah right, I use Z+ as backward.
Slip ratio is in fact the magnitude (length) of the slip vector, I
would think. So the only difficult thing here is ellipsoid friction
circles, where slip ratio actually is different for slipVector.x and
slipVector.z (or y in your case). But because the vector is already
divided into (x,y,z) I can calculate slip ratio like this:
gripCoeff_lat = slipVector.x*tireLateralGripCoeff;
gripCoeff_long = slipVector.z*tireLongitudinalGripCoeff;
(so ellipsoid friction circles are possible)
However, I see problems at the horizon when the car is rotating, on 2
wheels for example. Then I think I will face gimbal lock. Hm. Might
not be a problem, because a wheel that is NOT on the ground has no
friction. I should check out the cross product vectors more perhaps;
more of that in another post.
Slip angle is the angle between the vector that is pointing forward at
the wheel (the wheel's direction, which way it is facing) and the slip
vector. That's something you can calculate with the dot product.
I believe: |A||B|*cos(angle) = A dot B
...
> Very good! I planned on just moving the CM if fuel loads or anything else
>changed. I like the wheel breaking off idea :-)
Hehe, most important! :)
In fact, I already tried breaking off a wheel. It works quite nice in
fact. (you can try in testcar.ini by removing one of the wheels in
car.wheels)
><snip section on vectors>
>
> Interesting. I still don't get it yet :-) What if there's a force pointing
>at 45 degrees along your x/z plane? Magnitude 100? How does that show up in a
>vector class? (1,1,0) ?
Leaving signs alone for a moment (45 degrees would come up with
(-1,0,1) in my system), the vector would be:
(sqrt(50),sqrt(50),0). Thus its length would be
sqrt(sqrt(50)*sqrt(50)+sqrt(50)*sqrt(50)+0*0), which is 100 again.
Vectors with length 1 (length=pythagorean like you're using here and
there already, I believe) are unit vectors. Unit vectors have some
nice properties, depending what you do with them.
My guts say that if I normalize the slipVector (so it has length 1),
that the friction force vector at a contact patch is EXACTLY
-u*slipVector (u=friction coeff, derived from the slipVector's
original length).
The vector (1,1,0) has length (via Pythagoras)
sqrt(1*1+1*1+0)=sqrt(2). Normalizing it would mean scaling the vector
by 1/sqrt(2), or more generically 1/length(v).
It's really nothing more than taking the lateral/longitudinal/vertical
forces together and using one structure to get a 3D representation of
what you're probably already dealing with on paper. :)
But worry, as after this you get rotation matrices, which are 3x3,
quaternions, tensors and all kinds of stuff that's around. However, I
won't need much of that I guess until gimbal lock comes along perhaps.
So that I get funny figures when trying to project my slipVector from
the car's local coordinate system to the world coordinate system.
Seems fair enough. Although I would soon break up the total torque for
each wheel. For one, I want to deal with heat one day, which has an
effect distinctly for each wheel, and if a wheel breaks off again, you
should not apply the total front torque to just 1 of the wheels
instead of dividing by 2. A reason for this is I don't assume 4
wheels, actually. I assume anything from 0 to 8 wheels currently.
Although 0 wheels doesn't really do anything to the body, like in GPL,
that's for much later.
...
Actually, both versions are the same. I call Z longitudinal, and X
lateral (and Y vertical). You call Y longitudinal, which is the same,
as long as we keep consistent. ;-)
...
Ah, indeed I am. Always thought 6DOF was the top you needed. Because
of the 3 dimensions of translational degrees, and the 3 dimensions to
rotate in. Well, this is not mathematically correct, I'm sure, but you
can deal with any orientation/position in the humanly visible world
with those 6 degrees. Let's NOT get into relativity and the 4th
dimension (time), where acceleration is suddenly m*s^-2*t^-2. ;-)
>>I hope you mean 166kHz instead of 166Mhz?!
>>166Mhz would not be able to go realtime on my poor PII-400. I'll see
>>how the floating point functions work.
>
> Geeze!! What an incredible error on my part! Of course, what I really meant
>was 166 Hz, not Khz, and especially not Mhz!
Phew, haha, that leaves more room for realtime simulation! GPL runs at
288Hz btw. Why the cap the framerate at 288/8 I don't know. Could have
been 288/4. But well, 36 fps is very nice. And, why 288? Why not 256
(if they're using fixedpoint arithmetic) or anything like 300 if just
using floating point. Hm.
Get out of the cave! C++ offers operator overloading so you can define
+ for a class, for instance. So class Complex and class Vector (note
to forget class String) suddenly become easy to use. Although I'm not
sure whether to use * for dot product or cross product, hm. Some
classes are using % as well. I'll still have to decide.
It's not that easy to distinguish between global operator functions
and class member functions though; in my source code (see my homepage
of Racer) there's still a qvector.cpp tucked away; I can mail you the
corresponding vector.h if you like, and some sample test code).
It's not that difficult even for the basics. And if you have a right
hand you can even predict the direction of a cross product vector. :)
Ruud van Gaal, GPL Rank +53.53
MarketGraph / MachTech: http://www.marketgraph.nl
Pencil art: http://www.marketgraph.nl/gallery
Quoted text (11 lines)
>> I'll >>probably try a slip *vector* soon instead of merely a slip *angle*. >>It's easier with the vector because the friction force is then just >>-gripCoefficient*slipVector. >>Nice thing is I can include the wheel spinning velocity in >>'slipVector' too. Things are looking good. > > Good enough! :-) You may want to keep the slip angle and slip ratio thing >in the back of your mind while you continue. If you decide to use real tire >data in your sim, this is how most of it is displayed. Good idea, though. >Hadn't thought of that!Quoted text (11 lines)
>>Ah yes, haha, braking. Almost forgot about that ;-) >>Will have to do some DirectInput stuff soon. Have no braking yet. >>That's a future subject; how torque is related to braking power. So >>braking=0..100, torque=0..-T; how does the graph go? Is it linear? >>I have negative torque too to do drivetrain and mostly engine braking. > > Linear was close enough. This is that graph again using the linear relation: > http://performancesimulations.com/partthrottle.htm > > As far as brakes go, I define a total braking torque that's available for all >tires as of now, with a setting for front/rear brake bias that alters this.Quoted text (9 lines)
>>> Then, I use the Pythagorean theorem (I have no clue about vector calculus) >>to >>>limit the lateral force if necessary. >> >>The vector method would be easier (IMHO); normalizing not to 1, but to >>gripCoeff*forceNormal. That keeps the ratio between forceLat and >>forceLong constant. > > You mean *your* version of forceLat and forceLong or mine?Quoted text (7 lines)
>>10? What are the 4 extra degrees? My visualization centers in my brain >>haven't been upgraded yet ;-) >> > > If I'm not mistaken, simulating 4 spinning wheels adds 4 degrees (as long as >you are actually calculating rotational velocity/accel/position of each tire >independently).Quoted text (10 lines)
> <snip more on vectors> >>So I can just do: >> wheel.acceleration=wheel.force*gripCoeff; >>instead of splicing the vectors up in: >> wheel.accLat=wheel.forceLat*gripCoeff; >> wheel.accLong=wheel.forceLong*gripCoeff; > > These are simply user defined types, right? I had no idea you could do >multiple operations in one statement this way. (I've been in a cave for a >while.) I'll have to start playing with these. Thanks!Quoted text (7 lines)
><Snip more on vectors, cross products, and dot products> > > This is great stuff! Thanks. I've got a couple 3-D books and get confused >how vectors and cross and dot products work, so I came up with my own way to do >3-D (probably first invented in 1720 or so). This is definately stuff I want >to learn. This link you posted :>http://www.ma.psu.edu/~herzog/em11/p04a.html >is great. I'll take a look at it now.On Wed, 30 Aug 2000 04:35:02 GMT, "Matthew V. Jessick"
<[email hidden]> wrote:
>
>
>Ruud van Gaal wrote:
>...
>> I hope you mean 166kHz instead of 166Mhz?!
>> 166Mhz would not be able to go realtime on my poor PII-400. I'll see
>> how the floating point functions work.
>
>I expect he meant Hertz, not kiloHertz.
He did, fortunately :)
...
>X right, Y up and Z forward is not right handed, BTW.
That's right; I use Z backward.
...
>The SAE suggests using X forward, Y out the right side and Z down.
>Preferred standards for axis orientation are generally a religious thing,
>but there's no reason to be a heathen. ;)
I'll wait for the book. In the mean time the book I based my system on
was OpenGL's Red book. OpenGL uses the coordinate system I use. This
way I can relate the what I'm painting. Perhaps XYZ is a bad name in
itself and forward/right/down should be used. Although v.forward=-2 is
a bit weird. We should have Delphi's properties so we can simulate
forward and backward being available, and mapping that internally to
v.z (or whatever). Great idea, Delphi's set/get methods.
>Seriously, the first time
>you read a book and it uses the standard set you will be annoyed
>that they don't use your set.
I'm sure it will. Have seen about ALL of the them currently, the
possibilities of axis systems.
>Of course the SAE also ends up supporting the wierd standard
>convention for the sign of the tires slip angle, so what does one do? ;)
One stubbornly makes up his own ;-)
...
I'll keep the tip in mind and perhaps purchase the book a little later
on. I am reading up on so many things at the same time, it's hard
putting actual time into the actual simulation! ;-)
Thanks,
Ruud van Gaal, GPL Rank +53.53
MarketGraph / MachTech: http://www.marketgraph.nl
Pencil art: http://www.marketgraph.nl/gallery
Quoted text (7 lines)
>This book, available online from the www.SAE.org/bookstore >is excellent, covers in good detail what I've seen discussed in this thread, >and includes the SAE Standard for vehicle coordinate suystems and >vehicle dynamics terminology. > > �Fundamentals of Vehicle Dynamics,� Thomas Gillespie, SAE, > Danvers, MA, 1992. ISBN 1-56091-199-9
Ruud van Gaal wrote:
If you move the wheels just up and down relative to the cars main
frame, then you have a 5 rigid body simulation with
6 DOF for the main body and 1 more for each wheel body.
If you maintain a "state" for each wheels rotation then
you are up to 14, if you add various rotating drive train
elements you are up to... ;)
;)
We had a software engineer that wanted to run rocket
software at 32, 64, 128 Hz, etc. It was pretty funny
to sit in the meeting with the lead engineers.
Controls Engineer: "It's not 64 Hz, it's 50 Hz.
We prefilter at 100 Hz, not 128 Hz."
Software Engineer: "But what does it matter?"
It actually is serious. There was experience
working at 50 Hz, and they have to be careful that
they maintain adequate frequency separation
between the guidance/navigation/control loop and
all the many many oscillations that take place
on a large rocket. Not to mention the characteristics
of the hardware that mounts electronics boxes
and lots of other odd concerns...
A rule of thumb for digital simulation is you want to integrate
100 times faster than the frequencies of interest in the dynamics
you are modeling. This is for people designing systems that
could kill people if they screw up. On PC's, one rarely has
enough processor for a real time system that also has to
display graphics to do this. If you use more sophisticated
integration techniques or accept some risk of instability,
you can drop that factor of 100 down quite a bit, but you
have to be very careful and methodical.
That would imply that for a road car with a soft suspension at 1.6
Hertz you want to integrate at 160 Hz. For a more sporty car
at say 3 Hz suspension, 300 Hz. Etc.
However, if you start using slip ratio and keep a state
for the rotation of the tires, the longitudinal forces
produce dynamics rather faster than these frequencies.
Depending on how you set up the car (springs, center of gravity,
etc.) you can get into situations where the pitch frequency
is significantly higher than the heave frequency.
Just be careful, and watch for problems.
And don't push it too far ;)
--
Matthew V. Jessick Motorsims
[email hidden] http://www.motorsims.com
Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216
Quoted text (10 lines)
> > If I'm not mistaken, simulating 4 spinning wheels adds 4 degrees (as long as > >you are actually calculating rotational velocity/accel/position of each tire > >independently). > > Ah, indeed I am. Always thought 6DOF was the top you needed. Because > of the 3 dimensions of translational degrees, and the 3 dimensions to > rotate in. Well, this is not mathematically correct, I'm sure, but you > can deal with any orientation/position in the humanly visible world > with those 6 degrees. Let's NOT get into relativity and the 4th > dimension (time), where acceleration is suddenly m*s^-2*t^-2. ;-)Quoted text (7 lines)
> >was 166 Hz > > Phew, haha, that leaves more room for realtime simulation! GPL runs at > 288Hz btw. Why the cap the framerate at 288/8 I don't know. Could have > been 288/4. But well, 36 fps is very nice. And, why 288? Why not 256 > (if they're using fixedpoint arithmetic) or anything like 300 if just > using floating point. Hm.On Sat, 26 Aug 2000 04:19:16 GMT, "Matthew V. Jessick"
<[email hidden]> wrote:
...
I'm still looking at this formula and can't visualize it correctly or
something.
As I see it, the angular_velocity of the car lies in the XZ plane (the
ground) and points along the circle that describes the wheel's
rotation around the car's CM.
The radius vector points from the car's CM to the wheel. Also on the
XZ plane.
So the velocity vector, if cross-produced, either points up or down?
I'm interested in this, because I now calculate the wheel velocity
(wrt the ground) in world coordinates using some cos/sin rules, and
I'm afraid this will bite me once the car starts rolling sideways
(weight transfer is high on the todo-list) or pitch-wise.
Thanks,
Ruud van Gaal, GPL Rank +53.53
MarketGraph / MachTech: http://www.marketgraph.nl
Pencil art: http://www.marketgraph.nl/gallery
Quoted text (18 lines)
>> >You should eventually calculate the components of velocity at >> >each tire contact patch due to the sum of the center of mass >> >velocity and also the component due to rotation of the tire >> >about the center of mass when you calculate the >> >angle between the tires orientation and its velocity. >> >> Yes, I already had a look into that. Shouldn't be too difficult in the >> beginning, because the direction of the wheel velocity is >> perpendicular to the car's CM, which is constant, and I have a >> variable containing the angular velocity (around the yaw axis), so >> |v|=ang.vel.*r (where r is distance from CM to wheel center). > >This is correct as a "scalar" (that is, non-vector) equation >and is useful if you already know the direction of the >velocity component. It's straight forward to calculate both the >size of the component and its direction using vector equations. > >velocity_vector = angular_velocity_vector Cross_Product radius_vectorQuoted text (8 lines)
>> Good enough! :-) You may want to keep the slip angle and slip ratio >thing >>in the back of your mind while you continue. If you decide to use real tire >>data in your sim, this is how most of it is displayed. Good idea, though. >>Hadn't thought of that! > >Slip ratio is in fact the magnitude (length) of the slip vector, I >would think.Quoted text (15 lines)
>>>> Then, I use the Pythagorean theorem (I have no clue about vector >calculus) >>>to >>>>limit the lateral force if necessary. >>> >>>The vector method would be easier (IMHO); normalizing not to 1, but to >>>gripCoeff*forceNormal. That keeps the ratio between forceLat and >>>forceLong constant. >> >> You mean *your* version of forceLat and forceLong or mine? > >Actually, both versions are the same. I call Z longitudinal, and X >lateral (and Y vertical). You call Y longitudinal, which is the same, >as long as we keep consistent. ;-) >Quoted text (10 lines)
>>>> Then, I use the Pythagorean theorem (I have no clue about vector >calculus) >>>to >>>>limit the lateral force if necessary. >>> >>>The vector method would be easier (IMHO); normalizing not to 1, but to >>>gripCoeff*forceNormal. That keeps the ratio between forceLat and >>>forceLong constant. >> >> You mean *your* version of forceLat and forceLong or mine?
Ruud van Gaal wrote:
The angular velocity vector for a right turn is
downward, into the ground. Stick your right thumb out,
point it down, notice that your fingers curve around to the right
(clockwise if you looked down on them along the axis of your thumb.)
If that didn't work, forget I mentioned it ;);)
Actually, that seems to be a common way people are taught
to remember how to rotate a body in the standard "positive"
sense around an axis described by a vector. Seriously ;)
BTW, if you write right handed, always put down your pencil
before performing this excercise. Otherwise, you will be tempted
to use your left hand. You'll end up backwards, with a "left handed"
coordinate system ;) (Sorry, I don't know any better coordinate system
jokes!)
Since a right turn is a positive rotation around a body coordinate
axis pointing downward into the Earth, and the right turn adds
to ones compass heading, it is intuitive to use a positive
yaw rate for right turns. This is why it is a very common
standard in vehicle dynamics to put the yaw axis pointing
down into the Earth. (subtle plug for standard vehicle
dynamics coordinate systems ;)
Artists often insist on pointing the yaw axis upwards.
I feel that as the guy doing the complicated work of moving
things around the world right side up, upside down and sideways,
the vehicle dynamics conventions should prevail.
After all, artists can instantly notice when one of their
building objects is upside down. Our errors are more subtle ;)
Back to angular velocity:
Positive angular velocity (right turn) points downward.
If the car was stopped, parked on ice pointing North,
and someone twisted it rightward in yaw, then the
velocity at the first instant of motion of the left front tire
would be approximately North East.
The component is
angular_velocity_vector cross vector_cg_to_wheel
and for a front wheel, will point generally to the right.
(perhaps near North East for the left front, etc.)
Right thumb down along angular velocity vector,
right index finger points North West from cg to left front wheel,
right second finger forms the third axis of the righ t handed set
points to the right roughly north east, 90 degrees from both of
the others. (This is the result of the
cross product = thumb_vector cross index_finger_vector ;)
Seriously, walk past any engineering test room and you will see
several people making these wierd gestures at their test papers
at any given time ;);)
Usefully, this is the same component whether the vehicle is going North
at speed and starts to turn, or when its center of mass is stationary
and it rotates on the ice pad.
At speed, the wheels velocity in the world is
vector_of_cg_velocity +
(angular_velocity_vector cross vector_cg_to_wheel)
This is true in general for any point on the rigid body.
Imagine a navigation engineer using it to correct for his
navigational accelerometer box being on the top
end of a rocket 50 feet above the CG.
So much for equations, now draw a picture ;)
Luck,
- Matt
>
> I'm interested in this, because I now calculate the wheel velocity
> (wrt the ground) in world coordinates using some cos/sin rules, and
> I'm afraid this will bite me once the car starts rolling sideways
> (weight transfer is high on the todo-list) or pitch-wise.
Quoted text (16 lines)
> >This is correct as a "scalar" (that is, non-vector) equation > >and is useful if you already know the direction of the > >velocity component. It's straight forward to calculate both the > >size of the component and its direction using vector equations. > > > >velocity_vector = angular_velocity_vector Cross_Product radius_vector > > I'm still looking at this formula and can't visualize it correctly or > something. > As I see it, the angular_velocity of the car lies in the XZ plane (the > ground) and points along the circle that describes the wheel's > rotation around the car's CM. > The radius vector points from the car's CM to the wheel. Also on the > XZ plane. > So the velocity vector, if cross-produced, either points up or down? >On Fri, 01 Sep 2000 03:42:07 GMT, "Matthew V. Jessick"
<[email hidden]> wrote:
...
>> >velocity_vector = angular_velocity_vector Cross_Product radius_vector
>>
>> I'm still looking at this formula and can't visualize it correctly or
>> something....
>The angular velocity vector for a right turn is
>downward, into the ground.
Ah, that's where I went wrong then! I didn't know the angular velocity
is actually the axis of rotation.
Thanks for the elaborate and fun read :)
I will still us Y+ as up though; I'm more used to having a car float
in the air when Y>0. All my car rotations are counterclockwise along
the axes, so indeed heading=-rotation_around_Y_axis. But heading's
just a statistic.
And I'm sticking to the coordinate system I have now (OpenGL's);
yesterday I had a lot of trouble with the slipVector, and now almost
all negation signs have disappeared and things are working much
better. Still have some bugs here & there relating to 'in what
coordinate system was this vector again?'. Which only appears when you
start rotating the car. I do a lot of throwing with the car in every
direction and with different headings :) Hard to get right with
drawing endless pictures.
Also, the vector arithmetic seemingly is wiping out a lot of cos/sin
functions. Great stuff. :) One day rotation will probably be a matrix
even.
>Seriously, walk past any engineering test room and you will see
>several people making these wierd gestures at their test papers
>at any given time ;);)
I myself have been stretching my fingers to get a nice perpendicular
look. ;-)
>Usefully, this is the same component whether the vehicle is going North
Hmm, the terms North/East etc are not so bad; at least they all go in
the same direction. :)
...
>So much for equations, now draw a picture ;)
Hehe, I have been while reading this actually.
Thanks for the visually enlightening talk.
Ruud van Gaal, GPL Rank +53.53
MarketGraph : http://www.marketgraph.nl
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
On 31 Aug 2000 23:55:29 GMT, [email hidden] (JTW62074) wrote:
You're right. I'm mixing slipRatio and slipDifference here.
I would think the gripCoefficient of a tire would be based more on the
slipDIFFERENCE than the RATIO though. In the end, the contact patch
has a relative speed to the surface which is deciding how fast it is
moving with respect to the ground, and that should give the kinetic
friction coefficient.
>Perhaps I'm mistaken here, but I use something like the latter equation (unless
>the tire is rotating slowly enough to become unstable, then I switch to
>something like the first equation).
I actually use the first all the time. But indeed, when the slipVector
(which I use; which is just a world coordinate vector pointing into
the direction of the slipping) is very small (<1), I multiply the
force because by slipVector.Length() (which is <1, so the force
becomes smaller as well).
Works very nicely.
The nice thing about the slipVector is that I included the contact
patch velocity WRT the ground. This way, when you throw the car
forward, the wheels start rotating and the car decelerates until a
stable velocity is found (I have for the moment thrown out negative
torque to see what it all does).
...
> Rotating on 2 wheels shouldn't be a problem. As you implied, the force is
>grip_coef * normal_force, which is 0, so the force will disappear
>automatically. Works fine for me when a wheel comes off the ground.
I hope so. Weight transfer is nearby, so the first two-wheeler should
not be long.
>>I believe: |A||B|*cos(angle) = A dot B
>
> I still don't understand how this is implemented and represented in code:
>
> |A||B|*cos(angle) = A dot B
Here's an extract from my vector class:
double QVector3::Dot(const QVector3 &v1)
// Returns dot product with another vector
{
return v1.x*x+v1.y*y+v1.z*z;
}
So to get the slip angle, you take the wheel velocity (in world
coordinates), and the wheel's theoretical direction, and:
cos(angle)=A dot B/(|A||B|), so angle=acos(...)
I don't have that function yet in my class.
> I'll have to study the vector link you gave me. Do you have other similar
>links handy?
http://theory.uwinnipeg.ca/physics/twodim/node2.html#SECTION00310000000000000000
for example, which is in the middle of a whole lot of physics info.
> I've just broken all my tire forces into their proper directions
>(almost, there's a little bug there somewhere of course!) I used rotation
>equations to get the local tire forces projected into the world coordinate
>system. I think my method is pronounced "SLOW and CONFUSING" if I'm not
>mistaken.
I have confusing stuff too. Spent a lot of hours yesterday evening
getting the coordinate systems a bit right. Lots of negations
disappeared.
The only place I really use cos/sin now is to convert from car to
world coordinates, and back. The coordinate systems was a source of
bugs as well; mixing car and world coordinate vectors.
It now works marvelously (CURRENTLY, every tweak might disturb that :)
So I can for example throw the car to North-east, with the nose
pointing northwest, and the car will neatly stop because of sideway
friction.
And when I put the nose 45 degrees to a direction, and throw it
sideways (translation), it both decelerates AND gets a velocity
forward or backward, with rotating wheels etc.
Hope to get some more work done in the weekend, although I'm pretty
busy already.
> >My guts say that if I normalize the slipVector (so it has length 1),
>>that the friction force vector at a contact patch is EXACTLY
>>-u*slipVector (u=friction coeff, derived from the slipVector's
>>original length).
>
> Yes, I think you are correct and the approach will work well.
It does indeed :)
> What I've been
>doing is keeping slip ratio and slip angle seperated so real or simulated tire
>data can be used later. Since I don't know anything about the vector
>techniques you're talking about, I'll assume you can easily pull the same
>information from your vector classes and do the same thing if you eventually
>want to.
That's right. For slip Ratio however I'll have to store the vectors
that I calculated slipVector from; wheel ACTUAL velocity and wheel
THEORETICAL velocity.
...
> I explained that incorrectly. What I meant was, each wheel (in my model) has
>a maximum braking torque that it can produce independently of the others. If a
>wheel comes off the ground (or breaks off, which mine doesn't do!), the other
>wheels braking capabilities don't change. I don't get twice as much torque
>from a brake sent to one wheel.
Ah, ok. Good. :)
...
Ah, things are getting confusing indeed. :)
I actually have 3 coordinate systems; the tire's, the car's and the
world's. Longitudinal I call anything that is along the North/South
(Z) axis of a coordinate system. Doesn't matter which system actually.
...
> What I was referring to is limiting the lateral force (how about side force?)
>or the longitudinal force (throttling/braking force) somewhat appropriately,
>using nothing but the two simple/starting equations posted earlier for
>estimating some forces from slip ratio and slip angle.
Ok, though I now use a force Vector which results from the slip
Vector. So long/lat is no longer an issue and I work in local or
global XYZ. The vector's make it easier doing them all in one step.
> I meant that the vector sum of the two (or the total force actually being
>produced in "some" direction), shouldn't be allowed to exceed coef_grip *
>normal_force. If it did, then *my* version of lateral force (perpendicular to
>the tire's direction) gets limited by the Pythagoreum Theorem.
Yup. I still have a 'bug' I think because I'm separating the effects
of motor_torque -> friction_forward_on_the_car, and slip_vector ->
slip_opposite_force. Which might make the total friction more than is
possible. But well, it was late last night. ;)
And having a little problem with drawing my forces; I want to draw
local force vectors at the contact patches, but these are mostly in
world coordinates, but the whole thing gets rotated in OpenGL (as it
should), so I'll have to convert here & there. It helps visualizing
what happens though, instead of constantly looking at numbers and
visualizing myself.
> Is the vector system a computationally less expensive way of accomplishing
>this, or does it just make it easier to code/work out?
In the end, it will probably be less expensive. After the vector, you
get the matrix, which can get rid of some cos/sin calls if you have
it.
Other that that, it doesn't make too much of a difference. Perhaps
it's a bit slower because 3 coordinates get calculated all the time.
But in coding terms, it is really much, much easier. My code has
definitely become much smaller already. And less errors when
calculating.
> BTW, what is gimbal lock??
Try a flight sim. Fly your F-16 right up to the sky. Now change your
heading. Next, try changing roll. It's the same thing!
Gimbal lock is when a rotation along an axis has led to the 2 other
axes of rotation falling on top of eachother (something like that). A
problem with plane and world coordinates/angles.
If you try to make a flight sim, you'll find out. Quaternions are a
way to go around it, but these I have used only once some time ago,
and I don't really understand the math principles behind it yet.
Ruud van Gaal, GPL Rank +53.53
MarketGraph : http://www.marketgraph.nl
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
Quoted text (8 lines)
>>Slip ratio is in fact the magnitude (length) of the slip vector, I >>would think. > > Slip ratio isn't the magnitude (unless I'm visualizing or interpreting your >definition incorrectly.) If it was, wouldn't: >slip_ratio=TrueRotVel - FreeRollingRotVel instead of >slip_ratio=TrueRotVel / FreeRollingRotVel >?Quoted text (11 lines)
> In your version, you call Z (how about North/South?) "longitudinal" and X >(East/West) "lateral". > > I call North/South "Y" and East/West "X". That's it. I don't refer to >EITHER of these as lateral or longitudinal force. > > For me, lateral and longitudinal force (geeze, you're right, that is a big >word) are relative to the **TIRE'S** axis, not the ground plane. For me, >longitudinal force is going in the same direction the tire is rolling, (ie, >throttling or braking force) while lateral force is at a right angle to this >(produced by slip angle and load) .
Ruud van Gaal wrote:
> Still have some bugs here & there relating to 'in what
> coordinate system was this vector again?'.
One trick is include the coordinate frame in the vector name,
then it is more obvious if you are using it incorrectly.
I have World frame, Body, Wheel, Tire, Driver body, Driver head,
Camera, Viewpoint, Track, NED (North-East-Down), etc., etc...
so it is easy to become confused otherwise.
- Matt
