JenniferBuehler / grasp-execution-pkgs

Package(s) to execute a grasp incl. execution in Gazebo
BSD 3-Clause "New" or "Revised" License
34 stars 17 forks source link

Constantly failed of part 3 in the Automated grasping tutorial #4

Closed cangjiaxaun closed 6 years ago

cangjiaxaun commented 7 years ago

Hi, Jennifer it's me again:)

I was following your awesome tutorial performing grasp action with jaco.

I have successfully done the first two parts, but I got some problem when following part 3. I tried like 7 or 8 times, although I have "/jaco/grasp_execution/grasp: Action finished. Result = success: 1" and "Grasp action finished: SUCCEEDED". But every time the jaco hand could not grasp the cube tight enough, and the cube would fall when performing the home action.

Please tell me if you need other information generated in this process.

Thanks in advance!

JenniferBuehler commented 7 years ago

Did you enable the grasp fix plugin as described in the tutorial? You need it, otherwise the object will most certainly slip.

So if I understand correctly, the problem is not that no motion and/or grasp plan could be found, but that the object slips out of the hand because the grasp is not good enough?

Cheers Jenny

JenniferBuehler commented 6 years ago

Hi, I assume this is not relevant any more as this is ages ago ;) Closing this, please re-open if you have any further questions about this.

BTW I've just updated the packages here (and depending packages, e.g. joint-control-pkgs and graspit-pkgs), so if you are still using this, you should do an update of all packages.

marooncn commented 6 years ago

Hi, today I execute the automatic grasping as tutorial roslaunch grasp_execution_jaco_tutorial jaco_on_table_gazebo_complete.launch load_grasp_fix:=true load_graspit_planner:=true planning_results_directory:=~/result/

roslaunch grasp_execution_jaco_tutorial simple_automated_grasp_execution.launch run_type:=3 results_directory:=~/result/ But in about half of times, there are errors: (the first command)

[ERROR] [1522595045.569412806, 17.177000000]: Arm[RRTConnectkConfigDefault]: Unable to sample any valid states for goal tree (the second command) [ERROR] [1522595045.599731932, 17.181000000]: Could not plan joint trajectory [ERROR] [1522595045.599787696, 17.181000000]: Could not plan/execution motion, return code -2 [ERROR] [1522595045.599817436, 17.181000000]: Could not reach to cube1 [ERROR] [1522595045.599843433, 17.181000000]: Failed to run automated grasp execution

When there is no error, the grasp result is still not ideal: peek 2018-04-01 22-36

Any advice? BTW, In the installation period, household_objects_database pkg is installed, so I'm curious is other object is supported to grasp? Is there more detailed material such as paper or slider for us to learn your grasp algorithm and program?

JenniferBuehler commented 6 years ago

Yes that is unfortunately a downside of the GraspIt planning algorithm, it does not always compute a good grasp (also when you use the graspit simulator directly, you'll have to re-run the simulation until a good one comes out). Therefore, not every time a good grasp is computed.

What you can do is

  1. The planning is re-run X times afresh, and then the best results are picked. At the moment, X defaults to 1. You can increase this by setting the ROS parameter /graspit_planning_service/default_num_repeat_planning. The best grasp of X independent runs will be picked ("best" in terms of the grasp energy as computed by GraspIt). However this implies that the grasp energy is actually a good reflection of how good the grasp is, and I found this not to be the case always... it's worth giving it a go though. The planning will be slower obviously, because it will be re-run more than once.
  2. You can also change the iterations of the GraspIt planning algorithm, but this is unlikely to improve the result much - set it with /graspit_planning_service/default_max_planning_steps. At the moment ist 70000.
  3. try to improve the hand configuration for graspit by adjusting the contact points, I haven't tweaked the default ones used here very much. See also this tutorial. Maybe you'll get better results then.

It is also possible that a grasp is computed which may be OK, but MoveIt cannot find a motion path for this exact hand position. Maybe the finger would collide/touch the table or cube while moving there, which causes the MoveIt motion planner to fail. This is the error you are receiving about "could not plan joint trajectory". MoveIt is not perfect either, you could try to adjust MoveIt! parameters, but that's a lot of tweaking. Easiest way to go is to repeat the process until a grasp is computed for which a MoveIt! motion plan is found. Currently, the node implementation does not do that. See this line in simple_automated_grasp_execution.cpp. You could try to repeat the process until the whole action has succeeded.

And to your question about the household objects: I just updated this dependency. In fact only the message package household_objects_databse_msgs was required, and only because of the manipulation_msgs dependency to it. It is only the message type which we need here, there is no restriction on the types of objects used.

And finally: The grasp algorithm used here is not mine ;) My code is using GraspIt. I've made the ROS interface for it and the C++ API to control the GraspIt planning alogrithm without the GraspIt GUI. For more information about GraspIt itself, please check out their documentation :)

marooncn commented 6 years ago

Thank you, your explanation is pretty detailed and clear. I'll spend some time trying as your suggestion to get more stable grasp.