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?