[IGSTK-Developers] Inconsistencies within the IGSTK tracking framework
Ziv Yaniv
zivy at isis.imac.georgetown.edu
Wed May 7 16:12:26 EDT 2008
Andinet,
Many thanks for the quick fix. Now I really have to change my code to a
callback style data acquisition.
Ziv
Andinet Enquobahrie wrote:
> 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 <mailto: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 <mailto:zivy at isis.georgetown.edu>
> web: http://isiswiki.georgetown.edu/zivy/
>
>
--
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/
More information about the IGSTK-Developers
mailing list