Revision history [back]

Let's say I do a convex decomposition on the mesh of a link and include the convex component in seperate collision instances. Would this increase the performance compared to the case where I put the convex components in a single file and thus a single collision instance?

there is no general answer here except: it depends.

For MoveIt specifically: the convexity of any geometry entity is "lost". Afaik there is no performance gain to be had here. Now that MoveIt starts to look at alternative collision libraries and environments (Bullet fi), I expect this to become more of an issue and consequently will gain more attention.

In the Tesseract project they've forked URDF specifically to add these kinds of concepts and then support them throughout the planning infrastructure.

The reason collision geometry elements exist in URDF is to allow for lower fidelity models to be attached to links.

In the latter case the combined shape is not necessarily convex anymore and thus more computation heavy to check.

As I wrote: afaik there is nothing which can benefit from any convexity here. At least not in MoveIt as of this time.

Let's say I do a convex decomposition on the mesh of a link and include the convex component in seperate collision instances. Would this increase the performance compared to the case where I put the convex components in a single file and thus a single collision instance?

there is no general answer here except: it depends.depends. And it depends heavily on the consumer of your URDF.

For MoveIt specifically: the convexity of any geometry entity is "lost". Afaik there is no performance gain to be had here. Now that MoveIt starts to look at alternative collision libraries and environments (Bullet fi), I expect this to become more of an issue and consequently will gain more attention.

In the Tesseract project they've forked URDF specifically to add these kinds of concepts and then support them throughout the planning infrastructure.

The reason collision geometry elements exist in URDF is to allow for lower fidelity models to be attached to links.

In the latter case the combined shape is not necessarily convex anymore and thus more computation heavy to check.

As I wrote: afaik there is nothing which can benefit from any convexity here. At least not in MoveIt as of this time.

Let's say I do a convex decomposition on the mesh of a link and include the convex component in seperate collision instances. Would this increase the performance compared to the case where I put the convex components in a single file and thus a single collision instance?

there is no general answer here except: it depends. And it depends heavily on the consumer of your URDF.

For MoveIt specifically: the convexity of any geometry entity is "lost". Afaik there is no performance gain to be had here. Now that MoveIt starts to look at alternative collision libraries and environments (Bullet fi), I expect this to become more of an issue and consequently will gain more attention.

In the Tesseract project they've forked URDF specifically to add these kinds of concepts and then support them throughout the planning infrastructure.

The reason collision geometry elements exist in URDF is to allow for lower fidelity models to be attached to links.links. Using lower fidelity versions of meshes (ie: convex hulls) for collision detection does result in performance improvements. But mostly because there will just be less vertices/faces to check.

In the latter case the combined shape is not necessarily convex anymore and thus more computation heavy to check.

As I wrote: afaik there is nothing which can benefit from any convexity here. At least not in MoveIt as of this time.