[IGSTK-Users] Tip and Origin Translation Coordinates

[Jake McIvor]

Hey Fauze,

Glad to hear that helped.

You're right: the pivot calibration won't help directly, but it can be
used to calculate your 'calibrationTransform'.  (NDI also has a
utility for doing this and saves it directly into the .rom file).
Generally, I think it is recommended to do a pivot calibration before
each session to correct for any bending / shifting of the probe.

In the case of the 8700340 probe, +z is defined towards the 2nd marker
distal to the tip, which is likely in line with the mechanical axis of
the probe.  It that is the case, you could use a fixed translation in
the z direction instead of the inverse calibration transform to get
the coordinates of your second point.


Jake

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