[IGSTK-Developers] Inconsistencies within the IGSTK tracking framework

[Ziv Yaniv]

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/