Tool Changing
Many applications require swapping grippers or tools during execution. This document describes our recommended approach to implement these type of applications.
An example showing it put into practice is available in the fanuc_sim
robot configuration in the moveit_pro_example_ws
workspace:
- Run
Setup Planning Scene
to populate the initial knowledge of tool location. - Run
Tool Attachment Example
to perform tool attachment and docking.
Robot modeling
Our recommended approach is to have robot URDFs and tool URDFs in separate files, for instance:
- user_workspace
- description
- robot.urdf
- one_tool.urdf
- another_tool.urdf
The SRDF and other robot configuration files should not include any gripper-specific groups or links either. Tool-specific information should go into the tool URDFs, therefore fully decoupling robot and tool description files.
Runtime tool attachments
The general approach when attaching a new tool to a robot arm is:
- Move the arm tip to mate the tool at the tool holder.
- Execute the mechanism that physically attaches the tool to the arm. This is highly dependent on your tool changing hardware. It may be passively activated by arm motion, or require activating an IO signal, etc.
- Bring up tool-specific hardware interfaces (e.g. establish communication channels) and controllers.
- Execute the mechanism that physically detaches the tool from the tool holder. This could also be passive or require electrical activation.
- Update the internal collision model representation to include the new tool.
Detaching a tool would be similar, but in reverse order:
- Move the arm with the attached tool to dock into the tool holder.
- Trigger the mechanism that attaches the tool to the tool holder.
- Bring down tool-specific hardware interfaces and controllers so that those resources are available for other tools.
- Trigger the mechanism that detaches the tool from the arm.
- Update the internal collision model to not include the tool.
Steps 2 to 4 are highly dependent on the specific tool changing hardware and may even require dedicated controllers. MoveIt Pro implements mechanisms to achieve those steps in simulation (see section below), but it is up to the user to implement them for their specific hardware.
Step 5 (update the internal collision model) can be achieved with the AttachTool
and DetachTool
Behaviors:
-
AttachTool
expands the robot model with a tool, so that it can be used for collision checking and path planning. The tool is attached to the robot at a given link. Once attached to the robot, the tool will move with the link it is attached to. If the tool contains joints and those joints are reported in the/joint_states
topic, the tool collision shapes will update their state accordingly. -
DetachTool
removes a previously attached tool from the robot model. Once detached, the tool collision shapes will no longer be part of the robot model.
AttachTool
requires the tool to exist in the 'Planning Scene' beforehand, which can be done with the AddToolToPlanningScene
Behavior.
The tool is given as a URDF file, which describes the kinematics and collision geometry.
Calling AttachTool
basically updates the parent link of the tool to be a robot link, instead of the static 'world' frame.
Calling DetachTool
sets the parent link of the tool back to the 'world' frame, so it won't move with the robot anymore.
The tool will still exist in the 'Planning Scene' after DetachTool
is called.
This is to prevent collision with it on subsequent motion planning requests, for instance if the tool is docked in a tool holder.
To remove the tool permanently from the 'Planning Scene', the RemoveToolFromPlanningScene
Behavior can be called.
It is important to call AttachTool
and DetachTool
right after physically attaching or detaching a tool to prevent potential collisions or misleading planning failures.