How to properly implement self-collision detection for soft robots - model preparation, collision groups and debugging

[whaleson03]

Question about Self-Collision Implementation

I'm implementing a soft robot (TDCR) with cable actuation and need guidance on properly setting up self-collision detection. I've followed the trunk tutorial example but have questions about model preparation and best practices.

Current Implementation

I've implemented collision detection similar to the trunk example by splitting my model into parts:

def addCollisionModel(self, selfCollision=False):
    tdcrColli = self.node.addChild('CollisionModel')
    for i in range(2):
        part = tdcrColli.addChild('Part'+str(i+1))
        part.addObject('MeshSTLLoader', name='loader', filename=path+'trunk_colli'+str(i+1)+'.stl')
        part.addObject('MeshTopology', src='@loader')
        part.addObject('MechanicalObject')

        if selfCollision:
            part.addObject('TriangleCollisionModel', group=i, contactStiffness=1000)
            part.addObject('LineCollisionModel', group=i, contactStiffness=1000)
            part.addObject('PointCollisionModel', group=i, contactStiffness=1000)
        else:
            part.addObject('TriangleCollisionModel', group=1)
            part.addObject('LineCollisionModel', group=1)
            part.addObject('PointCollisionModel', group=1)

        part.addObject('BarycentricMapping')

And collision pipeline in the scene:

simulation.addObject('CollisionPipeline')
simulation.addObject('BruteForceBroadPhase')
simulation.addObject('BVHNarrowPhase')
simulation.addObject('CollisionResponse', response='PenalityContactForceField')
simulation.addObject('LocalMinDistance', alarmDistance=2, contactDistance=1)

Questions

Model Preparation & Construction:

1. How to properly create collision meshes: What's the recommended workflow for creating trunk_colli1.stl and trunk_colli2.stl from the original model? Should they:

   • Be simplified versions of the original mesh?
   • Have specific mesh density requirements?
   • Maintain exact geometric correspondence with the FEM mesh?

2. Model Splitting Strategy: How should I decide where to split the model? Should the split be:

   • Based on expected deformation zones?
   • Evenly distributed along the robot length?
   • Based on cable routing/actuation segments?

3. Mesh Quality Requirements: Are there specific requirements for collision meshes:

   • Minimum/maximum triangle count?
   • Mesh watertightness?
   • Normal orientation consistency?

Implementation & Configuration:
4. Model Splitting Necessity: Is it mandatory to split the collision model into multiple parts for self-collision to work? Can self-collision work with a single collision mesh?

5. Collision Groups: What's the correct way to assign collision groups for self-collision? Should different parts have different group numbers (as I'm doing with group=i) or is there a better approach?

6. BarycentricMapping: How does the mapping work when collision meshes are different from the FEM mesh? Any special considerations for accuracy?

Debugging & Feedback:
7. Collision Detection Feedback: How can I get output or debug information when self-collision occurs? Is there a way to:

• Print collision events to console
• Visualize contact points
• Access collision data programmatically

8. Performance: For a deformable robot with 6 cables, what collision detection settings would you recommend for good performance vs accuracy balance?

Context

• SOFA version: v23.06
• Soft robot with FEM-based deformation using .vtk mesh
• 6-cable actuation system with alternating long/short cables
• Inverse kinematics control
• Robot length: 265mm with complex internal cable routing

Any guidance on the complete workflow from model preparation to collision implementation would be greatly appreciated!

[bakpaul]

Hello !

First of all, thank you for using SOFA. I hope I will be able to help you.

Before going through your question, know that even if it i quite old now, SOFA is still moving a lot between releases. Stability issues are getting solved, new features added and so on. So i can only suggest to upgrade your version that is now 4 releases old.

Now let's dive into your questions:

1. This question is tricky because it will depends on many parameters. Because SOFA provide mapping mechanism, the collision topology doesn't need to be linked to the underlying deformable one except from the fact that it is better if they are close to the volume of the mechnanical mesh. If your collision model is out of this volume, you might get strange overlapping where bending appends. Then for the density, it is a tradeoff between precision and efficiency. The more element you have, the slower the collision detection. And having a collision model that is finer than the volumetric model will not add precision to the collision pipeline. Then there is the question of the colliding element type. Again, this is a tradeoff between efficiency and precision, having only point collision elements will be fast but if your mesh is too coarse then you'll get a lot of interpenetration. Only using Triangle will provide better precision but will take longer to compute.
2. First of all, model splitting is not necessary to have self-collision. You can use a data on the collision model to enable self-collision, but for very large collision model, this is not optimized given that you might know that some parts will never deform enough so no self collision will arise there and so, model splitting is a good way to optimize this. So the general message is, divide your collision model into aprt that will define surfaces that will never deform enough to have a self collision.
3. For this I would only advice to have well oriented normals. The watertightness is not important here, even when using a inflatable chamber.
4. Refer to 2. But the essence is, no it is not mandatory but it will be way slower to use the generic way.
5. Groups are exclusion groups. So two collision models with the same group number will not be considered for collision. This is again another way to optimize collision detection to avoid making unnecessary projection between two models that we know will never collide. But normally, for collision models that are based on the same topology (for instance when in the same node you add PointCollisionModel, LineCollisionModel, TriangleCollisionModel and so on), this is not necessary because those models will not be considered for collision between them.
6. Barycentric mapping are just linear function that will transfer forces that arise on the collision model to the mechanical model. It is very simple. Meaning that forces will only be applied to the terahedron of the mechanical model where the points of the element on which the contact arise are located. For instance, if you have very large edges for the collision that are longer than the size of the triangles of your mechanical model, then the tetrahedron between the two point of the edge will not be directly constrained by the contact but only through the internal deformation.
7. To visualize the collision information in the view in 3D, you can activate a visual flag called "ShowDetectionOutputs" in the dedicated panel. But I am not certain that this already existed in the v23.06. To access those data, scripts have been provided to do it easily. Again, this is up to date with current version, you might get trouble using it with an old version of SOFA: https://github.com/sofa-framework/SofaPython3/blob/master/examples/access_contact_forces.py
8. This is difficult to answer. The recommended strategy is to first make sure you have a working simulation, with a small timestep, big meshes, even if it is super slow and then try to optimize it by playing with parameters, using mutlithreaded version of some components. But I suggest to discuss this when you'll have something that fits your need first.

Hope that helps !

[github-actions[bot]]

⚠️ ⚠️ ⚠️
@whaleson03
Feedback has been given to you by the project reviewers, however we have not received a response from you. Without further news in the coming weeks, this discussion will be automatically closed in order to keep this forum clean and fresh 🌱 Thank you for your understanding

[github-actions[bot]]

⚠️ ⚠️ ⚠️
@whaleson03
In accordance with our forum management policy, the last reply is more than 4 months old and is therefore closed. Our objective is to keep the forum up to date and offer the best support experience.

Please feel free to reopen it if the topic is still active by providing us with an update. Please feel free to open a new thread at any time - we'll be happy to help where and when we can.