Re: Car's physics and setting...

[Tomte]

Engine inertia

Stored in engine.inertia.engine. (notice that engine.inertia.final_drive isn't used anymore) The engine takes power to spin up. For example, with the clutch fully disengaged you would otherwise spin up the engine far too fast. This slowed engine acceleration represents the engine inertia, and is specified by engine.inertia.engine (in units kg*m^2). A typical value may be 0.09, but I'm not too sure about this.

This is how engine inertia work in Racer. Is the kg*m^2 the same unit used in Redline?

According to one of Giles' comments, the intertia in redline is in kg*m^2. But how do we know that 0.09 is realistic?

[C14ru5]

Just to make things clearer: The document DonaemouS mentions that explains Racer's physics is here.

I would take all of Ruud's comments in the Racer document with a grain of salt. There are several values in car physics that programmers don't have any good way of determining by themself. I remember Jonas explaining that he added 'wheels.loadSensitivity' mainly because he was unsure about the default value himself.

Yesterday I finally confirmed something else: 'wheels.maxAngle' is given in radians. A value of 1.57 is approximately 90 degrees. The most common value in Redline Plug-in cars, 0.48, is equal to about 27.5 degrees. On The Steering Bible, I found a formula for calculating the turning circle using the steering angle, track, and wheelbase of a car. Note that this turning circle is not the same as the "curb-to-curb turning circle" that many brochures provide, since that value is the diameter that the outermost body part is able to "draw". Also, the formula is just an approximation that doesn't take into account Ackermann steering (not in Redline) or differential effects. Anyway, here is a version of the formula using radians instead of degrees:

Curb-to-curb tire turning diameter = 2 * (track / 2 + wheelbase / sin(angle*(pi/180)))
(Correct me if my math is wrong, or if the formula can be simplified using trigonometry)

'steeringWheelTurns' has no effect on how fast the wheels steer, it's just a graphical effect. On the other hand: wheels.maxAngle effects how fast the wheels steer when using the keyboard as input, as they always use about 0.5 seconds from neutral to extreme. According to Racer's Car Physics Reference, race cars rarely need a steering angle of more than 10 degrees. In Redline, however, since the keyboard input steering speed is determined by the angle, you may need to use a larger value than 0.18 radians. The reason I think so, is because race cars have only a small amount of steering wheel rotation. Not only does that help you keep both hands on the wheel, but it makes you go into opposite lock much faster, in order to correct oversteer and near-accidents. Inside Redline, it will take one half second to make full opposite lock to correct oversteer, so higher values may be necessary to be able to make faster steering corrections. It may be that the default value of 0.48 is nice, but my point is that this should be a value that we dare to experiment with.

That last paragraph was very long. Was this all just incomprehensible babble, or did it make sense?

[aegidian]

Engine inertia

Stored in engine.inertia.engine. (notice that engine.inertia.final_drive isn't used anymore) The engine takes power to spin up. For example, with the clutch fully disengaged you would otherwise spin up the engine far too fast. This slowed engine acceleration represents the engine inertia, and is specified by engine.inertia.engine (in units kg*m^2). A typical value may be 0.09, but I'm not too sure about this.

This is how engine inertia work in Racer. Is the kg*m^2 the same unit used in Redline?

According to one of Giles' comments, the intertia in redline is in kg*m^2. But how do we know that 0.09 is realistic?

Hmm - the engine inertia should be equivalent to the inertia of the flywheel and moving parts of the engine, expressed as a moment of inertia at the final drive (the driveshaft).

Let's try a few elementary mechanical premises,

A lightweight flywheel masses between 5 and 15 kg, a standard flywheel between 10 and 20kg. Now the flywheel is supposed to keep the mechanical parts of the engine moving when there's no force from the piston, so we could estimate that the moment of inertia of the engine is approximately equivalent to the moment of inertia of the flywheel, and therefore the moment of inertia at the final drive is approximately twice the moment of inertia of the flywheel, so...

http://www.autopartswarehouse.com/mmp/lincoln~town_car~flywheel~parts.html

Let's say the flywheel of a standard engine masses 15kg, then we can calculate the moment of inertia of a disc 0.30m radius (and about 7cm thick) as...

mass x radius squared divided by two

15 x 0.30 x 0.30 = 1.35 kgm^2

So, with a calculated engine inertia of 2.70 kgm^2, 0.09 really don't seem right. I'll have to go look at the code again.

[C14ru5]

Remember that Racer has several inertia settings that Redline lacks: In addition to engine inertia, there's also gear inertia and differential inertia. (There's also engine mass, but that only seems to affect the car's total mass.) Since there are more inertia variables, that may explain Ruud's lower 0.09 recommendation compared to our values that typically are around 0.2

Let's not forget the two questions "What does it do to the car in Redline?" and "Are there any other factors that can affect this behavior?". Luckily, this engineInertia seems to be pretty isolated in Redline's physics. The answer to the first question is that engineInertia determines how quickly the engine changes RPM when the clutch is detatched and power is applied or removed. The answer to the second question is torque and engineFriction.

By all means, if it's possible to find a real world equivalent to the value, I'm not holding you back
I'm just saying that it's not a crucial value to fully understand, since its effects are rather obvious.

[djpimley]

I'm just saying that it's not a crucial value to fully understand, since its effects are rather obvious.

Yes, it can be considered an X factor. We don't need it to be a real-world equivalent, we can just suck it and see.

[Tomte]

It may be that the default value of 0.48 is nice, but my point is that this should be a value that we dare to experiment with.

True, Redline uses radians for the steering angle. I think Andreu wrote up an article about that on the Redline Wiki a while ago.

I'm using different steering angles in my cars since the beginning, basically the road cars get 0.48 or similar, while the race prepped cars get a lower steering angle (0.36-0.42 I think). In theory, it should help the steering precision to use a lower angle, while it is counterproductive to quick opposite lock steering corrections.

[Andreu]

... but my point is that this should be a value that we dare to experiment with.

True, Redline uses radians for the steering angle. I think Andreu wrote up an article about that on the Redline Wiki a while ago.
...

Yes, I did, although it contains a *small* mistake in the example. I'll try to fix it when I have a chance.

As for experimenting with this value, I'd be careful. I think the wheel turning angle setting is more important than it seems with respect to controlling the handling of the car. Just an example here. Recently, I have been working on an update for my S2K. My older releases all contain a vast number of mistakes. One of these is a huge wheel turning angle of 1 radian. This was a mistake, granted, but recently I observed, and this is what I find interesting, that the greater turning angle gave the car understeer, and not oversteer, which is what I would have predicted. The reason for this, I noticed, is that when the front wheels turn too much, they no longer help the car in the turn, but become skidding surfaces, which causes understeer.

So, this is my point here: try to calculate the turning angle value from the specifications of the car. These specs can be found for many cars, and it is simple math after all.

[Toad]

This was a mistake, granted, but recently I observed, and this is what I find interesting, that the greater turning angle gave the car understeer, and not oversteer, which is what I would have predicted. The reason for this, I noticed, is that when the front wheels turn too much, they no longer help the car in the turn, but become skidding surfaces, which causes oversteer.

Sorry to butt in here on a topic that I don't have much technical understanding; but I'm somewhat confused by Andreu's comments about giving a car greater turning angle setting will end up with a car that oversteers.

The simplest defininition of oversteer I have seen is that the rear wheels lose adhesion while the front tires maintain grip with the road. There are more than a couple of ways to induce this condition. And one ugly one for any driver is as a result of the front tires regaining grip after having "become skidding surfaces" due to understeer, as Andreu describes. The front tires losing grip, regardless of wheel and tire angle defines understeer to me, an that is what Andreu says he would have expected before making tests on the car settings. So it seems that if wheel position were turned in during the skid (an understeering condition) and then the car regains front wheel traction, now we have gone from one extreme to the other and now have a wicked snap oversteer.

Is that what you are saying here Andreu? If so then I would agree with both of you that this setting is very important indeed to Redline cars. Even more so than real cars as we just don't have the feedback to sense when this condition is happening. I've heard it said what makes great drivers (real cars) is the ability to make the adjustments between oversteer and understeer better than the competition.

[Andreu]

[quote="Toad"]

This was a mistake, granted, but recently I observed, and this is what I find interesting, that the greater turning angle gave the car understeer, and not oversteer, which is what I would have predicted. The reason for this, I noticed, is that when the front wheels turn too much, they no longer help the car in the turn, but become skidding surfaces, which causes oversteer.

Don't worry about intervening. That's what it's alll about.

As for what I said, sorry, but I meant to say understeer. Somehow in my head they get mixed up.

Sorry if I was confusing the issue.

[aegidian]

One thing I hope to add to the wheel physics is Ackerman and ANti-Ackerman adjustments to the steering, just to complicate things for car developers already struggling with ways of dialling out over/under-steer.

[slowDan]

One thing I hope to add to the wheel physics...

If only huh?

[aegidian]

One thing I hope to add to the wheel physics...

Did I miss something? This sounds like you are adding things already! (keeps fingers firmly crossed!)

Should I ever get my hands on the code, that is...

[C14ru5]

There's a thread over at RaceSimCentral with a theory about the CoG height being a percentage of the roof height (from the ground), where this percentage is given by the car type. I'm not so sure about that theory, I think there would be a better pattern if one saw the CoG height in relation to the distance between the wheel axles and the roof. Anyway, the theory says that depending on car type, for road cars at standard running height you could get a good estimate of the CoG height as 38-40% of the roof height.

Reading through the thread, I came across a technical document containing Y and Z CoG and moments of inertia for 90 (not so interesting) pre-1999 road cars. I've put a local copy for you to download: Measured Vehicle Inertial Parameters (144KB)

We've suspected that the inertia formula on the wiki is only accurate for cuboids, but after having inserted the dimensions and CoG data into that inertia formula and comparing my results to the measured moments of inertia in that data sheet, I fall within two-three digits of precision. That means that we can trust our inertia formula pretty much - the challenge lies in finding the right center of gravity.

Some of you may find some interesting specific data in that document as well: Audi Quattro, BMW 320, Merc 190E, Saturn SL, Volvo 240...
The document quotes an older document from 1992 that supposedly has more than 400 cars in it: Garrott W.R. "Measured Vehicle Inertial Parameters" SAE Paper 930897
It's not available digitally, it seems, so I'll try to get a copy through the library at the University where I'm studying.

[Andreu]

Thanks for the tips! Very good information there. It would be nice to put it in the Redline wiki.

[DonaemouS]

Code:

wheels.friction x

I think it's time to understand how this value is calculated. I saw Jonas used higher values for small street cars, like Mini and Golf with a value of 15.

Otherwide, on sports cars like Viper and Maserati, is reduced to 10. Is this based on what?

I mean, is based on the type of the tires, the weight of the wheel, the car's dimension and what is the range?

[DonaemouS]

reading here and there i found something. In first, in the Jonas notes, he wrote about wheels.friction is the friction caused by rotating the wheel in Newton metre.

So, I searched about calculating wheel friction and I found infos about rolling resistance, in which they explain:

F = Crr*Nf

where

F is the resistant force,
Crr is the dimensionless rolling resistance coefficient or coefficient of rolling friction (CRF), and
Nf is the normal force.

They also give us a range for Crr: 0.030 to 0.035 for tires on tarmac.

Now I just needing Nf.

They provide (fortunately) a new example:

In a simple case such as a 40 kg object resting upon a table, the normal force on the object is equal but in opposite direction to the gravitational force applied on the object i.e. the weight of the object. In this case the normal force is given by, 40 kg · 9.81 m/s2=392.4 newtons where 9.81 m/s2 is equal to the acceleration due to gravity (near the Earth's surface).

In another case where the same object as mentioned above is on a 40 degree incline, we have to insert cos θ into the equation for normal force. Fnormal = mass · gravity · cos θ. So solving for the normal force, we get: FN = 40kg · 9.81m/s2 · cos 40° = 300.6 newtons

Now, I should able to calculate the friction. But, there is a big problem. The result is in newtons, instead Newton metre. So, how convert the newtons in nm. And, we need to calculate the rim+tire weight, or including brake discs and other movement parts around the wheel?

[Tomte]

in terms of weight, you would need to calculate the weight on the contact patch, i.e. car weight x weight distribution / 2 (i.e. one wheel per side). Basically, you need the corner weights of your car, which would include the tire, rim and brake disk.

For the rest, a force is always in Newton. On the other hand, Newton meter is always torque. So what jonas said doesn't make any sense to me, but I might just not understand it correctly.

Friction generally generates a force, as you wrote in your formula, never torque.

But then again, which friction are we talking about? Rolling resistance? Kinetic friction? Static friction? We have all three the tire/road contact patch, depending on the relative movement.

[C14ru5]

I've seen how wheel friction affects cars (for my slowest karts, I had to set wheels.friction to 0.01 for them to be able to get off the starting line at all). However, I didn't really bother messing around with the value on normal cars because it doesn't really affect the handling during racing. Still, it would be nice to compare our default value of 10/15 to some real life numbers.

During the Mythbusters Viewer's Special, their Crown Victoria coasted 2270 feet from 50mph. Let's try to replicate that inside Redline.

Car:
I took Redline's Crown Vic, changed the frontAirResistance to 0.74 (Wikipedia:8.7Cd-ft²), and I changed the finalDriveRatio to max out at 50mph. During testing, the wheels.friction was set to the same number for all four wheels.

Track: Default "new track" from Track Editor, finishPos-startPos=700m (2300ft), startLineOffset 100m to allow for accelleration to 50mph

Testing:
Accellerate to top speed 50mph, as soon you cross the starting line, throw the car into neutral (important! this removes engine friction). Perform further testing by modifying wheels.friction until the car crosses the finish line at around 1mph.

Result:
wheels.friction 53 (!) for each wheel, top speed 50mph, avg. speed 26mph, time: 1min07sec (700m+100m)
Perhaps the high result is because Redline doesn't have friction for the transmission, so wheels.friction needs to be higher than the 15Nm per wheel that maybe Jonas found somewhere.

It seems that our values are too low, but it shouldn't matter very much. The only situations where wheels.friction should be important is during coasting at low speeds, where there's no engine friction and very little wind resistance.

[C14ru5]

Getting frustrated by the dodgy suspension, I've tried to provide some measured data for the effect that wheels.maxsuspension has on the bump frequency and compression time (time from resting position until full compression).

Testing vehicle had mass = 1000 (irrelevant), CoG placed at {0,0,0}, supsensionFriction = 0, damperStrength = 0, frontSwayBar & rearSwayBar = 0. I also had to set topAirResistance = 0 so that the car could bounce around for a whole minute, which was my observation window. I know that these settings are not something you would have in a normal car, but I'm just trying to isolate the variables here.

Wheels.maxSuspension	Bounces/min	Frequency	Compression time (λ/2)	Response time (λ/4)
1.00 m	43	0.72 Hz	0.698 s	0.349 s
0.500 m	61	1.02 Hz	0.492 s	0.246 s
0.250 m	86	1.43 Hz	0.349 s	0.174 s
0.200 m	96	1.60 Hz	0.313 s	0.156 s
0.180 m	101	1.68 Hz	0.297 s	0.149 s
0.160 m	107	1.78 Hz	0.280 s	0.140 s
0.140 m	115	1.92 Hz	0.261 s	0.130 s
0.125 m	122	2.03 Hz	0.246 s	0.123 s
0.100 m	136	2.26 Hz	0.221 s	0.110 s
0.080 m	152	2.53 Hz	0.197 s	0.099 s
0.060 m	172	2.86 Hz	0.174 s	0.087 s
0.040 m	207	3.45 Hz	0.145 s	0.072 s
0.020 m	322	5.37 Hz	0.093 s	0.047 s

From the data in the table above, we see a rather linear relationship between wheels.maxSuspension and the compression time. However, when the suspension travel becomes 0.1 or less, the curve steepens dramatically. My guess is that these lower values are challenging the time resolution of the physics engine, causing imprecise results. I tried to get a reading for a suspension travel of 0.01, but it was too quick to determine what made up a suspension cycle with Snapz Pro X recording at 25 fps. Values <0.01 causes the car to become nervous and flip over. Negative values work - the wheels bounce below the surface, and Redline introduces it's very own soft emergency suspension, making cars look like jumping animals (at least with zero damping).

[C14ru5]

I found a mathematical relationship in the numbers above!

For every time wheel.maxSuspension is reduced to half the distance, the frequency is divided by 1.41, or (I guess this is a correct assumption) the square root of 2. I'm also assuming that the formula centers around the instance of "1Hz@0.5m", where the 0.5m value is 2*wheels.maxSuspension. It's a value also used when the calculating the resting height of the car, so I'm taking the chance that this is the variable that the physics engine also calculates the suspension frequency from. With these assumptions, we can arrive at a formula to calculate the natural suspension frequency:

f_natural = sqrt(2*wheels.maxSuspension)

By the way, suspensionFriction and damperStrength data is on its way... it's worth the wait.

[NoNameBrand]

I can't wait!

[C14ru5]

That maxSuspension algebra above involved using binary logarithms (which I hadn't done since high school), so my head is spinning a bit at the moment. Here's what I have so far that describes the other suspension variables.

I'm trying to find a way to calculate the following variables:
(suggestions for better variable naming won't hurt)

CTR -- cycles to rest -- the number of full suspension movement cycles until the suspension is stationary at its resting position.
t_c -- compression time / half-cycle-time -- the time it takes for the suspension to move from one extreme to the other. From extended->compressed or compressed->extended
t_r -- response time -- the initial time it takes for the suspension to move from it's first extreme to its resting position. The relationship between this and the compression time can give us a damping curve.

other variables:
m: mass
s_max: maxSuspension
s_f: supsensionFriction
s_d: damperStrength

I'm keeping sway bars out of the picture, they're all set to 0 for now. For those of you who want to know - sway bars under pressure reduce load transfer at the cost of reducing suspension travel. So yes, they are involved, but I'm not doing the number crunching for that.

Anyway, here's a couple of relationships that I've figured out from my test data:

1) CTR_f, or the number of cycles to rest that you get by only using supsensionFriction, is linearly proportional to mass.
CTR_f = 2*m / s_f
Example: A car weighing 1500kg will need a supsensionFriction of 3000 to complete 1 cycle by only using supsensionFriction. To keep the same amount of cycles, modify the supsensionFriction by the same factor that you modify the mass with.

2) CTR is most likely a sum of the resistance in "the springs and the dampers", and not a product of the two.
CTR = CTR_f + CTR_d
This is unconfirmed, so I'll need to test with combining a positive and a negative value to see what the result is.

3) CTR_d follows the same relationship to mass as the supsensionFriction, but speed (and therefore wheel.maxSuspension) plays a part that I have yet to determine.

I have lots of data, but I'll try to get the last two points sorted out before I share them with you. After that, we'll see if we can find a way to calculate both the compression time and response time.

[NoNameBrand]

I'm reading wikipedia's article on damping - I didn't study it in my two first year physics courses, though the DEs look familiar enough from later math courses.

Solving for time seems like it might be tricky, given where it shows up in the solutions to the DE:

x(t) = Ae^{y + t} + Be^{y - t}

(A, B, are determined by the starting conditions, and y is a function of the spring and damping coefficients and mass)


--

If CTR_f is a linear relationship between suspension friction and math, if you set it to be 0.5 cycles (ie, suspension friction equals four times the car's mass), does the car really return to rest with no oscillation of the suspension? If so, you could probably use that to set up a simpler equation to figure out the spring rate (which Jonas has said is calculated):

1 = c_damping / ( 2 * √ ( k * m ) )
=>
k = ( c_damping / 2 )² / m
= c_damping² / 4m

[C14ru5]

If CTR_f is a linear relationship between suspension friction and math, if you set it to be 0.5 cycles (ie, suspension friction equals four times the car's mass), does the car really return to rest with no oscillation of the suspension?

damperStrength behaves in this way, reducing the amplitude until 0. The behavior is different with supsensionFriction, where the springs go slower and slower until they stop. For instance, if I set it up to stop at 0.5 cycles, the initial response takes very little time, while the rebound phase (0.25-0.5 cycles) takes 5-10 seconds. Difficult to measure.

If it turns out to be too difficult to find a formula for calculating the times, I'll at least provide a data table with reference values.

[C14ru5]

I hope you don't mind the space that these tables occupy...

Different supsensionFriction at mass 1000, wheels.maxSuspension 1.0:

supsensionFriction (sf)	Cycles-to-rest (CTRf)	Response time (tr)	Compression time (tc)
0	infinite	0.33 s	0.67 s
100	22	0.33 s	0.67 s
200	11
300	8
400	6
500	5
600	4.25
700	3.5
800	3
900	2.5	0.33 s	0.67 s
1000	2.25	0.37 s	0.67 s
1200	2	0.37 s	0.67 s
1600	1.75
2000	1.5	0.37 s	0.67 s
2400	1	0.40 s	0.73 s
3000	<1	0.40 s	0.77 s
3500	0.75	0.43 s	0.77 s
4000	>0.5	0.47 s	0.73 s
4500	>0.5	0.5 s	0.67 s
5000	0.5	0.6 s	0.6 s
6000	<0.5	4 s	4 s
8000	<0.5	8 s	8 s
10000	<0.5	>10 s	>10 s

Comments:
- Compression time can be ignored for all stiffnesses that result in 0.5 cycles or more, as it's roughly equal to the natural frequency of the suspension (0.7 in our test case with 1m travel)
- Once you reach less than 1 cycle to rest, the response time approaches the compression time
- As mentioned before, the last movement until the suspension rests is very slooow, and that also makes some results quite difficult to measure.
- Once the cycles to rest is less than 0.5, the suspension moves rather quickly for a short distance (90% @ s_f=6000, 20% @ 10000) before it starts it slow settling process.
- While the curve is linear for the most part, there is an offset compared to the formula I gave earlier. That formula assumes that the magic values for supsensionFriction are multiples of 2000, while my data suggests that multiples of 2500. I don't know if this is just a result of the inaccuracies of my measurements, or if the difference is so great that it should be shown in the formula. Alternative formula with the new constant: CTR_f = 2.5*m / s_f


Different masses at supsensionFriction 2400:

mass (m)	Cycles-to-rest (CTRf)
500	0.5
1000	1
2000	2
3000	3
4000	4
5000	4.5

Comments: The relationship seems to be linear.


Different damperStrength at mass 1000, wheels.maxSuspension 1.0:

damperStrength (sd)	Cycles-to-rest (CTRf)	Response time (tr)	Compression time (tc)
100	>30	0.3 s	0.67 s
200	>30
300	20
400	15
500	12
600	10
700	8
800	7
900	7
1000	6
1250	5.5	0.36 s	0.7 s
1500	4.5
1750	4
2000	3.5	0.36 s	0.73 s
2500	3	0.40 s	0.77 s
3000	2.5	0.40 s	0.77 s
3500	2
4000	1.5	0.47 s	0.80 s
4500	1.25	0.5 s	0.80 s
5000	1	0.5 s	0.90 s
6000	0.5	0.63 s
6500	0.5	0.67 s
7500	0.25	0.8 s	0.90 s
8750	0.25	1.07 s
10000		1.27 s
11250		1.5 s
12500		1.73 s
15000		2.03 s	2.03 s
17500		2.37 s
20000		2.53 s
22500		3.1 s
25000	0.25	3.43 s	3.43 s

Comments:
- Similar to supsensionFriction (2500 -> 1), damperStrength seems to be based on the number 5000. Since damperStrength depends on speed, it has a similar pattern to the one we found for wheels.maxSuspension: If the damperStrength is reduced by a factor of the square root of two, the number of cycles to rest is multiplied by two. Arriving at the wheels.maxSuspension formula was difficult, so I'll have to look at this formula later on.
- Once damperStrength is strong enough to result in 0.25 cycles to rest, it doesn't "dampen just a short bit and then take time to settle" like supsensionFriction, but rather just smoothly dampens at a steadily growing rate. I don't plan on figuring out this rate, as I imagine most of us don't want such behavior in a car. The exception could be if you were making a hovercraft of some sort.


Tables for damperStrength with different mass and with different wheels.maxSuspension will have to wait a bit, I'm having a bit of a hard time reading good results from my tests.

[Sponsored content]