Post rigs

[Greg Locock]

Well frankly people don't spend millions of dollars on rigs and then say oh let's work at one operating point, do they?

[GSpeedR]

My previous post loosely describes the 'inverse algorithm' (Equation 2 in the link), and, as mentioned, there are numerous caveats and deficiencies. However, RemcoA has never mentioned that an actual test rig will be used and he hasn't described anything other than a LTI State-Space model of a quarter-car system (2DoF). I think the inverse algorithm is perfect for this case since the FRF is ideal and should perfectly represent the ideal system. If RemcoA seeks to extend his model to include nonlinear elements or (better yet) collect data on a real system, then the links DaveW provided would definitely be beneficial.

How can you work in the frequency domain, usefully, if the shock characteristic is non linear with velocity? If you have jounce bumpers? If you have rebound springs?

Greg, all perfectly valid points (freq analysis assumes linearity), however I have repeatedly stated that I am referring to an LTI Mathematical model (meaning, linear time-invariant) which will contain only linear elements. The questioner (RemcoA) described such a system, or at least I interpreted such a system; I don't know why I'm wasting my time defending this position if he/she doesn't give any additional details. If these techniques are applied to a model with nonlinear elements (virtual or real) then the FRF is a linearized approximation of the actual system, but freq analysis can still be useful.

Well frankly people don't spend millions of dollars on rigs and then say oh let's work at one operating point, do they?

Most rig software have techniques to handle multiple FRFs each representing an operating range (not point) and/or modify them during the iteration process.

[RemcoA]

Many thanks for all reactions. To clear up some things about my question: we are not performing actual rig shaking with the data obtained from my assignment. We just would like to have a tool to generate a "possible"(!) track surface to replace the random white noise with something a little bit more meaningfull in our virtual post shaker. You could say it is for education purposes rather than increasing laptimes by tenths using this method.

I use a fully linearised Quarter Car Model, which I will be expanding once I found the solution of reverse engineering the damper displacements to a "possible"(!) track profile.

My current TF generally looks like: Y/X = w^2/(s^2 + 2*w*z*s + w^2). Of course, this TF cannot be inversed in Matlab, since the order of numerator and denominator is inconsistent. What I currently tried is adding filtering components to the numerator, which seem to work. However, if I use lsim on this inverse TF with input vector the measured damper displacements (corrected for motion ratios etc), the system seems to lag, which is quite obvious for a first order filter like this, see this: http://postimage.org/image/erotpmhwb/ Blue is the generated track profile and in grey you see the measured damper displacement

GSpeedR, many thanks for the input, my next step will be implementing FFT and using your approach. Keep you all up to date and thanks for the discussions so far! Really interesting!

[DavidO]

I did not put any links in as information is in the Iterate Control site provided by DaveW. The relevant quote form that site is "iLC is a high performance drive file iteration tool that enhances or replaces MTS RPC® Pro, LMS/IST TWR or Servotest ICS. It is developed by Iterate Control.............. ". I also have a memory of a product based on state space modelling but I have emporarily forgotten the name. All such SW is protected by IPR so details are not really fully available other than from the companies concerned so my comments are based on opinions deduced from discussion and observation. What is certainly true is that the inverse algorithm is the natural choice if the rig model is very accurate and the rig has no "funny" dynamical properties For other situations it need to be modified to reduce sensitivity to error, nonlinearities etc as mentioned in my previous post. My guess is that most products do this using empirical "fixes" and have had considerable success. The claim by Iterate Control is that the "generalized" algorithm provides a systematic way of dealing with these problems.

[DaveW]

Many thanks for all reactions. To clear up some things about my question: we are not performing actual rig shaking with the data obtained from my assignment. We just would like to have a tool to generate a "possible"(!) track surface to replace the random white noise with something a little bit more meaningfull in our virtual post shaker. You could say it is for education purposes rather than increasing laptimes by tenths using this method.

I guess my first comment would be that real road inputs are not normal (Gaussian).

Many moons ago I was presented with recordings of the response of a road vehicle whilst negotiating a long road journey of around 24 hours, and was asked to propose a test specification for testing objects carried by the vehicle. I first computed the amplitude probability density (APD) for various channels & found they had quite stable distributions with high kurtosis. I discovered that the APD could be modeled as the sum of three normal distributions - a high RMS for a short period of time, an intermediate RMS for longer, and a low RMS for the majority of the time. A plot of log(APD) against Amplitude.abs(Amplitude) provided the mechanism for deciding the three values of RMS & fraction of time. [Incidentally, I was then able to compile a (slightly tongue in cheek) test specification using the highest RMS value and a reduced test time using Miner's Rule to add on the intermediate & low RMS sections to the high RMS section. The test time turned out to be less than an hour. The shape of the spectral density I proposed was an idealized version of that computed from the measurements. Importantly, I think, specimens were not subjected to inputs they would not have encountered in practice.]

I am sure that ways exist of reversing that idea to obtain more realistic drive files.

I use a fully linearised Quarter Car Model, which I will be expanding once I found the solution of reverse engineering the damper displacements to a "possible"(!) track profile.... My current TF generally looks like: Y/X = w^2/(s^2 + 2*w*z*s + w^2).

Seems like you have thought about the problem. My cautionary comments would be that a quarter car model omits the inputs from the other corners, & a quarter car model would be 4th order (I think).

p.s. During my searches I found this. Perhaps it might be useful to you.

[GSpeedR]

I use a fully linearised Quarter Car Model, which I will be expanding once I found the solution of reverse engineering the damper displacements to a "possible"(!) track profile.

My current TF generally looks like: Y/X = w^2/(s^2 + 2*w*z*s + w^2). Of course, this TF cannot be inversed in Matlab, since the order of numerator and denominator is inconsistent. What I currently tried is adding filtering components to the numerator, which seem to work. However, if I use lsim on this inverse TF with input vector the measured damper displacements (corrected for motion ratios etc), the system seems to lag, which is quite obvious for a first order filter like this, see this: http://postimage.org/image/erotpmhwb/ Blue is the generated track profile and in grey you see the measured damper displacement

RemcoA, I agree with DaveW regarding your transfer function, which looks suspiciously similar to a first order system TF. A 2DoF system should have a 4th order denominator and have a lot more terms than what you have there; I would return to your equations of motion and recheck how you are getting there (or explain the variables if you are confident in them). Lastly, Simulink may not be the best platform for this work, unless you have Control System or SystemID toolboxes. Simulink performs a time simulation of your system and thus requires it to be physically realizable, which your inverted TF will not be because the numerator order is higher than the denominator. However the math can certainly be done in Matlab and so I would recommend using that to create your drive time history.

[Caito]

Just to get it right, you can make a system that has more zeros than poles. A common derivator circuit is of the form -sRC, and it works fine. An integrator of the form -1/sRC is as common. The integrator is one of the most common blocks used in simulinks, or when simulating space state or whatever.

Both systems are BIBO unstable, which means, for a bounded input you don't get a bounded output.

So inverting a transfer function is not necessarily bad. You might make it BIBO unstable, but it might still be stable for the input of your system. If the system is of minimum phase, the inverse is stable by definition.

[GSpeedR]

Just to get it right, you can make a system that has more zeros than poles. A common derivator circuit is of the form -sRC, and it works fine. An integrator of the form -1/sRC is as common. The integrator is one of the most common blocks used in simulinks, or when simulating space state or whatever.

Both systems are BIBO unstable, which means, for a bounded input you don't get a bounded output.

So inverting a transfer function is not necessarily bad. You might make it BIBO unstable, but it might still be stable for the input of your system. If the system is of minimum phase, the inverse is stable by definition.

Perhaps what I should have said was that the "Transfer Function" block in Simulink must represent a physically realizable system, the same or fewer zeroes than poles. Your overall system need not be physical realizable (so I mis-spoke in my post above). You will note that the general Simulink library does not include an "s" block (laplace derivative) but a "d/dt" block which Matlab does not recommend using for robust models. So you can make a system with more zeros than poles but you can't do it completely within a TF block, as RemcoA attempted.

[Caito]

Just to get it right, you can make a system that has more zeros than poles. A common derivator circuit is of the form -sRC, and it works fine. An integrator of the form -1/sRC is as common. The integrator is one of the most common blocks used in simulinks, or when simulating space state or whatever.

Both systems are BIBO unstable, which means, for a bounded input you don't get a bounded output.

So inverting a transfer function is not necessarily bad. You might make it BIBO unstable, but it might still be stable for the input of your system. If the system is of minimum phase, the inverse is stable by definition.

Perhaps what I should have said was that the "Transfer Function" block in Simulink must represent a physically realizable system, the same or fewer zeroes than poles. Your overall system need not be physical realizable (so I mis-spoke in my post above). You will note that the general Simulink library does not include an "s" block (laplace derivative) but a "d/dt" block which Matlab does not recommend using for robust models. So you can make a system with more zeros than poles but you can't do it completely within a TF block, as RemcoA attempted.

Got it. A cheap solution to make it work in simulink might be adding poles to your system at very high frequencies until it has the same amount of zeroes than poles, so Simulink allows you to use it.

If you're using a model of a car, you can add poles at 100kHz and it won't affect the response of your system at logic-car frequencies (<25 Hz if I'm not wrong). You could try that and see how simulink behaves, though I doubt it's robust enough. Basically what you're doing is adding a lowpass filter at a high frequency to make your system stable.

Let me know how it works out!

Caito.-

[JMS11]

Sorry to drag up this year old thread, but I was reading through it & found it very informative and useful for what I'm currently working on.

DaveW mentioned a while back that he uses work dissipation to characterize how much heat a spring/damper setup will work into the tire. I have a few questions about that.

In theory, a spring won't dissipate any work, correct? All of the work put into it, will come back out when the spring returns to equilibrium. Therefore damping is what causes work dissipation.

Previously I thought the only way to increase tire heat was to make the tire "work" more through stiffer springs and dampers, so to increase tire heat you must also increase load variation. DaveW mentioned earlier that it is possible through 7 post rig testing to find a setup that increases heat while reducing tire load variation.

In my quarter car model, I have a constant damping coefficient for the tire. I've been varying it from 0-0.1. I can show that increasing the tire damping increases the work dissipation of the tire, and also reduces tire load variation. Therefore, finding the conditions that maximize the tire's damping rate is the key to getting the most "mechanical" grip out of the car.

However, damping rate of the tire probably changes with velocity, temperature, lateral distortion of the CP, twisting distortion of the CP, frequency & amplitude of the load input, etc, and I have no data to quantify any of these effects. So I feel like I've reached the limitation of how useful the simulation can be. It can still conceptually show how to "work" the tire harder with stiffer springs and dampers (increasing TLV and tire heat), but it won't be able to find the tire damping "sweet spot" that increases tire heat while reducing TLV. Is my understanding correct, or am I missing something?

[Jersey Tom]

In my quarter car model, I have a constant damping coefficient for the tire. I've been varying it from 0-0.1. I can show that increasing the tire damping increases the work dissipation of the tire, and also reduces tire load variation. Therefore, finding the conditions that maximize the tire's damping rate is the key to getting the most "mechanical" grip out of the car.

That's working under the very dangerous assumption that more heat in your tires is a good thing.

[DaveW]

DaveW mentioned a while back that he uses work dissipation to characterize how much heat a spring/damper setup will work into the tire. I have a few questions about that.

In theory, a spring won't dissipate any work, correct? All of the work put into it, will come back out when the spring returns to equilibrium. Therefore damping is what causes work dissipation.

Correct, but would appreciate a reference (so I could check the context...)

Previously I thought the only way to increase tire heat was to make the tire "work" more through stiffer springs and dampers, so to increase tire heat you must also increase load variation. DaveW mentioned earlier that it is possible through 7 post rig testing to find a setup that increases heat while reducing tire load variation.

Yes, but on a "trial & error" basis, and limited by what can be "seen" on a rig test.

In my quarter car model, I have a constant damping coefficient for the tire. I've been varying it from 0-0.1. I can show that increasing the tire damping increases the work dissipation of the tire, and also reduces tire load variation. Therefore, finding the conditions that maximize the tire's damping rate is the key to getting the most "mechanical" grip out of the car.

I think you require (at the very least) a bicycle model (to allow the two axles to interact). A "Viscous only" damping model might give estimates as high as 1.0 N/mm/sec, depending on the tyre & vehicle, but this a biased estimate because tyre damping is mostly hysteretic.

However, damping rate of the tire probably changes with velocity, temperature, lateral distortion of the CP, twisting distortion of the CP, frequency & amplitude of the load input, etc, and I have no data to quantify any of these effects. So I feel like I've reached the limitation of how useful the simulation can be. It can still conceptually show how to "work" the tire harder with stiffer springs and dampers (increasing TLV and tire heat), but it won't be able to find the tire damping "sweet spot" that increases tire heat while reducing TLV. Is my understanding correct, or am I missing something?

I think you are correct, but you might also explore the effect of inerters.....