rec.autos.simulators

To get a clearer progress on car editing, I'm trying to get my sim to
use the GPL-type cars. This will make comparisons easier so searching
for faults in the physics is easier.

As always, differentials are not really my piece of cake, but well.
I'm trying to come up with a nice pipeline'd tree structure which
describes the driveline, like:

      E
      |
      clutch (not really a component)
      |
      G
      |
      CD
     /  \
   FD    RD
  /  \   / \
 FL FR  RL RR

Where E=engine, G=gearbox, CD=central differential, FD/RD=front/rear
diff, FL/FR/RL/RR=frontleft upto rear-right wheels.
The idea is still to be worked out completely, but I have a hunch that
I start a torque flow at the top (the engine) down to the bottom, add
input from below (road reaction and braking forces) and after all
that, I calculate results using something like:

acceleration=totalTorque/(inertiaUpstream+inertiaDownstream)

Where ofcourse I'll meet problems probably that braking torques don't
really behave like applied torques, but as potentially applied torques
(so I don't think I can just add braking torques to the whole system).
Don't know yet how to tackle that (some time ago some discussions were
done about locking axles when braking was applied; like a lock mask
for each diff; formulas get really complex if you want a closed form
for a 3 diff car).
The above btw is for a rally car with 3 diffs, and the GPL cars
ofcourse have only 1 diff. The differential is, so far I know, a
Salisbury one. Which means clutches. Now, let's throw in some points:
- Each clutch has a certain maximum torque it can generate; this is
much like a brake (in that it only generates torque when requested
to). Right?
- How much Nm (torque) could a clutch approximately generate, or is
this somehow calculatable from GPL's settings.
- When the diff actually starts slipping (when the torque bias ratio
is crossed), can I assume the clutch will counter with exactly its
maximum torque (i.e. just like static and dynamic friction, IF the
clutch starts slipping, won't its locking torque diminish by half for
example; the same if you push a cupboard; once it starts sliding, it
is much easier to keep it sliding).
- I have a formula which seems to give the torque bias ratio;
cos(angle)*(1+clutches). Clutches come in pairs. You have 2 angles in
GPL; power on and power off (engine braking).
So for 2 clutches and 30 degree angles, you get cos(30)*(1+2)=2.598.
Would it be right if I took this as the torque bias ratio? I'm not too
sure namely.

So I would keep the diff locked until the torque bias ratio (and
preload) is overcome, then start unlocking, where the clutches keep on
generating their maximum torque to try and keep both wheels rotating
at the same speed. Not too sure if this is what the diff does, since a
diff is said to 'open up' at high torque differences, and this seems
more like a brake which can only apply so much torque. At its limit,
it just keeps trying to lock the axle with its maximum available
torque.

Thanks for any comments on this,

Ruud van Gaal
Free car sim  : http://www.racesimcentral.net/
Pencil art    : http://www.racesimcentral.net/

In other words, the torque doesn't flow until after you've
solved the particular equations of motion for your current
situation. And to do that, you have to look at the situation
as a whole. So as seductive as object oriented philosophy is
in this physical problem with well defined objects... the
utility is limited, because some object has to coordinate them
all. To do that, it has to know almost everything about the
internals of each object.

--
Matthew V. Jessick         Motorsims

Vehicle Dynamics Engineer  (972)910-8866 Ext.125, Fax: (972)910-8216

Although, as long as inertias of all wheel assemblies are the same, the
proposed approach could work; I'm still checking it out (so little spare
time!), but I thing that it should turn out OK (as long as the wheels
aren't locked).

-Gregor

Sounds too bad. You would say in real life all the objects are
themselves unaware of all the surrounding objects, so it would map
somehow to programming objects as well.
Ok, I'm warned, perhaps Gregor can work out a subscenario that works.

Thanks,

Ruud van Gaal
Free car sim  : http://www.marketgraph.nl/gallery/racer/
Pencil art    : http://www.marketgraph.nl/gallery/

You can still do Object Oriented design. But because of the tight
coupling you lose many of the more powerful benefits.

Usually for real time simulations one ignores
very high frequency transients in favor of assuming
a quasi-static scenario. We ignore stuff like the
"play" between two gears and exactly how the teeth
bounce back and forth or bend each other.
When you slam a car into gear, all the parts of the
drive train give a mightly lurch and at very high
frequency they all affect each other and come
to a concensus ;) about how fast to accelerate.

All this very high frequency colliding and scraping is
what lets the real life engine ignore what the surface
characteristics under the left driving wheel are.
In the real time simulation we usually say:
        "OK, I'm going to ignore the colliding and sliding:
just give me your best guess at what the "steady state" result
a millisec or so after the very short transient following my
control step."

But to do this you need to write equations to solve for
all the variables that characterize the steady state
condition. Because the surface to tire friction
characteristics affect the steady state solution,
they have to be included in the equations and thereby
affect the engine acceleration.
In real life, the parts just nearly instantly
BangBang.Bang scrape ..scrape... hhhhuuuummmmmmmmmmmmmm ;)
their way to the new steady state condition without
being directly affected by any parts that aren't directly
in contact with them.

The real time function that is doing the coordinating
(solving the equations of motion) has to ask pretty much
every object along the entire drive train for a large
amount of detailed infomation before the equations of
motion for the engine acceleration (and most everything
else and at the same time, unfortunately ;) can be written
and solved.

Until the engine acceleration is known, the engine

output to the clutch isn't known precisely, because

a significant part of the engine power is used to

accelerate the various rotating pieces of the engine.

And so on down the entire drive train.

This is why the software objects are so tightly
coupled. You can't really distribute significant
amounts of important processing down to the objects
like you can for a User Interface, for example.
--
Matthew V. Jessick         Motorsims

Vehicle Dynamics Engineer  (972)910-8866 Ext.125, Fax: (972)910-8216

  It's really unlimited.  The ramps are pressed together according to how hard
the two ends are twisted.  If the *ratio* goes beyond the maximum allowable,
then it'll slip.  It's wierd, but that's how it works.

 >- When the diff actually starts slipping (when the torque bias ratio

   I don't think you need to account for differences between static and dynamic
friction in the clutch.  If the torque bias ratio is exceeded, the excess,
remaining torque accelerates the wheels away from each other.  If they're at
different velocities but not exceeding the max torque bias ratio, the "current
bias ratio" (not the maximum value you're talking about here) provides the
amount of torque that accelerates the wheels towards locking.

  Cool.  I'll have to try that out :-)  I don't think this is right though, as
the friction coefficient of the clutches ought to have something to do with it
too.  Perhaps something like:

cos(angle)*(1+clutches * friction_coefficient) ?

  Actually, it's probably dependent on the total clutch area rather than the
number of clutches, but the formula you're using gives really good numbers.  I
recommend sticking with that one :-)  Mind if I borrow it? :-P

  Get rid of the thought that the brake "can only apply so much torque."
Instead, you'll be calculating the clutch "brake" torque according to both
wheel's input torques and the bias ratio at every time step.  It can be
infinite.  That doesn't make sense at first really, but for instance, turn to
RCVD page 742, top picture.  Assuming a 2.90:1 torque bias ratio:

  With RH wheel at (almost) 375 and LH at 125, right at the border where the
axle is still locked, there would have to be 250 lb-ft of torque to keep it
locked.  

  With RH wheel at (almost) 750 and LH at 250, right at the border where the
axle is still locked, there would have to be 500 lb-ft of torque to keep it
locked.

  In both of these cases, being on the border of the graph, the ramps press the
clutches with enough force to provide *exactly* enough torque to keep the
wheels locked.  You could extend these shaded areas towards infinity and the
clutch torque would go right up with it.

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

Just thinking that some sort of wind-up model might ease
the equations and allow discrete calculations for each
component, although what it'll do to the overall processing
power required I don't know.

It certainly worked tidily to prevent the engine running
away in my final year project model - I had to replace the
"etherdynamic" connection the previous author had left in
there ;-)

HTH,
Jonny

...
...

Years ago we measured static and sliding friction on some diff clutch
plates (from something like a Salisbury type diff).  The ones we tested
were partly submerged in lubricant and the tests we did indicated that the
static and sliding friction were the same, no change in torque after the
relative motion starts up.

So that should simplify your life a bit...

-- Doug Milliken

Oh, and I agree with everything you say :).

-Gregor

So if I have a max bias ratio of 2.0, and T1=100Nm, T2=150Nm, then I
have:

currentRatio=1.5
lockingTorque=(maxRatio-1.5)*(150-100) = (2.0-1.5)*50 = 25Nm.

Right? (if I try another route, I get different answers; if I would
say, 'max ratio is 2, so MaxT2=2*T1=200Nm; as it's only T2=150Nm right
now, we have 50Nm of locking torque'.

Notice an error in the above function; it should be:
cos(angle)*(1+noofPlates), so noofPlates is 2*clutches (2 plates per
clutch).

You'd say so yes, hm.
Perhaps the entire cos()... result must be denormalized with a factor,
where factor=1 means a clutch with x Nm (where x is unknown ofcourse).
I don't know, I'll perhaps try and use it and see how it feels.

Not at all. Hope it doesn't mess up your calculations though. ;-)

Thanks for the help sofar. 3 more questions:
1. When we talk about the bias ratio, is this purely the tire reaction
forces (road friction + brakes + rolling resistance), or is the input
torque affecting the ratio as well?
So: ratio = T_reaction_1/T_reaction_2
or is the ratio affected by the *input* torque (from the engine) as
well?

2. Where does the input torque come in? If you have a bias ratio which
is lower than the max ratio, you get a moment (let's call it M1) which
rotates the wheel velocities towards eachother, but how do you split
the input torque across both axles/wheels then? Just even? (with the
M1 added to the one and subtracted to the other)

3. What if one of the wheels gets locked by the brakes. A wheel brake
only applies as much torque as is needed to keep the wheel from
rotating, as long as the brake is capable to generate that amount of
torque. It seems then you can't just write down a closed form that
immediately states the resulting torques of the system
(engine->diff->wheels) (but perhaps with a shoot-and-correct method
you may get close enough in a couple of steps).

Thanks again for the help, I have a hard time grasping what these
gears exactly do in mathematical terms.

Ruud van Gaal
Free car sim  : http://www.marketgraph.nl/gallery/racer/
Pencil art    : http://www.marketgraph.nl/gallery/

Ruud van Gaal
Free car sim  : http://www.marketgraph.nl/gallery/racer/
Pencil art    : http://www.marketgraph.nl/gallery/

  Looks good, thanks.  Although I think that specifies far more locking than
you actually get in GPL.  You might put a factor in it (maybe .15 to .5) to
bring the bias ratio down.  With a low, wide track car like GPL's cars, a
torque bias ratio of 2-2.5 will probably keep the axle locked at all times
(except when flipping through the air like I usually do, of course.)

  If it does, I'll have to hunt you down and run you over with a Brabham :-P

  Input torque from the engine doesn't effect it, it's purely tire reaction
forces.

  I do it evenly and it works right.  

  This one I haven't given much thought to yet.  We're getting into classified
areas right now anyway, I think :-)  

  I'm still not really willing to share the specific algos yet, sorry.  I can
say though that when testing it in Racer, just display the current, calculated
bias ratio you're coming up with at all times.  If, when cornering, one wheel
goes up in smoke and the torque bias ratio locks itself to the max you've
specified, you've got it right.

  Sorry for being a *** about this  :-(

  Actually, I might be persuaded to share if someone could provide me with a
dll that plays wav files at different frequencies and volumes.....  :-)

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://www.racesimcentral.net/

Ah thanks, I'll have to see when I get round to creating a single
Salisbury differential.

Hehe, not like THAT has never happened before to me. ;-)

Ah, right, thanks. Weird things these differentials. Utterly brilliant
though. :)

Ok, thanks again.

Lol. I'm afraid so. :)

That's ok, oh, but let's read on...

Hehe, that's easy. Go to www.fmod.org and download their fmod. Comes
free for free applications, and for not much for commercial
applications. I even believe Chris is using it at this point (he
recommended it to me). It's a single FMOD.dll (you downloaded it with
Racer v0.4.8) and gives you WAV loading, as well as MP3, whatever, and
plays back in 2D, in 3D (software or hardware), with varying
frequences, volumes, the works. I must say, great API, and great
functionality (splined interpolations etc).

So where were we. ;-) No but you help enough as it is. I'll have to
hunt Gregor to get me the formulae for a 3 differential pipeline,
hehe. Almost impossible if you want to vary the differential types.
Fortunately the GPL cars have just 1 diff.

Ruud van Gaal
Free car sim  : http://www.racesimcentral.net/
Pencil art    : http://www.racesimcentral.net/

  Well that was just too darned easy!  No deal! No deal!  lol    

  I was thinking about 3 diffs today and might be able to pull it off in closed
form, complete with torque bias ratios at all 3 spots....  Will let you know if
it works and might share a little....  a little ;-)   Of course, when I need
your help doing some of the outrageous things you've done with Racer's graphics
and such, you will probably tell me,"Remember when.......and Gregor helped and
you refused?"  

  Hmm......   lol

  That's great that Chris pointed you in FMOD's direction...  He doesn't talk
to me anymore :-(  

  Thanks for the tip though, I'll check into it.  The problem is, I don't work
in an OOP environment and would have to write my own headers for it in all
likelihood (good luck), so it may not be an option.  Right now, I use an
interuppted sine wave system for sound.  It's great on a laptop, as throttle
position effects the sound too, but not so great if you've got any bass in your
speakers.  It humms a bit.  

  Speaking of sound, I actually got around to running the exhaust profile from
one of my engine sims through the speakers.  It actually sounded like a real
engine at low rpm's, but turned into an annoying high pitched sound at mid to
high rpm.  Still, I think there's potential there once I get all 8 or whatever
cylinders running through a proper exhaust system.  Sometime in 2030 maybe....
;-)

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

LOL! First use a search engine before you request software, hehe, it's
mostly all there on the net. :)

A little note saying 'Yes I got it in closed form, it's really quite
easy'? ;-)

Lol, sure. Not too sure yet how I'll do rain and reflections in
puddles. And have to get a look at GT3 one day on a PS2 and see how
it's looking. But still, looking at actual races is best to estimate
why the computer graphics still look too clean. A lot has to do with
lighting, it seems.

Hm, he might just be busy; he sometimes doesn't read or respond to
email for quite some time.

It's C, not even C++, and I think there are tutorials for VisualBasic
as well, which may map very nicely onto PowerBasic.

No intermixed wave samples?
I'll have to give Staccato a buzz again I guess; once mailed about
their pricing, but never got a response. It seems it lets you mix
actual wave samples and give a ring to that. People start complaining
about the lack of detail in the sound engine at this point. ;-)

Good luck with that. :) May depend a bit on how you interpolate your
sound; sound cards are using splined interpolations and what not. Just
like graphics cards no match for software solutions anymore almost.
FMOD has nice interpolation routines; I'm not much into doing audio
stuff myself, so that's a relief.

Ruud van Gaal
Free car sim  : http://www.marketgraph.nl/gallery/racer/
Pencil art    : http://www.marketgraph.nl/gallery/