[ODE] Brakes and rotational damping

[Matthew Harmon]

>No; brakes bleed off existing energy as heat. That's very different.<

Well, they convert angular momentum into heat… that’s what I was getting at.
The point being that the energy “leaves” the system as far as ODE is
concerned so I didn't think the velocity manipulation "cheat" was really
that bad. (If I understand it all correctly.  And, as Chris points out any
change is angular velocity is, by definition, caused by a torque.)

> You should never look at the current angle of rotation; you should look at
the angular rotation speed (which is very different).<

Sorry… I meant to say angular velocity… and what you show is essentially
what I am doing.  The problem is that while scaling by angular velocity
conveniently takes sign and magnitued into account, it also makes the
effectiveness of the brake decrease as rotational velocity decreases.  I
believe braking power is mostly irrespective of rotational velocity (except
for heat build-up and material properties which I am not modeling.)  So,
instead, we apply a constant counter-torque (scaled by brake pressure) and
check for reversal... i.e. brakes are locked.  I didn’t really see another
way around that, but would love some other ideas.  It always feels wrong
when checking for sign reversal, etc.


-----Original Message-----
From: Jon Watte (ODE) [mailto:hplus-ode at mindcontrol.org]
Sent: Thursday, February 09, 2006 4:01 PM
To: Matthew Harmon
Cc: ode at q12.org
Subject: Re: [ODE] Brakes and rotational damping




Matthew Harmon wrote:

>   - Velocity-Based Damping: Grab the angular velocity, reduce it, and
> put it back.  This is easy, avoids “backlash”, but probably isn’t kosher
> and I imagine may result in non-physical behavior in ODE.  However, this
> is “sort of” how brakes behave – they simply reduce any existing
> rotational velocity.

No; brakes bleed off existing energy as heat. That's very different.

>   - Add “counter-torque”: Apply a torque opposing the current angle of
> rotation.  This works, but has the “backlash” problem where applying too
> much torque will cause the body to reverse it’s spin.  We check for
> backlash and “lock” the body if it switches direction… but this feels a
> little like a hack.

You should never look at the current angle of rotation; you should look
at the angular rotation speed (which is very different). If you take the
anngular rotation speed, scale it by some factor (that depends on the
mass of the body, and is negative) and apply it to the body as a torque,
this will apply a well-defined impulse during the next time step. If you
do this, and get a reversal of rotation direction once, then you will
get a reversal at each and every step (or you have a bug in your math).
That means your scaling factor is too big; you're breaking too much.

In reality, this works swimmingly in most cases:

   dReal const S = -0.02;
   dReal const * L = dBodyGetAngularVelocity( b );
   dReal m = get mass scalar from body
   dBodyAddTorque( b, L[0]*m*S, L[1]*m*S, L[2]*m*S );
   ..
   dWorldStep( 0.01 )

Note that this is done in euler angle space, which is, technically
speaking, not an equal-force space -- i e, you'll get the "move strafe
faster than move alone" problem unless you compensate.

Cheers,

			/ h+