[IGSTK-Developers] Some component design questions

[Kevin Gary]

Ziv and Andinet,

Thanks a lot for taking the time to answer. Quick follow-up -

- What is the timeline for the refactoring? The closest thing I see on 
the wiki is a note on last week's agenda saying Iteration 10 should be 
closed by the end of the month? I ask because I have a couple of 
graduating students who are working from the old tracker because it is 
one of the few that adheres to IGSTK best practices (like using the 
AttemptTo pattern). I am wondering if the new component will be 
available soon and when the refactoring will be considered stable.

- Question 1 is still relevant, as like question 4 we are more 
interested in understanding how inputs correspond to real-world events. 
So the real question is, are there any real-world scenarios where a 
reset occurs, and typically what is the consequence?

Thanks again folks!
Kevin


Ziv Yaniv wrote:
> 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
> 
> 

-- 
===
Kevin A. Gary, Ph.D.
Assistant Professor
Division of Computing Studies
Arizona State University at the Polytechnic Campus
(480)727-1373
http://dcst2.east.asu.edu/~kgary
kgary at asu.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kgary.vcf
Type: text/x-vcard
Size: 135 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20071024/db96395d/attachment.vcf>