Quantifying the effects of tire load variation

[exFSAE]

You do indeed need good predictive tools for building bridges, aircraft, spacecraft. These CAE tools are all extensively validated before they are ever used "for reals." Even if I'm using something like ADAMS, which has had people banging on the solver for years and have high confidence in it in general - I'm still going to do some verification that I've set up my models or templates correctly. Maybe a quick comparison against K&C data.

For other commercially available software that hasn't been as extensively "beat on" by professionals, I'll do a bit more thorough verification. For something done in house, I want even more extensive checks before I use it to make critical path engineering decisions. Doing this sort of combined in & out of (x-y) plane dynamics work there are potential pitfalls all over the place.

Now you do make the good point that using one data set or data point for model validation is a joke. Very easy to set model parameters to match one data point exactly - though when you use those parameters on another case your quality of correlation may be worse. Definitely requires several examples to identify model parameters which best fit over a range of conditions.

Still, I come back to the point of wanting to prove level of significance. If we drive a FSAE car around in a rock quarry - sure - your "grip" (itself a nebulous term) is probably going to suck. But for a typical FSAE event, or the one any team is looking to travel to - what's the level of significance?

I think back to running at the Ford Michigan Proving Grounds. Ride effects there are probably insignificant to handling in comparison to say compliance rates or tire setup. Could spend a day screwing with high speed dampening and ride rates and such and probably get nothing appreciable out of it - or that time would have been better spent elsewhere.

So. For any given event you're planning to hit, I think it's good to do a quick litmus test to see if it's worth investing the time in pursuing further. Effective use of time is key in this series IMO.

[BillCobb]

Consider this:

Here is a decent question from the Steering Systems Group on LinkedIN:

http://www.linkedin.com/groups...oback=%2Egmp_1873982

Pretty straight forward question, but look at the 'answers'. These are the kinds of answers usually given by engineers who 'test' by changing parts and go out on the track to evaluate their progress. This is what I call 'Old School' engineering. You work like a mechanic, you talk like an optometrist ("Is this better or worse?") and the hesitation in you answer(s) hint at a lot of doubt in your ability. Plus, you hardly ever know the 'why' of a part change result. Your cars tend to have a lot of adjustment holes and weldment in them. And you get skewered in a presentation to management.

In this case, if you had a decent simulation (and I don't mean an Erector Set program [multibody dynamics]), you would know the cause of this phenomenon and how to eliminate it once and for all.

Industry mechanics only make 1/3 to 1/2 of New School engineers. We call them technicians.

Now can any of you tell us the analogy to a power transister in a hydraulic assisted steering system and what it takes to make it not shedder'? This makes a terrific Simulink model. Use a simple parabola for the control valve profile.

Or just order a truckload of different valves and t-bars and tierods and steering damper parts and a couple of barrels of hydraulic fluid. Then get down and dirty.

[exFSAE]

<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by BillCobb:
Pretty straight forward question, but look at the 'answers'. These are the kinds of answers usually given by engineers who 'test' by changing parts and go out on the track to evaluate their progress. This is what I call 'Old School' engineering. You work like a mechanic, you talk like an optometrist ("Is this better or worse?") and the hesitation in you answer(s) hint at a lot of doubt in your ability. Plus, you hardly ever know the 'why' of a part change result. Your cars tend to have a lot of adjustment holes and weldment in them. And you get skewered in a presentation to management.

In this case, if you had a decent simulation... </div></BLOCKQUOTE>

'Decent' is the key word. Just because someone makes a simulation or math model does not mean it is an accurate predictor. You don't know the confidence level in the predictions until you validate it - after which point you can comfortably use it to make engineering decisions.

That's the point here. Already in this example there's a fundamental assumption being made in how one would go about this math modeling that from previous work on this very topic - I don't agree with.

Leaning too heavily on the side of "old school" engineering, or tinkering as the case may be, is indeed something that can get you left in the dust by competitors who are taking an approach based more on total system understanding.

On the other hand, I think it's MUCH more dangerous to be too heavily on the side of "new school" engineering when you have blind faith in a predictive tool and then you make a very wrong decision based upon the results. That's where you'll be skewered in a presentation to management, or your team principal, or the man whose name is on the side of the race shop. It can be a common pitfall of newly graduated FSAE alumni going into industry, and one of many poor engineering practices which are soaked in when we're in college.

Consider this: When you're brand new to a team or organization and trying to justify your pay by appearing competent... you don't want to be THAT guy who points the way to a poor solution because you were overconfident in your tools.

When it comes to developing new simulation tools... there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – there are things we do not know we don't know.

It's that last one that will get ya.

[Moop]

Regarding tire load variation - is it typically calculated as a function of frequency in a frequency sweep? I mostly see it referred to as an RMS value and that's what it's referred to as in RCVD. But an RMS is just one value of a given time history, which is where I'm getting confused. I thought I could maybe make some time slices around each frequency and calculate the RMS tire load change in that slice, but I feel like I'm missing something obvious because this seems pretty hack.

The reason why I ask is in my current 4 post model, I'm looking at the transfer function of tire deflection*tire stiffness over road input as a measure of tire load variation. It lets me see relatively the impact of various parameters on the tire load variation, but it doesn't let me get back to say a sinusoidal load fluctuation(of the given RMS value) at each frequency that I could use to see how the actual cornering force is affected by the road undulations.

I suppose I could feed the tire load history through the relaxation function to get a rough idea, but I'm more interested in using this in a lapsim to degrade the grip based on the road input, and possibly try to include the effects of heave variation's contribution to tire load fluctuation via changing CG height(which the 4 post model doesn't capture unfortunately...). Including the effect of pitch variation would be cool too, but we're not an aero car yet and even if we were, I'm not sure how I'd capture the effect of varying downforce/aero distribution in a steady-state simulation.

Essentially, I'm interested in determining a performance index for 4 post testing that's more than a guesstimated weighted average of transfer functions that's worked well in the past(or never been used in past if you're me, haha).

Of course, this is all theory in my head right now. We have adjustable dampers this year so I'll do a skidpad test to see if the tire load fluctuation is worth pursuing or not.