On Thu, 8 Nov 2001 22:24:06 +0200, "Petri Blomqvist" <p...@iobox.com>
wrote:
>Of course, you can always do that yourself while waiting for compilers to
>gain this important feature. :-) I actually did that for my own sim. I just
>output the variable I want to graph, into a text file. Very crude, but I can
>view it with my own little (equally crude) graph viewer app. :-)
Indeed, might be a good one. Perhaps even to generalize it a bit
still, so it's easier to do (which effectively means you'll use it,
instead of having the technology to do it ;-)).
>> I have a hunch my tires are oscillating vertically (thus giving a
>> worse average grip), and this could be looked at more nicely with a
>> sort of graph utility and some generalized way of storing of a
>> variable's value.
>I don't really see how you could have unwanted oscillations in the
>suspension even using the tire rate, unless you're using really low damper
>values or a really big time step.
Well, say I have a tire with 200,000N/m tirerate. It's being pushed
1cm into the tarmac. That gives 200,000N/m*0.01m = 2000N of force. If
the wheel is 20kg, that would mean an acceleration of F=ma =>
a=2000/20=100 m/s^2.
Integrated at 200Hz that means v gets updated to 1/200*100 = 0.5 m/s.
So the next step, v=0.5 m/s, integrated again: 1/200*0.5=0.0025 m. Hm,
just 2,5mm. ;-)
But I think it was the damping that caused problems. The more damping,
the less numerically stable things got. With the help of Gregor, I put
in an implicit integrator, which steps back in time (see Baraff's
paper on Implicit Integration for example). This seems to make things
much more stable.
> I run my physics code at 500 Hz, and I'm
>not experiencing any oscillations, even if I lower it to something like 200
>Hz. One thing that improves stability greatly is including the second
>derivative in integrating the new suspension jounce distance (or any rigid
>body position, for that matter):
>dx/dt = v + 0.5*a*dt,
Yes, weird. The infinite Taylor series on integration would go like:
x(t0+h) = x(t0) + h*x'(t0)+(h^2/2!)*x''(t0)+...
translated that would be:
x(t0+h) = x(t0) + h*x'(t0) + (h^2/2!)*x''(t0)+...
= x(t0) + h*v + 0.5*a*h^2 + ...
which looks more like:
dx/dt = v + 0.5*a*dt^2
then v + 0.5*a*dt
I don't really understand that. What I do understand is that your
method takes the midpoint velocity. Like an RK2 step, only simpler I
think.
I already did some 0.5*a*dt^2 additions in the suspension and that
already helped. Perhaps using 'dt' (non-squared) helps even more?!
>where 'v' is jounce velocity and 'a' is the acceleration which is assumed to
>be constant over the time step. It's certainly better than a plain Euler
>integrator. I actually used a 4th order Runge-Kutta integrator originally,
>but I went back to a Euler integrator because I had coded some things in a
>way that doesn't really work with an integrator that needs to step back and
>forth.
Ouch, that doesn't seem a nice debug-friendly environment. :)
For collisions it might not be that bad; if I can figure out if
FastCar's linear projection method works ok even for a stack of cubes,
then I'd rather use that than to double buffer all my force results
(to be able to 'undo' a step).
...
>classes for meshes, sound fx etc. is even more difficult to me than coding
>the physics! But I digress. :-)
Hehe, well, if it works, it's hard to fix things. New things, I tend
to think, are much more interesting and attract all the energy.
>Anyway, any oscillation that would affect the tire load force to any
>significant degree would certainly be visible, and looking at the wheels in
>Racer, they look very stable. Are you sure it's not just a problem with
>calculating the lateral tire force?
Partly perhaps. ;-) Actually, it makes a whole lot of difference at
what HEIGHT I apply the lateral forces to the body. If I move the
application point away from the CG height too much, the body roll
torque gets unstable and sliding the car sideways, for example, can
make things a bit springy (although it was some time ago that I
checked the effect). It was a big problem with the SAE950311 method
(Barnard) where the slipAngle (SA) wouldn't be updated quickly enough,
and I'd get a slowly swinging car from left to right (in the order of
0.5Hz something), growing worse with every swing. I took out the
damping for that method though, since it caused trouble (have to
reinstate it and vary the damping force negative/positive for each
timestep, which seems to be needed).
Try increasing the damping of a wheel in Racer (all released versions)
to say 8000N/m/s. Kablam! That's mostly fixed now.
I took out the lateral forces 2 days ago to check if that may be part
of the problem, but the jitters kept on being there because of the
high spring rates (mostly the tire). Damping seemed to be a big part
of the problem.
>> Do you get the (dynamic) friction coefficient directly from the D in
>> Pacejka?
>No, I calculate the dynamic friction coefficient based on the slip ratio of
>a locked tire (-1, obviously).
Ah. I have the idea that Pacejka goes down too much there, and isn't
really suited for a locked tire coefficient. I play with the a0/b0
parameters to go easy on the lateral/longitudinal force fallback.
> Although actually, at the moment I'm
>experimenting with a simplified tire model instead of Pacejka. Since all
>those Pacejka coefficients are next to impossible to come by (except for
>that "Ferrari tire" that almost everyone seems to use)
Figures where half of it has not been calculated btw. No
load-sensitivity in those numbers. The car before that, a saloon car
or something (1.271 lateral friction coefficient) looks much better.
Perhaps some factors could make it apply to race tires.
Although Pacejka is quite complex, I can play with it (check out
Racer's Pacejka editor) and it doesn't really matter that there are so
many coefficients. Although a simpler BCDE version can also be useful
I guess.
>> Wouldn't that mean that you can't slip the tire? I mean, if both tire
>> spin and road speed are held at the same speed, surely there's no
>> slipping (and no slip ratio?!).
>No, you misunderstood. :-) I don't hold the tire spin and road speed at the
>same value, I simply prevent the tire-ground friction from doing what it
>can't do by definition - it's a friction force, so it always attempts to
>minimize the speed difference between tire and road. But because of the
>discrete time steps, the friction force we calculate at the beginning of a
>timestep can overaccelerate the tire during the time step so the speed
>difference can actually increase, which is physically impossible.
Hm, interesting idea. So you look at the road reaction (the output
from the Pacejka or Blomqvist curves ;-)) first to see how it would
accelerate the tire? (disregarding engine/differential torque for that
moment) Funny, I'd think you could only look at the combined forces,
not one force at a time and cap the friction (road reaction) force
separately and later add the engine torque.
But the friction force always points in the reverse direction of the
wheel vs road rotation, right? So how could it make the speed
difference *bigger*? By velocity reversal (spinning the wheel in
reverse)? (and giving more reverse speed than the wheel is current
going forward)
It would seem at medium to high speeds the friction check doesn't come
into play at all.
>In a sense I suppose you could call it that, although it only kicks in for
>the special case when the friction forces need to be prevented from adding
>energy to the system. *Real* predictor-corrector integrators are constantly
>predicting-correcting, I believe. :-)
You're right, you're I think only predicting with the friction force,
and not doing the same with engine force/torque for example.
>But it definitely eliminates all unwanted rotational oscillations in the
>tire!
Heh, that's why I want to understand it fully. :)
>> Still don't see how a big skid
>> would be done that way though.
>Believe me, it can! You should see the amount of smoke that's generated when
>I do donuts in a Camaro. :-)
Cool. :) Are you ever going to release a demo of your sim btw?
>I think I'll try to code a regular dry-friction clutch-plate LSD before I go
>for things like Salisburys or Torsens. :-)
Salisbury is a friction clutch plate LSD, but there's something about
the amount of locking torque it can generate, which is seemingly
infinite (well, at one point you get damage points awarded ofcourse
and a little firey particle is trigger ;-)).
>> If I use the AABBtree (quite a simple concept,
>> see 'AABBTrees Collision Detection for Deformable Models' by Gino van
>> den Bergen) for the car as well, I could do quick track-car detection
>> and be triangle accurate. Very important to get rough crashes to look
>> ok! ;-)
>Sounds interesting, will have to investigate. :-) I'm using the vertices of
>a simplified body model as collision contacts with the ground, which works
>perfectly as long as the ground is relatively smooth. No object-to-object
>collisions yet, as there are no other objects yet. :-)
Right, and falling straight onto a pit wall is hard to do with points
only. The AABBTrees are really like BSP trees (GPL uses those), and
you can run through 2 trees and find the overlapping areas. The
question is just how MUCH overlap it's going to generate.
I started with a semi-3D AABBTree, mostly 2D since a track basically
looks very 2D-ish (to the birds :)). But I see it can be generalized
for car-car collisions as well (and car-anything to add hittable
things on the track).
Unfortunately I have nothing in the direction of a contact point
solving system yet. And I don't really get Baraff supposedly 'much
easier' way of iteratively solving for all contact forces.
So no juicy collisions yet.
...
>Perhaps so, but one good aspect of doing the whole terrain as Bezier (or
>Hermite, or whatever) patches would be the amount of memory saved. Instead
...
read more »
