The online racing simulator
Quote from AndRand :

Fx - Slip Ratio from 0 to 90%, Slip Angle for 2, 5, 8 and 12 degrees on Figure 6.
Fy - Slip Angle from 0 to 30 degrees and SR 10, 20, 40 and 80% on Figure 7.

You say they dont match?

I was referring only to the bottom graph of figure 6, sorry. The top graph indeed is largely complete sliding.

I'm not sure I understand your question. My earlier post for figure 7 (top diagram) shows clearly no valleys or bumps. I'm not going to repeat the exercise for the top graph of figure 6. What I'm trying to show you is that your graphs are not showing what you think they are showing.
Deleted. Was having a brain fart
If you want I can send you .xls

But if you want numbers: here you go (this is also the saddle but bit different as I dont have previous one and had to figure out again). And I know what you are pointing out - this is because I used linear or exponential proportion instead of hyperbolic for changing of force curve along the opposite coordinate because I didnt bother for big values (more than 8-10%and 8-10 degrees) of SR and SA.

edit: F*ck it - comma. For me it was all scalable but I was changing Fx 10x too fast
Attached images
siodło tabele.JPG
And we have the error confirmed...

I picked a cell that was in the valley.

Column 17 (along horizontal axis) and row 25 (along vertical axis) (8 degree slip angle and 6 slip ratio).

Your top graph shows for FX = 792
Your middle graph shows for FY = 506

Vector addition should gives us (792*792+506*506)^0.5 = 1371 which is what we should see in your bottom graph. (This would change the curves dramatically but they'd still be wrong).

Your bottom graph shows 940 for this cell.

Quote :this is because I used linear or exponential proportion instead of hyperbolic for changing of force curve along the opposite coordinate because I didnt bother for big values of SR and SA.

I haven't the slightest clue what you're talking about there.

Anyway, here's the main point: You said you were plotting the vector sum. You aren't. I have no idea what you're doing, but it's definitely not right
Quote from AndRand :top 3d chart is result (vector sum) of charts below.

Okay, your graph is actually sort of making sense. Basically here's the deal. The data you uses measures combined SR and SA up to some value. The corner of the graph represents unmeasured values of SR and SA that you are interpolating. You are "guesstimating" that more combined SR and SA = less force, when in reality as slip becomes really big in either direction your force reaches a steady magnitude point in the SVx, SVy direction.

So I just tried making my own formulas (not pacejka) and ran into a similar issue as you. (falling off at the corners) so I just added an effect where Fx,Fy are just the naive Fx,Fy you get from the friction circle at very high values of slip. You can see the "ugly" effect in the 3d chart, but the feel might actually not be soo bad. Check it out:
Attached images
graphs6.JPG
Quote from jtw62074 :
Vector addition should gives us (792*792+506*506)^0.5 = 1371 which is what we should see in your bottom graph. (This would change the curves dramatically but they'd still be wrong).

Your bottom graph shows 940 for this cell.

Don't tell me Excel calculates it wrong as 939,84

@Nikn: I think you should zoom it in to get the feel of one quater 'cos it is symmetrical

BTW: I perceived those graphs as geometrical and forgot about units. In fact it doesnt matter if I use %, degrees or rads but the numbers should be used in the proper places for chosen units if taken from other charts
Quote from AndRand :Don't tell me Excel calculates it wrong as 939,84

@Nikn: I think you should zoom it in to get the feel of one quater 'cos it is symmetrical

BTW: I perceived those graphs as geometrical and forgot about units. In fact it doesnt matter if I use %, degrees or rads but the numbers should be used in the proper places for chosen units if taken from other charts

Whoops!! I was wrong Not sure how I came up with 1371. Guess I better call it a day
OK, I scaled the units, scaled change of longitudinal force according to the Figure 6.
And comparing to simple scaling to Fxmax (so Fx*Fy doesnt go over Fxmax) it looks bit different still . If anybody wants I attach .xls also.
Attached images
siodło FxFy.JPG
longslip v latslip.JPG
Magic formula.JPG
Attached files
Pacejka combined (4) dynamic response.rar - 331.5 KB - 150 views
I'm not sure what you're asking there?
I read there that LFS cars are default cars and I wonder if results are the same in VHPA and LFS using the same input data.
Well that is the general idea, but the tyre modelling in VHPA is comparatively simplified (there are no slip curves, for example, it's just not needed unless you want to drive it in real time).
Quote from Bob Smith :
Juls - I would argue, if you're not familiar with either empirical or brush models, than empirical models are at least easier to work with, as each part of the equations directly relates to part of the curve in certain circumstances, and it's easy to see which parts you need to replace if you don't like how part of an empirical model works.

Yes easier to implement, but then most of time you are not satisfied. IMO models based on slip curves don't set the problem the right way.

IMO this is the correct way to set the problem:
We have a tyre on the road, we push on the axis following a given force vector. What is the vector of the reaction force?
As soon as we set the problem this way, we sart using formulas involving time.

Even the simplest formula using time (model tyre as a set of non linear springs and dampers matching the slip curves) will avoid many pitfalls you get with slip curves. Because for example with slip curves and a discrete time physics engine, it is very easy to get reaction force stronger than the pushing force, tyres sliding magically at very low speed...etc.
All these flaws are already contained in the very beginning, when you decide to start from slip curves.

For me slip curves are tyre benchmark results, a very good way to check afterwards if your model matches real tyre...but not a starting point to write a model. But maybe I am crazy
Quote from Juls :For me slip curves are tyre benchmark results, a very good way to check afterwards if your model matches real tyre...but not a starting point to write a model.

A very true statement.
Tyre slip curves always represent a specific case, and even complex empirical data is only valid for a limited range of parameters (there are MF-based models with 81 coefficients).

Unless you're looking for a quick substitute for a tyre model (so you can e.g. check the plausibility a suspension model) avoid using special-case empirical data to make assumptions for a generic-case model.

Vain
Quote from Juls :Even the simplest formula using time (model tyre as a set of non linear springs and dampers matching the slip curves) will avoid many pitfalls you get with slip curves

and bring with it a whole set of other problems
iirc tyres have a surprisingly high spring constant which in turn requires a pretty darn high physics rate
Any spring-mass-damper can oscillate or become unstable, I don't see how any tyre model would be immune to this.
i can think of a few games that too my knowledge model a tyre as a solig block of steel with pacejka characteristics so they should be perfectly immune
Pacejka suffers from the same thing though, the cornering and braking stiffnesses act like springs and the car will just oscillate between the two slopes while stationary, and never settle as there is no damping.
hm handt thought about that but then again you cant expect a model that based around slip to work when there is none

now that i think about it i remeber that nkp suffered from that problem
stop on a slope and the car would slowly slide down that slope with the force vectors going mad
Slightly OT, but:

*Looks up at graphs and formula vector thingies talk*

How the **** do you guys know how to do this stuff?
Quote from Shotglass :hm handt thought about that but then again you cant expect a model that based around slip to work when there is none

Yes, you need a separate low speed solution, or you need to add damping, or a combination of the two.
Ah yes, I have played with that method before.

The relaxation length stuff goes even more horribly wrong at low speeds though, and instead of a vibration, you end up with your car sliding side to side with a magnitude of the relaxation length. I seem to remember having troubles getting the damping to work correctly, I'll have to have another play with it at some point, see if I can get that method to work.
Quote from Bob Smith :you end up with your car sliding side to side with a magnitude of the relaxation length.

That must have looked funny, as the typical value of relaxation length for lateral behaviour is around 1 m, FWIR. I must say all these things are pure theory for me, I haven't really experimented with them in code.
Here is another damping method (which you may have seen already): http://groups.google.pl/group/ ... tors/msg/509e0cfe0516548a
Hm yeah my exemple with spring dampers was too simple. I was thinking something like take a simple model like a LUGRE stiction/friction and I figured it would not look simple at all for the reader

I wanted to say something like that: IMO if you really model the tyre/road action/reaction like a stiction/friction mechanism, even a very simplified one, you can avoid many pitfalls.
- some stiction/friction models are robust at speed 0
- they can immediately take into account hysteresis
- they seem scalable and very convenient for object oriented programming

Of course you have lots of experience I clearly don't have. But as a software developer, my feeling is that implementing such model instead of the very usual slip curve model could be a win win situation. Possibly richer model at the end, probably less problems adjusting it, more intuitive. Don't see the problems precisely in advance...but usually I am not too bad guessing which general direction is less crowded with problems than the other

Tyre Physics progress spinoff thread for physics geeks
(168 posts, started )
FGED GREDG RDFGDR GSFDG