Hi Jake and Patrick;<br><br>I'm using the standard ROM file and rotating the probe about it's mechanical axis. I'm not at the lab right now, but the information that the tool coordinate<br>
system is defined at the center of 'Marker A' makes a lot of sense. Tomorrow I will confirm that I'm moving in a circle with 3D support. <br><br>Patrick, in this case, a pivot calibration wouldn't help right? As mentioned this is the case where a "rotational calibration (non-orthogonal)" should take place.<br>
<br>Thank you both for supporting me.<br><br>Best Regards<br><br>Fauze<br><br><br>On Thu, Jan 21, 2010 at 8:01 PM, Patrick Cheng <span dir="ltr"><<a href="mailto:cheng@isis.georgetown.edu">cheng@isis.georgetown.edu</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Jake,<br>
<br>
There is a pivot calibration class and example in IGSTK 4.2.<br>
<br>
Please refer to "Chapter 16 Calibration" of the IGSTK book, 2nd edition, page 225.<br><font color="#888888">
<br>
Patrick</font><div><div></div><div class="h5"><br>
<br>
On 1/21/2010 3:52 PM, Jake McIvor wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Fauze,<br>
<br>
Are you using the standard .rom file for your pointer tool?  Based on<br>
the Vicra Tool Guide I have seen (2006 version), the tool coordinate<br>
system is defined at the center of 'Marker A', or the marker closest<br>
to the tip of the tool.  It is offset from the mechanical axis of the<br>
pointer shaft.<br>
<br>
If you are rotating about the mechanical axis of the pointer shaft,<br>
then the origin of the tool should be moving in a circle.  Could this<br>
be the source of the movement?<br>
<br>
<br>
Patrick:<br>
I remember coming across a mention of an IGSTK rotational calibration<br>
class some time ago.  Is this still in development?<br>
<br>
<br>
Cheers,<br>
Jake<br>
<br>
--<br>
Jake McIvor<br>
MASc Candidate, Biomedical Engineering<br>
University of British Columbia<br>
<br>
On Thu, Jan 21, 2010 at 10:20 AM, Patrick Cheng<br>
<<a href="mailto:cheng@isis.georgetown.edu" target="_blank">cheng@isis.georgetown.edu</a>>  wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Fauze,<br>
<br>
...When we "rotate" the tool around it's own axis without any tip and origin<br>
translations...<br>
<br>
When you say "rotate", do you mean "Pivot"? If that the case, then you<br>
probably didn't set the "calibration transform" right.<br>
<br>
If you just "rotate" your needle, the object being displayed should not move<br>
at all, even without proper "tip calibration (translational)", because we<br>
only have 5 degree-of-freedom sensor. If it does move, it means the sensor's<br>
principle axis is not aligned with your needle's principle axis, then you<br>
need to do a "principle axis calibration (orthogonal axis swap)" or<br>
"rotational calibration (non-orthogonal)".<br>
<br>
Patrick<br>
<br>
On 1/21/2010 1:07 PM, Fauze Polpeta wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Dear Patrick;<br>
<br>
After applying the registration transform to a tool (consider the NDI<br>
Vicra Standard Probe - 8700340) and start the navigation, we've noticed<br>
a strange behavior in our 2D tool representation, which, in turn, is a<br>
line drawn in three OpengGL contexts (MPR). When we rotate the tool<br>
around it's own axis without any tip and origin translations, we faced<br>
that the origin is being shifted as it was being translated, but it's not.<br>
<br>
In order to draw the line that represents the tool we use the<br>
tipTransform (obtained on each track event) and the (inverse)<br>
calibration transform (see code below). Thus, with tip and origin<br>
translations in hands the line can be drawn. At a first glance I thought<br>
this was caused by a high registration error, but it's not, even with<br>
  such error below 3.0 this scenario remains. Is this caused by the way<br>
we are getting the origin's coordinates back? Should we rely on the<br>
rotation instead of origin translation?<br>
<br>
Thanks in advance for any suggestion.<br>
<br>
Regards<br>
<br>
Fauze<br>
<br>
<br>
----<br>
<br>
INPUT: tipTransform and calibrationTransform<br>
<br>
igstk::Transform inverseCalibrationTransform<br>
= calibrationTransform.GetInverse();<br>
igstk::Transform originTransform = igstk::Transform::TransformCompose(<br>
tipTransform, inverseCalibrationTransform );<br>
igstk::Transform::VectorType tipTranslation =<br>
tipTransform.GetTranslation();<br>
igstk::Transform::VectorType originTranslation =<br>
originTransform.GetTranslation();<br>
<br>
OUTPUT: tipTranslation and originTranslation<br>
<br>
<br>
</blockquote>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-users" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-users</a><br>
<br>
</blockquote>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br>