Talk:Tracker interface changes
From IGSTK
Contents |
Comments
New way of accessing tracker tools
I agree with the suggested mechanism for managing tracker tools:
- Tracker tools are instantiated by the application developer
- The tracker tool parameters are set by the developer
- The tracker tool is finally attached to the Tracker object
The examples for the Aurora and Polaris match well the coding style of IGSTK, both in terms of assigning responsibilities to objects and in terms of driving the components with the state machine.
- The new set of states for the TrackerTool makes sense. It is a bit unclear, however, what inputs will trigger the transitions between states, and who will provide those inputs. Presumably some of them will be triggered by the Tracker (e.g. to Visible).
Suggestion: whenever we create "RequestAdd...()" methods, we probably should have the matching "RequestRemove...()" method.
Ibanez 14:00, 19 June 2007 (EDT)
Potential safety issue with proposed access to tracker tools (highly unlikely to happen):
- Calibration is performed prior to the procedure.
- In the setup in the interventional environment, the program specifies that the tool is connected to physical port 1 but someone connects it by mistake to physical port 2. The calibration data is linked erroneously to the tool on port 1.
Can we somehow mitigate this?
TrackerTool States
What is the purpose of separating the "Connected" and "Enabled" states? These look like NDI concepts, but do they generalize to other system?
Patrick: Maybe change the "Visible" and "Invisible" states to "Tracked" and "Lost"? Visibility is more like the concept in SpatialObject.
Methods that will be changed
- The list of method to remove from the Tracker makes sense. Presumable most of them will be converted to "Request" methods and will be sending inputs to the state machine of the TrackerTool.
- The methods added to the TrackerTool look good. It will be nice to lock the Calibration transform to split the states when the Tracker tool is being "configured" and the state when the tracker tool is being actively used for tracking. The calibration transform is so critical to the tracking process that it will be unfortunate if the TrackerTool allows the calibration to be changed in the middle of a tracking run. In other words, it will be nice to have a process such as: StopTracking, SetNewCalibration, ResumeTracking.
Methods added to tracker tool
- How is the transform from the tracker being set to the tracker tool?
- The SetTransform() methond in the above image, should somehow be mapped into a input to the TrackerTool class, to change its states "Tracked" <=> "Lost"
- This should in turn generate some event in TrackerTool class, so instead of pull data from TrackerTool as shown in the image, we also have the flexibility to push data
- How does the tracker tool influence each other? Reference tool vs generic tools ?
- I think the tracker class is still responsible for composing the calibration, raw, and reference transform together
- We need to be careful when deal with reference tool transform, only when the reference tool is in valid tracked state, we can compose new trasnform for each tracker tool
Methods added to derived tracker tool classes
The specific methods for derived classes look good.
Suggestion: we should use safety by design in order to prevent an AuroraTracker from receiving a FlockOfBirds Tracker tool. One way to do this is to make the AddTrackerTool method protected in the Tracker class, and have every derived tracker to have a customized AddTrackerTool() method whose argument is the specific type of the appropriate tracker tool. For example, the AuroraTracker will have a method with signature RequestAddTrackerTool( AuroraTrackerTool * tool ); In this way, C++ type safety will ensure that the tools are not misplaced into trackers.
Ibanez 14:57, 19 June 2007 (EDT)
- It would be nice to have a GetTransform() method similar to the tracker's current method. The user already has all the tracker tools in hand. It's more intuitive in some cases to query each of the tools for its current transform without having to use the observer mechanism. In any case this breaks from the IGSTK approach of using events and payloads to transfer information, so I'm not sure if it is a good idea to have this method, although as I user of IGSTK I'd like it.
Comments from Norway
- The redesign looks very good from our perspective
- Better for application developers to relate to a TrackerTool object instead of (portnumber, toolnumber) pair.
- Exposing the TrackerTool objects gives application developers more flexibility and makes it easier to add Trackertool functionality in IGSTK later.
- Some concerns remain:
- Will all the states of a specific trackertool be available as events? (For polaris spectra there is at least "missing marker" and "out of volume" states that will prohibit the tracker tool from being tracked.)It would be nice to be able to differentiate between these states.
- Default implementations of methods in the tracker class. Is it possible to make the Tracker class abstract and define these metods as pure virtual? It is problematic that virtual methods return SUCCESS if inherited classes don´t implement these functions! If not, shouldn't they return FAIL by default?
- Tracker error handling is poor in some cases, (offTopic?):
Tosa 09:48, 27 June 2007 (EDT)
New methods for identifying tracker tools
I think we need some additional method for connecting physical wired Aurora/Polaris tools to the TrackerTool objects. When only using port and channel number for identification you will depend on the operator plugging the tools into the correct physical port on the Aurora/Polaris control box. In an OR environment (usually crowded with cables and equipment) and with the IGS system set up to track several tools its very easy to plug a cable into the wrong port. This is of cause a very dangerous situation that compromises the safety of the whole system.
When designing wired tools the preferred way is to program the SROM circuit in the tool connector with the specific tool information (Manufacturer, Part number etc.). This information can then be used to identify the tools connected to the system during the initialization phase. This is also the preferred way of doing things according to the communication examples in the NDI documentation - 'NDI Polaris and Aurora Combined Application Programmers Interface guide'.
- My suggestion is to add the following method to the AuroraTrackerTool and the PolarisWiredTrackerTool :
- RequestSetToolID(string Manufacturer, string ToolRevision, string SerialNumber)
We still need the other methods though RequestSetToolPort and RequestSetToolChannel during testing when using the generic 5D catheter tool etc. from NDI.
