Drake: Integrate grasp planner into Drake

[hongkai-dai]

We want to plan the grasping posture of the robot hand. We can try the following three approaches

1. Integrate GraspIt! http://graspit-simulator.github.io/ into Drake.
2. Write our own sampling based grasping toolkit.
3. Implement the optimization-based grasping planner in C++ (We have one of them implemented in MATLAB side of Drake).

I think the first approach (GraspIt!) seems most viable. I will start with that.

Once we have one grasp planner in Drake, we should be able to evaluate how robust it is using IIWA arm (in the position control mode), together with our gripper (Schunk hand or the Robotiq hand).

[liangfok]

SGTM. I recall GraspIt! adopting an unusual (to me) coordinate frame convention, especially w.r.t. the world. You might want to check that first to ensure we don't start off in the wrong direction.

[rpoyner-tri]

Looks to me like the GraspIt! license is GPL. Are we allowed to integrate viral-license software with Drake?

[liangfok]

The following web page indicates that as long as Drake and GraspIt! are decoupled by a middleware, Drake does not need to adopt GPL.

http://programmers.stackexchange.com/questions/110380/call-gpl-software-from-non-gpl-software

[jwnimmer-tri]

(a) I don't think the page says that anywhere and (b) the mere fact of middleware is not enough to escape the GPL; the license can still infect intimately coupled software, no matter the mechanism.

[liangfok]

Here's the quote I read from the above-linked webpage:

You can use a GPLed program from your own program without your program being affected by the GPL, but you cannot link the GPLed code into your own program without your program becoming subject to the GPL's terms.

If there's a middleware like LCM or ROS decoupling Drake from GraspIt!, Drake will not be _linked_ to GraspIt! and thus not be subjected to the GPL (I am assuming the term "linked" here refers to object linking by the linker during the build process). No?

[jwnimmer-tri]

"Use a program" there means via its command-line interface. Middleware is more complicated.

[sherm1]

It also says:

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide.

That's a reminder that these questions don't actually have answers. Until there is a lawsuit that goes to trial these legal questions remain unresolved. Useful questions here would be "what is the risk to us?" and "what is the benefit?", as well as "how can we reduce the risk?".

[hongkai-dai]

After reading the GraspIt! papers, I think we should be able to write an alternative grasp planner. I quickly summarize the features of GraspIt! as below

• Collision detection
• Dynamic simulation (time stepping linear complementary program)
• Computing grasp quality (index for force closure, for example).
• Grasp planning. They have three types of grasping planners
  
  
  
  • Primitive-based grasp. This only works for Barret hand, so not suitable for us.
  
  
  • Eigengrasp planning. This solves an optimization problem using probabilistic simulated annealing approach.
  
  
  • Database approach.
  
  

Some of the features are on our radars anyway like the collision detection and dynamic simulation, that we plan to add into Drake. The grasp quality function is not hard to compute. I think I can get a sample + optimization based grasp planner working, using our optimization hierarchy.

The risk of working on a planner ourselves is that we spend a lot of time, and eventually find that an optimal grasp coming from the planner is not robust, and we cannot use it in the real application (which I highly suspect is going to happen). As the Amazon Picking Challenge team already mentioned, they did not use the grasp planning.

What are people's opinion on this? Do you think writing a grasp planner ourselves aligns with our long-term goal in manipulation?

[liangfok]

The risk of working on a planner ourselves is that we spend a lot of time, and eventually find that an optimal grasp coming from the planner is not robust, and we cannot use it in the real application (which I highly suspect is going to happen).

For reference, how robust is the grasp planner in GraspIt!?

What are people's opinion on this? Do you think writing a grasp planner ourselves aligns with our long-term goal in manipulation?

:+1:

[liangfok]

Thanks for the explanation. Would you say that we should prioritize developing / acquiring a "skin" that can provide high fidelity and low latency contact sensory feedback of the grasp quality? Without that kind of feedback, I'm afraid any grasp planning will not be robust.

Possible research directions:

1. GelSight: http://www.gelsight.com/
2. Tactile sensors: http://wiki.icub.org/wiki/Tactile_sensors_(aka_Skin)
3. TakkTile sensors: http://www.labs.righthandrobotics.com/takktile-sensors

[liangfok]

OK. +1 for implementing an optimization-based grasp planner in-house and then using it for evaluating / motivating various tactile feedback technologies.

[RussTedrake]

+@ggould-tri and +@Lucy-tri — this is relevant to our discussion the other day.

[Lucy-tri]

+@sammy-tri This discusses GraspIt!

[hongkai-dai]

I don't think we will add graspit or any grasp planner into Drake, as we don't have any immediate usage of these planners. I will close this issue.