[IGSTK-Developers] Re: Further enhancements re: StateMachine::PushInput()

[Stephen R. Aylward]

Sorry that I've been out of it for several weeks - my life is now my own 
(kind of).

This is probably a really stupid question - but I am striving to 
catch-up on things!   It seems like having an event push mechanism poses 
challenges.

To overstate the challenges - isn't event queuing in a real-time system 
"bad"?   A single tracker may feed multiple objects or multiple trackers 
may feed a single object - each may involve a different mix of 
priorities.   Say we have an ultrasound probe with an affixed needle 
guide - perhaps the needle movement events will have a different 
priority than the ultrasound movement events - even though both come 
from the same tracker.  On the other hand, an object in an image guided 
intervention may be tracked via image registration initialized by 
multiple trackers - assuming image-based registration isn't an instance 
of a hybrid tracker (but perhaps it is), then one process may rely on 
multiple trackers.   Similarly, an object collision detection process 
may need info from multiple trackers.

I guess these challenges can be overcome by having event queues that are 
specific to each tracker/observer combination.  Is that that plan?

There is no need to respond if this is a truly bogus question...

Stephen



David Gobbi wrote:
> Hi Luis,
> 
> Taking this PushInput stuff up another notch, we also
> need a way to push events.
> 
> When a Tracker-derived class generates an event, we
> don't want the observer to be called until after the state
> machine has finished its processing.
> 
> This will require an EventQueue class, and this class
> probably belongs in ITK rather than IGSTK.
> 
> EventQueue::PushEvent(const itk::EventObject &);
> EventQueue::ProcessEvents(itk::Object &);
> 
> Another possiblity is to queue the observers instead of
> the events, but that would have to be built into itk::Object,
> and would require the PushEvent() and ProcessEvents()
> methods to be itk::Object methods.
> 
> - David
> 
> P.S. I'll add PushInputBoolean() to the state machine,
> and next week Hee-su will modify the IGSTK code
> to use it. Once it is done, Tracker coverage will
> finally reach 100%.
> 
> Luis Ibanez wrote:
> 
>>
>> Hi David
>>
>> That's a great idea,
>>
>> It certainly will help to clean up the code.
>>
>> Please feel free to make the modifications in
>> the State Machine, or if you prefer we can make
>> the changes on the State Machine from here.
>>
>>
>>    Just let us know,
>>
>>
>>        Thanks
>>
>>
>>           Luis
>>
>>
>>
>>
>> ------------------------
>> David Gobbi wrote:
>>
>>> Hi Luis,
>>>
>>> Since the PushInput() method was added, we've added a lot of ugly 
>>> code like this to the tracker:
>>>
>>>  if (result == SUCCESS )
>>>    {
>>>    m_StateMachine.PushInput( m_CloseTrackingSuccessInput );
>>>    }
>>>  else if( result == FAILURE )
>>>    {
>>>    m_StateMachine.PushInput( m_CloseTrackingFailureInput );
>>>    }
>>>
>>> I have a very simple fix for this, which either me or Hee-su can 
>>> implement:
>>>
>>>
>>> m_StateMachine.PushInputBoolean(result, m_CloseTrackingSuccessInput, 
>>> m_CloseTrackingFailureInput);
>>>
>>>
>>> By adding a "PushInputBoolean" method to the state machine, the nasty 
>>> if/else blocks that we recently added to igstkTracker can be removed.
>>>
>>> Does this sound reasonable?
>>>
>>> - David
>>>
>>>
>>>
>>
>>
>>
>>
> 
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers

-- 
===========================================================
Dr. Stephen R. Aylward
Associate Professor of Radiology
Adjunct Associate Professor of Computer Science and Surgery
http://caddlab.rad.unc.edu
aylward at unc.edu
(919) 966-9695