[IGSTK-Developers] Inconsistencies within the IGSTK tracking framework

[Andinet Enquobahrie]

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


-- 
==========================================================
Andinet A. Enquobahrie, PhD
R&D Engineer
Kitware Inc.

28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x124
www.kitware.com