Describe icra_manipulation_demo/grasp_pipeline_pre_review here.
Informal page for pre-release discussion on the grasping pipeline
Key points
- Three stacks:
- object_manipulation
- grasp
- place
- no object detection or adding objects to collision maps; expects that to be taken care of externally and will be supplied the collision names of what it needs
- will attach / detach objects from gripper while grasping / placing
- tabletop_object_perception
- a short-lived "convenience tool" for writing apps that use the object_manipulation stack
- the current tabletop_object_detector
- along with a tool that does our current collision environment processing for manipulation
- add known objects to collision env. as meshed, give them names
- add point clouds to collision env. as bboxes, give them names
- acquire a new static collision map
- applications
- will include all launch files
- keyboard interfaces
- manipulation demo script
- object_manipulation
- PR2 dependencies
- the notion of a Grasp can be made robot-independent
- in as much as we can work without actually having another robot
- the entire pipeline can be made robot independent, with the exception of:
- the act of actually setting a finger posture or applying finger forces
- I can sub those out into separate packages
- cluster based grasp planner
- fingertip reactive approach
- the act of actually setting a finger posture or applying finger forces
- the notion of a Grasp can be made robot-independent
Package structure
- object_manipulation
- object_manipulation_msgs
- object_manipulator
- grasp_execution
- reactive_grasp_execution
- hand_grasping_controller
- place_execution
- tools
- grasp_planner_db
- pr2_object_manipulation
- pr2_gripper_reactive_approach
- pr2_gripper_grasp_planner_cluster
- pr2_gripper_grasping_controller
- pr2_object_manipulation_launch
- launch files strictly for manipulation
- tabletop_object_perception
- tabletop_object_detector
- tabletop_collision_map_processing (laser speed moves to a launch file)
- pr2_tabletop_manipulation_apps
- pr2_tabletop_manipulation_launch
- launch files that also include the tabletop perception stuff
- pr2_pick_and_place_demos
- pick_and_place_executive
- pick_and_place_keyboard_interface
- pick_and_place_demo
- pr2_tabletop_manipulation_launch
ROS / C++ API's for object_manipulation
Only the object_manipulator will have a ROS API for now. The calls (see below) will offer all the functionality we have so far identified as needed. ROS API's for lower level modules might be added later hopefully without changing the high-level ROS API.
| | ROS | \ / V C++ object_manipulator <------- Grasp planner | | -cluster | C++ | C++ -database | | \ / \ / V V Place execution Grasp execution - without approach (we never used it) - with interpolated approach - with interpolated reactive approach
Proposed API
PickupGoal
The service must contain the following (in some exact syntax TBD):
# which arm to be used for grasping # Use string everywhere # enforce naming conventions for getting service and action names from arm names string arm_name # The object to be grasped GraspableObject target # a list of grasps to be used # if empty, the grasp executive will call one of its own planners Grasp[] desired_grasps # how the object should be approached GripperTranslation approach # how the object should be lifted GripperTranslation lift # the name that the target object has in the collision environment # can be left empty if no name is available string object_collision_name # the name that the support surface (e.g. table) has in the collision map # can be left empty if no name is available string support_collision_name ### Potential future additions if lower-level modules get ROS API's ### # which grasp planning service to use # string grasp_planning_service_name # which grasp execution service to use # string grasp_execution_service_name
PickupResult
# the result of the grasp ResultCode grasp_result # the grasp that was successfully executed (if any) Grasp executed_grasp # the arm that was used string arm_name
Gripper Translation
# the direction of the translation geometry_msgs/Vector3Stamped direction # the desired translation distance float32 desired_distance # the min distance that must be considered feasible before the # grasp is even attempted float32 min_distance
Result code
# task completed as expected # generally means you can proceed as planned int32 SUCCESS = 1 # task not possible (e.g. out of reach or obstacles in the way) # generally means that the world was not disturbed, so you can try another task int32 UNFEASIBLE = -1 # task was though possible, but failed due to unexpected events during execution # it is likely that the world was disturbed, so you are encouraged to refresh # your sensed world model before proceeding to another task int32 FAILED = -2 # a lower level error prevented task completion (e.g. joint controller nor responding) # generally requires human attention int32 ERROR = -3 # a bit hackish, means that at some point during execution we ended up in a state that # move_arm will not move out of. The world was likely not disturbed, but you probably # need a new collision map to move_arm out of there int32 MOVE_ARM_STUCK = -4 # the actual value of this error code int32 value
Graspable Object
# what type of object this is int32 DATABASE_MODEL = 1 int32 POINT_CLUSTER = 2 int32 type # the database model and its pose, if type==DATABASE_MODEL model_database/DatabaseModelPose model_pose # the point cloud itself, if type==POINT_CLUSTER sensor_msgs/PointCloud2 cluster
Placing
This is a perfect mirror image of grasping, but takes as input the grasp that has been executed and a desired place location.
# the object currently held by this arm should be placed ArmSelection which_arm # information about the grasped object Grasp executed_grasp # where the object should be placed geometry_msgs/PoseStamped place_location # how much the object should be padded by when deciding if the grasp # location is freasible or not float64 place_padding # the name that the target object has in the collision map # can be left empty if no name is available string target_collision_name # the name that the support surface (e.g. table) has in the collision map # can be left empty if no name is available string support_collision_name # how the place location should be approached int32 APPROACH_VERTICALLY = 1 int32 APPROACH_ALONG_GRASP = 2 int32 approach_type
Hand Description
This goes into a yaml file which get associated with the arm name.
# The frame of the end-effector string end_effector_frame # The preferred approach direction for the grasp # relative to the end-effector frame vector3 approach_direction # The name of the entire end effector in the collision environment string end_effector_group_collision_name; # The names of the "fingertip" links # better explanation to follow string[] fingertip_link_names; # The set of links that are allowed to be in contact # with the object during grasping string[] touch_link_names # The name of the link that a grasped object can be considered # rigidly attached to string attach_link_name
Grasp
# The internal posture of the hand for the pre-grasp # only positions are used JointState pre_grasp_posture # The internal posture of the hand for the grasp # positions and efforts are used JointState grasp_posture # The pose of the end-effector for the grasp relative to the object Pose grasp_pose