Hinge constraint limits upside-down?

[kate]

Hi,

I'm creating a btHingeConstraint using the version of the constructor that takes btTransform "frames", and it's working except for that the limits seem to be acting the opposite way round from how I expect them to.

e.g. If I create a static rb at (-2, 0, 0) and a dynamic rb at (2, 0, 0), constrain the dynamic to the static with a hinge at (0, 0, 0) (with zero rotation), and set the "low" and "high" limits to -10° and 50° respectively (converted to radians of course), the dynamic rb will fall to 50° below the horizontal - which seems upside-down to me?

hinge.jpg

The code I use to create the constraint is:

Code: Select all

btVector3 pivot; // constraint position in world space
btQuaternion rot; // constraint rotation in world space

btTransform ctWorldTransform;
ctWorldTransform.setIdentity();
ctWorldTransform.setOrigin(pivot);
ctWorldTransform.setRotation(rot);
btTransform transformInA = rb1->getCenterOfMassTransform().inverse() * ctWorldTransform;
btTransform transformInB = rb2->getCenterOfMassTransform().inverse() * ctWorldTransform;

btHingeConstraint* ct = new btHingeConstraint(*rb1, *rb2, transformInA, transformInB);
double min = -0.174533, max = 0.872665;
ct->setLimit(min, max);

Can anyone tell me what (if anything) I'm doing wrong?!

Many thanks,

Kate

(N.B. The image maybe doesn't show it clearly, but I am using a right-handed co-ordinate system).

[kate]

So, if I pass the rigid body pointers to the constraint constructor in the opposite order (i.e. child, parent rather than parent, child - as suggested in this thread) it works how I'd expect it to. Is that the order the bodies are supposed to go in?

(I was going by the ragdoll demo, where body A is e.g. the upper leg, and B is e.g. the lower leg... I'm somewhat confused so any input will be gratefully received!)

K.

[Erwin Coumans]

Hi Kate,

Which version of Bullet are you using? I highly recommend trying out latest Bullet 2.74 beta, because my collegue Roman did some work on the constraints recently.

I'll ask Roman to try to help out,
Thanks!
Erwin

[rponomarev]

Hello Kate,

For historical reason hinge angle and limits of the btHingeCostraint are defined with respect to bodyB frame, so they look upside-down with respect to bodyA frame

I added a boolean parameter useReferenceFrameA (false by default) to btHingeConstraint constructor. If you set it to true, limits should be as you expected

Thanks for pointing on that problem,
Roman

[kate]

Hi Erwin/Roman,

I was using v2.73, but I've switched to the new version now and included setting useReferenceFrameA = true, which makes the constraint behave as I'd expect - though I had to set HINGE_USE_OBSOLETE_SOLVER (back) to false in btHingeConstraint.cpp, otherwise it went a little crazy.

Thanks for your help

Kate

[Erwin Coumans]

Oups, the HINGE_USE_OBSOLETE_SOLVER has been reverted to false in the latest SVN.

Thanks again,
Erwin

[kate]

Hi again,

I'm noticing a similar thing happening with the ConeTwist and Generic6Dof constraints; I can get around it just by passing the rigid bodies in to the constraint constructor in the "Bullet-proper" order, though when I do that for the 6Dof constraint its linear limits end up back-to-front. I can get around that by flipping them, but I wondered if it was possible/likely that a use(Angular)ReferenceFrameA parameter could be added to these types too in the future? (I had a quick look at the code to see if I could alter them myself, but I don't really have the time right now to figure out how they work!).

Thanks,

Kate

[rponomarev]

Hello Kate,

We plan to add a possibility to choose between reference frames A and B for all joints.
This will work for both linear and angular parts.
Probably we'll release it in version 2.75

Thank you,
Roman