rec.autos.simulators

pacejkaForce is then used to accelerate the car, which gives a new
hubVelocity. My problem is that the torque from the driveshaft is
constant (in the test program), which gives a constant angular
acceleration. Obviously the torque from the road on the wheel will
counteract this torque, and the resultant torque will accelerate the
wheel. The torque from the road on the wheel is pacejkaForce * radius,
I think, opposite in direction to the torqueFromDriveshaft
(counter-clockwise as opposed to clockwise, or vice versa).

I have played around with various ways to do this, but I want to know
the *correct* approximation :-). The main stumbling block is that on a
real car, these two torques are generated simultaneously and rely on
each other, whereas on a computer only calculating one thing at a
time, you need to calculate A to calculate B, but B influences A.
Circular calculations are something which apparently can never be
solved, and anyway I am not about to try, so which is the best
approximation? I am thinking along these lines:

In this example, the torque from the road on the wheel from the last
frame is used to counteract the torque from the driveshaft on this
frame, meaning a lag of 0.01s (or whatever the sim frequency is).

The free-rolling angular velocity of the wheel is also badly defined.
Is this (1) if the wheel continued to roll, with no slip, at the
current angular velocity (ie = lastFrameAngularVelocity), or is it (2)
if the wheel continued to accelerate at the current rate, the angular
velocity at the next timestep? Maybe this is all explained in some
document which I haven't seen, but it seems like a lot of work to get
something working which is in itself just a mathematical approximation
to real life, requires 11 coefficients just for the longitudinal
version, and doesn't even let you easily input tyre speed,
temperature, castor, camber, pressure, contact patch area or pressure
distribution, all of which have some sort of affect on the forces
generated. That is unless I am missing something quite large here.

Moments of inertia are another area which I don't fully understand. I
am using the equation Torque = MoI * AngAcc (F=ma in rotational
terms), but it never seems to work properly. I am confused about
rotating bodies, as well. If an object like a cylinder is rotating and
I grab it, it applies a torque to my hand, while at the same time I am
applying a torque to it. If it is a low-torque motor (like an electric
screwdriver) then I can completely stop it, but I can still feel it
trying to turn in my fingers. If I drop an engine and run it connected
to nothing (or run it in the car with the clutch in :-), the engine is
producing torque, but it is running at constant RPM. I know there
cannot be a resultant torque (as it is not accelerating rotationally),
but where is the opposing torque? Is there a way, using energy or
momentum which solves this, or am I just missing something? If I open
the throttle to 30%, the engine produces more torque, which
accelerates the crankshaft. However, the engine will eventually
equalise at a new RPM, but there is nothing which can be providing a
higher torque on the outside. Please somebody explain all this to me
before my head explodes.

Thanks,
Nick.

PS // I remember somebody asking what conicity was in a tyre in
another post (I am not even sure if it was in rec.autos.simulators),
but as it is relevant: Conicity is a property of a tyre when it is not
completely upright. If it is leaning slightly, it will act as if it is
the bottom of a cone. Imagine the axis drawn from the hub
perpendicular to the wheel until it hits the ground. This happens if a
car is steering in one direction, the wheels will lean outwards at the
top, and conicity will try to make the wheel turn in the other
direction:

             -----\
  Turning   /    / \
   <---    /   X/   \    Drawn from the front/rear (NOT top!)
          /    /  >  \
         /    /     > \
     --------P --------O--------GROUND
         TYRE    CONE    

CONE = Imaginary cone drawn from the wheel, lying on its side on the
road. The base of the cone is the outside of the wheel, and the apex
(point) of the cone is at O. The centreline (axis of symmetry) goes
from X to O along the '>' line. So there you go, some dodgy ASCII art
into the bargain! The wheel doesn't shear like the diagram, but it
rotates around so it would be standing on point P if it were
completely solid.

Nick.

...

Is it now? You calculate engine torque (driveshaft torque) and road
reaction torque. Just apply the engine+roadreaction to the wheel
acceleration, and roadreaction to the car.
The wheel slipratio will then follow up for the next step. Since the
tire is made from ***, the reactions aren't that simultaneous, and
a timestep inbetween is not really a worry for a sim (but that's also
why timesteps are generally small).

What you want is a steady state solution, but in fact, by simulating
all the equations, you're automatically heading for the steady state
solution (which may not be expressable as a formula even).

In the end, you will have jittery things all over the sim, but with a
high enough frequency and some damping where useful, this is natural
and not a problem (at least not visually).

That's engine braking/friction torque (careful with this term, lol,
there was a long debate about this some time ago where it was used to
indicate resulting acceleration/feel instead of torque itself).
The pistons for one produce countering torque because of all the air
effects (inside the engine). You can add a negative engine torque as:

T_counter=brakingCoefficient*engineRPM

Then for the net engine torque you just have: T_engine+T_counter. As
RPM goes up, countering torque goes up as well until there's a
balance: T_net=0 (and constant RPM).
Look at SCGT/F12001 engine RPM tables for example. They have 2 lines;
one top (100% throttle) and one bottom (0% throttle). That's engine
braking.

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

In reality, engine torque = F( rpm, throtle ).

You can interpol the curves from the curves a 0% throttle and 100%
throttle, it's not so bad.

looks in binaries.auto.simulators i post a gas injection cartography
of a V8 engine. In our game we use cartography from car manufacturers
: WRC engines and 1600 cars.

The rpm are normalises from 0 to 1.

Sebastien TIXIER - Game Developer
Dynamics and Car Physics
http://www.eden-studios.fr
GPLRank Normal:-44.24   Monster:-124.44

I am thinking of it like this (using letters to save typing :-):

item A is torque from the driveshaft
item B is resultant torque (applied to wheel to get Fx)
item C is torque from the road

C needs B to get calculated, but B = A + C. Hence circularity.

so therefore C must be a timestep 'late', ie the data is from the
last frame, not this frame. It seems from what you say, you are
calculating the slipratio on the next frame(ie B, above), which
is the same kind of thing, so that's okay. Item No 2473 can be
scrubbed off the 'Help!' list :-)

I am not even going to make an excuse about the engine friction
thing... I guess I just thought internal friction couldn't be that high,
but after thinking about it during daylight hours I have come to
realise that to get 2000 rpm you won't be using much throttle so
friction won't be beyond believable levels :-) By the way, could you
post an example of the F2001 tables, as I don't have the game for
the PC, maybe just a small rev band of one of the engines?

Nick.

Yes, but it is not a linear interpolation. In fact it changes for each and
every single engine in the world. Formula One cars can alter the engine
mapping to make it more suitable to the driver/conditions, for example
in wet weather they can map the throttle so a large movement of the
pedal at a slow speed results in a small gain in revs, to allow the drivers
to control the cars better on the throttle coming out of corners. For
most engines it is fixed, though, depending on the relative lengths of the
throttle linkages and the shape of the throttle valve and surrounding
venturi.

Is there anywhere on the internet where part-throttle torque curves are
available?

Nick.

http://performancesimulations.com/partthrottle.htm

 I'm a bit tipsy from beer right now so can't contribute much else, but this is
an extrapolation from one of those F-1 game's curves from awhile back when Ruud
was asking about the same thing :-)

But yeah, you're right, I argued the same point that the particular parameters
of the engine have much to do with things, but if you took a straight
extrapolation, this is basically what you're looking at..  When I'm not so
toasty, I'll try to contribute a bit more :-)

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

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm

Well, I calculate the current state of all things, then apply. The
order may matter, but that's a matter of how you integrate: do you
first apply acceleration to velocity, then velocity to position, or
vice versa. Or do you average 2 step's accelerations, or do you do
x'=x+v*dt+1/2*a*dt^2. Or RK4 etc.

As long as you're integrating at a small enough step, the differences
should only matter much when a method is unstable. It's a simulation,
not real life.

Compression from the pistons does most of the countering torque,
friction is probably much less.

I could only find some for SCGT, which lacks the negative braking :)

[ENGINE]
idle_throttle=(0.1)
throttle_rpm_ratio=(16000.0)
auto_shift_rpm=(6700.0)
maximum_rpm=(7700.0)
engine_inertia=(30.0)
engine_friction=(0.1)
rpm_torque=(0.0, 0.0)
rpm_torque=(1000.0, 300.0)
rpm_torque=(2000.0, 450.0)
rpm_torque=(3000.0, 500.0)
rpm_torque=(4000.0, 520.0)
rpm_torque=(5000.0, 530.0)
rpm_torque=(6000.0, 510.0)
rpm_torque=(6500.0, 440.0)
rpm_torque=(7000.0, 320.0)
rpm_torque=(8000.0, 100.0)
rpm_torque=(9000.0, 0.0)

Perhaps throttle_rpm_ratio has anything to do with it. For a more real
example, see:

http://www.racesimcentral.net/#enginebraking

BTW, I've seen another bigger Pacejka implementation, which doesn't
use a*, b* and c*, but more elaborately named variables (rFz or such),
that also does combined forces, rolling resistance forces (My) and
gyroscopic precession (Mz,gyr). Seems some of the Pacejka
implementations may be a bit old.
It's called Delft-Tyre96, IIRC. For low speed, it uses the SAE950311
method (relaxation lengths) so that seems a good universal way to go.
It then speaks of slip velocities from which slipratio/angle is
derived.
Slip angle is defined as: tan(alpha)=Vsy/Vx (or was it Vsx/Vy), hence
the quirk that with relaxation lengths you deal with changes in
tan(alpha) instead of alpha itself directly (although Gregor uses
sin()). If you do go that way, heed the tip of who was it again, to
cap off tanAlpha at some maximum value (20?) as it tends to get very
high at sideway slips and this gives too much 'relaxation' (delay). :)

The abovementioned DT96 also does estimation of the effective rolling
radius, which can be used in your slipratio definition, although it
adds ofcourse extra coefficients. And most of the real-life Pacejka
fitted parameter sets are proprietary (although better tires are also
created by playing with the parameters, so playing with them in sims
is essentially the same thing, although it sometimes gives you tires
that aren't physically feasible).

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

F1 cars have active suspensions as well; then it's up to the
programmer how effective it works. As well as launch control (which
should be a driver skill in racing, IMHO, instead of a programmer
skill).

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

Nick.