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.

Sign up for GitHub

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

Jump to bottom

new GraspPlanning service to replace manipulation_msgs version #32

Merged
merged 2 commits into from
Oct 4, 2016
Merged

new GraspPlanning service to replace manipulation_msgs version #32

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b5c61b7
new GraspPlanning service to replace manipulation_msgs version
Sep 27, 2016
7f56c45
Adapt variable names and comments
Sep 30, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CMakeLists.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,7 @@ ExecuteKnownTrajectory.srv
GetStateValidity.srv
GetCartesianPath.srv
GetPlanningScene.srv
GraspPlanning.srv
ApplyPlanningScene.srv
QueryPlannerInterfaces.srv
GetConstraintAwarePositionIK.srv
Expand Down
27 changes: 27 additions & 0 deletions srv/GraspPlanning.srv
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# Requests that grasp planning be performed for the target object
# returns a list of candidate grasps to be tested and executed

# the planning group used
string group_name

# the object to be grasped
CollisionObject target
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about target_object or collision_object?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name is taken from the original manipulation_msgs/GraspPlanning.srv.
I prefer the short name here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for the short name target.


# the names of the relevant support surfaces (e.g. tables) in the collision map
# can be left empty if no names are available
string[] support_surfaces

# an optional list of grasps to be evaluated by the planner
Grasp[] candidate_grasps

# an optional list of obstacles that we have semantic information about
# and that can be moved in the course of grasping
CollisionObject[] movable_obstacles
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is movable_obstacles different from the allowed_touch_objects field in the Grasp.msg message?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the idea is that moveable_obstacles can actually be shifted by colliding with the gripper -- I'm pretty sure that none of our current planners can actually do anything with this, but there was some work going on at willow garage to do "push-based" manipulation and grasping, where the planner could figure out how to nudge things out of the way in order to get to the grasp and get a desired grasp.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. I think the potential usage you described is already encompassed in the allowed_touch_objects entry in the Grasp.msg messages in this service definition; in fact they even have the same description. I think we should avoid having entries with similar purpose as that could make the interface confusing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does one specify the list of allowed touch objects as an input to the service though, if they have no initial estimate of grasps? The "grasps_to_evaluate"/"candidate_grasps" field is optional, and I presume most users probably won't be specifying it, but if we remove the moveable objects, then we have to pass at least one candidate grasp that contains only the allowed_touch_objects, but is not actually a candidate? That seems pretty unclean, and potentially leading to the sort of headaches we currently have with "is_diff" in the planning scene.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikeferguson that's a good point.


---

# the list of planned grasps
Grasp[] grasps

# whether an error occurred
MoveItErrorCodes error_code