NaviTrack

Introduction

NaviTrack is a separate library that builds on OpenTracker and adds several modules and nodes. NaviTrack includes a copy of OpenTracker (version 2.0), and improvements in OpenTracker will be merged into NaviTrack after testing. A reference for the modules is given below:

The life of a module

A module is used to group functionality related to one specific device. The module will typically inherit from the NodeFactory and from ThreadModule (if it is to be threaded). The functions in the module will be called in this order:

• Constructor: Datamember initialization
• Init: Called during parsing of the configuration element. Good for initializing the module, specially with respect to attributes set in the configuration element
• createNode: Called during parsing of the nodes. Implementation of creation of nodes and storage of nodes in NodeVectors.
• Start: Called before the start of tracking. Initialization that needs to be done after creation of nodes can be done here
• Run: If it is a threaded module, this is the function that will be run in a thread. It typically has a while(!stop) statement were all the work is done. The data to be set in event attributes are stored in private datamembers and a 'changed' flag is used to tell the module that new dat is available. lock() and unlock() functions should be used to to access mutex semaphores when accessing these variables
• pushEvent: This is called by the main event loop and should be used to set the event attributes and update the nodes observers (call updateObservers(..) on the node

Adding a module

To add a module to NaviTrack, the following steps need to be taken:

• Make header files for module and nodes (sink and source) in the directory include/OpenTracker/input (if it is an input type modue). Use a similar existing module as template. Afer the class definition of the module you need to call the macro OT_MODULE(MyModule)
• Implement the classes with source files in src/input. For a module you typically need to implement the functions meantioned in the previous paragraph, a sink will need an onEventGenerated function and a source will need a pushEvent function. In the module source file you also need to call the macro OT_MODULE_REGISTER_FUNC(MyModule) { OT_MODULE_REGISTRATION_DEFAULT(MyModule, "MyConfig" ); }
• In the file src/misc/SPLModules.cxx - you need to add the macro OT_REGISTER_MODULE(MyModule) to the addSPLModules() function, as well as include the header file
• The source files needs to be added to the SOURCES variable in the CMakeLists.txt file
• In the file share/navitrack.dtd, there are several modification necessary:
  • Add MyConfig? to SPL_ConfigElements
  • Add MySource to SPL_SourceEventNodes
  • Add MySink (if any) to SPL_EventNodes
  • Make an !ELEMENT and !ATTLIST for the config element and node

NDI Module

The NDI module provides an interface to the Aurora and Polaris trackers produced by NDI. This module can be configured by the following statement in the configuration section of the OpenTracker XML file:

where the device is the serial port to which the tracker box is connected. Please note that the user needs read and write access to the serial port. Tracked tools can be defined in the XML file as in this example:

or

if the tool is wired.
A limitation of this module is that the full toolID needs to be known. The easiest way to find this is to connect a tool and omit the toolID. The debug print of the module will indicate which tools were found. This is the case for both Polaris tools and Aurora tools. An Aurora tool is defined the same way as a wired Polaris tool:

The module supports hot-swapping of tools, as long as all tools that will be used are defined in the XML file.

Flashpoint Module

The Flashpoint module provides an interface to the Flashpoint optical tracking system by Image Guided Technologies Inc. The module has been tested on Flashpoint3000 and Flashpoint5000 systems. Configuration is done with the following line:

maxbodies indicate the number of tools that will be tracked. A tool can be defined by:

where 'number' has to be less than or equal to 'maxbodies'. The tool is the name of a toolfile (not including the .too extension) as found in the tools directory of the Flashpoint computer.

Speech Module

Serbutton Module

The Serbutton module is a very simple module that allows a serial port to be used as an interface to up to three buttons. The buttons must be connected like this:

             /---* \ *----CTS
       RTS--|
             \---* \ *----DSR
       DTS-------* \ *----CAR

The module does not need a configuration element. A source is defined like this:

The buttons will be encoded in bit 0 (CTS), 1 (DSR) and 2 (CAR) of the button event attribute.

MedScan Module

The MedScan module provides a bidirectional interface to medical imaging equipment through a library called GIHI. The network library has been developed by the University of Oslo (UiO) to interface with medical image scanners for the purpose of real-time interaction. This library allows plugins to be written for different medical scanners with the following services:

• Images (typically real-time images)
• Commands (to control scanner parameters)
• Tracking (to retrieve information from embedded trackers)

The maintenance of this library is a collaborative effort between UiO and BWH. Detailed information on using this library to interface with an Excite 12.x MRI scanner is given here. GIHI is in the process of being faced out, since OpenTracker 1.3 provides generic event attributes which can be used to provide most of the features that GIHI has. GIHI might prevail as a library to equipment where installation of OpenTracker and its dependencies is not practical. The MedScan module can be configured by:

and a source is defined as:

In this example the 'image' service is selected and an image will be returned in an event attribute called 'image'. The special event attributes are:

• "lr": Coordinates of lower right corner. Type: vector<float>
• "ll": Coordinates of lower right corner. Type: vector<float>
• "ur": Coordinates of lower right corner. Type: vector<float>
• "ul": Coordinates of lower right corner. Type: vector<float>
• "wsid":
• "tblpos": Table position. Type: int
• "patpos": Patient position. Type: int
• "sliceth": Slice thickness. Type: float
• "xdim": Image size in x direction. Type: int
• "ydim": Iimage size in y direction. Type: int
• "image": The image itself. Type: MedScanImage (defined in "Image.h")

The standard attributes (position and orientation) are populated with the position of the lower left corner and the orientation of the image.
A MedScanSink can be used to control the scan plane of an MRI scanner (or other devices that can take such input). It can be defined as:

The sink accepts standard tracking data.

Terason Module

The Terason module provides an interface to acquire images from the Terason ultrasound system. The module requires the Terason SDK to be installed. This in only available on Microsoft Windows, and the module can thus only be used on Windows. The module is configured by:

and a source is defined with:

The event attributes are:

• "xdim": Image size in x direction (hardcoded to 640). Type: int
• "ydim": Image size in x direction (hardcoded to 480). Type: int
• "image": The image itself. Type: MedScanImage (defined in "Image.h")

This module is only moderately tested, and as we no longer have an Terason system, contribution from others is highly welcomed.

EndoScout Module

The EndoScout module provides an interface to tracking data from the MRI tracking system by Robin Medical. The module uses the recent IP interface from Robin. It is configured by:

and the tool:

Currently the module supports only one tracker, but will soon be extended to support two. More trackers are not supported by the hardware.