Tool definition

For medical robots like the Raven or the da Vinci, the last part of the kinematic chain is a removable tool. Since there are many different types of tools available, robot controllers should be able to load the tool definition at runtime.

Data

• Tool name or type (model number) [required]

• Tool unique identifier (serial number) [optional]

• Number of actuators required to control the tool (including gripper if any) [required]

• Coupling matrix to convert actuator positions to joint values (including gripper if any). A single matrix should be sufficient, the transpose can be used to determine effort coupling. A diagonal matrix can be used for gear ratios. [optional]

• Joint parameters:

  • Names [required]
  • Position limits [required]
  • Velocity limits [optional]
  • Effort limits [optional]
  • PID gains [optional]

• Kinematic information [required], either:

  • Parameters: DH, DH modified, Hayati. Which ones do we want to support?
  • Flag to indicate if generic methods can be used to compute FK, Jacobian, IK...
  • Service or module that will provide forward and inverse kinematics as well as jacobians

• Type of gripper [required]:

  • None
  • Continous/discrete?
  • Joint position/velocity/effort limit for continuous

• Cauterization?

  • Mono
  • Bipolar

• Engage parameters?

  • Joint position or effort limits
  • Method to engage? None, position or effort based?

Questions:

End effector

Should we separate the end effector from the kinematic chain, i.e. treat the gripper as a "third" robot attached at the end of < arm + tool >. The dVRK started with a single data structure/joint API for < arm_3dof + tool_3dof + jaw >. When adding the 5 mm tools, dVRK needed to handle the 7 actuators differently because the tool actually has 8 dofs (under actuated with some equality constraints, see below). Currently we have:

• Lowest level IO converts actuators to joints so we can control efforts on joints
• PID has 7 active joints
• Arm class breaks the 7 joints into groups of joints for kinematics and joint(s) for end effector
  • From the user API, two sets of commands, one to drive the kinematic joints (either in cartesian or joint space) and one for the end effector so dVRK now has < arm_3dof + tool_3dof > and < jaw >. For 5mm tools the API exposes < arm_3dof + tool_5dof > and < jaw >.
  • Also from API, size of jacobian now matches size of joints for kinematics
  • To note, RViz allows to create kinematic chains with joint values published by different topics so this works without hack
  • In future dVRK implementation, hope to be able to control jaw and kinematic differently (i.e. position vs. effort)
• To support ISI tools, there's about two types of wrists and multiple end effectors so that should allow to factor a lot of configuration code.
• Open question: end effector is not just a joint for da Vinci, it also has a constant cartesian transform that defines the control point used for tele-operation. Should this be added to the reported < arm + tool > kinematic or should we add a separate kinematic layer for < arm + tool + end_effector >?

Tools with "virtual" joints (kinematic constraints)

Separation of kinematic chain and tool effector was required for the dVRK to support 5mm/snake like tools (https://www.intuitivesurgical.com/products/instruments/images/5mm_Maryland_Dissector.jpg). These tools have 5 joints in the wrist but only 3 actuators. Parameters provided by ISI lead to the following mapping:

• Actuator to PID joints: < a3, a4, a5 > to < roll, pitch, yaw > (note, < a0, a1, a2 > are used for the "arm", < a6 > for the jaws)
• PID joints to kinematic joints: < roll, pitch, yaw > to < roll, pitch/2, yaw/2, yaw/2, pitch/2 >. Kinematics joints <q0, ..., q7> are used for FK and jacobians ( is for gripper). User API (ROS topics) show joint state with 8 values (position, velocity, effort). See https://github.com/jhu-dvrk/sawIntuitiveResearchKit/blob/devel/components/code/mtsIntuitiveResearchKitPSM.cpp#L233
• IK requires a constraint to enforce that q4 == q7 and q5 == q6. See https://github.com/jhu-dvrk/sawIntuitiveResearchKit/blob/devel/components/code/mtsIntuitiveResearchKitPSM.cpp#L306 and https://github.com/jhu-dvrk/sawIntuitiveResearchKit/blob/devel/components/code/robManipulatorPSMSnake.cpp#L24.
• Current dVRK implementation has a hard coded flag to indicate if the tools are 5mm/snake-like. Can/should we have a generic implementation with another coupling matrix and joint names mapping?
  • Would it be necessary to distinguish between actuators, PID (control) joints, and kinematics joints?
  • Would this approach also help with kinematics/visualization of parallelogram structures?

Under actuated tools

How do we handle under actuated tools? A fair number of dVRK users develop 5 DOF tools and for now trick the system by creating a dummy joint/link so that the IK can find a solution, then drive an actuator that is not connected to anything (using a very small coupling ratio so the actuator barely moves).

Deliverable

Should we set a deliverable goal to drive this development, e.g. given two tool definition files (8mm PSM and 5mm PSM), have working tele-op demo of dVRK PSM (JHU), Raven (UW) and Gazebo/RViz (WPI)? JHU has tested RViz but model of wrist joints are crude for 5mm tools.

Format

XML URDF extension, Json, tools to convert and/or check consistency across file formats.