Joint Coupling and Underactuated Hands¶

In the chapters so far we have used the terms “joint” and “DOF” as if they were the same thing, and one DOF always correspond to one and only one joint. This is not always true in real hand models, and it is not always true in GraspIt! either. GraspIt! allows you to connect multiple joints to a single DOF (joint coupling) and allows support for multiple coupling methods.

The best way to think of a DOF in GraspIt! is as a motor. It is responsible for moving the joints of a robot, and it is the only external interface to the robot available for doing that. In the GraspIt! GUI, joint draggers are not actually “joint” draggers but rather “DOF” dragger: only one dragger is presented to the user for each DOF. In the case of the Barrett hand for example, you will notice that there is only one dragger per finger, even though each finger has two joints. Moving the one dragger however affects both joints, as they are coupled to the same DOF.

In a fully actuated robot, there is one motor for each joint. In many cases however, we have joint coupling, that is multiple joints connected to a single DOF. The key aspect here is how exactly this coupling is implemented from a hardware standpoint, and whether we can replicate that in software.

A GraspIt! DOF is responsible for telling us how all of the joints that are attached to it respond to changes in the DOF. This intelligence is built into the DOF class and its implementations. Depending on how the joint coupling is achieved, DOF behave differently, which is why there are multiple implementations. The most important question is: when one of the joints of a DOF can not move (presumably due to some contact on its links), what happens to the other joints connected to the same DOF?

In dynamics mode, a DOF is also responsible for enforcing the same mode of operation. This is done via “DOF constraints” which must be built into the LCP solved by the dynamics engine. For instance, a rigidly coupled DOF must ensure that all of its joints always move at the same rate. Finally, the DOF is also responsible for applying forces to its joints (which then pass them on to the links) in dynamics mode. This is the only way of moving a Robot in dynamics. Force generation capabilities also depend on the implementation of the DOF, see the classes described below for details.

Rigid coupling¶

The simplest type of coupling is rigid, implemented in practice through gear transmission of steel cables. This means that whenever one joint from a DOF stops moving, all the other joints from the same DOF stop as well. In code, this is implemented in the RigidDOF class. Most hands in GraspIt! use this kind of underactuation (Robonaut, DLR, the 16 DOF version of the HumanHand). See the RigidDOF class for details.

Breakaway transmission¶

This kind of coupling allows a distal joint to “break away” and continue to close if a proximal link has been stopped. The break away point is marked, and the proximal joint is only re-engaged if the DOF goes back to the break away point. This is the type of transmission built into the Barrett hand. In code, this is the BreakAwayDOF, see this class for details.

Under development: compliant joints¶

This is the transmission achieved in practice through tendon networks and compliant (spring-like) joints. It is more difficult to simulate that the BreakawayDOF, as stopped joints are always connected to the DOF. In the code, this is the CompliantDOF. However, this is still an active area of research for us, and this kind of DOF has proven difficult to simulate in static mode.

For the compliant DOF we have also built a mechanism for hand quasistatic analysis. This mechanism exists for any kind of DOF, but is only relevant for the compliant one: due to its nature, the Compliant DOF will apply some unbalanced forces through existing contacts during the hand closing process. The Compliant DOF is thus responsible for computing these forces, which are then passed on to the quasi-static computation. This computation is then performed by the Grasp class; also see the chapter for details. A complete description of this engine and its applications can be found in the chapter.