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

Quote:

---

Originally Posted by Z

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!

---

Yes that's fair for this example. In regards to the original question 'tables vs math' the size still depends on which tables you use, resolution, their coordinate system etc.

Quote:

---

Originally Posted by Z

global fudge factor

---

The literature suggest that this is actually a decent assumption until you get into tire/ground interaction.
Couple sources that come to mind:
Georg Rill, SAE Paper 860575
Halliday, SAE Paper 983030

Quote:

---

Originally Posted by exFSAE

...for sure going to be a speed gain.

---

OK, I just want someone to show objective proof of this.

Here's my two cents for the morning:

Made a little dynamic simulation in MATLAB. 2nd order SMD with a nonlinear (quadratic) spring.
Using the direct math solution F=k*x*x is 100 times faster than a lookup table, even for low resolution.

(Yes it's not compiled and yes trig calculations use something close to lookup tables + polynomials...
I don't have a lap simulator to test this, maybe someone who does could compare and show their objective proof?)

~~~

Code attached; as per usual, change '.txt' to '.m' to run.

Gonna have to leave the "objective proof" as an exercise to the reader - and of course it's a bit more involved than f = kx^2. Just saying from my own experience is that full vehicle MBD in pro motorsport applications imposes significant runtime (and solver) challenges. Simplifying it to look-ups is a big gain.

On a side note, I would recommend avoiding Matlab for these type of exercises. It is generally horribly slow, though there are some things that get redirected to a compiled Fortran linear algebra library (LAPACK), and then their JIT'er does some things better than others. It's a good sandbox application and does some things quite well, but I would not use it for any sort of algorithm or numerical benchmarking - you can easily fool yourself.

Couple of comments from my direct experiences with all of this:

Compiled Matlab is not 'compiled' in the traditional sense. It's processed for distribution to limit circulation of the libraries. I have and use the Matlab compiler. It's executables are no faster than the editable scripts. (Geez, I almost said edible ???)!

I use the Watcom 32 bit Fortran compiler to produce double precision executable engines that are stuffed, loaded and post-processed by Matlab GUI's built with the Guide tool. Yes, they are really that fast 100x real time. With the flick of a LinkEdit switch, you can produce a .dll callable from Excel. So much for Invisible Basic.

Actually, heave and roll should be treated as separate reactions because of the effects of in-phase and out-of-phase side forces. (Don't let this phase you when you are not cornered). Steering system in front is to blame (net vs. difference tie-rod loads), and asymmetric rear suspensions (Panhard bars).

Next time you get onto a K&C machine (perhaps a virtual one), take along a complete set of tire patch loads (vertical, lateral, and aligning moments to start). These loads probably came from or could come from a cornering and braking simulation. Then recover your suspension parameters (tables or chairs) and recomputed another set of input loads. After 1 or 2 iterations of this technique (called "bootstrapping"), you will be able to judge for yourself the values of multi-dimensional tables, superposition, linearization, effects and manifestation (infestation ?) of structural compliance and compliance model equations.

The real value from the parametric equations comes from the identification of trends: Am I getting better or worse ?) because the structural (I.E. your ass-you-me d ) infinitely stiff unobtainium frames and cross-members just ain't so.

The problem you still face is the unnatural effect(s) of the clamping method used during the K&C test. Vehicles really use a process called "Inertia Relief". as in the NASTRAN Solution type. Most K&C clamping methods restrict the body/frame modes that contribute to bending, torsion and match-boxing. Sometimes you might want to eliminate 1 of the 4 corner clamps or replace them with a couple of front centric mounts using Cardan joints. If your results are much different, all your 20,000 data points are probably worth less than the ink cartridge they could be printed with (~ $35.00 U.S.) .

BTW: Some of you (like myself) still keep 16bit apps around that served us well for vehicle dynamics studies but no longer run directly under 64 bit Windows. (Like Pac-Man). To keep them alive, I am running a 32bit Windows for Workgroups app under a DosBox virtual machine and this combo keeps the 20th Century alive at my house for suspension analysis, etc. Rumor has it that the next version of Windows will have this ability directly by popular demand.

Play the Song, Jack ...

Hello everybody,

It might be worth at this point of the discussion to take a deep breath and remember what we are doing in the first place.

Firstly the crux of this debate is do you use lookup tables to generate roll centres and other suspension geometry parameters or do you calculate them from first principles. Firstly breaking this down by half of the car I am referring to the front end or rear end of the car. To this end there are 4 input variables that will effect roll centres, cambers and other suspension geometry variables. These are,

*Roll angle
*Heave displacement of the front and rear end.
*Individual wheel movements dictated by tyre squish/movement of the hubs on the tyre springs.

Also make no mistake the roll centres have a fundamental effect on the jacking forces/forces applied to the sprung mass. A cursory Free Body Diagram will show this conclusively. Consequently this isn't just a 1 D lookup table. You might get away with a 2D table resolving wheel and chassis movement. However this gets destroyed by roll angle so know we have a 3D table. However where this runs into trouble is the effect the roll centre locations are fundamentally effected by what both the left and right hand sides are doing. So we are back to 4 variables.

So that means we have four variables in play. So if we want to represent this at with 10 intervals per variable you are going to need 10^4 or 10000 points. Let me also state that this is a very course grid. If you doubt the numbers look at a typical 10 x 10 aeromap this is 100 points. It's what you need to carry around bear minimum so if you want to carry this around for suspension geometry there is no getting around the 10000 points. You also need this for cambers as well. On top of this you need to do it for the front and the rear. It doesn't take very long for all this to add up. Don't believe me download a C Compiler and start adding in the numbers and look at what happens. You also think you can cheat using lower memory variables but if you go down this road round off error will kill you.

The other thing you'll run into is the algorithms and processing times you'll need. The book in Numerical Recipes in C has an excellent multi dimension lookup table algorithm. They display it in two variables. Once this is expanded to 4 variables or 4 dimensions the equations get big, and the finer your grid gets the more searching you have to do. This is where the sting in the tail is for the lookup table method is for suspension geometry and you pay for it in run time.

The advantage of doing this from first principle is that the values are totally continuous and the run times where much faster. I also backed to backed the values so there was no point in using lookup tables. Also the values in ChassisSim have been validated on K&C rigs and other 3rd party packages so this method is on solid ground.

I'm not saying you can't use lookup tables to represent this. If you have the computing power and memory storage knock yourself out. However a first principles method works just as effectively with a fraction of the memory input and run time.

The ultimate payoff of this is the results. Check out the image in this link,

http://www.chassissim.com/blog/chass...imulation-tool

Look at the image - coloured is real, simulated is black. The steer trace, throttle and steer and dampers are almost indistinguishable. Also there are no grip or fudge factors here. This is what happens when you develop tyre models from real data and you use full multi body transient simulation. Just for the record the numerical engine runs about 80 times faster than real time on a ho hum laptop.

The validity of this speaks for itself.

All the Best

Danny Nowlan
Director
ChassisSim Technologies

The reason I brought up the case of the lookup tables was purely to allow arbitrary suspension to be modelled in the software rather than being restricted to the built in types that you have built in (if I remember is double wishbone but I don't remember which others there are). How can you currently model 5 link, 4.5 link (Audi, BMW, Ferrari), 4 link (Ford) & McPherson type suspensions?

Regarding the fudge factor. Correct me if I am wrong but if I remember correct, the process of making a Chassissim model is that you parameterise everything on the car except for the tyres. Then you provide the software a lap of logged data from the actual car and from this Chassissim reverse engineers the tyre model. Is this correct?

In this case the fudge factor is inside this reverse engineering process. Basically, in this way you will always have a match between your data acquisition and your model right? An example would be your tyre Fy will always be underestimated on the front but overestimated on the rear because you don't have the Mz in your tyre model.

From direct experience, reverse engineering the tire is a nice technique if you don't have any data at all, but it is at the same time very dangerous, above all if your driver is, for any reason, not close enough to the car limit (see for example FSAE, most probably, or amateur racing, which is now up to LMP2 sometimes).
Beside it, you are always ignoring some effects, like camber.

As i said, it is in my opinion a chance if you don't have any data (assuming you know your car very well and you trust completely your data), but still i would always use a tire model as a base if i had one.

Silente wrote " From direct experience, reverse engineering the tire is a nice technique if you don't have any data at all, but it is at the same time very dangerous, above all if your driver is, for any reason, not close enough to the car limit (see for example FSAE, most probably, or amateur racing, which is now up to LMP2 sometimes"

Interestingly this is related to one last Z’s question: “(PS. Can anyone give their typical "scaling factor" for TTC-Mu (ie. x 90%?, x 80%?...)?)”

Tire model made on flat track test are always a bit too optimistic because the A) belt grip (and temperature) is not necessarily representative of a given track asphalt B) moreover; there is no bumps on a flat track machine (unless you recreate different vertical tire movement frequency and amplitudes but not a lot of tire test programs include that feature)

So my answer would be 85 % of scaling factor for a Senna-like driver and 70 to 80 % for other ones, depending on their skills. Not very accurate, isn’t it?

I have been in situations where after “calibrating” the model (or fudge the data) you could see the real data of the steering, throttle, brake, suspension, linear potentiometers etc.. close to perfectly overlaying with the simulation. Then you put another quicker or slower driver or 2 drivers with the same lap time but with different driving styles and suddenly the data and the simulation traces do not overlay anymore. Same thing if the next day with the same car, same setup, same tire, same driver ….and the data and the simulation do not overlay because the track temperature changed 5 degrees C.

So if reverse engineering the tires is questionable and if tire model from flat track test are not precise who and what do you trust?

That is where my statement “You work in Delta” comes in.

I still remember vividly my first test on a tire testing machine many years ago where the manager of the tire testing facility told me: “You do not simulate here; you model”

I have been in a situation where we predicted that the lap time a given car on a new circuit was going to be 1.40.5 but the driver made the pole in 1:39.9. So we were 6/10” wrong. Yep but at the time we ran the simulation I did not know which way the wind was going to blow or what the tarmac temperature was going to be.

The goal of simulation is not so much spot on lap time prediction but calculation of the ratio of second of lap time per Kg of fuel or per degree of rear wing or per degree of front camber of per mm of front ride height. In other words I am more interested of the SLOPE of a given parameter influence on the lap time than its absolute value. Similarly when testing tires on a tire testing bench (flat track) I don't worry about the tire grip measured as much as I focus on a the tire grip VARIATION per KN of vertical load, per degree of camber, per degree of slip angle per psi of pressure. THAT is the kind of DELTA information that help us to build a winning car design and/or setup.

Just wanted to share this perspective in this (very good) debate.

Quote:

---

Originally Posted by ChassisSim

Firstly the crux of this debate is do you use lookup tables to generate roll centres and other suspension geometry parameters or do you calculate them from first principles.

---

To do one or the other is merely a choice - no right or wrong answer there. And I don't think anyone would argue that as you add dimensions to a look-up table it gets more computationally expensive.

The crux of the debate is if you do choose the lookup approach, whether you need to tabulate kinematics against 4 input variables. Beyond that, it could be asked whether you need to know spatial location of roll centers to calculate jacking forces.

The answer to both those is no.

Going in reverse order - there are different ways to compute jacking forces. Personally I've always been a fan of energy methods in various facets of engineering, and they can be applied to this case. Using the energy balance approach you can calculate the jacking force on any corner of the car knowing only (a) the tire forces and moments, and (b) the motion derivatives. You will find the 'theorem of virtual work' appear repeatedly in "Road Vehicle Suspensions" (Matchinsky). This is a very powerful method as it works for any type of suspension topology, and includes the effects of all tire forces and moments. With one implementation of tables you can support SLA or multi-link or whatever you want, transparently.

As an aside, that is an easy trap to fall into when just using spatial IC's or RC's, just about everyone seems oblivious to the fact that you will have jacking from Mx, My, Mz. Depending on your geometry, you can of course choose to ignore those effects if you know them to be small - but you can't just be ignorant of their existence.

In any event, let's come back to lookup tables. For an independent rear, the kinematic motion (and derivatives) are a function of wheel displacement only. As someone mentioned earlier, if you read 10mm of displacement it's of no consequence whether it came from heave or roll or pitch. All then that's needed is a 1D lookup - easy and fast. Even if you were to still use the "spatial" approach you still don't need to know where the axle "roll center" is. Let's say we want to work out the jacking at the LR. If you have knowledge of the LR's IC and tire forces then that's all you need (the IC of course just being another way of capturing information about the motion derivatives). For that time step the displacement or forces of the RR have no consequence to what's happening at the LR.

On the front, you have a choice. To be complete, the kinematics (most importantly the derivatives) are obviously a function of both wheel and steer displacement. At most you only need a 2D table at each corner. However, if you know that your motion derivatives don't change much with steer, then you may simplify these down to 1D lookup as well.

I think you will find then that this approach can have considerably faster runtime performance than doing full kinematic solutions. Your mileage may vary, but I would expect you will find this is typical among the major, industry-standard commercial solvers out there - written in C, Fortran, or hand-tuned assembly language by experienced specialists.

Quote:

---

Originally Posted by exFSAE

... The crux of the debate is if you do choose the lookup approach, whether you need to tabulate kinematics against 4 input variables. Beyond that, it could be asked whether you need to know spatial location of roll centers to calculate jacking forces.

The answer to both those is no. ...

---

After adapting our software for several different large customers (through the 1980s and 1990s), we gave the user several choices for defining the suspension. The documentation to cover these different methods grew considerably!

The original method was curve fits to K&C data (noted earlier by Bill Cobb), which was available from a few sources back then. This included the results of Fx, Fy tests at multiple ride heights, which gave jacking forces as noted by exFSAE -- a very general and clean representation. This made model building very quick, working directly from K&C plots that could be generated in a day or two on the test rig. I don't recall if we ever added curve fits for jacking from Mz input, but conceptually it would have been easy. This method requires that you have a car (and access to K&C) -- which was a limitation for some customers.

Later, tables were added, I think there were at least two types, one was a model of 2D instant center location and movement. These types of kinematic description are easier to populate if you are designing the suspension and don't have a car to measure on a K&C rig.

During that time period, multibody models began to become popular, but a full compliant suspension model really slowed down calculations for a full vehicle. Building a full multibody model was also very time consuming and error prone (I've seen some wild errors). Some users characterized the suspension by multibody simulation, then converted to a curve fit representation to calculate vehicle responses in a reasonable amount of time.

Bits of this history are documented in RCVD, for example, lap time (going back to slide rule days) is discussed starting on page 340.

Hi Bill, can you elaborate a bit on this?

Quote:

---

Originally Posted by BillCobb

Actually, heave and roll should be treated as separate reactions because of the effects of in-phase and out-of-phase side forces. (Don't let this phase you when you are not cornered). Steering system in front is to blame (net vs. difference tie-rod loads), and asymmetric rear suspensions (Panhard bars).

---

I'm familiar with the need to treat in phase and out-of-phase forces seperately when defining compliances (as I mentioned in a previous post) but I don't follow why you would need the same also for the kinematics.