[ODE] Collision constraint

Wed Jun 25 08:39:02 2003

hi,

you are correct. ODE corrects positional errors by applying a velocity
to objects and allowing that velocity to take effect over one time step.
so, yes, energy is inevitably added to the system, because the velocity
increases. but, "most" of the time this extra velocity is drained away
automatically so you don't see a global energy increase. to explain this:
suppose you have a contact constraint with a penetration of 1.0, and ERP
is set to 0.5. in timestep 1 the velocity is set to reduce the penetration
to 0.5. in timestep 2 it's reduced to 0.25, then to 0.125 etc. the extra
velocity required to do this is 0.5/h, 0.25/h, 0.125/h etc. the point is,
as long as the contact constraint remains in contact, the correction
velocity will be set irrespective of what the previous correction velocity
was, and everything works well (i.e. in the limit the correction
velocity goes to zero).

the problem comes when you have a significant nonzero correction velocity
and the contact is broken ... then the correction velocity turns into a
'real' velocity. this can happen e.g. if there is a pulling-apart force
right after a contact is made. it can also happen if you increase the
timestep greatly (because then the effect of the correction velocity is
magnified to be much more than the error correction system intended). this
effect was discussed a while ago.

there is a solution to this problem that has not yet been implemented (i
said that before, http://q12.org/pipermail/ode/2002-October/006007.html).
the solution does an extra solve per timestep to explicitly set the
correction velocity to zero after each timestep. this is the equivalent of
"just moving the objects" without adding any extra velocity, but it's a
little bit more computationally expensive.

russ.

--
Russ Smith
http://www.q12.org/

On Wed, 25 Jun 2003, Joakim Eriksson wrote:

> > > Isn't there anyone that knows if this is an issue with ODE?
> > >
> > ODE doesn't use penalty methods, so no, the issue discussed
> > doesn't affect ODE.
>
> As far as I can see the resolver is always and only generating a
> force to fix both invalid positions and invalid velocities.
> If that is the case then can't the resolver add in energy into the
> system? (When it fixes the penetrations)
> If the timestep is very small this shouldn't be a large issue
> but if one object manages to penetrate far into another it could
> be a problem.
>
> If I understand it correctly so if you are going to fix penetrations
> correctly without adding energy into the system you will have to
> actually move the objects. Not through velocities but by updating the
> position of the objects.
>
> Is this correct and does ODE do it?
>
> /Joakim E.
>
> > > > -----Original Message-----
> > > > From: Bob Dowland [mailto:Bob.Dowland@blue52.co.uk]
> > > > Sent: den 19 juni 2003 15:24
> > > > To: ode@q12.org
> > > > Subject: RE: [ODE] Collision constraint
> > > >
> > > >
> > > > I think you've hit the nail on the head here - this is the
> > > > main snag with "penalty methods" (penetration correction
> > > > force). I don't know how ODE's "correction" works, perhaps
> > > > someone can explain but using a simple spring model (force
> > > > proportional to error) can give rise to these additional
> > > > "bouncing" effects.
> > > >
> > > > If you think of the penetration as an error call it e and
> > > > note that it is a function of time e = e(t) then a simple
> > > > spring correction also called "proportional controller"
> > > > generates a force proportional to that error
> > > >
> > > > F = F (e(t)) = kp.e(t)
> > > >
> > > > this is the same ode as for a spring (giving "shm"). It's
> > > > nice and simple but does produce, well, a certain
> > > > springyness. An improvement on this is "proportional,
> > > > derivative control":
> > > >
> > > > F = kp.e(t) + kd.d/dt{e(t)}
> > > >
> > > > a spring with a damper. A little more complicated but gives
> > > > you a fighting chance at least. The trick, then, is to find
> > > > "good values" for kp and kd, (ie ones that make e go to zero
> > > > as quick as poss, not overshoot, and not oscillate about zero
> > > > - aka "critically damped") unfortunately this often comes
> > > > down to manual tweaking - depending on the situ.
> > > >
> > > > I don't know if this helps in any way - I guess it would be
> > > > more useful to hear what some of the ODE vets have to say on this.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Joakim Eriksson [mailto:jme@snowcode.com]
> > > > > Sent: 18 June 2003 09:42
> > > > > To: ode@q12.org
> > > > > Subject: [ODE] Collision constraint
> > > > >
> > > > >
> > > > > I have been looking a bit at the constraint system and
> > there is one
> > > > > thing I wonder.
> > > > >
> > > > > As far as I can tell so does the constraint solver only
> > > > > return a force.
> > > > > That force
> > > > > is then applied to the bodies. So the force turns into a
> > > > velocity that
> > > > > changes the body.
> > > > > Now what happens if a body is far into for example a
> > plane. So the
> > > > > penetration
> > > > > depth is large. That would force the 'c' part of the
> > > > > constraint equation
> > > > > to have a
> > > > > large value (To fix the penetration). If we would set
> > the ERP to 1.0
> > > > > then he
> > > > > would need to fix the error as quickly as possible. Now
> > > > > because we calc
> > > > > a force
> > > > > wont that mean that the body will get a velocity that forces
> > > > > it not only
> > > > > to quickly
> > > > > move out of plane but also to continue away from the
> > plane? Or am I
> > > > > missing
> > > > > something?
> > > > >
> > > > > If the problem actually does exists it would show in the
> > > > > following way.
> > > > > A fast moving object with a coeffiecent of resitition that
> > > > equals 0.0f
> > > > > that collides
> > > > > with for example a plane would still get a bounce effect.
> > > > How high the
> > > > > bounce would be would depend on the ERP and the
> > penetration depth.
> > > > >
> > > > > /Joakim E.
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > ODE mailing list
> > > > > ODE@q12.org
> > > > > http://q12.org/mailman/listinfo/ode
> > > > >
> > > >
> > > > _______________________________________________
> > > > ODE mailing list
> > > > ODE@q12.org
> > > > http://q12.org/mailman/listinfo/ode
> > > >
> > >
> > > _______________________________________________
> > > ODE mailing list
> > > ODE@q12.org
> > > http://q12.org/mailman/listinfo/ode
> > >
> > _______________________________________________
> > ODE mailing list
> > ODE@q12.org
> > http://q12.org/mailman/listinfo/ode
> >
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>