"Broken" hinge constraint [SOLVED]

[ejtttje]

I have a planar arm, i.e. a series of bodies connected with parallel hinge joints. However the middle hinge "breaks" and dangles instead of staying rigid.

The masses are 0.2 for each link, the base is mass 0 to keep it in the air. The link lengths are about 2 each. I've tried scaling these values, doesn't seem to affect it. When it is first created, the arm is straight, and I can see it "fall" immediately upon creation.

If I put the base at z=0 so it rests on the ground plane, the arm is supported and stays straight:


Is there a constraint "rigidity" parameter or something that can fix this? I haven't been able to find it.

[Erwin Coumans]

More info is needed, movies or screenshots is not enough

Large pivot transforms or large mass ratios can cause problems.

You might want to try out other constraints, such as slider or 6DOF and see if it improves.

Thanks,
Erwin

[ejtttje]

OK, some more data points: this is directly related to the gravity and center of mass of the immediately following link, but not to the total mass or CoM of subsequent links.

So in other words, in the previous screen shots, the CoM of each link was at the hinge, but as I move the CoM out along the link, the joints sag more. In particular, the sag on the first and last joints becomes noticeable. It's interesting that the sag of each joint only depends on the CoM of the immediately following link, not all attached links on the arm...

The sag scales directly with the gravity parameter.

I have a feeling I might not be doing my rotational inertia correctly, it may be using a relatively large inertia value based on the CoM distance, so I'll look into that.

But for future reference, it looks like if I switch to btGeneric6DofConstraint then I can set the max limit force and ERP for locked axis via btRotationalLimitMotor? Could you say a bit more on m_ERP vs. m_limitSoftness? The API documentation is a bit sparse there, it sounds like it's something like:

Code: Select all

if(abs(past_limit_error) > m_ERP)
    applyTorque(sign(limit_error) * min(m_maxLimitForce, abs(past_limit_error) * m_limitSoftness))

Alternatively I'd be happy with the hinge joint if there was a way to increase its stiffness. Perhaps there's a similar parameter(s) in btHingeConstraint that I could make accessible (and supply a patch for others) if you give me a pointer? Thanks?

[ejtttje]

It's interesting that the sag of each joint only depends on the CoM of the immediately following link, not all attached links on the arm...

Actually, I take this back, modifying the weight of the last link affects the sag of all of the links leading up to it.

So things seem "sane", it's just that the hinge constraint is too "weak"...?

[Erwin Coumans]

The iterative constrains solver constraints might be too weak indeed, especially when 'large' mass ratios are involved (even 1:10 can be problematic).

Increasing the number of iterations, or decreasing the internal timestep might improve things.

Have you tried btSliderConstraint and/or btGeneric6DofConstraint? They might converge better.
Thanks,
Erwin

[ejtttje]

Indeed, switching to btGeneric6DofConstraint fixes the problem. All joints sag evenly now, and I can adjust the m_ERP/m_restitution parameters in the RotationalLimitMotor/TranslationalLimitMotor respectively to tighten that up to my preference (I'm using 0.95, doesn't seem to cause much (additional) twitching)

Also, although using the generic constraint is a little less semantic/readable, overall I think it simplifies my particular code since the robot configuration can simply specify axis constraints directly instead of switching between different hinge/slider classes. I suppose I may try out the btGeneric6DofSpringConstraint as well, perhaps one constraint class can handle all my needs (e.g. also suspensions for wheeled robots).

Thanks!

[ejtttje]

For reference, I've experimented a bit with adding an integrative controller component to the constraint, which will ramp up constraint force to overcome constant inputs like gravity. This allows a smaller ERP to reduce jitter but still retain constraint rigidity, although my naïve initial solution will have alternative problems with constraints fighting each other. Just for thought, rough draft here:
http://code.google.com/p/bullet/issues/detail?id=263