- This topic has 12 replies, 3 voices, and was last updated 4 years, 8 months ago by
.
-
Posts
-
Hello! I’m trying to build a simple system with a soft inflating object. I’ve built up a cube with a cavity and have then applied the following for the actuation:
cavity.createObject('SurfacePressureConstraint', name='SurfacePressureConstraint', template='Vec3d', value='0.0001', triangles='@topo.triangles', valueType='pressure')The issue is that when I don’t have the object fixed at any point the forces on the surface doesn’t reveal to be symmetric, while my object’s geometry is symmetric. Instead it rotates upon inflation (I was considering the system without gravity to see how solely the forces acted on the object). I initially thought it was an issue related to the mesh I may have used as well as the surface normals of that mesh. But have found that it is not related to the mesh. And then when I was experimenting with the example in the Soft Robotics plugin of the pneumaticGripper I found similar behaviour. When removing the static constraint(BoxROI) and setting gravity to 0 0 0 in step6 it also began to rotate when inflated.
I’m confused about this rotation. I’m guessing its related to the Surface Pressure Constraint as there are no other external forces. Furthermore, how do I get rid of it? In the end I want to let my object inflate and move on a surface so I cannot incorporate a static box. Would highly appreciate advice! Thank you!
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
Hi Hugo,
I’m using a UniformMass. I checked that face normals are all pointing outwards and then tried the scene with a really basic symmetric mesh (8 triangles on every face of the cube) which I made in gmsh and found the same issue.
Then I opened the turtorial in the SoftRobotics Component for the Pneumatic Gripper in order to check if the system in the turtorial would face the same issue and it did.
And because I was having the issue for my meshes even when I built them up symmetrically and then found the meshed in the turtorial yield similar behavior I got to think it may be more then a mesh issue.Maybe there is an alternative method to build up the pneumatic actuator? Or is there a way in which I can figure out what the issue is?
Here are my files. With a little bit more fine mesh then the one previously discuused.A well as that I placed the cube on a surface.
https://github.com/ALFsarah/SOFA-cube-pneumatic-actuatorThank you for your support.
Hi!
I relooked at it, and am thinking it may indeed be an issue with the VTK, file.. Do you you have any recommendations for ensuring that one is right. As this changes the situation upon rotation whilst when rotating the stl of the cavity it behaves in the same way as before. I made it in gmsh are there specific things to watch out for besides the coarseness and the normals of the mesh. Thanks for your help and support! Hope you are doing well in the midst of these strange times.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
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
Hi Hugo thanks for the update. It can be quite challenging to make hexahedron meshes in gmsh for more complex geometries (such as one with a cavity). Would MeshLab be a useful alternative as I don’t have CGAL plugin?
Are you saying I cannot use trianglar mesh in this simulation, because the tetras are angles out and thus generate a momentum… I’m guessing that could mean one built up out of squares which are each split into two tetras would work better. Thanks a lot for your help! Hope I can get this figured out soon!
Hi @sarah,
Such behavior can come from multiple factors. To me, this clearly look like you are trying to solve an underdetermined system. By looking rapidly at your scene file, here’s what I would try, in order:
1. For the surface mesh on which you are applying pressure, try to use a subset of the trianglular faces from your tetrahedron mesh. This will remove the need for a barycentric mapping. Applying pressure on triangles that do not match their underlying tetrahedron’s faces can create regions of surface that have more, or less, of applied load than other surface regions. This will result in an non-uniform applied load, and therefore unbalanced system of you are not using boundary conditions.
2. Linear tetrahedrons, especially when used with a high value of Poisson ratio, can result in shear and pressure locking. If you can, use a hexahedral mesh which are tri-linear and suffer less from this phenomenon. If you can’t, than try to lower your Poisson ratio.
3. The corotational methods of Sofa are rough approximations of a real rotation extraction method. This can result in a badly conditioned matrix. Try to use a real geometric non-linear material such as those provided by the
TetrahedronHyperelasticityFEMForceFieldcomponent.If your cube is rotating while applying pressure on the complete surface, I would really try my #1 suggestion first, as to me it is a strong sign of unbalanced applied load.
Jean-Nicolas
Hi @jnbrunet,
Thank you for your suggestions!
Have been extracting the propper nodes in order to directly apply the surface pressure to the volume mesh. THis is a promising idea. However, I fell upon a different error… Mainly that SOFA says that [SparseLDLSolver] invalid linear system to solve. Please ensure there are enough constraints (not rank deficient). This got me thinking that because I chose those direct nodes I may causing the data issues as these are both the points where the force is being applied to and calculated for.. Does that make sense?
I will explore the scene some more, but thought if I keep you all updated some more ideas may pop up!Many Thanks!Hello again,
Found that this last problem with the rank deficiency was caused because I had also turned the subset of nodes into a Mechanical Object. Which is not necessary. Will run now that I removed that. But still shows rotation.. Am now trying option 3 in combination with 1 as lowering the posson ratio didn’t seem to reveal much change to the issue of rotation the code I have for the various parts is as follows now.
here’s the cavity:cavity = cube.createChild('cavity') cavity.createObject('MeshSubsetEngine', name='engine', inputPosition='@loader.position', inputTriangles='@loader.triangles', inputQuads='@loader.quads', indices=listNodes) cavity.createObject('Mesh', src='@engine', name='topo') cavity.createObject('SurfacePressureConstraint', name='SurfacePressureConstraint', template='Vec3d', value='0.0', triangles='@topo.triangles', valueType='volumeGrowth', flipNormal=True)Thanks! some tips on the
TetrahedronHyperelasticityFEMForceFieldwould also be appreciated but for now am going through the example scenes and the forum. 🙂Hi @sarah
My guess would be that inflating a cube is a hard problem due to the sharp edges of the cube. To help it, you would probably need to “bevel” these edges so that you get a gradient of pressure normal between two of the cube’s faces.
Meanwhile, you can swap the LDLSolver to a CG solver that will be able to approximately solve your system, even if it is not well formed.
I’ve adapt and simplified your scene so that you can experiment things:
If you turn on the
printLogof theStaticSolver, you will see that your system never fully converge at each time step, but still eventually converge to a stable inflated state.You could try with a sphere instead of a cube, you might have better convergence and might be able to swap back that LDLSolver.
Jean-Nicolas
Thank you Jean-Nicolas,
Also thank you for the addition you made to the scenegraph. Wasn’t getting them all to run in Sofa yet. But I’ll figure. I’m pretty sure it’s a mesh issue, as it seems to be more generic than just my cube. And using a simple flat mesh under gravity I found some similar issues. A sphere indeed may do well to, but would think it easier to mesh a cube in a symmetric way. I will do a more finer study of the meshes I’m using and with that further explore this issue. Thanks for your support. Have a good Easter weekend.Sarah
- You must be logged in to reply to this topic.
