Grippers

Robot arms typically have end-effectors which can grasp things. Grippers are troublesome when designing a toolbox for arms as they are part of the robot but typically not part of the arm which is actively controlled unless picking or placing. Additionally, grippers can't be expressed with DH notation but can be with ETS or URDF notation.

How it works

A rigid-body tree (ERobot class) can carry one or more Gripper objects (roboticstoolbox/robot/Gripper.py), exposed as the robot.grippers list — one entry per gripper, since a branched robot can have more than one (e.g. a dual-arm robot). The links that make up each gripper (e.g. the fingers) are held inside its Gripper object rather than the robot's main link tree, so robot.grippers[i] is a named end-effector: it can be used to compute FK, and has its own .tool transform (the pose of the gripper's grasp point relative to its base link).

Conceptually, a model like

L1--L2--L3--L4--HAND+-F1
                    |
                    +-F2

where F1/F2 are finger links, is represented as

L1--L2--L3--L4--GRIPPER1

GRIPPER1 contains F1, F2

Real examples in the shipped URDF models: Frankie/FrankieOmni (self.grippers[0].tool = SE3(0, 0, 0.1034)) and Fetch (for link in robot.grippers[0].links: ...).

Open question

Attaching an existing gripper model (or other end-effector subtree) from one robot model onto a different robot model — e.g. bolting a UR gripper onto a Panda after the fact — isn't a documented or ergonomic workflow today; Gripper objects are built as part of a model's own __init__. Tracked as issue #677.