[IGSTK-Developers] "Dual sensor tool" + tracker-data-buffering

[Frank Lindseth]

Hi Andinet and Patrick,

Some input regarding a topic that have been discussed:
The generic handling of the NDI trackers and tools, especially "Dual  
sensor tool".
Geir Arne (our tracking expert) have put together some hopefully  
clarifying comments (se below).

A question regarding a topic that have not been discussed (forgotten?):
The buffering of tracking data important for proper synchronization  
with real-time image streams.
The need for this buffering is explained before (e.g. several places  
in "The book", se below),
and it's difficult to see a better timing for it's introduction then  
the current re-factoring?

Regards,
Frank


Generic handling of the NDI trackers and tools, especially "Dual  
sensor tool"
------------------------------------------------------
Our design suggestion for the Tracker and TrackerTool classes are  
based on the latest NDI documents for
the Polaris and Aurora APIs.
- Polaris Application Program Interface Guide (IL-1070101 Rev.4, May  
2007)
- Aurora Application Program Interface Guide (IL-1070114 Rev.1, April  
2007)

For handling of tools these APIs have introduced the Port Handle  
concept.
"The API no longer supports the concept of tool ports, and instead  
assigns each tool a port handle.
Port handles are independant of the physical port numbering. Port  
handles provide greater flexibility than
port numbers and replace port numbers and port letters in most  
commands."

The port handle is assigned by the system for wired tools or  
requested by the application for wireless tools
(API command PHRQ). This makes a consistent handling of the tools  
throughout the API whether they are
wired or wireless. The API docs have a flow chart for port handle  
usage that details the logic for using
port handles.

Tool information can be requested by the PHINF command for the  
specific port handle. This is information
specified in the tool definition file (Manufacturer, Serial number  
etc...) and stored in the tools SROM device
or uploaded to the port handle from the application (for wireless  
tools). If physical port location is needed
this can also be requested by the PHINF command.

Aurora has a tool type called "Dual sensor tool" consisting of two  
5DOF sensors not fixed relative to each other.
In this case two port handles will be assigned by the Aurora system  
one for each channel (0 and 1) and
tool transformations will be reported for both sensors. The PHINF  
command can be used to get the relation
between port handle and physical port-/channel number.

Our opinion is that the Polaris and Aurora APIs enables us to design  
a tracker interface - handling tools
in a generic way whether they are wired/wireless, optical or  
electromagnetic. It also enables us to design
applications that don't need to know the physical port connection for  
a wired tool.



 From the tracker-chapter of "The Book"
-----------------------------------------------------
In a future version of IGSTK, the tracker buffer will store the  
position history for each tool, and
it will be possible to determine where a tool was at any time in the  
past after the instant when the
tracker began tracking the tools. This feature will make it possible  
to replay the positions of the
tools, and more importantly, it will allow for accurate  
synchronization of the tool positions with
video data. For example, if every video frame (generated by a planned  
“video” component for
IGSTK) has a timestamp, it will be possible to search the tracker  
buffer to get the tool positions
that best match the video frame’s timestamp and use those positions  
to update the display.




------------------------------
Frank Lindseth
Research Scientist (PhD)

SINTEF Health Research
Dept. Medical Technology
N-7465 Trondheim, Norway
Location: Olav Kyrres gt. 9, 4th floor, Trondheim

E-mail: Frank.Lindseth at sintef.no
Telephone: +47 928 09 372
Telefax: +47 930 70 800