Gripper open/close mismatch

[YueErro]

Apart from the #51 issue, there is a mismatch in the values we have to set to open and close the gripper (tested on the gripper 140).

In simulation 0.87 means to close it and 0.0 means to open it, however, on the real robot 0.87 means to open it and 0.0 means to close it.

[rkojcev]

Thanks for reporting @YueErro. @nzlz can you please have a look into this and propose a fix in a PR? Please also check the other grippers.

[nzlz]

The plugin is the same for robot grippers and the target pose is applied here, which its correct. I guess the issue is the URDF.

Also gazebo's lower and upper limits should match, makes no sense to start from -0.8 lower if we cant even reach it.
https://github.com/AcutronicRobotics/robotiq_modular_gripper/blob/09e28e56754030c16b551742a9b53bb39d0a7ec2/robotiq_140_gripper_description/urdf/robotiq_140.urdf#L294-L295

[YueErro]

We will also have to set properly the limits in simulation.
As far as i know, the range of them on the real robot are followings:

• Velocity: 30.0 - 250.0 mm/s
• Effort: 10.0 - 125.0 N
• Angular position: 0.0 - 0.87 rad

@ahcorde correct me if i am wrong, please.

[nzlz]

Few comments about the current state of the plugin:

#1
We use goal_linearposition, which is intended to be used to control the distance between fingers . This is wrong and its mixed everywhere in the plugin. We should use goal_angularposition to control the angle.

#2
Aside from this confusion, in the plugin the angles are:

• Open = 0
• Closed = 0.775

This angle is the maximum physical limit of the outer_knuckle_joints, of which the joint_finger is part of (right).

#3
Taking a look at the real drivers, I can see commented that the angle range is 0 - 0.87. But why 0.87 ? I guess the joints passing the force are left and right _inner_finger_joints. So taking this into account, the call to the gripper plugin should be (tested and working):

    <plugin filename="librobotiq_gripper_gazebo_plugin.so" name="robotiq_140_gripper">
      <joint>left_inner_finger_joint</joint>
      <joint>right_inner_finger_joint</joint>
    </plugin>

Instead of the current:

    <plugin filename="librobotiq_gripper_gazebo_plugin.so" name="robotiq_140_gripper">
      <joint>left_inner_knuckle_joint</joint>
      <joint>left_outer_knuckle_joint</joint>
      <joint>right_inner_knuckle_joint</joint>
      <joint>joint_finger</joint>
    </plugin>

However, even with this changes, the angle limit is the upper physical limit of the left and right outer_knuckle_joints. So my question is, are we sure the URDF limit values are okay? In the real robot, is 0.87 the real 0 position? Or 0.87 would be equivalent to our current plugins -0.095 (0.87-0.775)?

@ahcorde @carlossvg please share your knowledge here.

[ahcorde]

Regarding #1

We are using goal_linearposition because we have another gripper that the finger can rotate and that's why we use goal_angularposition. Maybe it's a bad choice.

#2

Yes, joint_finger is the joint that control the rest of the joints. I'm Okey with the open/close value.

We need to reconsider if we should use percentages. Because not all grippers have the same distance between grippers

#3

Maybe @ibaiape can answer this question better. But we are including more joints to improve the behaviour of the gripper. Some of the joints are mimic of others

[nzlz]

We need to reconsider if we should use percentages. Because not all grippers have the same distance between grippers

Wouldn't it be better to use Open and Close functions? We would need to add a OpenClose service to HRIM if this was the case. Also the Close function would be more complex as simple pose movement and would include a proper gazebo gripping. This could be achieved attaching links to the gripper once contact with the fingers occurs. Check gazebo's gripper abstraction.

If this is not a good option, the percentage usage you mention would be better than the current raw value IMHO. We would still be lacking a proper object gripping.

[rkojcev]

I like the percentage idea a lot, using percentages will help us generalize the messaging system for all grippers.

Open/Close can have it downfalls since sometimes in some applications we do not need full close, it can be an add on still have the option to use Open/Close commands but I would not leave it only to that.

[ibaiape]

We are using goal_linearposition because we have another gripper that the finger can rotate and that's why we use goal_angularposition. Maybe it's a bad choice.

+1, the DH 3 finger gripper kind of broke the way we control the grippers overall, the gripper model should be reviewed. Maybe a hand with rotating fingers shouldn't be the same as a more simple 2 finger gripper...
It was meant as a quick workaround and I never got back to review it, my bad.

How are the grippers controlled normally? I assume you'd usually go with passing it radians, and not what opening you want between fingers, but I'd also see passing an opening useful in more specific cases...

---

We need to reconsider if we should use percentages. Because not all grippers have the same distance between grippers

In my opinion I like the percentage idea a lot, using percentages will help us generalize the messaging system for all grippers.

I am apprehensive of passing the gripper a percentage value. You can easily do this on the user interface knowing min-max values, and I'd rather pass "real" data to components.

I guess we could do it the other way around, keep the max opening data in specs as it is and pass percentages, so you could calculate it later if needed. But you can argue the same for all other values: the speed/effort/acceleration of the gripper closing, or a servo's position. You can know the real values through specs and work with percentages.

I can see the percentage approach working, but I'd say this affects how we make use of this type of thing across HRIM as a whole (open for discussion, of course). I'm not against reviewing this, I'd just like to keep homogeneity on this kind of thing as much as possible. Having the gripper receive percentages while all other components receive "real" data feels quite counter-intuitive.

Maybe being able to do both? Control it by radians and having a percentage service, we could do this across other components.

---

On which are the proper values, we can always rethink how we apply the force across joints. The gripper plugin also provides the functionality of the mimic joints, as it's not supported in gazebo AFAIK, at least not in ROS2. The current gripper plugin is pretty minimal and that should be kept in mind, there's huge room for improvement.

A possible alternative would be to take one of the joints with the "proper" max opening as the "base" and apply a lower multiplier to other joints.

Also, I keep getting the feeling the gripper URDF's (at least the robotiq ones) aren't entirely OK; inertias were an issue that had to be solved for the AI team using them on the full arm if I remember correctly and I'm sure there's more issues.

[ibaiape]

Wouldn't it be better to use Open and Close functions? We would need to add a OpenClose service to HRIM if this was the case.

hrim_actuator_gripper_srvs/srv/GoalGripper.srv is exactly that, it's just not supported by the plugin (not hard to implement TBH)

[nzlz]

In simulation 0.775 means to close it and 0.0 means to open it, however, on the real robot 0.87 means to open it and 0.0 means to close it.

What is your impression here @ibaiape ? Is that statement correct? If it is, should we tweak this in the plugin?

[nzlz]

Regarding the goal_linearposition usage. It is not acceptable that we use messages the way they are not supposed to. Let's discuss everything internally.