rec.autos.simulators

   So far I'm still collecting resources, I have:
Baraff's papers, Mirtich's papers, Physics of Racing series, Hecker's
papers, Charney's paper.
Racer, Fastcar.
Any important resources missing? More source code to be found somewhere? One
thing I heard mentioned a couple of times here is SAE, what is that? Also, I
haven't found a comprehensive set of car data, yet. For example, where do
you get all the air-resistance, motor torque etc values from? This data
seems even harder to come by if you don't want to model the typical
race-cars, but rather off-road vehicles.

   I wanted to start writing a simple rigid body simulator that correctly
handles (collision-) forces. Then go on building a car model on that basis,
continually refining it. What do I have to watch out for? Are there any
decisions made early on which will later make further refinement impossible?

   What about 4x4 vehicles, BTW? I haven't seen anyone model them?

regards,

    BuschnicK

--
RealName: S?ren Meyer-Eppler | ICQ: 45724082

www: http://www.racesimcentral.net/
See what everyone else has seen, think what no one else has thought.

If you have the money, it's well worth buying a copy of Race Car Vehicle
Dynamics by Milliken and Milliken (I'm sure Doug Milliken himself will pop
in with details of where to purchase it from). Any online links worth
looking at you can probably get from Ruud Van Gaal's Racer page.

Also if you've got any specific questions, post them here with the prefix
"Car Physics:" and you should get some good responses.

 One

The Society for Automotive engineers http://www.sae.org. Good resource for
buying papers and books related to vehicle dynamics.

Also, I

hmm ... dunno. I'll leave that for somebody else to answer

Starting with a rigid body simulator is a good approach. One thing I
recommend is to think about everything your sim will need at the start and
building it in from there. If you go with the opinion that you'll just build
things in as you need them, you may find that you're constantly rewriting
code (but I suppose this is true of any software engineering project). One
good example of this is your suspension system. If you intend to use
constrained dynamics for simukating your joints, it's a good idea to do it
from the start as part of your RB simulator. That way when it comes to
actually modelling the suspension, you only have to worry about the vehicle
dynamics part.

Another thing that got me at the start is units - start with real world
units for your quantities (eg Kg, N, m etc) and stick to them. I just use
"game" units at the start and got to the point where I had to spend about 2
weeks just converting to real units.

Another good idea is to allow easy editing of the car values (eg from a text
file).

I think Racer supports them?

Good luck!

Mike.

<snip>

Seems to be an expanding field, this - excellent. Anyone out there
writing (or thinking of writing) an *open-source* sim? There's a gap in
the market for that...

--
Sceptical scrutiny is the means, in both science and religion, by which
deep insights can be winnowed from deep nonsense -- Carl Sagan

The GPL Scrapyard returns (slowly): http://www.hillclimbfan.f2s.com

   Well, if my project will produce anything worthwhile I'll certainly
release the source.
Racer also has a semi-open source license, see
http://www.marketgraph.nl/gallery/racer/ in the docs section. Depending on
your definition of open source it might be perfectly acceptable for you - at
the very least it allows you to learn lots from the source to kick-start
your own projects ;)

   BTW, a free open source sim fills a gap in "the market" ?! There's a gap
in the market for free real world cars as well! ;)

regards,

    BuschnicK

--
RealName: S?ren Meyer-Eppler | ICQ: 45724082

www: http://home.t-online.de/home/BuschnicK/
See what everyone else has seen, think what no one else has thought.

   EUR 133,43 at amazon - ouch! And I doubt I'll find that at my local
library... I'll be a cheap ass and see how far I can come with the material
available for free, which is surprisingly good.

   I have that bookmarked of course ;)

build

   That's why I'm asking here. Problem is I can't do a rigorous up-front
design because I don't have all the physics knowledge, yet. That's part of
the point of the project, learning by doing. I just wanted to avoid the
major stumbling blocks.

   I'll keep that in mind. I also wanted to try and do a system that
supports multiple integrators right from the start. I figure that if I
support at least two (Runge Kutta and Euler seem to be the most common)
adding more later on will be easier.
   What are the experiences with fixed vs variable time step simulators? I
figure fixed will be easier and numerically better predictable, but scale
less well?

   That was never a question for me. I loathe the miles, pounds etc system
and have only had bad experiences with 'game units' before - even in
non-physics heavy projects. So a proper metric system it is for me.

   Also a given. I figure tweaking all the different physics variables and
constants will be a major part of the work, so easy accessability and short
modify/test turn-around times are a must.

Ruud?

Thanks, and thank you for the good answer...

regards,

    BuschnicK

--
RealName: S?ren Meyer-Eppler | ICQ: 45724082

www: http://home.t-online.de/home/BuschnicK/
See what everyone else has seen, think what no one else has thought.

Yeah it is expensive. But if you come into an inheritance in the near future
it's definitely worth buying :)

Sounds like your starting with the correct approach anyway (unlike I did).
If you're going with the rigid body approach, the main thing is that you
have good, complete RB system so that you can feed it forces, impulses etc
at any point, constrain rigid bodies together etc. Once you have that your
vehicle dynamics can just sit on top, feeding forces to your RBs and you're
away.

One other link that could be useful for constrained dynamics is Andrew
Witkin's papers

http://www-2.cs.cmu.edu/~baraff/sigcourse/

You should also look into implicit integration methods for increased
stability.

The main problem you'll experience here is instabilities due to the stiff
springs you'll encounter in your suspension system. Depending upon which
integrator you use, you'll have to keep your timestep fairly small to avoid
your solution blowing up (implicit integrators don't have this problem, but
if your timestep's too large you'll miss out on the finer detail in your
suspension system).

Excellent. Good luck with the project.

No, that's not what I meant - I should have been more specific. (And
Ruud van Gaal has said specifically that the program is *not* open-
source in the normal definition, because he will not allow others to
release adapted versions.) It would be good to have a sim that could be
freely adapted and extended by other people, while possibly retaining
an "official" central version. The arcade games emulator MAME has
exactly that sort of licence.

LOL. It's odd, though, that racing games are now one of the few sectors
where there isn't a decent open-source program (I don't count Racer, as
I mentioned above, as its licence is too restrictive to count as open
source).

--
Sceptical scrutiny is the means, in both science and religion, by which
deep insights can be winnowed from deep nonsense -- Carl Sagan

The GPL Scrapyard returns (slowly): http://www.hillclimbfan.f2s.com

What does that mean? I'm very fuzzy with the terms, so I'd appreciate if you
could explain to me the difference between implicit methods and for example
simple Euler?

regards,

    BuschnicK

--
RealName: S?ren Meyer-Eppler | ICQ: 45724082

www: http://home.t-online.de/home/BuschnicK/
See what everyone else has seen, think what no one else has thought.

v(t+dt) = v(t) + a(t)*dt

For implicit integration, you also use values at the current timestep to
achieve your new solution. So you get a system of coupled equations to solve
at your new timestep, rather than the above. This is more compuationally
expensive than explicit integrators, but the integrator is (I think)
unconditionally stable.

I think one of Baraff's papers covers implicit integration, but I'm not sure
which one. Perhaps somebody else knows?

http://www-2.cs.cmu.edu/~baraff/sigcourse/notese.pdf

(been reading it just yesterday :) )

-Gregor

Stephen

Yep, I should have made this point. Stability and Accuracy are different
concepts. Accuracy relates to how close the numerical solution is to the
actual solution, whereas stability relates to whether errors in the
numerical solution are amplified in time. A stable solution will not
guarentee an accurate solution, and since the accuracy is a function of the
timestep, you'll get a decrease in accuracy by increasing the timestep.

The main reason for turning to implicit solvers in a dynamics problem would
be to avoid instabilities due to very stiff springs (such as you might find
in a suspension system). Of course you'll still need to keep quite a small
timestep to get accuracy, but an implicit integration should avoid any
instability.

And Vice-versa.

I've done work with RB models containing very (very!) stiff springs and
have found trouble with even implicit methods at exhaustively small
timesteps.  My goal is only a static solution, and so I would like to
discard dynamics accuracy (since steady-state is all I want).  Sometimes
my system will settle to a nice steady configuration, but 99% of the
computation time is about damping out the oscillations.

Dave