Grasp Quality Metrics

This section is intended as a practical guide on how to access the grasp quality tools in GraspIt!. Grasp quality metrics are an active area of research; for discussions of their theoretical aspects please see the section.

In GraspIt!, a grasp is completely defined by an object and a set of contacts, presumably created by a hand. In the context of grasp quality computations, the posture of the hand, or it’s position relative to the object are not important; all that matters is the location of the contacts. The interface to all of the quality computations is the Grasp class, which collects the contact between a hand and an object. However, an instance of this class never needs to know about joint angles, etc (with a few exceptions listed below).

In order to create a grasp, you must load a hand and an object into a simulation world, then place them relative to each other and change the joint values of the hand until multiple contacts are formed. To facilitate this process, load the dlr_flask.wld world file provided with the GraspIt! distribution. Then use the Grasp->Auto Grasp menu command. This should result in multiple contacts, using all the fingers as well as the palm. We will investigate the quality of the grasp in the following steps.

Grasp Wrench Space metrics

All the grasp quality metrics computed in GraspIt! rely on building the Grasp Wrench Space (GWS) from the individual Contact Wrench Spaces of all contacts (see for theoretical details). There are multiple ways to build a GWS, and then multiple ways to compute a quality metric on one. In GraspIt! a Quality Measure (QM) is more than just a number - it is an object that hangs around from the moment you create it until you dismiss it. At any point, you can ask a QM to update itself and provide you the computed quality value. You can access this functionality through the Grasp->Quality measures menu. The Quality measures window allows you to:

  • create a new Quality Measure, and assign it:
    • a name
    • a Quality Measure type
    • a GWS type
  • edit (change the name or type) of an already built Quality Measure

Once you have constructed a QM, the main GraspIt! window will display it, along with the most recently computed value, in the space provided in the lower left corner of the GUI.

Note that this dialog said nothing of GWS construction. The GraspIt! GUI does all that behind the scenes. Whenever a QM needs a particular type of GWS, one is constructed. However, multiple QM’s can share a GWS: if a QM requests a GWS type that exists already, it will be redirected to the existing GWS rather than building a new one. GraspIt! does the reference counting for you, so when a GWS is no longer needed by any QM, it is deleted. In general, it is building the GWS that is the computationally expensive part of the QM computation.

From a code standpoint, quality measures are organized as follows:

  • the Grasp class keeps track of the hand, the object and the contacts between them
  • the implementations of the QualityMeasure interface can compute quality metrics and provide you with the results. Any implementation of QualityMeasure needs an instance of a GWS class (but the same instance of the GWS class may be shared by multiple QualityMeasures).
  • the GWS implementations actually build the GWS from the set of contacts. This is usually done by computing the convex hull of individual Contact Wrench Spaces using QHull, an excellent library for building high-dimensional convex hulls. Building a GWS is a fairly expensive process (especially when many contacts are involved) and a bottleneck for many GraspIt! algorithms.

In general, a GWS is a 6-dimensional convex polyhedron. As such, it can not be visualized directly. However, GraspIt! allows you to view 3D projections of a GWS. Use the Grasp->Create GWS Projection menu for that. You will need to choose which 3D are fixed (used for projection). Note that a GWS (and its projections) are independent from Quality Measures - you do not need a QM to visualize a GWS. However, if the GWS does not contain the origin (the grasp does not have form-closure), or the GWS is a degenerate 6D object, the GWS construction process might be aborted and the visualization might not show anything. In general, form-closed grasps with a true 6D GWS create correct 3D projections.

Under development: Grasp Force Optimization

All of the QM’s discussed above share a common trait: they assume that the amount of normal force that can be applied at each contact is identical, and normalized to magnitude 1. In practice this is not true: a given contact can only apply the level of normal force that is possible given the actuation of the hand. A great amount of theoretical work exists on taking hand actuation into account when evaluating a grasp. In GraspIt! we have two tools for this, but one of them has never been extensively used or tested, and the other is still under development.

The first tool is an implementation of the Grasp Force Optimization approach proposed by L. Han, J. Trinkle, and Z. Li, Grasp analysis as linear matrix inequality problems, IEEE Trans. on Robotics and Automation, vol. 16, 2000. GraspIt! has the code necessary for all the concepts found in that paper, however, this part of the code has not been tested or used lately. It can all be found in the Grasp class, marked as Grasp Force Optimization (GFO) code.

The second tool is somewhat similar, but employs a different mathematical model (Quadratic Programming instead of Linear Matrix Inequalities) and is geared towards underactuated compliant hands. It performs a Quasi-static (QS) force equilibrium computation to see whether contacts are stable given the actuation scheme of the robot. All the details are in the chapter of this manual. The code itself is also in the Grasp class, marked as quasi-static analysis routines. However, this is still work in progress in our lab, so use with care. Also see the chapter of this manual for more details on DOF force generation capabilities in GraspIt!.