Does this tool require a mesh to perform a reach analysis or will a point set work?

[Levi-Armstrong]

[marip8]

The reach study nominally works with a point set provided as a point cloud file (.pcd). Some of the plugins accept a mesh file for the reach object to do collision checking, but it's not (or at least shouldn't be) required

[Levi-Armstrong]

Okay, I will give it a try and report back if I have any issues.

[Danilrivero]

Hello, we are in the same situation right now. Instead of using a mesh, I wish to use a predefined set of picking points located at a certain pose and orientation wrt. a robot's frame.

My initial approach was developing a set of picking points externally with another script and pass it through. Any issues related to this approach (and ignoring parameters such as the collision_mesh_filename) @Levi-Armstrong? Did you solve this proposal?

Thanks in advance.

[marip8]

Hello, we are in the same situation right now. Instead of using a mesh, I wish to use a predefined set of picking points located at a certain pose and orientation wrt. a robot's frame.

A mesh is not required to utilize the reach study capability. The TargetPoseGenerator interface is responsible for generating the waypoints for the reach study. Our current implementations of this interface (see here and here) load these waypoints from a point cloud (.pcd) file. For the demos, we happen to generate this .pcd file using mesh sampling per the documentation (see step 3 here), but nothing stops you from generating this .pcd file whatever way you want.

If you can encode these predefined pick points as a point cloud .pcd file, then you can use the TransformedPointCloudTargetPoseGenerator class out of the box to load your points relative to a specific frame in the URDF.

Otherwise, you can implement your own class that implements the TargetPoseGenerator interface. I did this for a workshop at ROSCon that I put on about this repository in 2023 (see exercise 2 here). You can implement your class in c++ or Python (I think the workshop repository shows both).

Any issues related to this approach (and ignoring parameters such as the collision_mesh_filename)

As you noted, you can simply ignore the collision_mesh_filename and collision_mesh_frame without issue if you don't have a collision mesh that you want include dynamically as a part of the reach study.

[Danilrivero]

Thanks for your swift response, I will check your workshop. Can confirm this works fine by externally generating the set of points required through a .pcd file from initial testing.