[IGSTK-Developers] Some component design questions

[Kevin Gary]

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

-- 
===
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/20071023/6a569f13/attachment.vcf>