Difference between revisions of "2013 Summer Project Week:ProstateBRP"

From NAMIC Wiki
Jump to: navigation, search
Line 33: Line 33:
 
***Navigation software can assume that the robot can handle the message exchange protocol only after getting acknowledgement message.
 
***Navigation software can assume that the robot can handle the message exchange protocol only after getting acknowledgement message.
 
**Need a message format specialized for for sending command?
 
**Need a message format specialized for for sending command?
*�**Only missing feature we need is unique ID for query.
+
**Only missing feature we need is unique ID for query.
 
***Changing device name is a good solution.
 
***Changing device name is a good solution.
 
***Changing device name is actually ideal solution for Slicer, because when it receives messages with different name, it will create new MRML nodes and can make sure that it will not be overwritten.
 
***Changing device name is actually ideal solution for Slicer, because when it receives messages with different name, it will create new MRML nodes and can make sure that it will not be overwritten.

Revision as of 14:45, 21 June 2013

Home < 2013 Summer Project Week:ProstateBRP

Key Investigators

  • WPI: Gregory Fischer, Nirav Patel
  • BWH: Junichi Tokuda, Nobuhiko Hata, Clare Tempany

Objective

  • Define and review the clinical workflow
  • Define QA protocol
  • Test a new OpenIGTLink-based communication protocol for Slicer-Robot integration.

Approach, Plan

Progress

  • Discussion on June 18
    • Greg, Andras, Junichi, Nirav, Csaba, Sebastian
    • Integrate the protocol for BRP and Kuka's lightweight robot?
      • It's not easy but could do per workphase
      • The idea is to define message exchange protocol per workphase. Developer can decide which workhpases is going to be used.
      • Navigation software can assume that the robot can handle the message exchange protocol only after getting acknowledgement message.
    • Need a message format specialized for for sending command?
    • Only missing feature we need is unique ID for query.
      • Changing device name is a good solution.
      • Changing device name is actually ideal solution for Slicer, because when it receives messages with different name, it will create new MRML nodes and can make sure that it will not be overwritten.
      • Device name with unique query ID should be like: "CMD_12345" where "12345" is the unique query ID. The query ID does not have to be a numerical characters.
      • When reply to "CMD_" message, the device name for the reply message should be "ACK_12345"
      • The query ID is used only for queries that requires strict 1-to-1 correspondence between query and reply. For queries that does not require it, we use a device name without ID. For example, querying current position or status does not, because we are always interested in the latest position/device status.

Protocol Definition

ProstateBRP_OpenIGTLink_Communication_June_2013

Delivery Mechanism

The work will be delivered as a 3D Slicer extension. The code is hosted at https://github.com/ProstateBRP/BRPProstateNav

References