[IGSTK-Developers] Continuting the discussion on error handling methods....

[David Gobbi]

Hi Andinet,

For landmarks: For image-guided surgery, the user will usually set the 
positions of all the landmarks before doing any tracker measurements.  
In fact, to save time, I always set the landmarks before I even wheeled 
the computer into the OR, so that the only thing the surgeon had to do 
was measure the landmark positions with the Polaris.  I think the 
error-checking should be done when the transformation is calculated, not 
when the landmarks are set.  This also helps to centralize the error 
checking, since you also need to check the RMS residual of the point 
fit, as well as minumum number of points when the transform is calculated.

Also: when in the operating room, it often occurs that one of the 
doughnut fiducials either falls off or ends up in a position 
inaccessible to the tracker.  This can easily happen after the fiducial 
has been located, but before the tracker has been used to measure its 
position.  There has to be a way to either delete such fiducials from 
the list, or better, to mark them as "ignored" since deleting them from 
the list will disrupt the numbering of the fiducials.

Rule #1 of the operating room: you need to be prepared for anything that 
might go wrong!


About error checking:

To ease the burden of error checking, I think that we need macros or 
some other shortcut to convert state-machine inputs to IGSTK Events and 
vice-versa.

For example, we need a concise way to state, in code, the following:
1) when we receive input A while in state B, event C will be generated 
and we will end up in state D
2) when object A produces event B, send input C to our state machine
If we had macros for the above, I think that event-based error-handling 
code would be easier to write.

 - David

Andinet Enquobahrie wrote:

> Dear all
>
> I am putting the final touches on the LandMarkRegistration and 
> ImageReader classes implementation for iteration 6. The main loose end 
> I need to tighten up is error handling. Although we have brainstormed 
> several options for error handling , we haven't yet reached a consensus. 
> If you would like to refresh your mind on this topic,  please refer to 
> the wiki page that David put together.
>
> http://public.kitware.com/IGSTKWIKI/index.php/Error_Handling#Kinds_of_Errors 
>
>
> For my specific needs, I am planning to implement event observers for 
> recoverable error conditions in landmark registration and image reading.
>
> The recoverable error conditions that I am anticipating are the 
> following.
>
> For LandMarkRegistration class
>
> 1) A request for transform computation before "enough" number of 
> landmarks are established.
>
> 2) Incorrect order of landmark establishment.  I am enforcing a 
> specific order of landmark establishment i.e  image followed by 
> tracker coordinate for landmarks 1,2,3 (We are using 3D Rigid body 
> transform)  For example, an error condition arises if the application 
> sets image coordinates of two landmarks successively without setting 
> the tracker coordinate of the first landmark.
>
> For ImageReader classes
>
> 1) An image read request before specifying the image file name.
> 2) Error during image reading operation (may be corrupted image data, 
> invalid image format etc..)
>
> This is not an exhaustive list by any means. But I believe these are 
> the major ones.
>
> I would like to get your comments/thoughts/suggestions on
>
> - additional major error conditions and
> - my pick of an error handing method
>
> thanks
>
> -Andinet
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>