remove grasp service support from pick_place's fillGrasp #328
Conversation
|
As you've pointed out, there's not much value here with this single default grasp. Would we rather have this Long term: we need a default grasping service, even if its pretty basic. |
| @@ -576,7 +472,6 @@ void move_group::MoveGroupPickPlaceAction::fillGrasps(moveit_msgs::PickupGoal &g | |||
| -std::numeric_limits<double>::max()); | |||
| } | |||
| goal.possible_grasps.push_back(g); | |||
There was a problem hiding this comment.
I'm pretty sure this section needs to be un-indented, but all my clang-format efforts have failed me since Travis didn't run
There was a problem hiding this comment.
You were right, I just changed that to trigger the check...
For some reason my clang-format (3.9) keeps reordering my list of includes alphabetically,
so I don't use it at the moment...
If you have an idea how to change that, that would be nice :-)
|
Actually, I do think the one default grasp is enough for this interface. (We could add more if someone provides reasonable grasps). |
|
Think you could write up a quick tutorial on using grasping services and its integration to moveit? You or I could also then add a table with available open source grasp planning packages to that tutorial |
v4hn
force-pushed
the
pr-kinetic-simplify-fillGrasps
branch
from
7a15839
to
57a3eba
Compare
Not sure I'll have time for that in the near future, but it sounds like a good idea.
I'm pretty interested in such a list myself. I'm only aware of your |
v4hn
force-pushed
the
pr-kinetic-simplify-fillGrasps
branch
from
57a3eba
to
b359aa4
Compare
The combination of the service support here and an optional hard-coded default grasp is problematic because if the service is not available for any reason, but should be called, the pick-request will end up with the hard-coded grasp. This can create unexpected trajectories. With MoveGroupInterface::planGraspsAndPick, a replacement for the removed functionality is available. This removes the dependencies on manipulation_msgs and household_objects_database_msgs. (These were not even consistently specified in package.xml and CMakeLists.txt)
|
Thanks! The tutorial need only take 10 minutes of quick notes so that we have something started for the future... |
The combination of the service support here and an optional hard-coded default grasp
is problematic because if the service is not available for any reason, but should be called,
the pick-request will end up with the hard-coded grasp.
This can create unexpected trajectories.
With MoveGroupInterface::planGraspsAndPick, a replacement for the removed functionality
is available.
This removes the dependencies on manipulation_msgs and household_objects_database_msgs.
(These were not even consistently specified in package.xml and CMakeLists.txt)
Should not be back-ported to retain current behavior.