Multiple btMultiBodyJointLimitConstraint problem/bug

Post Reply
michi
Posts: 8
Joined: Tue Dec 13, 2016 10:11 am

Multiple btMultiBodyJointLimitConstraint problem/bug

Post by michi »

Hi,
Just recently started looking at using btMultiBody but found some strange behaviour that might be a bug.

I attached a modified TestJointTorqueSetup.cpp sample to this thread.
What I am seeing is the following:

1) I have 2 links both have motors and joint limit constraints.
2) When joint limit for link 0 is reached link 1 gets modified (an internal impulse seems to get applied)
3) When I remove the joint limit constraint of link 1 then the joint limit constraint for link 0 works as expected.

So basically joint limit 0 gets ignored (although that limit has been reached) and link 1 gets modified.
Wondering if the is some internal indexing in Bullet is wrong.

To get correct joint limit 0 behaviour comment our the 2 lines below the following comment.
// Remove this joint limit constrtaint got get correct behaviour.

To see the wrong behaviour comment the joint limit for link 1 back in.

Also not sure if this kind of things should go to the forum or directly to git.
Attachments
TestJointTorqueSetup.cpp
(15.16 KiB) Downloaded 205 times
michi
Posts: 8
Joined: Tue Dec 13, 2016 10:11 am

Re: Multiple btMultiBodyJointLimitConstraint problem/bug

Post by michi »

added comment. Turning the 2nd motor off helps as well ...
michi
Posts: 8
Joined: Tue Dec 13, 2016 10:11 am

Re: Multiple btMultiBodyJointLimitConstraint problem/bug

Post by michi »

so is there 1 constraint per link limit?
maybe I should not use motors&joint limits but just motors and clamp the joint limits myself checking the current joint positions ?
Kindest regards
michi
Posts: 8
Joined: Tue Dec 13, 2016 10:11 am

Re: Multiple btMultiBodyJointLimitConstraint problem/bug

Post by michi »

and so I thought ... checking the URDF sample I can see joint limits and motors attached so it should work .. not sure why my attached sample does not :(
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Multiple btMultiBodyJointLimitConstraint problem/bug

Post by Erwin Coumans »

The btMultiBody setup is complicated and error-prone, and that is one (more) reason to re-use the URDF loader (in C++), the PhysicsClientC_API (in C, C++) or simply use pybullet to reproduce issues. (it takes too much time to dig through custom btMultiBody setup)

If you add a joint limit and a motor with conflicting targets, it is up to the solver what the resulting behavior is (you cannot satisfy both constraints at the same time, so it is undefined how/where the error is handled). In our implementation of projected Gauss Seidel, the order in which constraints are added to the world influences the undefined result (constraints added 'later' are satisfied a bit better).

Ideally the joint limit and motor is rolled into a single constraint with explicit logic to avoid such conflicts. This is implemented in the btGeneric6DofSpring2Constraint for btRigidBody. We should implement equivalent logic for our btMultiBody joint limit/motors.
michi
Posts: 8
Joined: Tue Dec 13, 2016 10:11 am

Re: Multiple btMultiBodyJointLimitConstraint problem/bug

Post by michi »

Thanx for the comment.

>The btMultiBody setup is complicated and error-prone,
>(it takes too much time to dig through custom btMultiBody setup)..
Sure. Thats why I did minimum changes to the original "TestJointTorqueSetup" in my attached sample.


>If you add a joint limit and a motor with conflicting targets, it is up to the solver what the resulting behavior is (you cannot satisfy both constraints at the same time, so it is undefined how/where >the error is handled). In our implementation of projected Gauss Seidel, the order in which constraints are added to the world influences the undefined result (constraints added 'later' are satisfied a >bit better).
Given that the URDF loader adds btMultiBodyJointLimitConstraint constraints in ConvertURDF2BulletInternal and then motors to btMultiBodyJointMotor in ImportUrdfSetup::initPhysics you run into exactly the same potential problem you describe.

>Ideally the joint limit and motor is rolled into a single constraint with explicit logic to avoid such conflicts. This is implemented in the btGeneric6DofSpring2Constraint for btRigidBody. We should >implement equivalent logic for our btMultiBody joint limit/motors

That sounds like the solution to this issue.
Post Reply