@AndrejOrsula your feedback and thoughts on features you would like as part of the Gripper interface are much appreciated. Right now it is a basic action client, this works well for many basic applications IMO.

Codecov Report

Patch and project coverage have no change.

Comparison is base (89be9a5) 50.50% compared to head (d685866) 50.50%.

@@            Coverage Diff             @@
##             main    #2157      +/-   ##
==========================================
- Coverage   50.50%   50.50%   -0.00%     
==========================================
  Files         387      387              
  Lines       31816    31816              
==========================================
- Hits        16065    16064       -1     
- Misses      15751    15752       +1     

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

Hello @peterdavidfagan,

Thank you very much for looking into it!

Yes, I think having a simple-to-use interface for grippers would be quite beneficial. Besides sending commands, it would be great if the same interface also enabled users to query the current state of the gripper. Here are some primary categories that could be discussed (some of these might be beyond the scope of a gripper interface):

• Support grippers with GripperCommand and FollowJointTrajectory (JointTrajectoryController) interfaces. From what I have seen, many simulated grippers and multi-finger grippers (hands) implement only the FollowJointTrajectory interface or something similar (but not GripperCommand).
• When sending goals via action requests, support getting feedback and result in a synchronous or asynchronous way.
• Simplistic open() / close() commands with optional position and max_effort arguments.
  • If a gripper with FollowJointTrajectory interface supports controlling each finger separately, it might be nice to have an interface for that too (e.g. set_target_configuration()).
• Simplistic is_open / is_closed getters (properties), with the option of also directly getting the JointState of all joints.
  • If a gripper has some additional sensors (e.g. force/tactile), it might be nice to have a way of passing the output of these through the interface.
• Option to automatically parse joint names, link names (and other necessities) directly from SRDF/URDF based on the MoveGroup of the gripper.

Looking at the current action client in this PR, I am not so sure about the use of a new subprocess for each gripper action. It is probably good enough for most use cases, but I feel like the overhead might be too much for some applications (it could become a bottleneck in some robot learning scenarios). Handling of feedback/results could also become cumbersome. Just my personal opinion, as I have not tested it. What do you think?

I tried two separate interfaces in my previous attempt, but both have some limitations: MoveIt2Gripper (FollowJointTrajectory interface | example) and GripperCommand (GripperCommand interface | example). I used the first one for a simulated gripper inside Gazebo, and the second one to control a real gripper. Both of these use rclpy as the interface for all communication. Do you think there are better alternatives to using rclpy based on your experience with moveit_py (e.g. binding directly to the MoveIt 2 codebase, which could eventually provide some of the functionalities for free)?

Thanks @henningkayser for the quick feedback on this.

However, the same action should be supported by MoveIt's gripper controller handle which is supposed to also handle the runtime state of the action call. Would it be too much to ask to bind to the controller interface?

I can look to scope this development item this weekend. It makes sense to align the Python library with the existing C++ codebase where possible so I'll look into what is required to bind these.

And if yes, how can it be improved to streamline usage through the Python bindings?

I'll need to take a look at the existing code to answer this properly. Happy to start looking into it this weekend.

Thanks @AndrejOrsula for the detailed response and valuable points.

Besides sending commands, it would be great if the same interface also enabled users to query the current state of the gripper.

Makes sense.

Support grippers with GripperCommand and FollowJointTrajectory (JointTrajectoryController) interfaces. From what I have seen, many simulated grippers and multi-finger grippers (hands) implement only the FollowJointTrajectory interface or something similar (but not GripperCommand).

For this point, my current thought process was that the FollowJointTrajectory interface is exposed through planning groups with the necessary ros2 controls configuration. For instance with the existing library one could define a planning group for the entire manipulator or the hand alone. Do you see this as too cumbersome and am I missing something?

When sending goals via action requests, support getting feedback and result in a synchronous or asynchronous way.

Thanks for this I agree, this should be supported.

Simplistic open() / close() commands with optional position and max_effort arguments.
If a gripper with FollowJointTrajectory interface supports controlling each finger separately, it might be nice to have an interface for that too (e.g. set_target_configuration()).
Simplistic is_open / is_closed getters (properties), with the option of also directly getting the JointState of all joints.
If a gripper has some additional sensors (e.g. force/tactile), it might be nice to have a way of passing the output of these through the interface.

I planned to make the open/close gripper methods, members of the GripperClient class for convenience. It would be nice to have the other methods you listed as well.

I tried two separate interfaces in my previous attempt

Thanks for sharing these.

Do you think there are better alternatives to using rclpy based on your experience with moveit_py (e.g. binding directly to the MoveIt 2 codebase, which could eventually provide some of the functionalities for free)?

In this case of the new Python library, I believe there are performance benefits to leveraging the C++ library directly.

Support grippers with GripperCommand and FollowJointTrajectory (JointTrajectoryController) interfaces. From what I have seen, many simulated grippers and multi-finger grippers (hands) implement only the FollowJointTrajectory interface or something similar (but not GripperCommand).

For this point, my current thought process was that the FollowJointTrajectory interface is exposed through planning groups with the necessary ros2 controls configuration. For instance with the existing library one could define a planning group for the entire manipulator or the hand alone. Do you see this as too cumbersome and am I missing something?

That makes sense @peterdavidfagan, and it is certainly usable that way. Both open() and close() commands could be just motions to named targets. But I wonder if it might be beneficial to have such a gripper-specific wrapper around FollowJointTrajectory (while being compatible with the GripperCommand interface). 🤔

I'm skeptical about the decision to use subprocess to call out to the ROS 2 CLI when you could just write a Python node that creates an action client and abstracts it away, e.g. this. Is there a specific reason you decided to go this route?

Is there a specific reason you decided to go this route?

Hi @sea-bass,

This was an quick but unclean solution for interfacing with available action for the GripperCommand, it was working fine for my use case so I didn't go much further (Note: under the hood it uses rclpy to create a node to interface with the available action). I did start by implementing an action client in Python but was encountering issues when running it from within a notebook.

This approach is far from perfect, I wanted to open the discussion around this and then consider adding it to my task list to develop the gripper interface for the Python library.

I agree with @sea-bass using the CLI here does not make sense. Why would the user not just make an action client? Its only a few lines of code and then they have lots more flexibility to support the features like @AndrejOrsula requested.

If you want to make a GripperActionClient class that helps speed up integration/standardize how users interact with the GripperActionController then I think ros2_controllers/gripper_controllers would be a better home for this code.

If you want to make a GripperActionClient class that helps speed up integration/standardize how users interact with the GripperActionController then I think ros2_controllers/gripper_controllers would be a better home for this code.

Thanks @MarqRazz, and this makes sense.

If I do write such a class in ros2_controllers/gripper_controllers, for the Python bindings do you think it makes sense to start writing a separate Python binding library for ROS 2 control? I think it may be useful for replicating some of the functionalities of libraries like https://facebookresearch.github.io/fairo/polymetis/overview.html as it is closer to the control stack.

Yes I think Python bindings to the hardware_interface would be super useful! We have had a few customers ask how they can integrate their robot interface written in Python to ros2_control.

If you are considering adding these features I would highly recommend attending one of the ros2_control maintainer meetings and running it past them before you get started.

Thanks @MarqRazz, I'll look to follow up with this approach once I have finished the work I am doing on grasp pose estimation.

We already have a gripper action with this controller plugin coming from here. If it's really about the same action interface, we should not duplicate functionality, but rather think about making it easier to access it. (I know that MoveIt's controller interfaces are not ideal, but this would be a good opportunity to think about how to improve them)

This PR is stale because it has been open for 45 days with no activity. Please tag a maintainer for help on completing this PR, or close it if you think it has become obsolete.

This PR is stale because it has been open for 45 days with no activity. Please tag a maintainer for help on completing this PR, or close it if you think it has become obsolete.

This PR is stale because it has been open for 45 days with no activity. Please tag a maintainer for help on completing this PR, or close it if you think it has become obsolete.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 50.50%. Comparing base (89be9a5) to head (d685866).
Report is 440 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2157      +/-   ##
==========================================
- Coverage   50.50%   50.50%   -0.00%     
==========================================
  Files         387      387              
  Lines       31816    31816              
==========================================
- Hits        16065    16064       -1     
- Misses      15751    15752       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

This PR is stale because it has been open for 45 days with no activity. Please tag a maintainer for help on completing this PR, or close it if you think it has become obsolete.

This PR is stale because it has been open for 45 days with no activity. Please tag a maintainer for help on completing this PR, or close it if you think it has become obsolete.