About "scaling the world" and constraints

[lvezzaro]

Hello, this is my first post here.
I read all the posts I could find related to the issues I'm facing, but I couldn't find a definitive solution.
I'm not a physics expert by any means, so please forgive me if what I say doesn't makes any sense.

Anyway, what I'm trying to do is to model a surgical robot using rigid bodies and constraints. Since the objects I'm trying to model are small, I did as recommended and scaled the world, increasing the gravity accordingly. What I didn't expect is that the constraints became much more "springy" with the increase in gravity.

Attached is a modified version of "ConstraintDemo.cpp" illustrating the issue. By toggling the "#define UNIT_METERS" at the beginning of ConstraintDemo::initPhysics(), you can switch between meters and centimeters. I'm using (somewhat) realistic values for the masses, so it's even more strange to me that when meters are used, the constraints are more stiff, even though the masses for the bodies are very high.

Another issue illustrated by the demo is the change in stiffness of constraints caused by reducing the "length" of the second segment (BOX2_HALF_WIDTH), and how this phenomenon is amplified when the units are in centimeters.

As you can see, I increased the solver 's "m_numIterations" to 200 and set a small time step for the simulation, but the constraints are still not stiff enough. I guess I could increase the iterations and reduce the time step even more, but I don't know if that's really a reasonable solution. I'm also using "6Dof" constraints as those should be stiffer.

I should point out that the kinematic chains I'm going to use in the application I'm working on are simpler and segments are shorters, so these issues may not be a problem for now. Still, I can't predict what kind of robot's I'll need to model later on, so I want to know if this is an inherent issue with the constraint solver (as some forum posts seem to suggest) and if perhaps I should consider a different physics engine, while I still can do that.

Thanks in advance for any help,

Luca

[diamond.geezer]

I have a similar problem with my model which I am about to post a query about.
My understanding is that it is the nature of the bullet 6DOF implementation is that you cannot enforce any absolute constraint limit.
The joint must pass the limit you set, only then it does it detect this error and attempts to push back to correct the situation.
The faster and heavier the moving bodies are and the larger the timestep then the larger the error before it can start to push back.
I suspect this is why you are seeing increased "springiness".

There are some ways I have found that will help this, but it all gets a bit hand-wavy. Fundamentally you cannot say absolutely do not pass X degrees.
I understand that other engines such as ODE that are not impulse driven do not have this issue.

Anyway, the main thing you can do is drop the timestep right down - this stops the bodies getting too far beyond the limit before the response kicks in.
You can also try anticipating the error and give it a smaller freedom of movement to compensate.
There are also some parameters you can set on the constraint that help somewhat.
The most useful is setParam(BT_CONSTRAINT_STOP_ERP, [value from 0 to 1], [axis of movement] )
This sets the error margin which is how far off the limit the joint is allowed to be.
The default is like 0.2 , I found that 0.9 is a lot more useful.

Another one is setParam(BT_CONSTRAINT_STOP_CFM, [value from 0 to 1], [axis of movement] )
This sets the "Constraint force mixing factor when joint is at limit"
I have no idea what that means, but it does make it less springy.
Try values around 0.01 , give or take an order of magnitude

HTH

[lvezzaro]

I'm not sure if I understand correctly, but are you saying joint limits cannot be enfornced in any way?
Indeed it looks like a force is applied to compensate for constraints that are outside the allowed limits, and one may think that increasing the gravity somewhat influences that behavior because of the increased weight. But as my example clearly shows, higher weights (more mass, less gravity) yeld more stiff constraint than in the case with lower masse but higher gravity. So either weights are not taken in account or for some reason light objects do not go well with constraints.
I've already tried playing around with the constraint parameters, but with little luck. I'll try again and see if something change.

EDIT:
I tried, setting BT_CONSTRAINT_STOP_ERP very close to 1 helps a lot, while I can't get a value for BT_CONSTRAINT_STOP_CFM that is better than the default.