Generic6DOF joint friction bugged (with example)

Post Reply
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland
Contact:

Generic6DOF joint friction bugged (with example)

Post by Dragonlord »

I try to setup a linear motor on a generic 6dof constraint subclass with the simple task of cancelling all forces to keep a platform (no angular movement, only linear up-down movement possible) at a steady altitude. It's a preparation for more but I can't even get this simple problem working. I do this right now:

Code: Select all

void debpBPConstraint6Dof::getInfo2( btTypedConstraint::btConstraintInfo2 *info ){
   const btVector3 axis( m_calculatedTransformA.getBasis().getColumn( pIndexMotorY ) );
   const btScalar linearVelocity = m_rbA.getLinearVelocity().dot( axis ) - m_rbB.getLinearVelocity().dot( axis );
   m_linearLimits.m_targetVelocity.setY( -linearVelocity );
   btGeneric6DofConstraint::getInfo2( info );
}
The motor is enabled and the maxMotorForce set to SIMD_INFINITY. Nevertheless the platform is slowly sinking. I don't understand this behavior. "linearVelocity" is taken from the 6dof constraint motor dealing with bouncing. I'm setting the motor each simulation step to output exactly the opposite force of the velocity acting on the rigid body (body B is static world geometry so it has no effect here).

Where is this strange pull down force coming from? It can't be gravity since this is applied before constraints are evaluated. Or is getLinearVelocity() not updated yet?
Last edited by Dragonlord on Thu Jul 27, 2017 8:19 pm, edited 1 time in total.
User avatar
drleviathan
Posts: 849
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Generic6DOF constraint cancel force problem

Post by drleviathan »

Something does not compute. You use a Generic6DofConstraint to eliminate all motion except vertical up and down (a 1Dof slider) and then you want to keep it at a fixed altitude... which means you want to clamp down on the last open degree of freedom making it a 0Dof constraint. Maybe use a FixedConstraint instead?

Alternatively, you could just make it a KINEMATIC object. You would implement a custom MotionState that overrides getWorldTransform() to set the height and vertical velocity accordingly.

Finally if you want springier motion toward a fixed height but with some dynamics collision response you could implement a custom Action which blends the effect of a linear+angular spring onto body's current velocities. Such logic might be easier to "tune" to do what you want rather than trying to dial in various strengths on a 6DofConstraint.
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland
Contact:

Re: Generic6DOF constraint cancel force problem

Post by Dragonlord »

That's not the final goal. This is just a step in between to get it working. What I want in the end is inner joint friction, hence the joint resisting to be moved along the limited degree of freedom, like a rusty hinge on a door.
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland
Contact:

Re: Generic6DOF constraint cancel force problem

Post by Dragonlord »

I did some more testings and after running into a strange problem where the first step produces a linear velocity that should not be there I have the suspicion Bullet is bugged. Can somebody confirm this behavior to be wrong?

Code: Select all

// before doing simulation step (showing state after last simulation step)
printf( "appliedForce.y=%g linearVelocity.y=%g\n", m_jointFeedback->m_appliedForceBodyA, m_rbA.getLinearVelocity().y() );

if( m_rbA.getLinearVelocity().y() < 0.01 && m_jointFeedback->m_appliedForceBodyA.y() < staticFrictionForce ){
	m_linearLimits.m_lowerLimit[ 1 ] = m_calculatedLinearDiff.y();
	m_linearLimits.m_upperLimit[ 1 ] = m_linearLimits.m_lowerLimit[ 1 ];
	m_linearLimits.m_enableMotor[ 1 ] = false;
	printf( "STUCK: limits %g %g\n", m_linearLimits.m_lowerLimit[ 1 ], m_linearLimits.m_upperLimit[ 1 ] );
}else{
	m_linearLimits.m_lowerLimit[ 1 ] = -1.5;
	m_linearLimits.m_upperLimit[ 1 ] = 0.0;
	m_linearLimits.m_enableMotor[ 1 ] = true;
	printf( "MOVING: limits %g %g\n", m_linearLimits.m_lowerLimit[ 1 ], m_linearLimits.m_upperLimit[ 1 ] );
}
The platform is located at 2.05 and can go 1.5 downwards. The setup should make the constraint stuck below a certain friction force but moving if it goes beyond. The output is the following:

Code: Select all

// step 1:
//   appliedForce.y=0 linearVelocity.y=0
//   STUCK: limits 0 0
// step 2:
//   appliedForce.y=0 linearVelocity.y=-0.1635
//   MOVING: limits -1.5 0
First simulation step the platform is locked to the current position by setting the linear motor limits to 0 for both.

The result after the first step (step 2 in the output) though is not correct. The applied force is 0 which is wrong. It should be 0.1635 (=9.81*1/60). Also the linear velocity is not 0 which is wrong. The platform should not be moving if both limits are the same. The setup for the stuck case is the same as btFixedConstraint has (see constructor) but the result is different.

I assume Bullet bug. Somebody else confirms, or did I do something wrong here?
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland
Contact:

Re: Generic6DOF constraint cancel force problem

Post by Dragonlord »

I tried putting together a test case in ExampleBrowser (getting this to work is a real pain). The attached file is the first part of the problem, the one with the constraint doing strange things right at the start. In my real test case this also leads to strange jittering but I could not directly reproduce it with the example here. Further investigation needed. The setup is though also slightly different. I'll try to better recreate it.

Basically the output of the example is the following:

Code: Select all

appliedForce=0 linearVelocity=-0.166667 position=1.99866
appliedForce=0 linearVelocity=-0.166667 position=1.99813
appliedForce=0 linearVelocity=-0.166667 position=1.99754
appliedForce=22 linearVelocity=0.0333338 position=1.99738
appliedForce=22 linearVelocity=0.0333338 position=1.99751
appliedForce=9.60003 linearVelocity=0.0266676 position=1.99797
appliedForce=9.68002 linearVelocity=0.0213346 position=1.99838
appliedForce=9.74397 linearVelocity=0.0170674 position=1.9987
appliedForce=9.79521 linearVelocity=0.0136542 position=1.99896
appliedForce=9.83615 linearVelocity=0.0109234 position=1.99917
appliedForce=9.86894 linearVelocity=0.00873899 position=1.99934
appliedForce=9.89511 linearVelocity=0.00699091 position=1.99947
appliedForce=9.91614 linearVelocity=0.0055933 position=1.99958
appliedForce=9.93288 linearVelocity=0.00447464 position=1.99966
appliedForce=9.94627 linearVelocity=0.00357914 position=1.99973
appliedForce=9.95708 linearVelocity=0.00286388 position=1.99978
appliedForce=9.96567 linearVelocity=0.00229168 position=1.99983
appliedForce=9.97253 linearVelocity=0.00183392 position=1.99986
appliedForce=9.97803 linearVelocity=0.0014677 position=1.99989
appliedForce=9.9824 linearVelocity=0.00117445 position=1.99991
appliedForce=9.98592 linearVelocity=0.000939846 position=1.99993
appliedForce=9.98876 linearVelocity=0.000752449 position=1.99994
appliedForce=9.99099 linearVelocity=0.000602245 position=1.99995
appliedForce=9.99279 linearVelocity=0.000482082 position=1.99996
appliedForce=9.99425 linearVelocity=0.000386238 position=1.99997
appliedForce=9.99537 linearVelocity=0.00030899 position=1.99998
appliedForce=9.99631 linearVelocity=0.000247478 position=1.99998
appliedForce=9.997 linearVelocity=0.000197411 position=1.99999
appliedForce=9.9976 linearVelocity=0.000157356 position=1.99999
appliedForce=9.99811 linearVelocity=0.000125885 position=1.99999
appliedForce=9.99846 linearVelocity=0.000100136 position=1.99999
appliedForce=9.9988 linearVelocity=8.01086e-05 position=1.99999
appliedForce=9.99906 linearVelocity=6.4373e-05 position=2
appliedForce=9.99923 linearVelocity=5.14984e-05 position=2
appliedForce=9.9994 linearVelocity=4.14848e-05 position=2
appliedForce=9.99949 linearVelocity=3.29018e-05 position=2
appliedForce=9.99957 linearVelocity=2.57492e-05 position=2
appliedForce=9.99966 linearVelocity=2.00272e-05 position=2
appliedForce=9.99974 linearVelocity=1.57356e-05 position=2
appliedForce=9.99983 linearVelocity=1.28746e-05 position=2
appliedForce=9.99983 linearVelocity=1.00136e-05 position=2
appliedForce=9.99991 linearVelocity=8.58307e-06 position=2
appliedForce=9.99991 linearVelocity=7.15256e-06 position=2
appliedForce=9.99991 linearVelocity=5.72205e-06 position=2
appliedForce=9.99991 linearVelocity=4.29153e-06 position=2
appliedForce=9.99991 linearVelocity=2.86102e-06 position=2
appliedForce=10 linearVelocity=2.86102e-06 position=2
appliedForce=10 linearVelocity=2.86102e-06 position=2
appliedForce=10 linearVelocity=2.86102e-06 position=2
I wrote my observation in the code as comment:

Code: Select all

// platform constraint. allows moving up and down between two limits.
// for this problem show-case the limits are identical. in this configuration
// the constraint equals a fixed constraint. the problem is visible in the
// joint feedback data and body linear velocity. at the beginning there is
// a linear velocity for up to 5 frames although the platform should at rest.
// also there is no correction force for up to 3 frames then suddenly a huge
// one of 22. Then after frame 5 the constraint hickups seem to go away and
// it starts fixing the error introducted by the initial hickup and converges
// to the stable situation. the initial force explosion is though enough to
// break the test case of "static joint friction" (limits lifted if force
// exceeds for example 15 [N].
I'll keep things updated in this post if I can reproduce better.

EDIT: This has been tested on GIT HEAD from yesterday.
Attachments
Problem1.zip
ExampleBrowser Test Case
(7.49 KiB) Downloaded 554 times
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland
Contact:

Re: Generic6DOF joint friction bugged (with example)

Post by Dragonlord »

I've setup another example with the kinematic joint friction case. Bullet is definitely bugged since it is unable to counter gravity using a motor even if the force is set ridiculously high. The atteched example shows the problem.

If nobody is going to take a look at this problem I'm going to throw it at the GIT bug tracker.
Attachments
Problem1b.zip
Bug Example
(7.44 KiB) Downloaded 508 times
Post Reply