Physics Simulation Forum


All times are UTC

Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Sun Jul 16, 2017 10:37 pm 
User avatar

Joined: Mon Sep 04, 2006 5:31 pm
Posts: 190
Location: Switzerland
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:

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?

PostPosted: Mon Jul 17, 2017 8:30 pm 
User avatar

Joined: Tue Sep 30, 2014 6:03 pm
Posts: 306
Location: San Francisco
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.

PostPosted: Tue Jul 18, 2017 5:16 pm 
User avatar

Joined: Mon Sep 04, 2006 5:31 pm
Posts: 190
Location: Switzerland
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.

PostPosted: Thu Jul 20, 2017 10:49 pm 
User avatar

Joined: Mon Sep 04, 2006 5:31 pm
Posts: 190
Location: Switzerland
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?

// 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 ] );
   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:

// 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?

PostPosted: Mon Jul 24, 2017 2:34 pm 
User avatar

Joined: Mon Sep 04, 2006 5:31 pm
Posts: 190
Location: Switzerland
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:

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:

// 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.

File comment: ExampleBrowser Test Case [7.49 KiB]
Not downloaded yet
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC

Who is online

Users browsing this forum: Bing [Bot], Exabot [Bot] and 13 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group