Rosanswers logo

Hello, I am using pr2_pick_and_place_manager explained here, in order to pick up objects. I'm calling it from code.

Object detection works very robustly, and I am using objects from the household database. However, grasping often returns UNFEASIBLE - which means it couldn't find a feasible grasp for the object. Sometimes grasping works if the object is centered on a table in front of the PR2, but not always.

Do you have any suggestions about how to reduce the number of times that no feasible grasp is found, so that the robot could pick more robustly the objects?

Turning the robot towards the table? Moving the arm closer to the object before attempting a grasp?

EDIT: This part of the output:

  [INFO] 1311008555.087295: tabletop detection reports success
  [INFO] 1311008602.329595: detection finished, finding bounding boxes for 
  clusters and sorting objects
  [INFO] 1311008602.330844: object 0, red: recognized object with id 18724
  [INFO] 1311009564.034749: attempting to grasp an object, whicharm = 0
  sending object collision name of: graspable_object_0
  [INFO] 1311008668.999249: grasp result: UNFEASIBLE
  [INFO] 1311008668.999630: no feasible grasp for this object with the r arm
  [INFO] 1311008668.999930: pick-up failed.

The object marker seemed to be in the right place:object markers were correctly recognized

EDIT2: I copied the grasp goal and result into this text file http://web.mit.edu/mitko/Public/rosdebug/grasp_goal_and_result.txt

EDIT3: Indeed if I try a different object there I see a bunch of grasps evaluated for feasibility: image description

UPDATE: When I send the grasp goal to

 rosservice call /objects_database_node/database_grasp_planning

I get

 grasps: []
   value: 0

Value 0 corresponds to success according to http://www.ros.org/doc/api/object_manipulation_msgs/html/srv/GraspPlanning.html so I guess for some reason the grasp planner returns no grasps. Is there a way check why?

Originally posted by Dimitar Simeonov on ROS Answers with karma: 535 on 2011-06-06

Post score: 4

Original comments

Comment by Matei Ciocarlie on 2011-07-22:
I can replicate the correct behavior where I am indeed getting grasps back. I know that there are a few objects in the database that do not have grasps, but they are rarely used. The object recognition node only uses a subset of the models, and those with no grasps should not be in there.

Comment by Dimitar Simeonov on 2011-07-20:
I ran a script to see all objects for which there are grasps returned. http://pastebin.com/KyRJQ1zw contains the model ids of all the objects that have grasps- the rest of the objects in the "" dataset have no grasps. Also the call command is there - just a rosservice call. Can you replicate this?

Comment by Matei Ciocarlie on 2011-07-18:
No grasps in the service response is strange... What arguments are you passing in? In particular, what object id?

Comment by Dimitar Simeonov on 2011-07-18:
Hello, I worked on other stuff for a while but now I'm trying to solve this again. Looking at the markers - they appear to be in the right positions - torso is raised up and the table is close enough. I didn't see any grasp planner markers - maybe it is not trying any?

Comment by Dimitar Simeonov on 2011-06-08:
Thank you for the suggestions. I won't have access to PR2 next couple of days, but will get back to you after that.

Comment by Matei Ciocarlie on 2011-06-08:
Also, if you can maybe post a screenshot from rviz, with the collision map and the collision model markers listed here: http://www.ros.org/wiki/pr2_tabletop_manipulation_apps/Troubleshooting

Comment by Matei Ciocarlie on 2011-06-08:
Is the robot torso all the way up? With the torso down, the PR2 has difficulty grasping from a table, as it can not really reach above its shoulders.

Comment by Dimitar Simeonov on 2011-06-08:
Hello Matei, I am using PickAndPlaceManager from pr2_pick_and_place_demos to call the detection, and to grasp the object. Usually a put two or three objects on a table in front of a robot in a random configuration with at least few inches of separation.

Comment by Matei Ciocarlie on 2011-06-07:
Dimitar - how does your collision map look like? It might also be complaining that all the grasps are actually in collision with the environment. Also, what service exactly are you using to detect the objects?

Comment by Dimitar Simeonov on 2011-06-07:
I havent tried raising the torso - it has been on varying heigh in my tests - thanks for that! I think that by UNFEASIBLE they mean that no feasible grasps are found (according to documentation). I can't turn the object database - it's needed for reasoning over the object names.

Comment by ben on 2011-06-07:
I don't have any advice yet. I have been putting the roll of tape in the center of the table or close to it. Have you tried raising the torso? Is the problem usually that it can't find a grasping pose or are there other problems as well? Have you tried turning off the object database?

Comment by Dimitar Simeonov on 2011-06-07:
ben, thanks for the comment! Does picking up the duct tape work robustly at if you move it around? Do you have any advise on how to increase the proportion of times the PR2 successfully picks it up?

Comment by ben on 2011-06-07:
Just posting here that I'm experiencing similar problems at Penn with our PR2. The object detection seems to work well (in my case, I'm not using the database), and in many cases, picking up a roll of duct tape works decently but it fails to put down the roll of tape because it returns 'infeasible'.


1 Answer 1


Rosanswers logo

UNFEASIBLE does mean no feasible grasps were found--there are a number of things that can go wrong. Sometimes it means the object is out of reach, other times that there's no grasp that doesn't make the arm collide with the table, still other times the pregrasp is out of reach or in collision, even still other times there's no way to lift the object from the grasp pose... if you look at the messages going by in the window where you launched pr2_tabletop_manipulation.launch you should be able to see more info about why the grasp(s) failed. You do want the torso to be all the way up, pretty much anytime you're trying to do tabletop manipulation. Also, in that picture the robot looks pretty far from the table--to grasp objects that far into the table, I would definitely drive the base right up to the edge of the table. It's really quite surprising often how small the robot's workspace actually is--stuff that looks reachable very often really isn't.
As for putting stuff down, in more recent versions (Electric) the place goals have been raised in z to start--in older versions, if calibration causes the table to be significantly tilted, sometimes all the place poses will be in collision with the table. Even so, it should eventually resort to the last-resort-place in which it kind of shoves the object diagonally down onto the table--the fact that it doesn't suggests to me that your collision map is preventing the arm from planning any sort of movement to above the table.

Originally posted by hsiao with karma: 741 on 2011-08-03

This answer was ACCEPTED on the original site

Post score: 1

Original comments

Comment by Dimitar Simeonov on 2011-08-03:
thank you for the answer - I solved the problem by only using objects for which grasps are in the database (as seen from my machine - non-reproducible bug explained in comment #12 above). As for reachability - you are right - the objects need to be close enough to the robot


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.