Skip to content

urdf2graspit

Jennifer Buehler edited this page Apr 13, 2016 · 7 revisions

Conversion from URDF to Denavit-Hartenberg parameters

This package converts from URDF to Denavit-Hartenberg parameters used in the GraspIt! format.

The main class Urdf2Graspit provides functions to transform a robot described in URDF to its description in the GraspIt! format. This requires a few steps:

  • Conversion of all mesh formats into Inventor format
  • Removal of fixed links in the URDF (fixed links are not fully supported by GraspIt! yet)
  • Transformation of joint transforms such that the rotation axis is always z (to allow for conversion into Denavit-Hartenberg Parameters)
  • Conversion of the joint transforms to the Denavit-Hartenberg convention.
  • (optional) scaling of the model.
  • Generate contact information for the hand model.
  • Generation of all required xml and inventor files.

There is also a ROS node which does the whole job, given a URDF file and the names of the hand link and the finger joints.

Usage

Refer to this tutorial for instructions on how to do the conversion from urdf to graspit format.

You may also be interested in the package urdf2inventor which provides a viewer which can help you find the right link names on your robot URDF.

EigenGrasp notes

GraspIt! uses "Eigen Grasps" to plan for grasps. Find more about eigengrasps in the graspit manual. Also see the paper Dimensionality reduction for hand-independent dexterous robot grasping (Ciocarlie et al, IROS 2007) and the GraspIt! user manual chapter on EigenGrasps.

The robot xml file which is created by urdf2graspit loads this Eigengrasp by default with your robot. If you open this robot (or the world file), you will be able to try out any changes you do to this eigengrasp file with the graspit simulator GUI. To try it out, go on Grasp --> Eigengrasp Interface. Here you can use the slider to test the behaviour.

As far as I understand now, an eigengrasp value is "a direction of motion in joint space". Values range between -1 and 1. This defines how fast the joints move proportionally to each other.

In the literature, an "EigenGrasp" is often referred to as "hand synergies". Essentially, an eigengrasp allows to change one value to make the whole hand do a grasp movement, hence this one value affects all the DOF's. You can see that for example in the DLR hand (coming with the GraspIt source), if you comment out the loading of the eigengrasp file in the robot file (DLR.xml) the Eigengrasp Interface will fall back to adjusting all single DOF's. If an eigengrasp is loaded, this interface provides one slider for each defined eigengrasp, and you can close the whole hand with it.

The urdf2graspit converter generates one eigengrasp which will move all joints in positive direction (1.0). For each robot, new eigengrasps can added individually. This is more like a template which you probably need to adapt for your own robot. You can find the template in <your-urdf2grasit-output-folder>/models/robots/<your-robot-name>/eigen/eigen.xml. The GraspIt Eigengrasp Interface of the simulator can be used to experiment with such values. It provides sliders to see the DOF values when no eigengrasps are loaded from file. By default, in the displayed values, 0 means the middle between min and max joint value. E.g. if min joint is 0, ans max is 0.8, the displayed value 0 will correpsond to DOF value of 0.4, displayed -0.4 will correspond to 0, and 0.4 will correspond to 0.8. This behaviour can be adjusted in the eigengrasp XML file (YOUR_ROBOT/eigen/eigen.xml) by changing the origin.

Note: The contact points generated by urdf2graspit may still need to be improved, I have not had the time to inspect how they can be defined better. So the grasp planning results may not be optimal.

Denavit-Hartenberg parameters

The DH parameters are broadly not as intuitive to understand as URDF. It is a completely different way to describe a model and its joint space.

Resources:

GraspIt! contacts

The GraspIt! format for contact points is VGR. Defined contact points on a hand greatly help to reduce search space for the planner. Unfortunately, there is very little documentation available online.

In the VGR file which contains the contact points of a robot hand, each point is separated by new line.

  1. Robot name
    [string]
  2. Number of contacts
    [int]
  3. Finger and link number
    [int, int]
  4. Number of friction edges. This defines a polyhedron, presumably relative to the contact position below, in which friction may occur.
    [int]
  5. Friction edges. One line for each friction edge (total number defined in 2.).
    6 * [number-friction-edges]
    where [number-friction-edges] = [float, float, float, float, float, float]
    The 6 values specify friction cone boundary wrenches.
    See more documentation in function ContactFunctions.h : setUpFrictionEllipsoid().
  6. Virtual contact location
    [float, float, float]
  7. Frame quaternion
    [float, float, float, float]
  8. Frame location (mostly equals virtual contact location)
    [float, float, float]
  9. Virtual contact normal
    [float, float, float]
  10. Virtual contact friciton coefficient (COF)
    [float]

Outstanding issues

The code is in beta/experimental state so there are still improvements that can be made. Please refer to the issue trackers in this repository to see what is going to be worked on.