Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gripper states are reversed in simulation compared to reality #192

Open
jkaniuka opened this issue Jul 13, 2023 · 2 comments
Open

Gripper states are reversed in simulation compared to reality #192

jkaniuka opened this issue Jul 13, 2023 · 2 comments

Comments

@jkaniuka
Copy link
Contributor

I have been using both the real robot (xArm6) and the simulation in Gazebo and noticed there is a problem. In section 5.7(xarm_api/xarm_msgs) it says:

Proper range of the open distance is from 0 to 850. 0 is closed, 850 is fully open. 500 is used as an example. 'ret' value is 0 for success.

When we look at the SRDF (xarm6_gripper_moveit_config/config/xarm6_with_gripper.srdf) file, you can see that distance 0 indicates an open state, and distance 850 indicates a closed state.

  <group_state group="xarm_gripper" name="open">
    <joint name="drive_joint" value="0"/>
  </group_state>
  <group_state group="xarm_gripper" name="close">
    <joint name="drive_joint" value="0.85"/>
  </group_state>

This has two consequences:

  1. Simulation does not de facto imitate reality.
  2. In simulation, there is a problem with gripper control using MoveIt- errors like the one below appear, for example.

Invalid Trajectory: start point deviates from current robot state more than 0.01
joint 'drive_joint': expected: 0, current: 0.85

@jkaniuka
Copy link
Contributor Author

jkaniuka commented Aug 3, 2023

Hi @vimior, the gripper in the Gazebo simulation for xArm6 is still not working properly. Do you plan to solve this issue in the nearest future?

@penglongxiang
Copy link
Contributor

Hi @jkaniuka, sorry about the unpleasant experience. it is true that this command discrepancy exists in the gripper simulation and real hardware. However, the logic was like this since four years ago, if we reverse the direction and change the command unit now, it may influence all other users who had already developed their application based on our repo.

If the consistency between gripper simulation and real hardware control is a must for you. You may modify the code or add your own command mapping logic in the way you discovered. Again, sorry for the inconvenience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants