Difference between revisions of "OpenIGTLink/ProtocolV2/Type/QTrackingData"

From NAMIC Wiki
Jump to: navigation, search
(Created page with ' << Version 2 Draft Page =Summary= The QTDATA message type is intended for transferring 3D positions of surgical tools, markers etc. Its …')
 
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
[[OpenIGTLink/ProtocolV2/Draft | &lt;&lt; Version 2 Draft Page]]
+
[[OpenIGTLink/ProtocolV2/Index | &lt;&lt; Version 2 Index Page]]
  
 
=Summary=
 
=Summary=
Line 15: Line 15:
 
|-
 
|-
 
| align="left" | NAME_1
 
| align="left" | NAME_1
−
| align="left" | char[20]
+
| align="left" | char[32]
 
| align="left" | Name (=Id) of the instrument/tracker
 
| align="left" | Name (=Id) of the instrument/tracker
 
|-
 
|-
Line 32: Line 32:
 
| align="left" | QUATERNION_1
 
| align="left" | QUATERNION_1
 
| align="left" | float32[4]
 
| align="left" | float32[4]
−
| align="left" | Quaternion
+
| align="left" | Quaternion (QX, QY, QZ, W)
 
|-
 
|-
 
| colspan=3 align="center" style="background:#f0f0f0;" | ...
 
| colspan=3 align="center" style="background:#f0f0f0;" | ...
 
|-
 
|-
 
| align="left" | NAME_N
 
| align="left" | NAME_N
−
| align="left" | char[20]
+
| align="left" | char[32]
 
| align="left" | Name (=Id) of the instrument/tracker
 
| align="left" | Name (=Id) of the instrument/tracker
 
|-
 
|-
Line 54: Line 54:
 
| align="left" | QUATERNION_N
 
| align="left" | QUATERNION_N
 
| align="left" | float32[4]
 
| align="left" | float32[4]
−
| align="left" | Quaternion
+
| align="left" | Quaternion (QX, QY, QZ, W)
 
|-
 
|-
 
|}
 
|}
  
−
==GET_TDATA==
+
<font color="red">Feb 2, 2011: The length of the coordinate system field was corrected. (It should be the same as TDATA.) </font>
 +
 
 +
==GET_QTDATA==
  
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
Line 68: Line 70:
 
|}
 
|}
  
−
 
+
==STT_QTDATA==
−
==STT_TDATA==
 
  
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
Line 82: Line 83:
 
|-
 
|-
 
| align="left" | Coordinate system name
 
| align="left" | Coordinate system name
−
| align="left" | char[20]
+
| align="left" | char[32]
 
| align="left" | Coordinate system to use. Can be empty for default coordinate system. (not included if action = 2)
 
| align="left" | Coordinate system to use. Can be empty for default coordinate system. (not included if action = 2)
 
|-
 
|-
 
|}
 
|}
  
−
* All tracking data from one frame is included.
+
==STP_QTDATA==
−
* Invisible/unavailable trackers/instruments are not included.
 
−
* Easy to develop. Sample pseudo code: '''while(true) { recv(trackingdata); updateView(trackingdata); }'''
 
−
*Usually the tracking data will be sent using the standard coordinate system, which is also used for POINT, IMAGE, ... But this does only work after patient registration. Therefore the body of START_PUSH has an optional field for specifing the coordinate system "CAMERA". To switch back to the standard coordinate system, one has to send STOP_PUSH and afterwards START_PUSH without explicitly specifing the camera coordinate system.
 
  
 +
{| border="1" cellpadding="5" cellspacing="0" align="center"
 +
|-
 +
| align="left style="background:#e0e0e0;" | Data
 +
| align="left style="background:#e0e0e0;" | Type
 +
| align="left style="background:#e0e0e0;" | Description
 +
|-
 +
|}
  
−
==STP_TDATA==
+
==RTS_QTDATA==
  
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
Line 100: Line 105:
 
| align="left style="background:#e0e0e0;" | Type
 
| align="left style="background:#e0e0e0;" | Type
 
| align="left style="background:#e0e0e0;" | Description
 
| align="left style="background:#e0e0e0;" | Description
 +
|-
 +
| align="left" | Status
 +
| align="left" | 8 bit unsigned
 +
| align="left" | 0: Success 1: Error
 
|-
 
|-
 
|}
 
|}
−
 
−
==RTS_TDATA==
 
−
 
  
 
=Implementations=
 
=Implementations=
−
The TDATA message type is implemented in the following source code.
 
−
*[http://svn.na-mic.org/NAMICSandBox/trunk/OpenIGTLink/Source/igtlTrackingDataMessage.h igtlTrackingDataMessage.h]
 
−
*[http://svn.na-mic.org/NAMICSandBox/trunk/OpenIGTLink/Source/igtlTrackingDataMessage.cxx igtlTrackingDataMessage.cxx]
 
  
 
=Contributors=
 
=Contributors=
Line 116: Line 119:
 
=Comments=
 
=Comments=
  
−
''Junichi'':
+
See [[OpenIGTLink/ProtocolV2/Type/TrackingData]].
−
*How about adding 8- or 16-bit status field in TDATA? This will allow us to indicate that coordinate system is not registered. I would like to keep START_PUSH message simple....
 
−
 
 
−
''Alexander'':
 
−
*What status types can be specified?
 
−
*In the case the coordinate system is not valid, a STATUS message should be returned.
 
−
*Well, I understand that you would like to keep it as simple as possible. We really like to specifiy the coordinate system like "Camera" or "Patient". We could also specifiy a SET_COORD message, but I think this would be overkill. I still vote for a data specific argument field in START_PUSH. Maybe other future data types can also use this field?
 
−
*Due to consistency, I think we should add this field to STOP_PUSH, too.
 
−
*We would like to allow only one TDATA push for each client at a time, so a second START_PUSH will stop the first and start the second. A STOP_PUSH will stop the push regardless of the arguments in the body. What do you think about that?
 
−
 
 
−
''Junichi'':
 
−
* I haven't defined status types... it can be a bit array like: bit 0: registered or not; bit 1: line-of-site error; ....
 
−
** Do you think it is useful? if not, we can omit it.
 
−
* I agree that we need a way to specify coordinate system. It's good idea to have data specific field in the START_PUSH.
 
−
* I agree with the last comment. I would say one TDATA push for each device name, because multiple data sources may exist. The coordinate system can be overwritten by another START_PUSH message with the same device name and type.
 
−
 
 
−
''Alexander'':
 
−
* I think we don't need the status type. But maybe we define a TDATA in v3 after collecting some feedback from different users. I could think about other fields like diameter of instruments, etc. But for now I would like to keep TDATA as simple as possible.
 
−
* Ok, starting another trackingdata push with the same device name will implictly stop the first one. But if another device name is used, a second push will be started.
 

Latest revision as of 04:43, 30 November 2011

Home < OpenIGTLink < ProtocolV2 < Type < QTrackingData

<< Version 2 Index Page

Summary

The QTDATA message type is intended for transferring 3D positions of surgical tools, markers etc. Its role is almost identical to TDATA, except that QTDATA describes orientation by using quaternion.

Message Types

QTDATA

Data Type Description
NAME_1 char[32] Name (=Id) of the instrument/tracker
TYPE_1 8 bit unsigned 1: tracker, 2: 6D instrument (regular instrument), 3: 3D instrument (only tip of the instrument defined), 4: 5D instrument (tip and handle are defined, but not the normal vector)
-- 8 bit unsigned Reserved
POSITION_1 float32[3] (X, Y, Z)
QUATERNION_1 float32[4] Quaternion (QX, QY, QZ, W)
...
NAME_N char[32] Name (=Id) of the instrument/tracker
TYPE_N 8 bit unsigned 1: tracker, 2: 6D instrument (regular instrument), 3: 3D instrument (only tip of the instrument defined), 4: 5D instrument (tip and handle are defined, but not the normal vector)
-- 8 bit unsigned Reserved
POSITION_N float32[3] (X, Y, Z)
QUATERNION_N float32[4] Quaternion (QX, QY, QZ, W)

Feb 2, 2011: The length of the coordinate system field was corrected. (It should be the same as TDATA.)

GET_QTDATA

Data Type Description

STT_QTDATA

Data Type Description
Resolution 32 bit unsigned Minimum time between two frames. Use 0 for as fast as possible. If e.g. 50 ms is specified, the maximum update rate will be 20 Hz.
Coordinate system name char[32] Coordinate system to use. Can be empty for default coordinate system. (not included if action = 2)

STP_QTDATA

Data Type Description

RTS_QTDATA

Data Type Description
Status 8 bit unsigned 0: Success 1: Error

Implementations

Contributors

Alexander Schaal

Comments

See OpenIGTLink/ProtocolV2/Type/TrackingData.

Retrieved from "https://www.na-mic.org/w/index.php?title=OpenIGTLink/ProtocolV2/Type/QTrackingData&oldid=72184"