Bodies oscilate like crazy when attached with a JointFixed

Game Mechanics
#1

Hi,

I’m simulating basic Lego blocks and I’ve attached a number of simple Bodies, each comprised of a single GeomBox, together with fixed joints. Depending on collisions these joints will have to be broken during the simulation, which is why they are not just a single Body with a bunch of GeomTransforms.

I’ve connected a number in series as an extension from a main chassis (imagine 4+ blocks extending out like an ‘arm’ with only the root block attached to the chassis). My problem is that when the simulation starts, the arm wiggles a little, and then the wiggle accelerates until the arm is throwing itself around like crazy. If I construct the arm with smaller blocks with more balanced connections (i.e. not at the tips but in the centre) the wiggling can be eliminated or at least reduced. The larger constructions, however, are valid and can be held static with real Lego and should, I think, be able to be simulated.

I’m a newbie and I’ve obviously missed some physics setting for the joint or the world or something. It seems like the simulator is trying to make corrections and these corrections are compounding the error. I’ve tried playing with the ErrorReductionParameter, MaxCorrectionVelocity and ContactSurfaceThickness in the world, as well as the ERP and CFM in the Joint (althoughf for a fixed joint these parameters don’t seem to be used) - but to no avail.

I’m using the newest code checked out from CVS.

Does anyone have any suggestions?

Thanks in advance,
James

#2

I don’t really know much about ODEJava or what you’re using, but I can explain some typical scenarios where numerical integration can cause trouble. It is evident that there must be some kind of spring-like force attaching the two bodies at the joint. Two possibilities come to mind (I’m just guessing here):

  1. Undamped oscillation. If there is no friction, things will never improve. Actually, they may randomly get worse because of numerical inaccuracies.

  2. Suppose you use Euler’s method for stepwise numerical integration. If there is a linear damping force, which would normally cause the oscillation to die out exponentially, numerical trouble might cause the damping force to not only reverse the velocity, but also increase the speed! It is of course impossible in the real world, but since you have some fixed timestep, intead of an infinitely small one, this can happen. One solution is to decrease the time step.

I have reason to believe that there might be trouble if

mass(of oscillating body) < frictionConstant * timeStep ,

but it depends a lot on how your program does these things. Try playing with mass and friction. Be sure to tell me if I’ve been too technical.

#3

Thanks. And no, not too technical.

I’ll try playing with those params and see what happens. I’ll post my results.

On another note:
You mentioned using ‘Euler’s method for stepwise numerical integration’. An engineering friend mentioned something about potential problems with using Euler’s method when simulating physics and suggested I use some alternative. I say some alternative because I wasn’t really listening to him at the time, I was too busy trying to get my boxes to draw right.

Now it seems like I should have been taking notes.

Is there some way to change to this alternative method with Ode/OdeJava? What is this other method? Do people think this is the right thing to do?

#4

I don’t know which method OdeJava uses, and I have never used it. That’s why I’m only guessing. You may want to be sure that this is actually the problem before you start doing a lot of stuff.

But if you can, it might be an idea to use a Runge-Kutte method. There are other methods as well.

http://en.wikipedia.org/wiki/Runge-Kutta_method

There is lots of info on wikipedia, look up numerical integration or something similar if you’re interested.

#5

Try to call body.adjustMass() AFTER you’ve added it to the world (not before). It did wonders for my simulation.

#6

I found this too. This is one of those things were Odejava being object orientated doesn’t exactly fit with ODE. You expect that the order of method calls doesn’t matter, since they are just objects, but since ODE under the hood isn’t, it does seem to matter.

Will.

#7

Using the JointFixed is not recommended in the ODE docs, though I understand what you are trying to do.

A work-around is to add the geoms to the Body and don’t use joints, then when you need to detach one, simply remove it from the body and attach it to a new independant body (you shouldn’t even need to re-create it).

Cheers,

Will.