Difference between revisions of "OpenIGTLink/ProtocolV2/Type/SensorData"
Line 181: | Line 181: | ||
=Implementations= | =Implementations= | ||
The TDATA message type is implemented in the following source code. | 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.h igtlTrackingDataMessage.h] | ||
*[http://svn.na-mic.org/NAMICSandBox/trunk/OpenIGTLink/Source/igtlTrackingDataMessage.cxx igtlTrackingDataMessage.cxx] | *[http://svn.na-mic.org/NAMICSandBox/trunk/OpenIGTLink/Source/igtlTrackingDataMessage.cxx igtlTrackingDataMessage.cxx] | ||
+ | --> | ||
=Contributors= | =Contributors= |
Revision as of 04:14, 14 July 2010
Home < OpenIGTLink < ProtocolV2 < Type < SensorDataContents
Summary
SDATA is a message type, which is used to transfer sensor reading, 3-axis position, velocity, acceleration, angle, angle velocity and angle acceleration. The message format is intended for manipulator control and various types of sensors.
Message Types
TDATA
Data | Type | Description |
NSENSOR | UINT16 | Number of sensors |
FORMAT | UINT16 |
Bit 1: Name flag |
SENSOR1 | ||
(NAME) | UINT8[20] | Sensor name |
(ARB1) | FLOAT32 | Arbitrary value 1 |
(ARB2) | FLOAT32 | Arbitrary value 2 |
(ARB3) | FLOAT32 | Arbitrary value 3 |
(ARB4) | FLOAT32 | Arbitrary value 4 |
(POSITION) | FLOAT32[3] | Position (m) |
(VEL) | FLOAT32[3] | Velocity (m/s) |
(ACCEL) | FLOAT32[3] | Acceleration (m/s^2) |
(FORCE) | FLOAT32[3] | Force (N) |
(ANG) | FLOAT32[3] | Angle (rad) |
(ANGVEL) | FLOAT32[3] | Angular velocity (rad/s) |
(ANGVEL) | FLOAT32[3] | Angular accelearation (rad/s^2) |
(TORQUE) | FLOAT32[3] | Torque (N*m) |
... | ||
SENSOR_N | ||
(NAME) | UINT8[20] | Sensor name |
(ARB1) | FLOAT32 | Arbitrary value 1 |
(ARB2) | FLOAT32 | Arbitrary value 2 |
(ARB3) | FLOAT32 | Arbitrary value 3 |
(ARB4) | FLOAT32 | Arbitrary value 4 |
(POSITION) | FLOAT32[3] | Position (m) |
(VEL) | FLOAT32[3] | Velocity (m/s) |
(ACCEL) | FLOAT32[3] | Acceleration (m/s^2) |
(FORCE) | FLOAT32[3] | Force (N) |
(ANG) | FLOAT32[3] | Angle (rad) |
(ANGVEL) | FLOAT32[3] | Angular velocity (rad/s) |
(ANGVEL) | FLOAT32[3] | Angular accelearation (rad/s^2) |
(TORQUE) | FLOAT32[3] | Torque (N*m) |
GET_TDATA
Data | Type | Description |
STT_TDATA
Data | Type | Description |
STP_TDATA
Data | Type | Description |
RTS_TDATA
Implementations
The TDATA message type is implemented in the following source code.
Contributors
Alexander Schaal
Comments
Junichi:
- 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.