Difference between revisions of "OpenIGTLink/ProtocolV2/Type/SensorData"
From NAMIC Wiki
(→TDATA) |
|||
| Line 163: | Line 163: | ||
| align="left style="background:#e0e0e0;" | Type | | align="left style="background:#e0e0e0;" | Type | ||
| align="left style="background:#e0e0e0;" | Description | | align="left style="background:#e0e0e0;" | Description | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
|- | |- | ||
|} | |} | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==STP_TDATA== | ==STP_TDATA== | ||
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.
