Car physics - reference
| Home | Every physical aspect of the car should be in the car.ini file. |
|
|
|
Introduction
This document describes the various physical aspects of cars that you can tweak in Racer; it is the physics editor's Bible. As the featurelist grows, this list may not always be entirely complete; check out the file data/cars/default/car.ini, which will have 99.9% of all the possible variables set (these are used as default values in case specific car.ini files for other cars miss them). I'll try and add some generic information on how Racer simulates vehicles here as well, hopefully combining the completeness of a reference guide with accompanying information on how to use it (and what is and isn't simulated).
There is a special page for the Pacejka tire formula (which is used as part of the tire model). If you have a hard time getting a drivable car, the car physics troubleshooting page might help out. Also make sure you read the tutorial when you start a car (for info on car cameras etc).
Note this document isn't meant for setting up the car; that's a separate issue. This document describes the features behind the setting up, which are mostly static for the casual driver (who just changes suspension rates, things like that).
If you find settings (in car.ini files) that are missing from this document, please mail me so I can add the omitted parameter to this page.
Thanks go to Claes Wikdahl for creating the Mitsubishi Evo6 which I used in clarifying some concepts.
Changes
Throughout Racer's life, many new variables have entered the stage. See pitstop.totalnfs.net/racerwiki/index.php/Car_ini_changes for a list of changes sorted by Racer version.
Linearity is used in a number of places (controls, steering,
throttle, engine mapping, braking). If we take
steering as an example, 0 is fully non-linear, smoothing steering a lot when
not fully applied (around the center, steering is slow; it gets faster as you
come to the limits of the wheel rotation). 1 is fully linear. Values above 1,
upto 2 actually increase response, exaggerating the actual input (giving an
exponential response). Most controls will benefit from a mild non-linearity
though (0..1).
The shape used to get non-linearity is an x^3 polynomial. To be more precise, here is the pseudocode, where 'l' is linearity.
function Linearize(v,L)
if L>1 then {
L=2-L; if(v>=0){ invV=1-v; return v*L+(1-L)*(1-invV^3); } else { invV=1+v; return v*L+(1-L)*(-1+iv^3); }
else return v*L+(1-L)*v^3
General notes
Also, for aerodynamics for example, you can copy the default values and paste them into your car's car.ini file as a template for modifications. Added variables should generally not change you car's behavior (or not much) to keep forward compatibility.
| Miscellaneous car aspects | Chassis (body) properties |
| Steering | Engine |
| Driveline (gearbox, clutch, handbrakes,...) | Differential(s) |
| Aerodynamics | Suspension |
| Tires/wheels | Cameras |
| Driving aids | Lights |
| Everything about lights is on its own page. |
You can specify some information about the car itself. Nothing much is done with this, other than it may be used in the future in the 'garage' (where you select a car).
The sounds now have their own page.
The car is split up into several models. The parts that have an associated 3D model use a model chunk. Within that chunk you can specify model.file, which indicates the DOF file to use (from the car directory), and a scale.x/y/z, with which you can scale the model. It is recommended you do NOT use the scaling, as this takes time when loading and may confuse you in the Modeler.
More information on the exact definition of model chunks can be found in the car models tutorial.
A small section on AI modifies the car behavior when in AI mode (press Shift-A during a race to toggle AI). The following AI parameters are available per-car:
The setting body.mass indicates the mass in kg. Note that the engine weight is added (engine.mass) as may others (a driver for example).
Very important for the handling, the center of gravity is specified in car.cg.x/y/z. For versions upto (and including) v0.5, the X and Z values were ignored; this is because the CG must match the center of the (graphical) body model. Now, a nullpoint is defined, which basically is where-ever you'd want it, but mostly it's quite close to the CG (and it is definitely recommended to be on the CG itself). The nullpoint makes it possible to independently move your 3D model and your CG to match up.
More information on the nullpoint way of thinking can be found here.
| To the right you see a typical car. Notice the numbering of the wheels. Actually, the suspensions (their body attachment points) define the locations of the wheels. The axis system is that which OpenGL uses (the SAE uses a different vehicle axis system, but I've adopted OpenGL's system for ease of graphics display). The Y goes up through the roof of the car. This image shows the local coordinate system of the car as it was defined in the modeler. You can move the CG relative to the nullpoint in car.cg.x/y/z. The nullpoint isn't shown here, but it's the point from which every other location is calculated. The nullpoint by definition IS location (0,0,0). |
 |
The lower the CG height (cg.y), the more stable the car. A value of about 0.3 to 0.4 (m) is typical for most cars, although F1 cars might get lower ones. Values below 0 are not physically possible; the CG Y value will always lie somewhere in the bounding hull of the car (to visualize the hull, imagine pulling a cloth all over the car and pulling it tight; the shape of the cloth is then approximately the bounding hull).
The inertia values describe how willing the car is to rotate around its local X/Y/Z axes (so around the Center of Gravity, or CG). The higher the number, the more energy it takes to rotate the car (the less quickly it will start rotating). The numbers are stored in body.inertia.x/y/z and have the SI units kg*m^2. I don't have a general formula for these numbers, but it seems like normally the X value is highest, the Y value is a little lower (90%) and the Z value is lowest (perhaps ~60% of the X value).
An example Ferrari of 1280 kg has a X inertia value of 1950. That will get you started. Lower weight cars have lower inertiae.
Car collision handling now has its own page.
The steering wheel in Racer is simple. It has lock (how many degrees it can turn), can deliver Ackerman effects (one wheel turning more than the other) and has linearity added to modify steering responsiveness per car.
The steering wheel is represented by a 3D model.
The maximum graphical angle of the steering wheel is specified in steer.lock (in degrees, not radians!). It's mostly a graphical option; the relationship to your real controller's lock may be preserved if you specified it in your controlset (not yet in v0.5.0).
The steering ratio (ratio of steering wheel rotation divided by wheel lock) is calculated based on this value, and the value of wheel 0's lock (wheel0.lock). So: steeringRatio=steer.lock/wheel0.lock.
The Ackerman effect is that of the inner wheel turning more than the outer wheel in a tight turn. This improves turn-in for low-speed big-angle corners.
Theory: although Ackerman steering geometry is used on a lot of passenger cars, it is less common on racing cars. This is because at racing speeds the wheel deflection will generally not exceed 10 degrees, and the effect of Ackerman geometry would be very little, so leaving it out isn't a problem. At the opposite side, karts often have a LOT of Ackerman steering.
For more control of the steering 'feel', you can adjust steering linearity per car. You do this with steer.linearity. The default is 1.0, meaning fully linear. For more info on this value, see linearity above.
Next to the global control settings, you can modify force feedback strength per car. This helps to subtly modify force feedback for some cars.
The engine now has its own page.
You can specify the gearbox workings in the gearbox section.
Stored in the engine subtree, shifting can be done manually or automatically. Mostly (without freeshifting) what happens is a 3-phase process; declutch (time_to_declutch), a moment in neutral (time_in_neutral) and lastly the clutch engages again with the new gear set (time_to_clutch). Note a separate set can be specified (v0.5.2b7.5+) for downshifting, which in conjuction with blip_throttle (see racer.ini).
These parameters define shifting:
Racer (from v0.5) can do freeshifting, so the user can attempt to put the car in a certain gear at any time. More parameters will deal with bad shifts later.
The clutch is the part that splits the driveline into 2 parts; the preclutch part (the engine itself) and the postclutch part (driveshaft plus differentials and wheels). The parameters are:
The handbrakes can be applied to any and all wheels. The wheels that are affected are set in handbrakes.wheels. Set it to "23" for example and the handbrakes will work on wheel2 and wheel3 (see image). Mostly these are the 2 rear wheels, which should correspond to "23".
Then, for every wheel, define the maximum handbrake torque in wheel<x>.max_handbrake_torque. If not defined, the value of wheel<x>.max_braking is used, but that generally is too high. Theoretically, a handbrake will generate approximately 10% of what the normals brakes can generate.
Note that the combined effect of pedal braking and handbrakes will never exceed the max_braking torque. So they are added, but clipped at max_braking.
Generally there are 4 wheels. You can set this in car.wheels. From 2 to 8 wheels are supported. Note though that motorbikes are not supported; you can make one, but motorbikes tend to rely on a lot of gyroscopic forces, which aren't simulated in Racer (v0.5).
Wheels are normally powered through the differential, but you can fake a power link by setting wheel<n>.powered to 1. Normally, this value isn't used unless you want to fake 4WD; see the tutorial on differentials for more information on this.
The tire is located mostly by the suspension it is attached to. There was an additional offset for the contact patch center, specified in wheel<x>.x; but this value has become obsolete since around v0.6.5, and should now always be set to 0. To offset the 3D model of the wheel, use wheel<n>.model.offset.x instead. Also, wheel<n>.y and wheel<n>.z are unused; to move the wheel physically, modify susp<n>.x/y/z.
Specify a 3D model in wheel<x>.model.file. The tricky bit is to get the right model at the right wheel. See the image above for a graphical view of where the wheels should be located. The radius of the wheel is defined in wheel<x>.radius, which is important to get right so the car doesn't sink into the surface (much). The tire's width is defined in wheel<x>.width but is currently unused. It may be used in the future for skidmark widths.
This specifies how much (in degrees) the wheel is able to rotate (around its spin axis) due to steering input. Pass a number (in degrees) in wheel<x>.lock. For the wheel to actually follow the steering wheel, set wheel<x>.steering to 1. If you want 4-wheel steering, set wheel<x>.reverse_steering to 1 for the rear wheels to get logical steering responses.
Notice there are problems with real-life vs. simulated steering, since most of the times, a computer sim wheel will not be able to rotate as much as a real wheel. This gives problems since too much lock will make the car feel very sensitive, since the steering wheel's input is more sensitive than a real steering wheel. Non-linear steering can help this, but this is personal preference; generally hardcore simmers will run close to linear steering, while non-linear may feel easier for others.
Camber is the roll angle between the tire and the track surface. The suspension geometry decides what amount of camber is actually present.
Specify static camber in wheel<x>.camber (in degrees). Negative camber means the tire will lean inward to the car. Positive camber means the tire will lean outward. This defines the amount of camber when the wheel is in its rest position (no suspension compression, no steering).
Camber is dynamic, meaning effects like steering affect the total amount of camber. See the suspension section for more details on camber changes.
Toe gives a slight static change in tire direction. 5 degrees toe means the tire will rotate 5 degrees counterclockwise (as seen from the top of the tire looking down). You specify the amount of toe in wheel<x>.toe.
A bit of front toe in seems to be able to give a slightly better (more stable) turn-in. Similar effects can be achieved with toe on the rear wheels.
The tire's mass is specified in wheel<x>.mass, and the inertia is in wheel<x>.inertia. Note that this mass encompasses the entire wheel, so not just the rubber tire, but also the hub, brakes and all that moves vertically and is part of the unsprung mass. This mass pulls the tire down (according to gravity). The inertia is a single value indicating the spin inertia; any engine or braking torque uses the inertia to decide how fast the wheel will spin up or slow down.
Rolling resistance is mostly friction that makes the tire slow down. You can specify the coefficient in wheel<x>.rolling_coeff. It is multiplied by load (Fz in the SAE axis system) to come up with a generic torque slowing the tire down. Rolling resistance is taken to be linear (although some books use a quadratic relationship). In real life, you can get to a point where vibrations will occur in the tire, making the rolling resistance go up a lot, but this is mostly at a point at which the tire wouldn't work well anyway (all tires have a maximum speed they can be driven at).
For typical values, a regular car's tire usually has a coefficient of 0.007-0.012 (0.7%-1.2%). Truck tires generally have less, around 0.005 to 0.007. Note that this is related to load. From v0.8.8, you can see the actual rolling resistance force relation (F_rollResistance/load) live in the Ctrl-1 debug screen (2nd page probably; press Ctrl-1 twice).
Note that MF5.2 (Pacejka) defines a more elaborate roll resistance torque (My=SAE coordinates, so the tire moment around the spin axis):
My=R0*Fz*{ qSy1+qSy2*Fx/Fz0 + qSy3* |Vx/Vref| + qSy4(Vx/Vref)^4 }
However, linear approaches seem ok enough, and Racer doesn't implement this (yet?). So the debug screen will currently show a constant number (only switching from positive to negative, depending on the spin velocity of each wheel, always working to slow down the wheel).
Tire force buildup (relaxation)
Commonly known as relaxation lengths.
relaxation_length actually comes in 2 parts; relaxation_length_lat and relaxation_length_long (in wheel<n>.tire_mode). They determine the lag in the tire's flexing towards a slip angle. If you're driving slow, and turn your steering wheel, the tire doesn't immediately give you the lateral force. It takes a while; the rubber must still adjust to the new settings. There is no minimum speed for this (low speed is where the effect is most noticable) but there is a point where slip ratio/angle is calculated directly because the tire rotates so fast that integration of slip ratio is worse than calculating it directly (however this is only at high speed around 200 km/h).
Relaxation is implemented longitudinally & laterally. Normally the longitudinal relaxation length is around 10 times less than the lateral relaxataion length (since tire stiffness is much higher longitudinally than laterally). Start values are around 0.9 for lateral and 0.09 for longitudinal.
Tire forces are generated in a couple of directions.
Notice that the .crv files, previously used for lateral/longitudinal forces, are obsolete (superseded by Pacejka for many years).
Combined forces are a complex subject; it is too complex to define here, but the general idea is to combine lateral & longitudinal forces such that a mix wouldn't overflow a maximum amount of tire force. This uses something that looks like a friction circle; when you use maximum lateral force, that means there is no longitudinal force that you can obtain from the tire anymore.
For combined forces, you need to specify the optimal slip angle and ratio in the Pacejka curves. These parameters are in wheel<n>.pacejka.optimal_slipratio and wheel<n>.pacejka.optimal_slipangle. The slip ratio is a ratio (no units), something like 0.15 can be a good start value. The slip angle is specified in radians; a value for 6 degrees (typical for a race car; a regular road car would be more in the 10-20 degree range) would amount to around 0.10 radians.
Braking torque is specified with these parameters:
Given these parameters, brake bias is defined implicitly. Maximum braking torque is defined as max_braking*braking_factor, so the brake bias can be defined as this product for the front wheels, divided by this product for the rear wheels.
You can also control the brake disc temperature with a few extra
parameters; brake_heating, brake_dissipation
and brake_max_temp. Check the tutorial
on brake discs for more information.
The wheel<x>.skidding parameters define when skidding occurs. This is used mostly for audio.
Mostly you'll edit camera positions from within Carlab. For consistency, here are the used parameters:
Note that for the new graphics engine some new entries will be added to allow for more natural car cameras.
To be able to drive the car, you can sometimes expect some help to be implemented. Currently (v0.5.2 beta 5) automatic shifting and traction control are implemented. ABS is scheduled for the future.
Driver aids - automatic shifting
Automatic shifting is possible by setting engine.shifting.automatic to 1. See Gearbox shifting for more details.
Driver aids - traction control
Traction control can be used to avoid spinning the (often rear) wheels while accelerating. It is allowed in certain classes to implement this. When the wheel speeds differ too much, TC kicks in and cuts the throttle, until the wheel speed ratio returns to acceptable levels.
Currently traction control uses wheel speeds (rotational velocities) to determine a ratio. The front wheel speed is the combined (averaged) rotational velocity of front wheels, and the rear speed is similarly an average of the rear wheels speed. Note that versions before v0.8.3 did an addition of all velocities, so if the number of front wheels and rear wheels isn't equal, you'd get incorrect traction control behavior.
The following variables determine the behavior:
ABS (anti-lock braking system) is implemented since Racer v0.5.2b5.3.
ABS can be used to avoid locking the wheels while braking. When the wheel speeds (see traction control) differ too much, ABS kicks in and releases the brakes, until the wheel speed ratio returns to acceptable levels.
The wheel speed ratio is calculated the same way as with traction control.
The following variables determine the behavior:
(last updated December 21, 2009 )