[IGSTK-Developers] Some component design questions

[Ziv Yaniv]

Hi Kevin,

Looking at any of the current tracker related code is a waste of time. 
The code is really undergoing major changes, extreme makeover if you will.

Andinet already answered questions 2 and 3, and question 1 is tracker 
related so the code is probably being changed as we speak, so all that 
is left is question 4.

I can only speak for the Aurora (magnetic) and Polaris (optical) 
trackers as I haven't worked with others. When a tool is not detected, 
lost line of sight or metal interference, the physical tracker notifies 
the software side that the tool is missing/not visible. That is, 
information is always transmitted back from the tracker. As to dropped 
packets and missing information I think/hope this is validated by igstk 
code that does CRC checking. For the gory details you will have to look 
at igstkNDICommandInterpreter and its use.

How other tracking systems deal with errors in communication I have no 
idea. I guess Andinet dealt with this for the micron tracker. I don't 
know what communications protocol is used, only that the connection is 
through firewire.

                           regards
                              Ziv

Kevin Gary wrote:
> IGSTK component developers -
> 
> We had a few questions about some of the state machines in IGSTK 
> components, hope someone can help us out:
> 
> 1. The current tracker has a reset input (pushed by the RequestReset 
> method) that takes the tracker back to the CommunicationEstablished 
> state. We are wondering why that reset exists and in what real-world 
> scenario would a reset occur? We note that the proposed new design does 
> not have such a reset.
> 2. The Landmark3DRegistration state machine forces 3 or more points to 
> be selected for the registration process. The state machine does not put 
> an upper bound on the number of points used. Is there a theoretical 
> upper bound? Is there an upper bound commonly used in practice? Does 
> including more points reduce the error significantly?
> 3. The tracker's "AttachObjectToTrackerTool" method is public (not 
> called by anyone) and has no interaction with the state machine. It is 
> typically called by applications and results in sending a request to the 
> SpatialObject::RequestAttachToTrackerTool method. Should there be a SM 
> check here? Will the Tracker allow such an assignment in all states?
> 4. We are building simulation models for testing. For example, if there 
> is a line-of-sight obstruction of an optical tracker, we would simulate 
> that in a test by not transmitting information back from the tracker. Do 
> the trackers IGSTK supports have published error rates in terms of 
> dropped data packets? In other words, if a tracker typically operates at 
> 100Hz but has a 0.1% drop rate, we would simulate a missing packet every 
> 10 seconds.
> 
> Thanks for any info anyone has...
> 
> K2
> p.s. Thanks to those who took the survey. Its still open if you haven't: 
> http://webapp.poly.asu.edu/asusurvey/TakeSurvey.asp?SurveyID=5229m31K8olKG
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers


-- 
Ziv Yaniv, PhD., Research Assistant Professor
Imaging Science and Information Systems (ISIS) Center
Department of Radiology
Georgetown University Medical Center
2115 Wisconsin Avenue, Suite 603
Washington, DC, 20007,

Phone: +1-202-687-7286
Fax: +1-202-784-3479
email: zivy at isis.imac.georgetown.edu
web: http://isiswiki.georgetown.edu/zivy/