2014 Summer Project Week:Robot Control With OpenIGTLink

• 

  Projects List

Key Investigators

• Greg Fischer (WPI)
• Nirav Patel (WPI)
• Junichi Tokuda (BWH/SPL)
• Andras Lasso (PerkLab, Queen's)

Project Description

• This Project is to further develop a workflow and communication protocol for interfacing robots with image-guided therapy systems using OpenIGTLink.
• Also, we would like to enhance JAVA implementation of IGTLink and support more message types.

Objective

• Some of the supported standard messages in OpenIGTLink for JAVA are Position, Status, String and Transform. During this week we would like to add support for other message types like NDArray, Sensor and any other useful messages for controlling the robot using IGTLink.
• Also, would like to collaborate with team working on MATLAB interface for IGTLink and test it with JAVA implementation.

Approach, Plan

• Taking BRP Robot Application as base and extending it for any other robot applications.
• Testing it for MATLAB and standard C++ implementation.

Progress

• We have tested IGTLink communication with the clinical workflow described at http://www.na-mic.org/Wiki/index.php/ProstateBRP_OpenIGTLink_Communication_June_2013 which was implemented during 2013 Summer Project Week.
• NDArray is being implemented but not yet tested.
• Sensor message yet to be implemented.

OpenIGTLink XML command specification

• Command message:
  • Type: STRING
  • Device name: CMD_uid
    • The _uid part is optional, it's for matching requests and responses. The uid is a unique string to identify the request, such as a counter or timestamp.)
  • Content: Command XML element
    • Name attribute contains the command name
    • Any number of additional attributes and/or child elements to specify further parameters for the command can be added.
• Command response message:
  • Type: STRING
  • Device name: ACK_uid
    • uid matches the uid in the command message's device name
  • Content: CommandReply XML element
    • Status attribute containing the status of the command; allowed values: SUCCESS or FAIL
    • Message attribute containing a human-readable status of the command completion
    • Any number of additional attributes and/or child elements to specify further return values can be added.
  • Example command and response content:
    • Command: <Command Name="SomeCommandName" SomeAttribute1="attribute value 1" SomeAttribute2="123" />
      • Should we specify type of the attribute??
      • Should we specify that this is a read/write request??
    • Response: <CommandReply Status="SUCCESS" SomeReturnValue1="123" SomeReturnValue1="abc" />