Gazebo | Ignition | Community
Ask Your Question

Revision history [back]

... when I remove the collision tag (or add a small box instead) for that joint, it works smoothly.

This sounds a lot like your STL mesh contains excessive geometry, i.e. too many triangles. To make your simulation step faster, you could decrease the complexity of the geometry. You can do that in several different ways; manually remodel the mesh in your favourite 3D graphics software (e.g. Blender) or use algorithm that does this for you automatically (e.g. Blender's Decimate Modifier or something like Open3D's simplify_quadric_decimation() if you want to do it programatically). If your model requires a lot of detail in certain parts (e.g. gripper where correct representation is important), manual remodel might work better for you and you can only simplify the parts that matter less. It can often be desirable to have two different versions for each model - one for visual (detailed, with material) and one for collision (simplistic).

By visual inspection, I couldn't find any source of collision.

I don't have insight into the concrete implementation details, but collision checking is usually optimised in a way where bounding boxes around links are checked first (often axis-aligned bounding boxes). Collision checking with the mesh itself is performed as a fine-tuning step afterwards only if collision with the bounding box was detected. This assures that limited resources are wasted on objects that are far away, while still keeping all the detail up close. This could explain while your simulation suddenly slows down even if there is no visible collision happening yet (it was just being optimised). Please correct me if someone who worked in such area reads this.

... when I remove the collision tag (or add a small box instead) for that joint, it works smoothly.

This sounds a lot like your STL mesh contains excessive geometry, i.e. too many triangles. To make your simulation step faster, you could decrease the complexity of the geometry. You can do that in several different ways; manually remodel the mesh in your favourite 3D graphics software (e.g. Blender) or use algorithm that does this for you automatically (e.g. Blender's Decimate Modifier or something like Open3D's simplify_quadric_decimation() if you want to do it programatically). If your model requires a lot of detail in certain parts (e.g. gripper where correct representation is important), manual remodel might work better for you and you can because it allows you to only simplify the parts of the mesh that matter less. It can often be desirable to have two different versions for each model - one for visual (detailed, with material) and one for collision (simplistic).

By visual inspection, I couldn't find any source of collision.

I don't have insight into the concrete implementation details, but collision checking is usually optimised in a way where bounding boxes around links are checked first (often axis-aligned bounding boxes). Collision checking with the mesh itself is performed as a fine-tuning step afterwards only if collision with the bounding box was is detected. This assures that limited resources are wasted on objects that are far away, while still keeping all the detail up close. This could explain while why your simulation suddenly slows down even if there is no visible collision happening yet (it was just being optimised). Please correct me if someone who worked in such area reads this.