Tracker Requirements

From IGSTK

Contents 1 Purpose of Tracker Class 2 Use of the Tracker Class 3 Requirements of the Tracker Class 4 Proposed or Future Requirements of the Tracker Class

Purpose of Tracker Class

The tracker class is the superclass for classes that talk to tracking devices. It defines the interface through which other IGSTK classes get tracking information, while its subclasses do the actual work of sending commands to the tracking device and decoding the data records that are sent back.

Use of the Tracker Class

The Tracker objects are instantiated, initialized, and controlled by the application. The application is also responsible for connecting a Communication object to the Tracker object.

SpatialObjects can be connected to a Tracker object, and will receive transformations from the Tracker object.

Requirements of the Tracker Class

[DG: Perhaps these should directly reflect the requirements listed in the bug tracker? The requirements listed below read more like a class design.]

The Tracker class should:

• 1. be derived from itkObject

• 2. have a SetLogger() method

• 3. have an Open() method, which will result in an attept to open communication with the tracking device

• 4. have a Close() method, for closing communication with the device

• 5. have an Initialize() method, for initializing a newly-opened device

• 6. have a Reset() method, for forcing the device to known but uninitialized state

• 7. have a StartTracking() method for requesting a transition to a tracking state

• 8. have a StopTracking() method for requesting a transition to a non-tracking state

• 9. have an UpdateStatus() method for updating the status according to information received from the tracking device.

• 10. have a GetToolTransform() method for getting the transform for a tracker tool

• 11. have an AttachObjectToTrackerTool() method for attaching spatial objects to the Tracker

• 12. have a SetReferenceTool() method to indicate that a particular tool is to be used as a reference, and that other tools should be tracked relative to this tool

• 13. have a SetPatientTransform() method to set an itkTransform object that will be used to convert from the tracker's native coordinate system to the desired patient coordinate system

• 14. have a SetToolCalibrationTransform() method to set an igstkTransform object for a particular tool that will be prepended to each Transform received for that specific tool (its purpose it to calibrate the geometry of a physical tool with respect to markers or magnetic receiver that the tracking device is actually tracking)

• 15. have a state machine that is private and invisible to any subclasses

• 16. have an internal interface consisting of protected virtual methods that defines an interface for subclasses

• 17. not have virtual public interface methods, since the public interface cannot be overridden by the subclasses because the public interface methods are what drives the internal state machine

• 18. create a separate thread for tracking when in the tracking state

• 19. provide support for tool buttons and foot pedals, so that these can be used to drive actions in the application

• 20. inform the application of which tools are available via events which carry information that allows the application to identify the tool and tool type

• 21. inform the application via an event when a tool goes offline due to the tool becoming unplugged or malfunctioning

The following changes were new for Iteration 5:

• the Open(), SetReferenceTool(), SetPatientTransform(), and SetToolCalibrationTransform() methods are new

• the SetCommunication() method has been removed, although derived classes should have a SetCommunication method whenever possible

• the state machine in Iteration 4 was not fully private

• the base class for Iteration 4 did not provide a protected interface for its subclasses, the derived classes use the same public interface as the base class

The following changes are new for Iteration 6:

• the use of a separate thread for communicating with the device while in the tracking state

The following changes are new for Iteration 7:

• generation of events for foot pedals or tool buttons

• generation of events when tools come online or go offline

Proposed or Future Requirements of the Tracker Class

• tracker communication should be done with binary string objects, not with char arrays, in the interest of making the code safer