Add attribute to indicate if a mesh is a convex hull?

Would the maintainer be open to adding an an attribute to the mesh tag indicating if the mesh is a convex hull? The default would be false.

<mesh filename="" convex="true" />

The use-case here is to utilize this information in planners / collision checkers that can enable certain optimizations when the meshes they are passed are convex. One example would be FCL, which has optimized implementations for convex-convex algorithms. (Comment on GitHub by gavanderhoorn)

1 Like

Not a URDF maintainer here, just interested by-stander.

Wouldn’t the elegant approach be to extend any collision checker that supports such optimized checks with a checking function that evaluates whether a given mesh is convex? Like that, the checker could decide whether or not to run the algorithms optimized for convex meshes upon loading of the meshes.

That would be expensive to check. It only has to be done while loading the URDF of course, so that might not be a huge problem.

However, isn’t the issue tracker a better place discuss this? This thread here has to risk of splitting the discussion between there and here.

I think enhancements might get better discussion on this discourse category, so I’ve been recommending people post here. If not here, then I’m not sure which issue tracker would be best. There are several with code that might need to be updated.

Fair enough. Added a link in your issue pointing here.

You could perform this check but you may have issues depending on how the data is saved. If the data is saved with floating point precision and you check it with double precision you could get a false positives. Also I don’t think in the case of collision checking you what the software to make this decision. I think it is better if it is explicitly defined by the user.

Thanks for the detailed response. I was not aware of issues caused by the encoding of the meshes. Interesting.

Regarding your original request, I personally think that this is an application-specific detail and would model it through ROS parameters. This strikes me as the “most KISS” approach.

However, you only add information that relates to the robot model. So, a case can also be made that the URDF is the most specific (and hence suitable) place to put.

I’d like to point out that then you can get into issues of keeping the information consistent: There can be concave meshes that are marked as convex --what does the software do? But maybe that is a case of ‘garbage in, garbage out’.

In conclusion, I wouldn’t do it, but I see where you are coming from. :wink:

It might be good to keep non-ROS consumers of URDF in mind as well. Ideally they would have access to this ‘meta’ information too. Encoding it as an attribute makes that straightforward. ROS parameters do not.

It would also avoid fragmenting the necessary information to successfully parse a URDF. Fragmentation like that is common in other areas of ROS already (MoveIt fi: joint limits from urdf, but also from config yaml, can be overridden with parameters and there’s some dynamic reconfigure parts as well).

Note that other formats already support explicitly marking meshes as convex, or that capsules should be used for collision detection/physics, and they use similar approaches (attributes or a different tag/element/entity).

Thanks for the detailed answer! I was not aware that other formats already support such a tag. Good to know.

I would prefer to encode the collision information in the urdf even if it is a new tag. Given that it provides a section for collision geometry I would assume it would be good to support a variety of collision geometry types. A detailed mesh is usually not the ideal geometry for a collision geometry. It would be nice to expand this to not only support convex hull type but Multi-Sphere, Octomap, Point Cloud, Signed Distance Field, etc which are more suitable for collision checking. I am hoping for an answer soon as I have a deadline. If this is not something of interest to be added to this repository I will need to proceed with creating my own variant to be released with a new motion planning package.

This seems reasonable as long as the default behavior (when the tag isn’t available) remains the same as it is today. This seems like it would be true, but has anyone verified this to be the case?

I propose adding a few more tags.

  • convex_hull - This would accept mesh formats along with pcd

  • mulit_sphere - This would except pcd that incodes the radius at each point

  • octomap

  • sdf

1 Like