The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
[..] but I don't know what to do to make ROS/MoveIt! "aware" of the gripper, such that the gripper (and any objects in it) do not collide with anything [..]
For the case you describe (ie: gripper attached and not changing at runtime) I would expect just updating your urdf would be the easiest. After updating the MoveIt configuration package, the links of the gripper would automatically be considered in collision checking and planning.
If the base model of your UR5 has been created with care, you can probably create a wrapper xacro, in which you only instantiate your arm, the gripper and add a joint (most likely fixed) that connects them together. The MoveIt package would then be created using the result of your wrapper xacro (so manipulator & attached gripper). See industrial_training/../sia20d_workspace.xacro in the ROS-Industrial training exercises for an example, where an SIA20D is instantiated, then a vacuum gripper and finally they are connected using some intermediate links and joints.
Such as how to define a model of the gripper [..]
You could do this similar to how you model(led) the rest of your robot / system / scene: either by using the geometric primitives supported in urdf, using a mix of meshes & hand-crafted urdf or by exporting a CAD model from something like SolidWorks. In my experience, performance is best if you make sure your collision models are low in detail (but still accurately model the outer dimensions of your gripper).
[..] how to set the state (open/closed position) of the gripper, [..]
For actual control I've seen two approaches being taken most of the time:
Approach 1 is the least involved and the least integrated. MoveIt will do all motion planning for you, but will not be able to control your EEF through it. For a simple open/close gripper and the UR5 you mention, this might be as simple as wrapping the set_io service of the ur_driver node with some suitable grip_open, grip_close services and calling them at the appropriate times. If grasping requires coordinated motion between manipulator and EEF though, things may get complicated, as motion and IO may be difficult to synchronise right now.
Approach 2 is harder to implement: MoveIt needs JointStates and controller interfaces to be able to do this. End-effector declaration in MoveIt config pkgs can also be confusing. Advantage is that all planning (motion and gripper) can now be done in MoveIt and you could make use of the pick-and-place pipeline that is part of it. I don't have too much experience with that, but see the Pick and Place using Python and How to use the Grasp message? posts to moveit-users for some info, and moveit_commander/demos/pick.py for the very high level code that can be written if you manage to plug into that pipeline.
Getting approach 2 to work does also have the benefit of getting visualisation of your gripper state 'for free': you already have JointStates and a urdf. RViz should then have no difficulty visualising it. Of course, for a simple open-loop open/close gripper you'll have to do some trickery (as you may not have actual state to publish). You may also want to do this if you decide to go with approach 1, just for the sake of visualisation (which I think can be very valuable).
[..] but I couldn't find a document explaining all these steps. If no such document is available, maybe an overview of the necessary steps with links to the appropriate documents/tutorials would also be helpful.
Afaik you're unfortunately right: no single source for this information exists. The moveit-users mailing list is a good place to start, and the various PR2 (grasping) related MoveIt packages may also be intersting. The pick-and-place pipeline is probably the least documented, although admittedly I haven't spent too much time trying to find information. I'm guessing most users only use MoveIt for its motion planning capabilities, and don't integrate EEF control with it.
| | 2 | No.2 Revision |
[..] but I don't know what to do to make ROS/MoveIt! "aware" of the gripper, such that the gripper (and any objects in it) do not collide with anything [..]
For the case you describe (ie: gripper attached and not changing at runtime) I would expect just updating your urdf would be the easiest. After updating the MoveIt configuration package, package (or creating a new one), the links of the gripper would automatically be considered in collision checking and planning.
If the base model of your UR5 has been created with care, you can probably create a wrapper xacro, in which you only instantiate your arm, the gripper and add a joint (most likely fixed) that connects them together. The MoveIt package would then be created using the result of your wrapper xacro (so manipulator & attached gripper). See industrial_training/../sia20d_workspace.xacro in the ROS-Industrial training exercises for an example, where an SIA20D is instantiated, then a vacuum gripper and finally they are connected using some intermediate links and joints.
Such as how to define a model of the gripper [..]
You could do this similar to how you model(led) the rest of your robot / system / scene: either by using the geometric primitives supported in urdf, using a mix of meshes & hand-crafted urdf or by exporting a CAD model from something like SolidWorks. In my experience, performance is best if you make sure your collision models are low in detail (but still accurately model the outer dimensions of your gripper).
[..] how to set the state (open/closed position) of the gripper, [..]
For actual control I've seen two approaches being taken most of the time:
Approach 1 is the least involved and the least integrated. MoveIt will do all motion planning for you, but will not be able to control your EEF through it. For a simple open/close gripper and the UR5 you mention, this approach 1 might be as simple as wrapping the set_io service of the ur_driver node with some suitable grip_open, grip_close services and calling them at the appropriate times. If grasping requires coordinated motion between manipulator and EEF though, things may get complicated, as motion and IO may be difficult to synchronise right now.
Approach 2 is harder to implement: MoveIt needs JointStates and controller interfaces to be able to do this. End-effector declaration in MoveIt config pkgs can also be confusing. Advantage is that all planning (motion and gripper) can now be done in MoveIt and you could make use of the pick-and-place pipeline that is part of it. I don't have too much experience with that, but see the Pick and Place using Python and How to use the Grasp message? posts to moveit-users for some info, and moveit_commander/demos/pick.py for the very high level code that can be written if you manage to plug into that pipeline.
Getting approach 2 to work does also have the benefit of getting visualisation of your gripper state 'for free': you already have JointStates and a urdf. RViz should then have no difficulty visualising it. Of course, for a simple open-loop open/close gripper you'll have to do some trickery (as you may not have actual state to publish). You may also want to do this if you decide to go with approach 1, just for the sake of visualisation (which I think can be very valuable).
[..] but I couldn't find a document explaining all these steps. If no such document is available, maybe an overview of the necessary steps with links to the appropriate documents/tutorials would also be helpful.
Afaik you're unfortunately right: no single source for this information exists. The moveit-users mailing list is a good place to start, and the various PR2 (grasping) related MoveIt packages may also be intersting. interesting. The pick-and-place pipeline is probably the least documented, although admittedly I haven't spent too much time trying to find information. I'm guessing most users only use MoveIt for its motion planning capabilities, and don't integrate EEF control with it.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
