btMultibody instability

Post Reply
benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

btMultibody instability

Post by benelot »

If I modify the MultiDofDemo.cpp in the bullet examples by simply adding 50 links instead of the original 5

Code: Select all

	int numLinks = 50;
and raising the base position to 30

Code: Select all

btMultiBody* mbC = createFeatherstoneMultiBody_testMultiDof(world, numLinks, btVector3(-0.4f, 30.f, 0.f), linkHalfExtents, baseHalfExtents, spherical, g_floatingBase);
	
I get highly unstable behavior in both the fixed base and floating base case. Just twitching with the mouse at the "rope" makes it go flying. Any way to get more stable behavior?

It also works with 10 to 20 links, but then it is harder to get it unstable.
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: btMultibody instability

Post by Basroil »

Have you tried decreasing the timestep size and using double precision? timesteps will help with most stability issues by improving the integrator accuracy, while double precision will help with rounding and large ratios/ small increments (if your change in position is 0.0001 and you add it to a position that's 200, single precision math will simply fail to add it and you might get 200.0002 or 200.0000 instead of 200.0001). If the problem is poorly defined it won't help much, but if you modified the demo one of those two (or both) may help.
benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: btMultibody instability

Post by benelot »

Thanks for the input! I will check how it works when I use it in my code which uses a timestep of 0.001.

The double precision is a compile flag right? I tried to compile that on my Linux machine, but failed to do so (I was using a general Cmake build process). I will try again and write what the problem is.
benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: btMultibody instability

Post by benelot »

Ok, so it builds properly, but when I compile against my code I get the following undefined references:

Code: Select all

 undefined reference to `btMultiBody::addJointTorqueMultiDof(int, int, float)'
undefined reference to `btMultiBody::btMultiBody(int, float, btVector3 const&, bool, bool, bool)'
...(more multibody related things)
undefined reference to `btCapsuleShape::btCapsuleShape(float, float)'
undefined reference to `btStaticPlaneShape::btStaticPlaneShape(btVector3 const&, float)'
undefined reference to `btHeightfieldTerrainShape::btHeightfieldTerrainShape(int, int, void const*, float, float, float, int, PHY_ScalarType, bool)'
undefined reference to `btRigidBody::btRigidBody(float, btMotionState*, btCollisionShape*, btVector3 const&)'
When I turn it back to a non double precision build, it finds the references again and works normally. What might be wrong? Are these components not for double precision?

I am building with the following cmake line:

Code: Select all

cmake -G"Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_BULLET2_DEMOS=ON -DBUILD_CPU_DEMOS=ON -DBUILD_BULLET3=ON -DBUILD_OPENGL3_DEMOS=ON -DBUILD_EXTRAS=ON -DBUILD_SHARED_LIBS=ON  -DINSTALL_EXTRA_LIBS=ON -DUSE_DOUBLE_PRECISION=ON ..
User avatar
drleviathan
Posts: 849
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: btMultibody instability

Post by drleviathan »

The problem, I think, is that you're submitting floats to some class constructors that explicitly require double. The way to avoid this problem is to never use the float type directly and to never use float literals (e.g. 1.0f or 1.23e4f). Instead always use btScalar and always explicitly cast any literals you happen to need:

Code: Select all

    // don't do this
    float radius = 1.0f;
    float height = 2.0f;
    btCapsuleShape capsule = new btCapsuleShape(radius, height);

    // do this instead
    btScalar radius = btScalar(1.0);
    btScalar height = btScalar(2.0);
    btCapsuleShape capsule = new btCapsuleShape(radius, height);

    // definitely don't do this either
    btCapsuleShape capsule = new btCapsuleShape(1.0f, 2.0f);

    // instead: when using float literals ALWAYS explicitly cast to btScalar
    btCapsuleShape capsule = new btCapsuleShape(btScalar(1.0), btScalar(2.0));
benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: btMultibody instability

Post by benelot »

You are right, that is what I am doing...thanks for helping me out, I will see if that fixes it.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: btMultibody instability

Post by Erwin Coumans »

Indeed, I can reproduce the btMultiBody issue in the current version of Bullet (single precision, premake).

It may be that constraints (mouse picking, contacts etc) add too much energy into the system, and energy increases further due to velocity dependent forces (gyroscopic forces etc).

I created an issue so that I (or someone else) hopefully track down the issue eventually:
https://github.com/bulletphysics/bullet3/issues/471

This btMultiBody instability hasn't shown up yet when loading robot URDF files of humanoids, robot arms or vehicles, as far as I recall.
benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: btMultibody instability

Post by benelot »

@drleviathan

It seems that the library gets compiled to be used with doubles, but the btScalar is still typedefed to be a float. Do I have to manually set BT_USE_DOUBLE_PRECISION? In the cmake process, I defined
-DBUILD_BULLET3=ON and thought that would be sufficient.

Edit:
Nothings changed related to double precision compared to 2.75. By default, Bullet uses single precision. If you build the library using #define BT_USE_DOUBLE_PRECISION, anything that includes this double precision build of the Bullet library/header files needs to have this define (BT_USE_DOUBLE_PRECISION) too.

Thanks,
Erwin
(Erwin Coumans, http://www.bulletphysics.org/Bullet/php ... ous#p17755)

Is that still the way to go?
Post Reply