Follow-up non-realistic mesh collision

[Antoine Laborde]

Dear all,

This is a follow-up to the discussion I opened on the 1st of october called "Contact detection on mesh objects". By setting up the radius parameter of ChCollisionShapeTriangleMesh to a non zero value, some contacts between meshes were detected, but many contacts are not detected and the meshes continue to go through each others. I added a video to show what is happening concretely.

The two gears are controlled by a motor links, controlled by speed, that go in opposite directions so that the gears collide. For information, to get the .stl files, I open an assembly file in FreeCAD, select a part and export it in .stl format.

Here is what I tried:

- Subdivide the mesh to create more triangles. The idea was that by adding more triangles, the chance of detecting a contact would increase. But it changed nothing 

-  Tune the radius, envelope and margin parameters but I didn't find a combination that solves all the problems 

- Saved the mesh object in STL and OBJ formats but none of the two brought better results 

- In the code attached bellow, there is a scaling in load_stl_mesh so that everything is in mm, I tried to remove it, but it did not help 

- Let the second gear rotate freely using a revolut joint instead of a motor link, but it did not help

I am stuck in my learning of pychrono and rigid body collision and any help would be greatly appreciated ! I put the code bellow but unfortunately, I can't send you the .stl files.

PS: I won't be available next week but I wanted to ask for help before being unjoinable 

[Bent Møller]

I posted an issue on the github page for chrono a long time ago (no answers except for my own workaround) and this might be what is giving you problems here. From what I've observed, collisions with even very simple meshes (when not marked as being convex) just doesn't work as it should:

https://github.com/projectchrono/chrono/issues/541

I'm not sure what to do except for creating convex hulls from the input-mesh. It seems that then the collision-checking ends up using a different approach which seems to work.

[Radu Serban]

Bent – sorry for the (very) late reply. I can confirm that there is an issue with collision detection of non-convex trimeshes.  Looking at the results, I suspect a bug in edge-edge collision. But I did not write this part of the code and have never looked at it very closely.  The reason things appear to work fine for the original track-shoe meshes in demo_MBS_collision_trimesh is that these are relatively fine meshes and so collision pairs get generated between many features of these meshes.  When switching to box meshes, any issue in a particular type of pairwise feature interaction will result in obvious errors. By the way, I pushed a modification of that demo that allows switching between the two types of meshes and control other setting s to help identify such problems.  If I get some time, I will chase down this bug; or hopefully someone else gets to it before me.

 

Antoine – having said all that, for your particular problem with gears, I would still try to leverage collision between convex shapes as that is a much more robust algorithm.  Instead of providing the entire gear mesh as one collision shape for a gear body, it would be much better (for robustness, but also computational efficiency) to create a model for the collision shape of a single tooth (that is a convex mesh) and then replicate that as many times as necessary in the collision model associated with the gear body.  Look at the function CreateLuggedGeometry() in demo_VEH_SCMTerrain_WheeledVehicle for an example of generating a (non-convex) collision model by assembling multiple instances of the same (convex) mesh and using convex hull collision shapes for each of these parts.

 

--Radu

--
You received this message because you are subscribed to the Google Groups "ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to projectchron...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/projectchrono/10cc7f1a-18d8-46aa-a421-a844f277d60cn%40googlegroups.com.

[Antoine Laborde]

Thank you both for your answers. I will post here what helped with my problem in case somebody come accross this post.

First, using the python wrapper, I tried to use the function AddTriangleMeshDecompositionV2 that seemes to implement what Bent implemented at the time. Though the function seemes to be executed it changed nothing to the simulation.

I was not satisfied with the way I was programming so I decided to use the C++ original project to be closer to the documentation.

So after installing Project Chrono and Visual Studio, I wrote a simple script to load my gears and make one rotate because of the other and it worked out-of-the-box, no need for a convex decomposition! 

However I then implemented the convex decomposition, like Bent did, and it worked too so this option is ready to use if needed.

So the lesson is to use directly C++ if possible. However the convex decompostion fails for some component but this might be the subject of a new discussion.

Antoine