Revision history [back]

why isn't it able to move the arm to the object?

It surely is able to do that, but that's not what you want. You don't just want to move the arm to where the object is, but instead, you want to grasp the object, meaning you would like to stably fixate it in the end effector, maybe touching the object at specific regions such as a handle, and allow the arm to move around with the object grasped. Probably you like to include a safe approach motion of the arm. You might want to be able to specify how to grasp the object with the end-effector (e.g. how much force). You might even have an end-effector that is no simple one-dimensional gripper and can even grasp in multiple ways. And you might also want to lift the object off the table (which direction is that?) for a certain distance (how far?) after closing the gripper to demostrate that it's actually grasped stably and isolate the object from its support surface to simplify later motions.

Grasping an object is not an easy thing to do. There have been major international research programs on the topic, and in my opinion we are still far from having it "solved" even in theory. The MoveIt pick_and_place pipeline tries to make this more accessible by boiling the problematic points down to the Grasp message that should be provided by the user (or some intelligent scripts they implement) and imho the original author(s) did quite a decent job there.

The pick-place-capability...

• provides an integrated pipeline to reason about the whole grasp process and decomposes it into a number of executable trajectories for multiple low-level controller.
• does forward projection such that you will not start executing a grasp to only then find out that because of some obstacle or the kinematics of your arm you can't lift the object off the table after closing the endeffector.
• manages attaching and detaching of the grasped object so that collision checking when moving the arm with an object attached will also check for collisions of the object in the environment (even in the forward projection).
• supports parallel checking of multiple candidate grasps for all the different trajectory-parts of the grasp
• it provides a visualization of evaluated grasps during the process in RViz

... along with all the usual capabilities of MoveIt. This is quite a lot.

In practice, most of the time you will have to provide a valid Grasp message yourself for a successful grasp (and as I pointed out already, this is not necessarily easy and also highly depends on your setup). If you call the pick(std::string) method, the pick_place pipeline will try to request candidate grasps to test from an external service instead (you have to provide that ROS-service yourself) and adds a somewhat meaningful "default" grasp. The code for that part is here: https://github.com/ros-planning/moveit/blob/kinetic-devel/moveit_ros/manipulation/move_group_pick_place_capability/src/pick_place_action_capability.cpp#L417

That being said, there are quite a number of rough edges in the pick/place capability. Our lab fixed some of them only recently and pushed the fixes upstream. Other improvements are being discussed just these days, e.g. https://github.com/ros-planning/moveit_msgs/pull/32 . All contributions that improve the current performance and usability of this capability are definitely welcome!