Implement new pick&place plan capability

[henningkayser]

This effort aims at providing a new generic pick and place planning pipeline based on MTC. Here we can discuss design and specification details.

Development PR: https://github.com/ros-planning/moveit_task_constructor/pull/111

[rhaschke]

We aim to have 3 move_group capabilities:

• Pick
• Place
• Pick+Place

Key concepts / architecture

• Pick and Place will be implemented as reusable MTC containers (improving the existing ones),
• which instantiate configurable stages for a GraspProvider and PlaceProvider respectively.
• To handle bimodal grasping (i.e. choosing left or right gripper for grasping) all relevant properties should be passed via solution properties from the chosen gripper and grasp_msg.
• Those provider stages should be instantiated via pluginlib.

Picking

We will provide two basic GraspProvider stages:

• One taking a predefined list of possible grasps (grasp_msg).
• One being an action client calling an external action server to provide grasps.
  • The server might return grasps both in its feedback and its result messages (to allow for early start of planning).
• The GraspProvider will need the following parameters:
  • eef defining (eef group, arm group, parent link in arm group)
  • a grasp_frame (PoseStamped)
  • a generic key-value parameter map that will be passed on to the action server
    • action server name (with default: grasp_provider)
    • config: e.g. selector for left/right/both hands (to be used by action server)

Grasping Messages

Fields of the grasp_msg are not fully discussed yet. Probably we will need many fields of the existing grasp message.

• grasp_frame as PoseStamped (relative to the parent_link)
• ignore_collision_links of the hand during finger closing Instead of providing exact grasps, would be great if we could handle tolerances and MTC would generate more grasps within those translational or rotational tolerances?

[felixvd]

@henningkayser Did anything happen about this since it was posted? If yes, could you update to avoid potentially duplicating work?

[rhaschke]

Unfortunately, we didn't make progress on that in Bielefeld...

[v4hn]

Unfortunately, we didn't make progress on that in Bielefeld.

Nor in Hamburg. There is always more urgent things to do, though it is still on my (long) list of todos. :/

[felixvd]

We have implemented something similar that we plan to reshape into this PR soon. Just saying in case someone was planning to tackle this during the holidays.

[rhaschke]

:+1: I'm curious to see your approach.