Bullet or ODE for many rigid joints?

[Rikus]

Hey everyone!

I'm having this issue on PhysX:



Each entity have around 10~ continuous joints (an entity in this project is a robot made of different moving parts, max 30~ joints) and on PhysX it's behaving like a gummy bear.
Increasing the solver iteration count on PhysX to 30 helps, but not good enough, increasing it to 100 seems to do the trick but we are aiming to a thousand of these entities, but even on a very powerful dedicated server (which we are going to use) it will not be able to handle it.

A co-worker of mine suggested me to use Bullet to tackle this (I have little experience using it, just capsule colliders for a big MMORPG we work on).
Does Bullet offers a solution to the "rubber band" effect of joints without increasing the iteration solver to a gigantic value?

Note: All objects are dynamic

[Basroil]

If you mean dynamic joints, it's still going to cost you several iterations (in an 18 pitch-yaw chain I use 100-150) unless you like limp noodle joints. You can probably get away with less by disabling gravity on the bodies of the joint (definitely in bullet/ODE, maybe in physx) if it doesn't affect what you are trying to do with it.

Your other option would be to implement a featherstone system, but nobody seems to want to make one for bullet for fear of killing deactivation (which makes no sense anyway, since the most common applications would be in dynamically controlled joint sets anyway). If you go that route, please do submit a patch, I know a ton of others would love to have one.

[Dirk Gregorius]

All iterative solvers will have this problem. I recommend looking into PhysX articulations. They might help with these kind of problems. Alternatively give Havok a try. They have a chain constraint exactly for these kind of issues.

[Dirk Gregorius]

Just out of curiosity. You plan to simulate this on the server? How many transforms for rigid bodies you expect to be able to send to the client per second?

[razer]

The gummy effect is because bulletphysics and other (physx) use impulse dynamics. This engine blindly applys impulses.
Such system will always vibrate. More joints - more vibration.

Sound like you do not need physics at all.
May be you just need collision detection

or even simpler use some graphics engine that has model with subnodes.

If you just wish to set angle of every joint at certain angle then you just need graphics engine that supports models with subnodes.
If it runs on server then you only need a model class. (without graphics, without physics)
BTW Real robots hand with 10 joints will vibrate as well. It is very complex to make such hand to move like it should.

[Erwin Coumans]

I am planning to add a Featherstone joint to Bullet, that should solve this problem.

When do you need it?
Thanks,
Erwin

[Basroil]

I am planning to add a Featherstone joint to Bullet, that should solve this problem.

The old Featherstone thread (from 2005-2013) hasn't seen activity recently, has the work finally come to a reasonably advanced point? Also, how nicely will it play with hinge motor joints?

[Rikus]

Thanks for all the answers!
I've doing some tests for a couple of weeks with Bullet and PhysX specifically related to this problem, tried many approaches and as Dirk Gregorius said, it's all about iterative solvers. (I haven't tried with articulations, I will research about it.)
I digged around Featherstone, I don't think I have the mathematical knowledge for implementing something like that.

Dirk Gregorios, yes this is aimed to be controlled by a server. Clients will not replicate the physics, just plain and simple visual interpolation of 3D models.
The structural composition of each entity would be like 'robots' with mostly pistons and motors, with an average of 15 (5 to 25) motors/pistons for each entity.
All structural parts (non-active rafters/pipes/rails) will be part of the rigidbody they are connected to. i.e.: o== (motor+rail+rail) will be 1 rigid body with 1 joint.
Network wise, for this particular project I don't need to send data more than 4 times per second and only for objects that had a considerable change (i.e +/-5 degrees), and it doesn't have to be real time, the client can be many seconds behind so I can discard a lot of irrelevant packets and do great interpolation. EDIT: Forgot to mention, that you cannot see all entities at once with all parts detailed. If you zoom out too much, they just become a simple icon.

Erwin Coumans, that would be awesome, and not just for me, for everyone. I was doing all the rest of the programming thinking that I had the physics covered. But when I did a few real tests my world just torn apart. I stopped coding until I had this solved. But if you think Featherstone will most definitely help me with this issue, I can continue working on everything else.

For making these entities I just need boxes, and even a composite rigid body it's enough. But!
The problems come from pistons/motors needed (with limited force), and for that I need Joints, and Joints causes this rubber band effect/gummy effect.
I tried other non-newtonian approaches, like using colliders and making the physics myself, it worked for very basic scenarios, but making a biped 'stand' was a total failure.

I'm open to all kind of suggestions and questions!
Again, thanks for all your support and answers!

[IresomPCH]

Hello~

I'm recently trying to build a robot simulator using Bullet Physic Library. (Great Thanks to Bullet Team for the work!!!)
I use C#/XNA 4.0 as the main program structure, and thus the "BulletSharp by anthrax11" is adopted. (Thanks to anthrax11 too!!!)

I modified the RagdollDemo and integrate the MotorDemo to let the ragdoll stand and move limbs.
The capsuleShapes are replaced by boxShapes, and the joints of legs are hinge constraint.

The setup parameters are as follows:
-----------------------------------------------------------------------------------------------------------
Joint OverrideNumSolverIterations = 30
World SolverIterations = 20

Sole size = 0.15f, 0.06f, 0.36f --> for width / height / length

Joint MuscleStrength = 1.5f

ground.Friction = 0.5f
ground.RollingFriction = 0.5f
ground.SetAnisotropicFriction(groundShape.AnisotropicRollingFrictionDirection, AnisotropicFrictionFlags.AnisotropicRollingFriction);

rigidBody.Friction = 1
rigidBody.RollingFriction = 0.3f
rigidBody.SetAnisotropicFriction(shape.AnisotropicRollingFrictionDirection, AnisotropicFrictionFlags.AnisotropicRollingFriction);

The whole ragdoll structure is about 36Kg
-----------------------------------------------------------------------------------------------------------
In order to let user controll the joint angle all the time, I use world's TickCallback to make ragdoll related rigidbodies keep active.

the current result is shown in this picture:

HumanoidSim_20130924.png

(Note: The cubes in the picture are simply drawn at the rigidbody's center, not the actual rigidbody size)

The two main problems:
1. The joints are not "hard" enough, it should be the iteration solver issue...
2. The rigidBodies at the "sole" position slightly sink into the ground with a minor tilt angle, and the whole ragdoll structure drift around...
and it looks like there's no friction force exists...(Coused by impulse-based algorithm ?)
I've tested changing the friction parameters, but it doesn't help...

As I know, the DARPA VRC's Gazebo simulator and the V-REP robot simulator also adopt Bullet as their physic library, but their simulation result look good to me. There's no above-mentioned problems...

Could anyone help with the that?
Maybe the featherstone algorithm is the fundamental solution?

[Dirk Gregorius]

The collision shapes should overlap the joint pivot points. This gives better results due to better mass distribution. I would also make sure the bodies gets lighter from the pelvis to the outer limbs. Don't squeeze light bodies between two heavy (e.g. clavicles). You usually get better stiffness by lowering the timestep instead of raising the iteration count. E.g. halfing the timestep is better than doubling the iteration count. In your example I would try 240 Hz with maybe 128 iterations. I would be curious if this improves you simulation. Maybe share a video

HTH,
-Dirk

[IresomPCH]

The collision shapes should overlap the joint pivot points. This gives better results due to better mass distribution. I would also make sure the bodies gets lighter from the pelvis to the outer limbs. Don't squeeze light bodies between two heavy (e.g. clavicles). You usually get better stiffness by lowering the timestep instead of raising the iteration count. E.g. halfing the timestep is better than doubling the iteration count. In your example I would try 240 Hz with maybe 128 iterations. I would be curious if this improves you simulation. Maybe share a video

HTH,
-Dirk

Thanks Dirk~
I'm assuming that your suggestions is for me because you mention the pelvis~

The mass distribution of the ragdoll is:
Head 1.5Kg
Torso 5.5Kg
Pelvis 3.5Kg
UpperArm 2.5Kg
LowerArm 2.5Kg
Hand 1Kg
UpperLeg 3Kg
LowerLeg 3Kg
Sole 2Kg

The actual collision shape do overlap the joint pivot points.
I just temporarily draw the whole things using simple cube model at center position.
Some complex 3D models may be used later on~

I just tried 240Hz and 120/120 iterations for solver/constraint, the ragdoll still drifts a little bit, but it's much better than 60Hz and 20/30 iterations. The stiffness of the whole structure looks even better~

I'm now using 420Hz and 120 iterations, and there's no obvious drift movement right now.

Don't know how to make XNA render video files...
When this simulator gets more mature, I may use capture software to record some testing results, great thanks~

[Erwin Coumans]

Using a small internal timestep, such as 1000 Hertz (1./1000) will help convergence, and I think that is what Gazebo/ROS is using, in combination with more iterations (20 or 30 or so). I do collaborate with them (http://www.osrfoundation.org) they are 15 minutes drive from my place.

I am testing Featherstone joints in combination with the Bullet PGS constraint solver, it takes a bit more time before committing the code into the repository. There will be no joint drift with Featherstone, but there might be other issues. Also, in my implementation there is only a hinge (revolute) and slider (prismatic) joint, in addition to limits and contact constraints.

Aside from this, we are also experimenting with a direct solver, based on the COMPASS, building the full A and b/rhs matrix.
http://www.mat.univie.ac.at/~neum/softw ... MPASS.html
We are doing those tests with Bullet hooked up to Matlab, and with an experimental C++ port of COMPASS. If the solver finds a solution, it is typically high quality, but sometimes it doesn't find a solution.

[Erwin Coumans]

The latest trunk of Bullet has a Featherstone btMultiBody implementation. It needs more work before it can go in production, but if you like you can try it out.