btMultiBody instability (character shoots up into the air)

Post Reply
teh_ballerer
Posts: 9
Joined: Fri Sep 26, 2014 3:31 am

btMultiBody instability (character shoots up into the air)

Post by teh_ballerer »

I'm trying to make a sports game with physically simulated characters. I created a torso (still missing arms and head) using btMultiBody, ran the simulation, and watched the btMultiBody crumple to the ground as expected. I then wrote a for loop to easily clone this btMultiBody, and position the clone at an offset so I can observe them all crumple to the ground. This works nicely, however some of the btMultiBody instances are unstable as I increase the total number of them in the simulation. I have created 22 of them because that is the number I will need simulated in my game. When some of the multibodies fall to the ground, they shoot upward into the air and fly throughout the void indefinitely (they don't just shoot up into the air and fall back down, they fly throughout, twisting and spinning violently).

I have observed this behavior with a fixed timestep of 8 ms. I have noticed that different timesteps (both larger and smaller) and different numbers of btMultiBody will produce different results, namely, the multibodies that shoot upwards into the air differ with different setups. I am curious as to why different timesteps produce different results, because I thought smaller timesteps was needed mainly to avoid tunneling, but I see none of that here (see my videos at the end of the post).

I am using bullet.git dc731280b865317d0df66da64ab292bfbb341c32 (the most recent revision in GitHub at the time of this post) on OS X 10.9. I tried both single and double precision builds of Bullet, but it makes no difference.

With 22 btMultiBody and a timestep of 700 microseconds, none of the btMultiBody instances shoot up into the air, which is good. I'm hoping that with some improvements to Bullet's Featherstone implementation, I won't need such a small timestep, but I'm also hoping that when Bullet 3.0 is released I'll be able to run this realtime on the GPU, even if it means getting a $500 video card.

So is this simply a bug due to the early work in progress Featherstone implementation? Or is this something that I will have to just figure out a way to deal with? Currently it seems my only solution is to use very small timesteps until the simulation is stable.

Here are some videos to demonstrate. In one video, I run the simulation realtime, and in the other video, I run the same simulation one time step at a time so you can see what happens.

http://youtu.be/YKjdF9K3we0

http://youtu.be/m6Q2pahcvNA

P.S. I should also note that I tried the same simulation using the Simbody library. I had no stability problems at all with 22 characters, however the only thing stopping me from using Simbody is I don't see any work towards a simulation that runs 100% on the GPU, which is my only chance of getting this project to work real time.

P.P.S. The mass of each link in the btMultiBody is 1. The size of the btMultiBody is approximately the same as a human.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: btMultiBody instability (character shoots up into the ai

Post by Erwin Coumans »

So is this simply a bug due to the early work in progress Featherstone implementation
Yes, that is a bug and I hope to get some time to sort that out before next release. If you have time/knowledge to track it down, create a small reproduction case or even fix it, please use this issue: https://github.com/bulletphysics/bullet3/issues/290

Thanks!
Erwin
kingchurch
Posts: 28
Joined: Sun May 13, 2012 7:14 am

Re: btMultiBody instability (character shoots up into the ai

Post by kingchurch »

teh_ballerer wrote:
With 22 btMultiBody and a timestep of 700 microseconds, none of the btMultiBody instances shoot up into the air, which is good. I'm hoping that with some improvements to Bullet's Featherstone implementation, I won't need such a small timestep, but I'm also hoping that when Bullet 3.0 is released I'll be able to run this realtime on the GPU, even if it means getting a $500 video card.

P.S. I should also note that I tried the same simulation using the Simbody library. I had no stability problems at all with 22 characters, however the only thing stopping me from using Simbody is I don't see any work towards a simulation that runs 100% on the GPU, which is my only chance of getting this project to work real time.
When you compared the Bullet Featherstone with Simbody, did you run them at the same step size of 700us ? Currently both Simbody and Bullet Featherstone are running on CPU, so there is no difference on that regard. One key difference on the integrator side is that Simbody has a variable step size integrator and an error estimator that will automatically reduce the step size until the error threshold is met. A more meaningful comparison is to force both simulation at the same fixed step size of 700us or whatever (you can do that with Simbody by forcing the minimum step size to be equal to maximum step size or a ridiculously large error threshold to the Stepper/Integrator API) and see the stability.

Did you try the same test with Bullet sequential impulse constraints (Hinge or 6Dof) first ? If all you need is mass ratio of 1:1 between those links it might not be that hard to stabilize a dozen of those mechanisms using just the SI constraints. The limitations of SI joints typically show only when you have big mass ratios or large forces exerted at the joints. And if your goal is to run the simulation on GPU, SI solver is probably your only option at the moment until Erwin or someone port Featherstone to GPU / OpenCL which is non-trivial given the complexity of the recursive algorithm compared to SI.
teh_ballerer
Posts: 9
Joined: Fri Sep 26, 2014 3:31 am

Re: btMultiBody instability (character shoots up into the ai

Post by teh_ballerer »

Erwin Coumans wrote:If you have time/knowledge to track it down, create a small reproduction case or even fix it, please use this issue: https://github.com/bulletphysics/bullet3/issues/290
I have modified the MultiBodyVehicle demo to create my test btMultiBody(s), and posted the gist link on the issue tracker.

You might have to play with the timestep, or number of multi bodies to get the explosion behavior to show itself on your machine. Once you find a setup that explodes, it will explode every time on your machine when you restart the simulation.
kingchurch wrote:When you compared the Bullet Featherstone with Simbody, did you run them at the same step size of 700us ?
I ran Simbody with an 8 millisecond time step, but reading the rest of your post it looks like I didn't properly set a fixed time step (I used SimTK::TimeStepper::stepTo). The 700 microsecond time step came about because I wanted to see how small I needed to make the timestep in Bullet before it would stop exploding. By that point I had already deemed Simbody too slow to work interactively, but I will try it again.
kingchurch wrote:A more meaningful comparison is to force both simulation at the same fixed step size of 700us or whatever (you can do that with Simbody by forcing the minimum step size to be equal to maximum step size or a ridiculously large error threshold to the Stepper/Integrator API) and see the stability.
I will try Simbody again and make sure to change the min/max step size, as well as the error threshold and compare my findings with the Bullet results.
kingchurch wrote:Did you try the same test with Bullet sequential impulse constraints (Hinge or 6Dof) first ?
I did not. I created 2 rigid bodies linked with a btHingeConstraint, then I went all in with the Featherstone method.
kingchurch wrote:If all you need is mass ratio of 1:1 between those links it might not be that hard to stabilize a dozen of those mechanisms using just the SI constraints. The limitations of SI joints typically show only when you have big mass ratios or large forces exerted at the joints.
The masses are 1 because I haven't gotten around to tweaking them yet. My plan is to give each link a realistic mass based on a typical human weight. So the total mass of all the links would be around 80 kg. Also I plain on exerting forces large enough to allow the bodies to perform explosive movements like running, jumping, etc. Not sure if those would count as "large" forces or not.
kingchurch wrote:And if your goal is to run the simulation on GPU, SI solver is probably your only option at the moment until Erwin or someone port Featherstone to GPU / OpenCL which is non-trivial given the complexity of the recursive algorithm compared to SI.
I'm able to run the simulation at interactive rates using an 8 ms timestep, so if the Featherstone implementation can be stabilized enough to run well at that rate, then I might not actually need the GPU acceleration. Also this project is in very early stages and I have just been evaluating the feasibility of simulating it on today's hardware, so I won't be releasing anything anytime soon. I was just afraid that if I had to stick with a microscopic time step to maintain stability, that my only choice would be using the GPU. So for now I guess running Featherstone on the CPU is fine if some stability improvements can be made.

Update: I tested Simbody again using SimTK::Integrator::setFixedStepSize to fix the timestep. With the timestep fixed to 33 ms, the bodies hit the floor nicely. However in Simbody when the bodies are laying on the floor, they don't come to rest as easily as they do in Bullet. They wiggle and squirm on the ground. Eventually one of the bodies exploded into the air similarly as they did in Bullet (and my simulation no longer ran at interactive rates), but this was after it wiggled on the ground for awhile. I then lowered the timestep to 20 ms, and all the bodies hit the floor and I observed no explosions. The bodies can be seen wiggling very very subtly but that's probably because in Simbody they don't go to sleep. So Simbody does appear to be more stable, but the bodies wiggle about on the ground a lot, and if the timestep isn't small enough (e.g. 33 ms) an explosion can still occur.
kingchurch
Posts: 28
Joined: Sun May 13, 2012 7:14 am

Re: btMultiBody instability (character shoots up into the ai

Post by kingchurch »

teh_ballerer wrote:
Update: I tested Simbody again using SimTK::Integrator::setFixedStepSize to fix the timestep. With the timestep fixed to 33 ms, the bodies hit the floor nicely. However in Simbody when the bodies are laying on the floor, they don't come to rest as easily as they do in Bullet. They wiggle and squirm on the ground. Eventually one of the bodies exploded into the air similarly as they did in Bullet (and my simulation no longer ran at interactive rates), but this was after it wiggled on the ground for awhile. I then lowered the timestep to 20 ms, and all the bodies hit the floor and I observed no explosions. The bodies can be seen wiggling very very subtly but that's probably because in Simbody they don't go to sleep. So Simbody does appear to be more stable, but the bodies wiggle about on the ground a lot, and if the timestep isn't small enough (e.g. 33 ms) an explosion can still occur.
Which collision model/algorithm did you use with Simbody ? I only checked the Elastic Foundation model before and it had a lot of problems (slow and tunneling) . I know that Simbody team are working on integrating Rigid Contact with the solver which is needed for games. Not sure of the current status of the rigid contact integration.

Is the instability with Bullet featherstone problem only evident under the stress test in your video ? What if only a single character model is used ? What if only single DOF joint (Hinge) is used ? It will be useful to build the identical model using just SI Hinge/6DOF joints and compare the difference. SI's stability can also be significantly boosted if you reduce the step size to something like 700us.
teh_ballerer
Posts: 9
Joined: Fri Sep 26, 2014 3:31 am

Re: btMultiBody instability (character shoots up into the ai

Post by teh_ballerer »

kingchurch wrote:Which collision model/algorithm did you use with Simbody ?
I'm not sure, I didn't choose anything specific. I just wrote the bare minimum code to get Simbody running. I'm using the GitHub release version 3.41. The only specific thing I chose was to use the RungeKuttaMersonIntegrator.
kingchurch wrote:Is the instability with Bullet featherstone problem only evident under the stress test in your video ?
The video currently contains the only test that I have so far. I can change the number of btMultiBody created and watch them fall. I'm going to work on creating a controller now that will apply torques to make them walk (this might take awhile to get any successful results).
kingchurch wrote:What if only a single character model is used ?
The instability still occurs if only one btMultiBody is in the simulation. Since each btMultiBody falls slightly differently (even though they are all have the same configuration, except for their start positions), adding more btMultiBody makes it easier to find one that explodes, because it will fall in whatever perfect manner causes everthing to go haywire.

If you want to try it for yourself, I have shared a gist on the issue (#290) that Erwin made for this. You can modify the timestep and the number of btMultiBody. You can actually go ahead and modify the btMultiBody being constructed to be whatever you want, and observe what happens on your machine.

https://gist.github.com/donnyward/f2130d62915bd8b896cf
Post Reply