-
Notifications
You must be signed in to change notification settings - Fork 1
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.
-
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?
-
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 dos (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 group 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 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 >?
-
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 are used for FK and jacobians. 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?
-
How do we handle under actuated tools? Fair amount 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 coupling ratio very small so the actuator barely moves).
XML URDF extension, Json, tools to convert and/or check consistency across file formats.