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.
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.
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
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
also see the chapter for details. A complete description of this engine
and its applications can be found in the chapter.