[ODE] Units used by ODE

[Nate W]

On Wed, 14 Aug 2002, Keshav wrote:

> I was wondering in which units the ODE library works?
> Is it in the world_units or meters??

IIRC, the units are pretty arbitrary.  Still, it seems to me that if you
treat the length units as meters and use -9.8 for gravity, you should (and
do) get reasonably realistic simulations.  That said, I often tweak
gravity until things fall (and fall over) at realistic rates, and many of
my simulations are nowhere near -9.8.

> My world gravity is 0.0, -2.5, 0.0.
> If I set the gravity to -9.8, then, the car becomes very unstable.
>  
> What should be the right gravity to set?

Instability could be a result of many things, not just gravity.  For
example, what's your frame rate?  ERP?  CFM?  I've got simulations using
much higher values than -9.8 with no problem, so I suspect the true cause
of your instability is something other than just gravity.

>  I have a car whose length, width and height are say 2.5, 1.0 and 3.0
> meters respectively. Say, the mass is about 600kg, hence the weight is
> (600 * 2.5) = 1500kg. I have four wheels for my car.

I'd try reducing the mass a lot.  Like down to 10 units.  It shouldn't
affect the behavior too much unless you're running into things, and you
can change the weight of your other objects to suit.  I'm not sure why,
but I have a hunch that mass values can contribute to stability
problems... or it could just be that they need adjustments to ERP and CFM,
I'm not sure.  

> Now, when I simulate, the result is very different from the original.
> When I have scaled the car evenly, shouldn't it behave the same way?

If you make something much larger without changing gravity, you'll find
that it acts as if gravity has become much smaller.  Things appear to fall
more slowly, because in a sense they have farther to fall.

> Also, I would like to know, in which units force is measured?

I think you could probably think of it as newton-meters *if* your objects
masses are equivalent to kilograms of mass in the real world, *and* your
objects' linear measurements are equivalent to meters in the real world.  
I'm not 100% certain of that though, so I'll appreciate reinforcement (or
argument) from everyone else out there. :-)

Basically, I think that if you use SI measurements for everything, you can
treat everything as SI unites.  But, once you depart from SI (for example
if you reduce an object's mass to make the simulation more stable), then
your values become vague quantities than can (must) be tweaked by hand
without regard to their equivalent real-world measurements.  The latter
approach works fairly well though, so I use it all the time.  I'm not
saying it's the right way to do things - it could just be that I'm too
lazy to do things the 'right' way.  It may be possible to get good results
using SI measurements for everything if you tweak the ERP and CFM to
maintain stability.  Then again... note the following recommendations from
sections 10.4 and 10.7 (Making Good Simulations) in the FAQ:

"#  mass ratios - e.g. a whip. Joints that connect large and small masses
together will have a harder time keeping their error low.

#  keep lengths and masses around 1

#  LCP solver takes a variable number of iterations (only
non-deterministic part). if it takes too long, increase global CFM,
prevent multiple contacts (or similar), and limit high ratio of force
magnitudes (tree grabbing problem)"

And also 11.8: "Should I scale my units to be around 1.0 ?

Say you need to simulate some behavior on the scale of a few millimeters
and a few grams. These small lengths and masses will usually work in ODE
with no problem. However occasionally you may experience stability
problems that are caused by lack of precision in the factorizer. If this
is the case, you can try scaling the lengths and masses in your system to
be around 0.1..10. The time step should also be be scaled accordingly. The
same guideline applies when large lengths and masses are being used.

In general, length and mass values around 0.1..1.0 are better as the
factorizer may not lose so much precision. This guideline is especially
helpful when single precision is being used."

-- 

Nate Waddoups
Redmond WA USA
http://www.natew.com