Draft Specification

From ITPWiki

Jump to: navigation, search
DRAFT Specification:  Interoperable Telesurgery Protocol (ITP)

      Blake Hannaford, U of Washington
      Tom Low, SRI International

Version 0.3        9-Feb-2007       //  Initial Draft for Technical Comments
Version 0.41      13-Mar-2007       //  Synthesis of SRI and BRL inputs to V0.3
Version 0.42      3-July-2008       //  Incorporation of SRI and BRL inputs
Version 0.43      8-July-2008       //  Debugging associated .h file.
Version 0.44      12-May-2009       //  Imported to ITP Wiki

The following specification defines internet-based digital communication between a user interface system (master, "surgeon site"), and surgical robot system (slave,"patient site") to enable effective control suitable for surgical tasks.   The specification is aimed at teleoperation in which slave robot hands directly follow surgeon's hand motions.

Enhancements to the specification to support advanced functions such as force feedback and limited automation are described.

1.   Coordinate Systems

   1.1  Translation and rotation coordinate systems

      A common right-handed coordinate system is used to describe rotation and translation commands.   The three axes are defined with  respect to the surgeon's head are:

          X   Horizontal,  + = facing away from surgeon
          Y   Horizontal,  + = surgeon's Right.
          Z   Vertical,    + = surgeon's Down.

          Roll      X axis   + = Right Hand Rule (RHR)
          Pitch     Y axis   + =  RHR
          Yaw       Z axis   + =  RHR

   1.2   Rotation Order:

      The order in which Roll, Pitch, and Yaw angles are applied must follow one of the two equivalent schemes:

        Either:
          *   Roll, Pitch, Yaw about FIXED axes
        or
          *   Yaw, Pitch, Roll about BODY ROTATED axes.

2.   Master --> Slave Direction

   2.1   Transmission Format

      The protocol uses UDP packets, or TCP packets depending on the packet type. (UDP packets are not guaranteed to be received, so for vital packets use TCP.)

      The TCP/IP ports for this protocol are:

         Master -->  Slave             port 36000
         Slave  -->  Master            port 36001  (future)

      Packet sending rate is not specified by this protocol. 

      Data in the packets may be binary, ascii or other format.  The data format must be specified in the packet type description.  (see packet types below)  Packet type 1, Raven teleoperation packet, uses binary transmission specified in R7teleoperation.h.

      Byte order (endian-ness), and variable type-sizes will be determined by the Intel/IBM PC-standard.
     
   2.2  Clutching / Indexing

      Clutching/indexing is the process allowing the operator to reposition their hands without causing slave manipulator motion.   In packet type 1 this state is indicated in the surgon_mode field of the packet:

        "SURGEON_ENGAGED"       1
        "SURGEON_DISENGAGED"    0

      When the surgeon_mode value of the packet indicates SURGEON_DISENGAGED:

         Position:    Master will continue transmission during handle repositioning. Position increments will be ignored by slave.

         Orientation:   Master will continue transmission during handle repositioning, orientation increments will be ignored by slave.

                      ISSUE:   Need to resynch handle vs tool orientation after index. Cannot truly index RPY parameters.

         Grasping:    Grasp state should freeze during pedal up (either open, closed or current % torque)

   2.3  Units

         Translation:    Integer microns

         Rotation:       Integer micro-radians.

         Grasp:          Absolute, Integer relative torque (+ = grasp, - = open).

   2.4  Packet Sequencing

         Each packet contains an unsigned sequence number.

         Out of sequence packets are ignored.    To determine out of sequence:

            Subtract seq num of last accepted packet from seq num of current packet.  
            If delta > 1/2 max unsigned int, then detect "rollover" and accept the packet.
            else if delta > 1, reject packet.

        If no packets are received by slave after (SLAVE_COM_TIMEOUT) seconds,  slave enters "SURGEON_DISENGAGED" state.    Slave will not re-enter "SURGEON_ENGAGED" until it sees the sequence "SURGEON_ENGAGED" -> "SURGEON_DISENGAGED" -> "SURGEON_ENGAGED".

   2.5   Packet Types

        The packet will contain an unsigned integer "pactyp", representing the kind of packet in use. 
        The packet types defined at this time include:
                    1             Incremental Motion command Master->Slave
                    2             Absolute Motion command Master->Slave
                    3             Force and joint-limit feedback packet Slave->Master

	The packet will also contain an unsigned integer "version" which represents the version of this document and the R7teleoperation.h file in use.    The version number may contain a decimal (such as 1.27).  To represent this the ``floating point" version number will be obtained by dividing the "version" field by 100. 

   2.6   Packet Type Numbering and Extensibility

        The value of the packet type field will be divided into ranges to support independent development of different features by different groups.  The protocol numbering ranges will be allocated as follows:

         1-127         Common Packets supported by all slaves and masters
       128-255         UW-specific packets
       256-383         SRI-specific packets
       384-            reserved for future participants

        Multiple packet types may be sent in a single working software version.   For example, an implementation may send incremental motion (type "1") packets interspersed with other packet types for more advanced or autonomous functions.

        Software which receives packets (slave or master) shall be free to choose their own policies for what to do with received packet types that they do not support.

        Common packet types will not be adopted unless all participants agree to support them.   Packet types which support features unilaterally developed by a group should be numbered within the value range belonging to that group.


3.   Future enhancements

      The following packet types or features are contemplated for future development of this protocol.

        1)  Initialization packets.   master hardware identification (M-> S). Slave Hardware identification (S->M).

        2)  Make sure orientation mapping is persistent across indexing events.

        3)  Track / log rejected out of sequence packets and sequence number rollovers.

        4)  Slave --> Master  Communication pathway to support following features:
             - <now packet type 3> Kinesthetic force feedback
             - <now packet type 3> Feedback of joint limits
             - Feedback of kinematic singularities, and motion constraints.
             - <now packet type 3> Feedback of slave state (E-stop/Run/etc).
             - low-rate updates of info like slave side air temperature, motor temperatures, etc.

        5) Network characterization requires a "reflected packet" type- send this packet immediately back to the sender so that round-trip time and other network characteristics may be measured.
    
        6) Implement quaternians for orientation.
    
        7) Typdefs- define types for portability across computing platforms.

Personal tools