Automated grasp execution

This documentation is still under construction

The automated execution as demonstrated in the automated grasp tutorial uses several ROS actions and services, some of them provided in the package grasp_execution. To grasp an object, the robot needs to take at least the following steps:

1. Object recognition to locate the object to be grasped at a pose in the world.
2. Grasp planning to obtain details of the grasp, such as the required end effector pose and the joint state. Results come in a manipulation_msgs/Grasp.msg (identical to the one now kep in moveit_msgs). The end effector pose is returend relative to the object, so that the resulting grasp(s) can be used at any object pose.
3. Reach planning to obtain a motion plan to reach the arm to the grasp position. Results come as trajectory_msgs/JointTrajectory.msg. This step also covers collision checking for the end effector at the grasp pose. If there are several eligible grasps (e.g. from a grasp database), some may not actually be viable at the current object pose, due to collisions with the environment (e.g. the table). An implementation of this step can choose any strategy to determine which grasp is selected for execution in the next steps.
4. Reach the arm according to the resulting motion plan of the reach planning step.
5. Grasp the object if the precondiions are fulfilled, meaning the reach action was successful and the arm is at the required target pose for grasping.

The diagram below depicts the ROS services and actions used by the automated grasp executor to achieve the grasping task (omitting the object recognition step). Note that not all data passed around is depicted in the diagram for the sake of clarity.

Notes about the individual steps in the diagram:

• Grasp planning: this could be any service to return eligible grasps, either from a database, or by on-line grasp planning.
• Reach planning: the Pose object in the dataflow is the end effector target pose.
• Reaching: The joint trajectory execution should ideally be controlled by velocity commands, using the velocities specified in the joint trajectory. See also this wiki page for an explanation why.
• Grasping: The Pose object is the actual current end effector pose, to be used for the eligibility check. Several JointTrajectory instances are actually passed: For the actual grasp, and optionally also for the approach and retreat movements. While the Grasp action handles eligibility checking and possible approach/retreat actions, the GraspControl action handles the actual opening/closing movement (e.g. more advanced implementations operate with force feedback, while simple onces just close the grippers). Please also refer to the documentation in grasp_execution which describes the Grasp.action and GraspControl.action action servers in more detail.

Simple implementation

A helper class for getting started with programming the grasping task is provided in SimpleAutomatedGraspExecution. It can be derived to vary some aspects. There are currently 3 implementations of it, which only vary in how they do the grasp planning. They are used in the three parts of the automated grasp tutorial respectively:

• SimpleAutomatedGraspFromTop uses a simple hard-coded grasp from top, and will probably only work for the Jaco robot used in the tutorials.
• SimpleAutomatedGraspFromFile loads a specific grasp planning result from a file.
• SimpleAutomatedGraspOnlinePlanning does the grasp planning on-line using the GraspIt! grasp planner with the ROS services of grasp_planning_graspit_ros. It loads the model to the GraspIt! world and puts it on a table (as support surface) before doing the grasp planning.

Parameters can be set in a .yaml file as in the template provided in SimpleAutomatedGraspTemplate.yaml (see for example the example SimpleAutomatedGrasp.yaml for Jaco).

Important
While the execution is running, the object infromation pipeline has to be running in order to keep track of possible object movements and update the MoveIt! environment. The /tf environment needs to be updated, including the position of the object (class ObjectTFBroadcaster can be used to help with this, it is automatically launched in the tutorials).

Limitations
As the names of the current implementations suggest, there are a number of limitations, because this only serves as an example implementation. All implmentations are at a simple level and can be improved. Some specific points:

• In the grasp planning step: class SimpleAutomatedGraspOnlinePlanning only runs once and takes the first result as the only eligible grasp.
• In the reach planning step: all SimpleAutomatedGraspExecution implementations only support one (the first) eligible grasp. It does not iterate through all grasps to find any currently eligible grasp.
• There is no failure recovery. For example, if the reach has not been accurate enough (or the object has moved slightly) and therefore the grasp eligibility criteria do not hold, no new reach plan is made to account for any changes in the environment.