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.

[nikhil-sethi]

I recently stumbled on a similar problem and created a plugin that could read poses from a YAML file. For us, the main application was to directly evaluate the reachability of a toolpath generated using the noether package without converting to a .pcd first.
The yaml files look like this:

poses:
  - position:
      x: 0.3629872500896454
      y: -0.06363007426261902
      z: -0.0005234468844719231
    orientation:
      x: 0.09166051483190088
      y: -0.0017855572788278349
      z: 0.9957755116009193
      w: 0.005127601962168693
  - position:
      x: 0.3251079320907593
      y: -0.0632486343383789
      z: 0.006282307207584381
    orientation:
      x: 0.07515697809440232
      y: -0.002977202008927411
      z: 0.9971538575858108
      w: 0.005171964196712022

The plugin assumes the z axis of the quaternions as the target normal vector.
@marip8 let me know if a PR would be appreciated for such a functionality

[marip8]

I think that would be very useful actually

[nikhil-sethi]

Added #89 and ros-industrial/reach_ros2#45