rec.autos.simulators

Just to check that I have things right :

1. The engine works at some RPM (controlled by the throtle)
2. From that RPM we get an engine torque
3. This gets multiplied by a gear factor...
4. ... and a differential factor
5. The resulting torque is applied on the wheels

Now a few questions :

1. Assuming that I'm modelling an open differential, how do I know how much
of the engine torque it transmits to each wheel? I've read that the portion
of the engine torque that a wheel gets is inversely proportional to the
'resistance' on the wheel. i.e. if one wheel is on top of ice and the other
on tarmac, the first wheel will get most (all?) of the engine torque.

So how do I determine the wheel's 'resistance'? I guess if the wheels are
sitting/moving on different types of ground (ice, tarmac, etc) then I could
use the friction coefficient. I'm more interested however on a car turning
on tarmac. Since the outer wheel need to run faster, it needs to spin
faster, i.e. it needs more torque. Is there a way to model this so that the
required portion of the engine torque comes out of the math?

2. How is the engine RPM affected when you press the throtle? Obviously it
increases, but by how much? Would the following procedure be correct?

At every integration step :

1. Adjust engine RPM depending on throtle position
2. Follow the above procedure to work out torque on each wheel
3. Integrate quantities (e.g. using Euler)
4. Determine wheel RPM and make the engine RPM equal to it

The last step troubles me the most. If both wheels rotate at the same speed,
then it might be right, in the sense that the wheels will slow down (due to
rolling friction), making the engine RPM drop (which is what I'd expect).
To keep the car running at constant speed, you'd need to press the throtle
just enough to produce the torque to overcome rolling (+ internal)
friction. great!

But what happens if the wheels are rotating at a different speed (e.g. when
going around a corner)? Do I use some proportionality factors as in the
differential?

Anyway, sorry for the long post and I'll be grateful for any replies. The
questions might be a bit basic, suggesting that the person asking them
doesn't really know much about how cars work....which is true! ;)

--
Morfeas

The procedure of my solution is thus:

1. Get engine torque due to the current RPM possibly using a look up table,
(if launching, the current RPM will be the idle RPM) and
relate it to the throttle.

2. Apply this engine torque as an output to the flywheel to get a flywheel
acceleration.

Now this is where things start getting tricky for me!

3. Get the speed of the rod going IN to the differential from the engine by
multiplying the flywheel speed
  by the clutch amount (if engaged, 1.0f, if not 0.0, and anything else in
between) and dividing by the currently
 selected gear ratio.

4. For now, for simplicitys sake, apply the same amount of torque to both
wheels.

This next bit gets even more confusing for me!...
5. Get the road reaction torque from the wheels, and use it as a resistive
torque against the clutch. Multiply (?)
by the torque ratio.

6. Put this resistive torque back in to the clutch, which will in effect
fight against the engine flywheel.

7. Apply this resistive torque at the flywheel to the engine speed, which
will reduce it. Doing this will mean that
for example if you pull a wheel spin, the resistive torque will fight
against the engine and bring the rpm back down.

My main problem in this is getting the different accelerations of the rods,
as they are based on torque/inertia of the
drive train. If you have read Ruud Van Gaals page (racer.nl) there are
documents about the squared inertia equation
for two gears. Then the most difficult part for me is getting the resistive
torque and putting it back into the engine. This is where
my implementation is currently failing as my wheels spin, and the car starts
moving, but the rpm does not reduce so as the
rpm redlines there is no torque left to power the wheels and things start
going wrong as I am at 1mph in 6000 revs :(

To do it properly, you cannot make a direct link between the wheels and the
rpm (clutch effects and inertias) , but it can
 be used as a guide so that you know what the rpm *should* be.

Let me know if you get a solution!

Regards, Alex

Only indirectly; especially when you add a diff, first get the engine
right. At a certain RPM the engine has a POTENTIAL torque that it can
output. The throttle then roughly interpolates between no usage of
that torque and max usage.
As you also have engine slowdown due to friction and cylinders pumping
(etc) you can do something like:

- Get a torque curve; at RPM x you have y torque available.
- Get a slowdown curve; as this is mostly linear you can use a formula
instead: T_min=coeff*rpm

Then the engine must become its own rotating entity; engRotVel,
engInertia. Throttle gets used like this:

- T_min=coeff*rpm
- T_max=torqueCurveValue[rpm]
- throttle=getInput() (assume 0..1)
- T_engine=throttle*(T_max-T_min)+T_min
(the engine torque output)

Then you use the T_engine to accelerate the drivetrain. That's where
things get tougher, but in the end it's a whole system with an
effective inertia (indeed note the squared inertia effects that Alex
noted on my site).

Going out towards the wheels, the torque will be T_input/2 at both
wheels (that's open diff specific). See RCVD; it has a chapter on the
open and locked diffs.

Not the torque that goes there; actually the reaction torque (which is
~0 for ice) doesn't fight the input torque as much as the tarmac side,
so the wheel on ice accelerates much faster.

That's the road reaction force; the track surface pushing back, as a
result of the tire spinning at a different speed from the surface
moving underneath it (called 'slip ratio'; 'slip velocity' is actually
less important).
Use Pacejka or just F_road_reaction=slipRatio*anotherCoeff for a quick
starter.

Multiple ways, and some may be more elegant or understandable. Some
use a balanced and off-balanced way (like Gregor Veble and Todd
Wasson; try googling for those names and 'Car physics' in RAS). Try
getting your hands on a Lego differential (Tecnic) and things may get
clearer.
Important is to check the end results;
(vel_out_1+vel_out_2)/2=vel_input (not taking into account the gearing
ratio)

I still at one point want to do a full Lego-diff simulation, to check
what the diff is doing visually. Would be fun. :)

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

Once the clutch torque is overcome (T_engine>T_clutch for example),
the clutch starts slipping (note that T_clutch can be made dynamic
depending on the clutch pedal input).

Then you have 2 assemblies; 1 is the engine, the other is from the
clutch onwards. I think in my Racer I'm making a mistake somewhere:
once the clutch starts slipping, what is the effective inertia of the
entire drivetrain? Does it include the full engine's inertia, or just
a proportional part of it? (there's a bug in Racer where pressing the
clutch fully and braking does not do the same thing as putting the
gearbox in neutral and braking).

You might see this as the engine as a whole. One big assembly for a
complete 'engine inertia'.

In Racer the clutch/diff setup is a bit too non-generic still; that's
why no 3-diffs setup has been done yet. But see the drivetrain as a
bunch of independently rotating objects, each with their own ratio and
inertia. That's what I do.
The problem is when things start locking on to eachother; you might do
some approximation for locking torques to avoid the harder LaGrange
approach that Racer has (thanks to Gregor Veble), since that's more
flexible (but may hide some tricky vibrational issues).

Also note that due to rounding errors, at some point you need to check
whether the parts of the assembly are still rotating correctly; at
times, my engine and rest of the drivetrain start floating off a bit.
I then unlock the clutch and let it lock back up again.

Before starting to implement things, also take a look at the brakes;
these don't just generates torque but only up to a point, until they
lock. Interesting stuff I haven't thought of a really graceful method
for yet.

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

okay

Thats similar to what I'm having problems with.
I get the engines angular acceleration due to throttle, but transferring it
to the clutch is difficult as I'm not sure which inertias to use. Do I just
use
(don't take the +s literally, I'm using them to denote which inertias to
use)
I_effective = [clutch_inertia + final_drive_inertia + diff_inertia]
and do I include the powered wheel inertias? If so, how?

Yes, I do.
 > The problem is when things start locking on to eachother; you might do

Perhaps a problem I am experiencing above?

Also, to get the resistive torque back into the engine from the wheels,
do I calculate the I_effective in the reverse direction starting from the
wheels
to the clutch? Or do I use the same inertia as is calculated for
accelerating
the clutch?

Thanks!

This is catered for in the following

// HERE

torqueCurveValue[rpm] would return the torque depending on the rpm given,
and would be defined by you.
It could be a look-up table, whereby you give it an rpm and it returns a
torque for that rpm, but would require
a huge array. A better way would be to approximate a curve by having a
similar lookup table, but for, say every 1000rpm
not every 1 rpm, then interpolate between the bounds the rpm lies between
and returning that.

Example:

Torque[0] = 100;    at 0 rpm, torque = 100
Torque[1] = 150;    at 1000 rpm, torque = 150
Torque[2] = 180;    at 2000, torque = 180
...
Torque[6] = 0;   at 6000rpm, torque = 0;

then if you want to find say the torque at 3500 rpm

// obviously you would need to pre-determine which table entries the rpm you
are looking for
// lies between. For this example, between Torque[3] and Torque[4]

torqueBoundarySize = 1000;            // rpm step per entry in the rpm
table, constant
torqueChange = Torque[4] - Torque[3];        // since it lies between 4000
and 3000rpm, get the difference
torqueAtRPM = Torque[3] +[  (3500 - 3000) / torqueBoundarySize] *
torqueChange;

return torqueAtRPM;

this is just a suggestion, but I believe it is a simplified method of what
Ruud's Racer uses
but Racer can use any amounts of boundaries and variable steps in rpm, and
the value retrieved is a normalised
value (0....1) and the resultant is multiplied by the maximum torque the
engine can procude,
to give the final torque.

Hope this helps!