[IGSTK-Developers] Re: Connection TrackerTool-Physical tracker port

Geir Arne Tangen Geir.A.Tangen at sintef.no
Thu Aug 16 05:24:57 EDT 2007 

Hi Luis,

I have included my comments below :

On Aug 16, 2007, at 1:32 AM, Luis Ibanez wrote:

>
>
> Hi Geir,
>
> I'm assuming that these methods are to be implemented only in
> the PolarisTrackerTool and AuroraTrackerTool... is that right ?

Yes, I think so since as far as I know the FlockOfBird doesn't have  
the functionality of reading
ID information from the physical tool.

>
> Also, do you see any reason for disconnecting/connecting the
> tools during the surgery ?
>

Yes, since the Aurora and active Polaris have only 4 physical ports  
we will soon run into
the case where we cannot activate all tools at startup. In our  
clinical projects we
typically want to track these tools :
- Reference frame
- Fiducial markers with sensors for patient registration or dynamic  
correction of breathing
motion etc.
- Endoscope
- Ultrasound probe
- catheters or surgical tools

In our endovascular project we ended up dividing the navigation  
prosedure in two
phases. First patient registration with active fiducials, then  
unplugging the fiducial sensors
and plugging in the other navigation tools before continuing with  
navigation.

Also you have the case where everything is connected and ready to go,  
then during the
procedure some equipment in the OR needs to be moved and you have to  
disconnect
all the cables to make room and then reconnect them (hopefully to the  
correct tool port !).

For safety reasons I think that the TrackerTool objects should  
periodically check the
toolInformation to see if the toolIdentification is still valid  
(tools are still connected to the
same ports). This will lead to a toolIdentificationInvalid state that  
the application needs to
handle in some way (at least give an alarm to the user that the tool  
has been unplugged
or the port number has changed).

> I'm reworking the State machine of the TrackerTool, and I was
> assuming that the settings of Port, Channel and SROM were done
> at the very beginning, (before starting to track) and never
> changed afterwards.

When using a SetToolID method the user shouldn't be allowed to set  
Port and Channel.
These will be set internally by the TrackerTool object after  
communication with the
Tracker. In this case SROM should not be set either since this has  
been pre-burned into
the tool.

I agree that we also should have the alternative of setting Port,  
Channel and SROM
when we don't have the SROM info available. But this is more  
hazardious since in this
case we won't be able to check the integrity of the tool connected.  
Maybe a warning to
the operator should be issued ?

If the port/channel changes for a TrackerTool object after startup it  
means the
tool configuration has changed. I dont know the best way to handle  
this since this also
means that the SpatialObjects have to be changed for the tools.
Maybe we should just delete the TrackerTool objects and allocate/ 
initialize new objects
according to the new configuration ?

>
> The current intention with the state machine is to ignore
> subsequent calls to RequesetSetPort() for example.
>
> A sketch of the proposed State Machine is available in the Wiki:
>
> http://public.kitware.com/IGSTKWIKI/index.php/ 
> Tracker_interface_changes#Tracker_Tool_State_Machine
>
> This is for the base class TrackerTool.
>
> The derived classes {Polaris,Aurora,FlockOfBirds}TrackerTool,
> will have a separate StateMachine where the settings of ports,
> channel, bird #, will be made, and a boolean status method will
> return if the tool is ready to be used.
>

Just one comment.
I think the toolIdentificationCompleted state shouldn't be reached  
before you have attached to the tracker
and verified the tool information of the physically connected tools.

Regards
Geir Arne

>
>  Please let us know what you think of this suggested organization.
>
>
>     Thanks
>
>
>        Luis
>
>
> --------------------
> Patrick Cheng wrote:
>> Hi Geir Arne,
>> I agree, I think it should be a two way street.
>> 1. We can give it a port and channel, and get the SROM (ID  
>> information) from the physical tool, to verify if that's the  
>> correct tool as we expected.
>> 2. We should also be able to give it an ID information, and let  
>> the tracker figure out which port and channel it's being connected  
>> to.
>> These fit into the redesigned tracker interface well, since we  
>> have access to the TrackerTool object.
>> Thank you,
>> Patrick
>> Geir Arne Tangen wrote:
>>> Hi Patrick,
>>>
>>> Thanks for the response though I still think we need some kind of  
>>> verification that the TrackerTool object is connected to
>>> the correct physical port.
>>>
>>> In one of our projects we are simultaneously tracking 4 tools  
>>> (reference tool, active fiducial markers + two catheter tools).
>>> In this case it can be difficult to verify that the tool cables  
>>> are connected to the correct ports without checking the SROM
>>> tool information (Reading the SROM information with command PHINF  
>>> towards the NDI equipment).
>>>
>>> Geir Arne
>>>
>>> On Aug 13, 2007, at 5:33 PM, Patrick Cheng wrote:
>>>
>>>> Hi Geir Arne Tangen,
>>>>
>>>>
>>>> >RequestSetToolID(string Manufacturer, string ToolRevision,  
>>>> string >SerialNumber)
>>>>
>>>> I think this method is nice to have, but in practice, the needle  
>>>> tool we  are using is sterilized and with SROM file pre-burned  
>>>> into the tool. We don't have the ID information for those tools.
>>>>
>>>> What I have been doing in our application is, if the tool is not  
>>>> being plugged into the right port and channel, we have the  
>>>> option to correct that miss connection error and reinitialize  
>>>> the tracker.
>>>>
>>>> Patrick
>>>>
>>>> Geir Arne Tangen wrote:
>>>>
>>>>> Hi developers,
>>>>> I have a suggestion for a new method in the TrackerTool class  
>>>>> for identifying the physical tool to
>>>>> the TrackerTool object during initialization. This will cover  
>>>>> the fault situation when the operator
>>>>> connects the wired Polaris/Aurora tool to the wrong physical  
>>>>> port on the control box.
>>>>> Comments are added to the 'Tracker Interface changes'  
>>>>> discussion page :
>>>>> http://public.kitware.com/IGSTKWIKI/index.php/ 
>>>>> Talk:Tracker_interface_changes#New_methods_for_identifying_tracker 
>>>>> _tools Geir Arne Tangen
>>>>> Research Scientist (MSc)
>>>>> SINTEF Health Research, Medical Technology
>>>>> E-Mail: Geir.A.Tangen at sintef.no
>>>>> Phone : +47 98245142
>>>>> Fax : +47 93070800
>>>>> Web adress: http://www.sintef.no/medtech
>>>>> _______________________________________________
>>>>> IGSTK-Developers mailing list
>>>>> IGSTK-Developers at public.kitware.com
>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk- 
>>>>> developers
>>>>
>>>>
>>>>
>>>
>>> Geir Arne Tangen
>>> Research Scientist (MSc)
>>> SINTEF Health Research, Medical Technology
>>>
>>> E-Mail: Geir.A.Tangen at sintef.no
>>> Phone : +47 98245142
>>> Fax : +47 93070800
>>> Web adress: http://www.sintef.no/medtech
>>>
>>>
>>> _______________________________________________
>>> IGSTK-Developers mailing list
>>> IGSTK-Developers at public.kitware.com
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>
>>>
>>>
>> _______________________________________________
>> IGSTK-Developers mailing list
>> IGSTK-Developers at public.kitware.com
>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers

More information about the IGSTK-Developers mailing list