A new free vehicle dynamics resource - Dan's Vehicle Dynamics Corner

[exFSAE]

In terms of lookup tables for Roll centres it's one of these ideas that are great in theory but not really practical. It we take a typical suspension geometry layout you have 4 input variables, wheel movement, vertical movement and roll.
If you have a lookup table for 10 points for each of those variables you need 10^4 or 10000 points. This is a coarse lookup table. I've run it back to back with the hard point method and it was a night and day difference.

The lookup table simply couldn't compete.

Hm, can't say I agree with this. To calculate your jacking forces all you need are 1D look ups at each corner (for independent front and rear susp). I'd agree that 10 points per curve *sounds* coarse, but particularly for most racecars with relatively small suspension travel, it's not unreasonable. Kinematics tend to not be wildly nonlinear or extreme curvature in your working range, too.

In any event that means 10 [data points] * 5 [kinematic look up curves per corner] * 4 [corners] = 200 points, not 10000.

I'd say it's typical in commercial solvers that the lookup approach is considerably faster than full multi body kinematics.

[ChassisSim]

exFSAE,

My friend go through and redo you maths. Let's take a 2 x 2 matrix. You have 4 elements and or 2^2. If we look at a typical suspension geometry you have 4 input variables per half of the car.

This is roll angle, heave and the two wheel displacements. All of these effect the roll centre which in turn impact the jacking forces and Force application points. Even on a course grid of 10 points you need to store it in a 4d matix and this is where the 10^4 comes from. In terms of software implementation you have big time memory management issues. Also in terms of running this in real time you have just handicapped yourself. It gets worse when you have to return cambers as well..

To see this effect for yourself grab mitchell's or susprog. Do a heave sweep for the roll centres and then for each of these heave points do a roll angle sweep. You'll see this unravel very quickly.

Do that and get back to me.

All the Best

Danny Nowlan
Director
ChassisSim Technologies

[Flight909]

exFSAE,

This is roll angle, heave and the two wheel displacements. All of these effect the roll centre which in turn impact the jacking forces and Force application points. Even on a course grid of 10 points you need to store it in a 4d matix and this is where the 10^4 comes from. In terms of software implementation you have big time memory management issues. Also in terms of running this in real time you have just handicapped yourself. It gets worse when you have to return cambers as well..

To be fair the roll angle not really a suspension parameter, it is a vehicle parameter. If you read 10 mm displacement on your front right suspension, you don't know if that is coming from roll or heave. So, you can describe the different kinematic characteristics as an function of single wheel displacements. You can then transform these values from the chassis coordinate system to the world coordinate system to account for roll and pitch (and then solve your jacking forces and so on).

I agree with exFSAE, in my experience this gives well-behaved curves. I would however argue that you might want to have a 2D-lookup for the front, where steer input affects the kinematics as well.

[Z]

exFSAE,

As a word of warning, whenever Danny starts his reply to you with "My friend...", I suggest you brace yourself for the inevitable tsunami of BS coming your way!
~~~o0o~~~

If we look at a typical suspension geometry you have 4 input variables per half of the car. ... This is roll angle, heave and the two wheel displacements ... and this is where the 10^4 [numbers] comes from.

Danny,

You are not advancing the credibility of your racecar consulting business, software, or maths skills, with the above comments (repeated several times now!).

Or, if you still insist you are right...

Can you explain how, for a "half-car" and ignoring tyre-squash, "roll-angle" and "heave" can change INDEPENDENTLY of the "two wheel displacements"?

Z

[Claude Rouelle]

One comment of one of our engineers who do work on creating and using simulation tools: Danny leaves out a crucial part, and that is what kind of datatypes you work with. The memory requirements for holding double precision numbers versus half precision numbers are quite drastically different, so simply talking about how many points you have without talking about the size of each point is a bit useless..

Even taking his "worst case" example of 10,000 datapoints in a table, each at double precision (64 bits) - that is 0.08 megabytes of total memory. Let's say this number is "not large".

[Goost]

Can you explain how, for a "half-car" and ignoring tyre-squash, "roll-angle" and "heave" can change INDEPENDENTLY of the "two wheel displacements"?

Z

Tire deflection isn't ignored in his model. Shouldn't be in any proper dynamics model as you surely know.
This is off topic to an already off-topic discussion...

~~~

Running sims at 5 times real speed isn't Danny's business - have you watched the videos?
He can simulate a lap in less than seconds.
He can run optimization loops and loops on your setup before the car can make it around the track and back to the pits.

Sure lookup tables have their place, this discussion is just missing the point of the computationally lightweight and surprisingly accurate modeling technique Danny uses.

Would be neat to hear some objective comparison of the two. Accuracy vs speed vs complexity vs how fast did it make your car in the end?

[Z]

Tire deflection isn't ignored in his model.

Goost,

The point is, Kinematically speaking (and for a "half-car", etc.), "roll-angle" and "heave" are DEPENDENT VARIABLES on the "two wheel displacements" (as pointed out by Flight909).

Danny is suggesting the use of 10,000 numbers, when 9,900 of them are redundant!
~~~o0o~~~

As for the "...surprisingly accurate modeling technique" of Danny's, and all the other racecar simulators, I wonder just how accurate the predicted lap-times would be without their use of a "global fudge factor". That is, to my knowledge, ALL these simulators require the input of some sort of "global grip factor". This ARBITRARY input parameter then directly scales the output laptime. So, get this "fudge factor" right, ... and the laptime is spot-on.

But, of course, this requires you to know the right answer (= real laptime) BEFORE you do the simulation! I would like to see how accurate these simulations are when you DO NOT have a good guess of the "global-tyre-road-Mu" beforehand. For example, when a lot of dust has blown onto the track... Or, when an FSAE Team uses the TTC data directly (ie. with some Mu = 2++!), with no scaling...

Always easy to accurately "predict" a number, when you already know that number...

Z

(PS. Can anyone give their typical "scaling factor" for TTC-Mu (ie. x 90%?, x 80%?...)?)

[Tim.Wright]

Erik, actually I'm with you on this, the amount of fudging that goes on in the world of lap simulation is depressingly mind boggling... I've seen many "validated" lapsim models running on trajectories derived from telemetry data which neglect track banking, gradient and kerbs which which have massive first order effects on the vehicle behaviour.

This is why I always start with open loop handling responses to quantify a design or setup change in the first instance.

If you do a decent enough job of the fudging and you don't completely destroy the model - you will at least have something to give you some idea of laptime sensitivies to various high level design decisions.

[exFSAE]

exFSAE,

My friend go through and redo you maths. Let's take a 2 x 2 matrix. You have 4 elements and or 2^2. If we look at a typical suspension geometry you have 4 input variables per half of the car.

This is roll angle, heave and the two wheel displacements. All of these effect the roll centre which in turn impact the jacking forces and Force application points.

My friend, let's redo your assumptions

I alluded to this before, but this guy's follow-up post hits the nail on the head (emphasis added):

To be fair the roll angle not really a suspension parameter, it is a vehicle parameter. If you read 10 mm displacement on your front right suspension, you don't know if that is coming from roll or heave. So, you can describe the different kinematic characteristics as an function of single wheel displacements.

(And yes, I for sure agree to his point you can add fidelity but including steer on the front to make for a 2D table at each corner, and then 1D still on both rears)

You don't need to know where the roll center is to find the jacking force on any one corner. In an independent suspension, you have your IC and that's all you need to know. Or really, the more complete picture to me is to forget about tracking the IC location and just work jacking force out of an energy balance at each hub. All you need then is the kinematic derivative at any suspension position (e.g. dCamber/dZ) This is covered in either Matchinsky or Blundell. I know it's one of the blue books on my desk

In any event this reduces the 4D lookup to 1D.

Running sims at 5 times real speed isn't Danny's business - have you watched the videos?
He can simulate a lap in less than seconds.
He can run optimization loops and loops on your setup before the car can make it around the track and back to the pits. Sure lookup tables have their place, this discussion is just missing the point of the computationally lightweight and surprisingly accurate modeling technique Danny uses.

If a full vehicle simulation is doing a complete kinematic solution at each point, I'm fairly certain you will find considerable speed gains when using a lookup. The math and implementation are trivial by comparison.

In the case of full dynamic multibody simulations, you can go from struggling to hit realtime performance.. to running several times faster than realtime. If you're not resolving the full dynamics, sure you may be starting faster than realtime as it is.. but simplifying the calculation of wheel position and orientation from multibody to lookup table is for sure going to be a speed gain.

[Tim.Wright]

Just to share my experiences on using lookup tables in a number of vehicle simulation models.

I use quite coarse curves to define the kinematics (max 20pts). For compliance maps I generally use less because I use a linear approximation where possible (because summing multiple non-linear compliances responses guarantees a wrong result).

Usually the front axle has 5 maps to describe each wheel centre coordinate (X, Y, Camber, Spin, Toe) as a function of wheel vertical (Z) travel and steering rack travel for each wheel. So if your steer/vertical space is defined with 20 points, you have:
2 (wheels per axle) x 5 (dependent d.o.f. per wheel) x 20 (steering positions) x 20 (damper positions) so 4000 points for the front axle wheel movements.

Then you could add another 3 maps for spring, damper and ARB deflections which is another:
2 (wheels per axle) x 3 (dependent d.o.fs. spring, damper, bar) x 20 (steering positions) x 20 (damper positions) so another 2400 points.

The rear axle is the same but without the steer input so 320 points.

That gives a total of 6720 points for the kinematic definition of the full vehicle including all your steering geometry, kingpin orientation, jacking effects and motion ratios.

For compliances you can define each dependent degree of freedom of the wheel as a function of an applied force (braking, acceleration, cornering, aligning torque). This would give you an extra:
4 (wheels) x 4 (loadcases) x 5 (dependent d.o.fs) x 5 (load values) = 400 points.

If you want to have the compliance of the left wheel dependent on forces applied to the right wheel (i.e. to model steering or subframe compliance) then you can double that to get 800 points.

If you want to make the compliance dependent on vertical wheel travel and steering position your point count goes up dramatically. Less density is required for this so consider 5 points for vertical and steer inputs this requires a point count of:
4 (wheels) x 4 (loadcases) x 5 (dependent d.o.fs) x 5 (wheel travel pts) x 5 (steering positions) x 5 (load values) = 10000 points.

Again you double this to add in assymetrical effects coming from forces acting on the opposite wheel - so 20000pts

So if you have all of the above options ticked you have:
6720 pts for the kinematics
20000 pts for the compliance
26720 pts in total

With this level of complexity you are able to solve at 5-10 times faster than real time from what I have seen.