[SOLVED] Fixed constraints not so fixed with GenericConstraintSolver

[jnbrunet]

Hey everyone!

I have a small scene consisting of a sphere and a tool controlled by an Omni (with the help of the NewOmniDriver from the sensable plugin). The tool is only two smaller spheres attached with a line.

The sphere is fixed with a BoxROI and the force field is TetrahedralCorotationalFEMForceField. I use the GenericConstraintSolver with the FreeMotionAnimationLoop.

Here is what happens when I “hit” a fixed constraint with the haptic tool:
http://imgur.com/h2KTAc9
As you can see, one of the fixed constraint start moving

Here is the scene file:
http://pastebin.com/aa6HzJHa

If you want to replicate the scene, the sphere mesh is the same as sphere_10.obj in the sofa’s shared directory. You just need to change the obj path in the scene file.

Also, I found this older thread that seems to ask the same thing as me, be I do not use the LCPConstrainstSolver (I do use the LCPForceFeedback…).
https://www.sofa-framework.org/community/forum/topic/fixedconstraint-not-fixed/

Could this be caused by the UncoupledConstraintCorrection? I’m not sure how this constraint correction is used and how to calibrate it…

Thanks!

Sofa version : 5f0ac5c (very close the the master branch)
Fedora release 23 (Twenty Three)

[Hugo]

Salut Jean-Nicolas,

I tested your scene locally with an Omni.
My guess is that the problem is due to the FixedConstraint. But no worries, this is normal. While solving the constraints, the velocity of the points is increased (due to collision response). But in the FixedConstraint, ONLY the positions are fixed. When collisions are computed, they impact the velocity, thus creating a drift of the point/object.

If you want also the velocity to be fixed, the short way is to uncomment the code starting at lines 253 in FixedConstraint.inl:
#if 0 /// @todo ADD A FLAG FOR THIS

But a clean way would be to write a class derivating from FixedConstraint, also fixing the velocities.

Another solution is to used RestShapeSpringForceField instead of FixedConstraint, but this does not really respect any realistic physics.

Cheers,

Hugo

[jnbrunet]

Hey Hugo!

That makes perfect sense.

It still have a little “glitch” as you can see here:

http://i.imgur.com/8OA2NHf.gifv

It always seem to be the same fixed point that doesn’t keep his position/velocity

But as you said, maybe a cleaner version with a class derivating from FixedConstraint would be better.

I was more curious than anything, so we can mark this thread as solved 🙂

If anyone want the quick patch:

diff --git a/modules/SofaBoundaryCondition/FixedConstraint.inl b/modules/SofaBoundaryCondition/FixedConstraint.inl
index 63c7e92..98df053 100644
--- a/modules/SofaBoundaryCondition/FixedConstraint.inl
+++ b/modules/SofaBoundaryCondition/FixedConstraint.inl
@@ -248,10 +248,11 @@ void FixedConstraint<DataTypes>::projectJacobianMatrix(const core::MechanicalPar
 // When a new fixed point is added while its velocity vector is already null, projectVelocity is not usefull.
 // But when a new fixed point is added while its velocity vector is not null, it's necessary to fix it to null. If not, the fixed point is going to drift.
 template <class DataTypes>
-void FixedConstraint<DataTypes>::projectVelocity(const core::MechanicalParams* /*mparams*/, DataVecDeriv& /*vData*/)
+void FixedConstraint<DataTypes>::projectVelocity(const core::MechanicalParams* mparams, DataVecDeriv& vData)
 {
-#if 0 /// @todo ADD A FLAG FOR THIS
+#if 1 /// @todo ADD A FLAG FOR THIS
     const SetIndexArray & indices = f_indices.getValue();
+    helper::WriteAccessor<DataVecDeriv> res ( mparams, vData );
     //serr<<"FixedConstraint<DataTypes>::projectVelocity, res.size()="<<res.size()<<sendl;
     if( f_fixAll.getValue()==true )    // fix everyting
     {

Thanks!
Jean-Nicolas

[Hugo]

Hi Jean-Nicolas,

As I already said, this is some kind of a hook. The fact is that the constraint solver seems not to handle projective constraints properly.

I did not succeed to reproduce your error when applying the trick/patch written above.
But I am using a newer version of the Omni driver (not yet released but soon!).

As I said, you can use the RestShapeSpringForceField instead of fixed constraint, but this is no real solution.

Cheers,

Hugo

PS: in the Sensable plugin, a EnslavementForceFeedback is always added for the collision model associated to the Omni.
I dont’ see it in your scene, but I am no expert in collision detection and do not know the role of this component.

[Author]

Posts