[IGSTK-Developers] Inconsistencies within the IGSTK tracking framework

[Andinet Enquobahrie]

Ziv,

RequestUpdateStatus method is renamed as UpdateStatus and moved to tracker
private interface. I have also fixed all the tests and examples that used to
manually
call this method.

http://www.vtk.org/Bug/view.php?id=6985

Let me know if you encounter any issues...

-Andinet


On Wed, May 7, 2008 at 10:26 AM, Ziv Yaniv <zivy at isis.imac.georgetown.edu>
wrote:

> Hi Andinet,
>
> I agree with both your suggestions, remove RequestUpdateStatus from the
> public API, and remove SetValidityTime altogether. Hopefully these changes
> won't break too much code (I will need to modify pivot calibration to work
> in this manner).
>
>          thanks
>              Ziv
>
>
> Andinet Enquobahrie wrote:
>
> > Hi Ziv,
> >
> > Good points you brought up and thanks for the detailed description. My
> > comments
> > are below.
> >
> > > 1. How to perform transformation data acquisition.
> > >
> > > a. No loop in my code. The tracker is acquiring data at a specified
> > > frequency and we are supposed to observe the tracker.  When we get
> > > TrackerUpdateStatusEvent we need to invoke
> > > m_TrackerTool->RequestGetTransformToParent() and listen to the events
> > > generated from the tool to get the transform as payload. To acquire many
> > > transforms, lets say for averaging I have to maintain an ivar to do the
> > > accumulation.
> > >
> > > b. Have a loop in my code while(...) tracker->RequestUpdateStatus()
> > > and then ask for m_TrackerTool->RequestGetTransformToParent() and listen to
> > > the events generated from the tool. To acquire many transforms, I use a
> > > local variable.
> > >
> > > The pivot calibration code currently does 'b'. This is not good as
> > > there is a concurrent loop that is being run by the tracker. On the other
> > > hand the API should not have a RequestUpdateStatus() for the tracker, it
> > > should only be updated internally.
> > >
> > > If option 'a' is the IGSTK way of data gathering then we need to
> > > remove the RequestUpdateStatus() from the tracker and update all the
> > > relevant code to work "correctly".
> > >
> > >  Option 'a' is the correct one.  RequestUpdateStatus is a callback
> > method for the
> > Pulse event observer. It is defined in the Tracker constructor as
> > follows
> >
> > m_PulseObserver = ObserverType::New();
> > m_PulseObserver->SetCallbackFunction( this, &
> > Tracker::RequestUpdateStatus );
> > m_PulseGenerator->AddObserver( PulseEvent(), m_PulseObserver );
> >
> > This method gets invoked internally when a pulse event is observed by
> > the tracker.
> > I don't think we will need RequestUpdateStatus() method be part of the
> > public API. Users should not need to manually invoke this method.
> > I will do some investigation and testing and move this method from
> > public to
> > private interface and remove the "Request" prefix.
> >
> >  2. How to set the validity time of the transformation.
> > >
> > > Right now there are two options to set the validity time of the
> > > transformation.
> > >
> > > a. SetValidityTime() - does what the user expects.
> > > b. RequestSetFrequency() - surprises the user as it shouldn't have
> > > anything to do with the validity time.
> > > When the user invokes the RequestSetFrequency method the state machine
> > > invokes Tracker::SetFrequencyProcessing this in turn has the side effect of
> > > changing the validity time:
> > >
> > > /** The "SetFrequencyProcessing" passes the frequency value to the
> > > Pulse
> > >  * Generator. Note that it is still possible for the PulseGenerator to
> > > reject
> > >  * the value and stay at its current frequency. */
> > > void Tracker::SetFrequencyProcessing( void )
> > > {
> > >  igstkLogMacro( DEBUG,
> > >                 "igstk::Tracker::SetFrequencyProcessing called
> > > ...\n");
> > >
> > >  this->m_PulseGenerator->RequestSetFrequency( this->m_FrequencyToBeSet
> > > );
> > >
> > >  //Set the validity time of the transforms based on the tracker
> > > frequency
> > >  //Add a constant to avoid any flickering effect
> > >
> > >  const double nonFlickeringConstant = 10;
> > >  this->m_ValidityTime = (1000/m_FrequencyToBeSet) +
> > > nonFlickeringConstant;
> > > }
> > > I believe that the last two lines should be removed from the method.
> > >
> > >
> > >  The computation of validity time based on the tracking frequency is
> > actually correct.
> > Validity time of a transform depends on the tracking frequency. The
> > relationship is
> > described with the equation shown above with an additional constant
> > factor to take
> > into account the flickering effect.
> >
> > The problem is with the SetValidityTime public method. This method lets
> > users set
> > a bogus validity time without consideration of the tracking frequency.
> > For example,
> > if the  frequency of a tracking device is 20Hz, but a user specifies a
> > validity time
> > of 1000ms, then the pipeline timing coordination will get out of sync
> > and the tools
> > will not be properly rendered. Therefore, I suggest removing the
> > SetValidityTime
> > public method.
> >
> > -Andinet
> >
> >
> >
>
> --
> 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.georgetown.edu
> web: http://isiswiki.georgetown.edu/zivy/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20080507/a79e1bf3/attachment-0001.html>