[Hugo]

Are the joint angles in the calibration or only during the simulation?

Hugo

[Hugo]

Hi @weibayang

The TetrehedronFEMForceField has no option for anisotropy.
A volumetric constitutive law including anisotropy is the hyperelastic laws (TetrahedronHyperelasticityFEMForceField). Unfortunately, this does not exist in the core of SOFA. This really becomes a priority for the core of SOFA. I created an issue here.
However, developers of the SoftRobot plugin might have implemented this for their robotic purposes.

Best,

Hugo

[Hugo]

Update of my first paragraph: the simpler case were the object should remain in an equilibrium is the case of one hexahedron with quad faces. Triangles mean tetra, i.e. oriented mesh, i.e. a momentum will be generated.

Hugo

[Hugo]

Hi Elek !

We have a CentOS 7 on the CI running successfully. Strange.
Which compiler do you have?
clang5 or gcc7 minimum are required.

Any other config detail would help.
Best

Hugo

[Hugo]

Hi @weibayang

and welcome to the SOFA forum!
Which constitutive law are you using in SOFA, i.e. which ForceField ?

Best,

Hugo

[Hugo]

Hi @robclark

Welcome on the SOFA forum!
I am really sorry for this issue, that we are aware of.

The QtViewer of SOFA does not support Retina screens. Could you try the other viewer of SOFA: QGLViewer (see in the GUI, the View widget) or run: runSofa -g qglviewer

Please let us know if it helps.

I am sorry for this first disappointing experience!
Best wishes,

Hugo

[Hugo]

Hi @priya-vada4

I already saw this kind of issue.

Some reported this problem due to the glew library. I was installed with homebrew which was not up-to-date (with a dependency on the old OpenGL): brew upgrade glew

Let me know whether this helps.
Best,

Hugo

[Hugo]

Hi @pasquale94

Welcome on the SOFA forum!
Nice start in SOFA, xml towards python is a good way to start.

In the TetrahedronFEMForceField you also have an option computeVonMisesStress which will allow you to compute the vonMisesPerNode or vonMisesPerElement. However, extract the stress and strain separately is not implemented to my best knowledge.

@jnbrunet can you confirm?

Best,

Hugo

[Hugo]

Hi @bobiko

I am no big expert of the Geomagic.

Strange, did the calibration phase run properly? maybe run it again.
Is there nothing enforcing these values in your script, because it looks pretty round {0, -11, -3.5} !

Best wishes,

Hugo

[Hugo]

Hi @benjamin

I don’t have access to the class SlidingActuator itself, but looking at the tripod script here in the SoftRobot plugin, the rotation (Euler angles) are indeed between 0 and 1 (see cos and sin functions used). But normalization should not be an issue.

For the pb of template, without the actual C++ class I can not help really further.

Again without the code of the SlidingActuator, hard to tell but yes I would write the scene with the SlidingConstraint alone.

I am sorry not to be able to help you more. Maybe another round with the Defrost guys would be more efficient.

Best,

Hugo

[Hugo]

Hi @matfit

Yes you are perfectly right with the BilateralInteractionConstraint!
This way the QR and the kidney will influence one another.

Since the BilateralInteractionConstraint implements the constraint on one template and since you kidney is deformable, it has to be Vec3d. But your QR code is actually just a rigid with a visual square mapped on it. So, you might end up with:
– a Vec3 kidney
– a rigid particle (corresponding to the QR code frame) with a Vec3 child node + RigidMapping, and finally a visual node with the square

The example scene is available in examples/Components/constraint/BilateralInteractionConstraint.scn

I hope this will help.
Best,

Hugo

[Hugo]

Hi @matfit

Before providing an answer, which object is driving which other object?
Is the QR code square just passive and following the kidney?
Is it the inverse way around?

Best,

Hugo

[Hugo]

Do not forget to share your achievements every Friday!
Cheers,

Hugo

[Hugo]

Hi @sarah

I answer your two latest posts here.
First, I would go for an even simpler geometry (cube with only two triangles on a face) and a MeshMatrixMass computing the full integration of the mass term.

Instead of a constraint, there is a forcefield applying a constant pressure on your object: SurfacePressureForceField. You can find an example in examples/Components/forcefield/SurfacePressureForceField.scn

Second, to check a VTK, the best could be to use Paraview for visualization of VTK meshes. Otherwise, in SOFA, you can have a look at the normals which are a basic yet useful indicator.

Best wishes,

Hugo

[Hugo]

Hi @simon

It works for me:

Best,

Hugo

[Hugo]

Exactly!

A current work group is thinking about a new design that could prevent from this limitation: “Data update / dependency”

[Hugo]

Hi @simon

Thank you for noticing us the issue with the forum.
When it happens (to anyone of you all), let us know as soon as possible using the contact form.

It is no error but just a warning. It should not be of a concern in your case.

I was able to run the scene, even if the result is strange:

Best

Hugo

[Hugo]

Hi @benjamin

Further to discussion, it seems that the class SlidingActuator that you presented in your first post above is the one you should be using. This component of the SoftRobots plugin allows you to define the “direction” made up of: the position x,y,z and the orientation.

By specifying the proper origin (x,y,z) of your sliding constraint and its orientation with Euler angles, it should be working.

Let me know if this unclear.
Best,

Hugo

[Hugo]

Hi @sarah

The component you are referring to is located in the SoftRobot, correct?
I therefore don’t know its code.

However, as all pressure components, its effect is obviously mesh-dependent. I would have also thought about a mesh issue. What tells you that it isn’t one?
The rotation you notice can come from the asymmetry of your faces thus creating a momentum on your object due to unbalanced forces.
Which mass are you using?

Best,

Hugo

[Hugo]

Hi @jjcasmar

Order of initialization will be following the scene graph through the init visitor (MechanicalVInitVisitor). If the data dependencies (link between DataEgine and MechanicalObject) do not follow the scene graph, you might end up with an empty MechanicalObject.

Do you see my point?

Hugo

[Hugo]

Hey @jjcasmar

Thank you very much for the feedback it will be very useful to other plugin devs for debug infos.

Best,

Hugo

[Hugo]

Hi @louises

Welcome on the SOFA forum!
What you are looking at is an equilibrium state.

In dynamics, you will have such oscillations (usual example given is a pendulum) and a solution to get a steady state is to add numerical (Rayleigh) damping. However, this does not represent the physics and might create deviation between your simulation and your experiment.

Using a static simulation, you will end up with the proper equilibrium state. Take a look at the example: examples/Components/solver/StaticSolver.scn

Cheers,

Hugo

[Hugo]

Hi @jjcasmar

Could you share (a simplified version of) your scene to make sure we are on the same page?

Hugo

[Hugo]

Hey @jjcasmar

I rarely compile SOFA and plugins in debug, so I don’t have much experience. Sorry about this.
However, everything shouldn’t be compiled in debug on Linux to get all debugging information?

Hugo

[Hugo]

Hi @sarah

Great to hear that you got the monitor to work.
However, the VTKExporter should be working fine. It is validated and stable, I just gave it a try myself. Maybe some data were wrongly defined. In case you need it later, do not hesitate to rely on the example scene: examples/Components/misc/VTKExporter.scn

Shall we close the topic?

Best wishes,

Hugo

[Author]

Posts