[IGSTK-Developers] Follow up: an igstkReferenceCalibration class?
Hui Zhang
zhang at isis.imac.georgetown.edu
Wed Nov 30 19:01:24 EST 2005
Hi, David,
Yes, we use some similar way here to define the tracked needle. At first we
use pivot method to calculate the offset from the tip to the sensor. For
tracked needle, that offset is a 1D value along z-axis, so we get (0, 0,
offset) as the translation component. For the symmetry of cylinder object
such as needle, we set (0, 0, offset + length) as the translation to the
second point along the needle. (Needle is along z-axis in its coordinate
just as you said.) Then, for each reported tracker position/orientation, we
calculate the transformed positions of the tip and then the second point.
Those two transformed positions are set as the input to define the cylinder
spatial object.
The tricky way we used here is to use two points to define the cylinder-like
object, to avoid using the one center point + rotation transform to define
the cylinder. I think the way you mentioned to use ToolCalibrationMatrix
that described the approximate orientation of the tool sounds good. We can
try to set the rotation matrix to default x, y and z axis to find the
correct shape definition. So, should I add some functions like:
SetDefaultRotationToX, SetDefaultRotationToY, .... in igstkPivotCalibration,
so that the output transform can be used directly instead of an additional
igstkReferenceCalibation step?
BTW, to keep the pivot calibration compatible with 1D and 3D translation, I
put two different functions to invoke the calibration:
RequestCalculateCalibration, will return 3D translation like (x, y, z) for
non-symmetry object;
RequestCalculateCalibrationZ, will return 1D translation like (0, 0, z),
this works for symmetry cylinder-like tools.
Regards,
James
----- Original Message -----
From: "David Gobbi" <dgobbi at atamai.com>
To: "Hui Zhang" <zhang at isis.imac.georgetown.edu>
Cc: "Patrick Cheng" <cheng at isis.georgetown.edu>; "'IGSTK-developers'"
<igstk-developers at public.kitware.com>
Sent: Wednesday, November 30, 2005 6:16 PM
Subject: Re: [IGSTK-Developers] Follow up: an igstkReferenceCalibration
class?
> Hui Zhang wrote:
>
>> 5D or 6D 'point' means 5D or 6D position/orientation transform returned
>> by the tracker, just as you mentioned.
>
> Thanks, I was pretty sure that was what you meant.
>
> So I thought that I would backtrack a little bit and describe how I used
> to do calibrations with my vtkTrackerTool class (which is currently in
> IGSTKSandbox/Utilities/Atamai.)
>
> Originally I had a ToolTipCalibration and a ToolAxisCalibration: one would
> fill in the tranlation part of the tool calibration transform, and the
> other would fill in the rotation part of the transform. The Axis
> calibration only gave two angles, so really it was only a 5D calibration,
> but that was okay because all my pointers were shapes like cylinders.
>
> Later I eliminated the ToolAxisCalibration because I needed special
> equipment in order to rotate the tool exactly around its axis while it was
> tracked. Instead, I just set a ToolCalibrationMatrix that described the
> approximate orientation of the tool (i.e. whether the shaft was along the
> x, y or z axis). Then, I did a ToolTipCalibration to accurately calibrate
> the tool tip position. This worked fine, because I was using the pointer
> to locate fiducials, and only the tip position had to be precisely
> calibrated. Precise calibration of the tool orientation is only useful if
> you are using the tool to do measurements at positions other than the tool
> tip.
>
> Also, for some tools e.g. most needles and pointers that come from, the
> orientation is already defined as part of the design of the tool, and in
> some the manufacturing tolerances will be more precise than a
> tracker-based calibration procedure.
>
> I guess that one point I'm trying to make here is that it is never good
> enough to be "as accurate as possible." Even if a person calibrates his
> or her instruments to be as accurate as possible, that doesn't mean that
> they are accurate enough.
> A person always needs to have a quantitative assesment of the required
> accuracy, and a person always needs a quantitative assessment of the
> accuracy of the calibration and the resulting measurements.
>
> - David
>
>> ----- Original Message ----- From: "David Gobbi" <dgobbi at atamai.com>
>> To: "Hui Zhang" <zhang at isis.imac.georgetown.edu>
>> Cc: "Patrick Cheng" <cheng at isis.georgetown.edu>; "'IGSTK-developers'"
>> <igstk-developers at public.kitware.com>
>> Sent: Wednesday, November 30, 2005 5:23 PM
>> Subject: Re: [IGSTK-Developers] Follow up: an igstkReferenceCalibration
>> class?
>>
>>
>>> Hui Zhang wrote:
>>>
>>>> Hi, all,
>>>>
>>>> As we find that the igstkPivotCalibration can only give 3D translation
>>>> in the output transform, which is limited by the pivot routine, so
>>>> should we have a general igstkReferenceCalibration to get the 3D/5D/6D
>>>> transform?
>>>
>>>
>>> It looks like we should adopt a naming convention that includes "Tool"
>>> as part of the name, to make it clear that the transform is to be used
>>> as a ToolCalibrationTransform:
>>>
>>> igstkPivotToolCalibration, igstkReferenceToolCalibration
>>>
>>>> The idea of igstkReferenceCalibration class is to compute the reference
>>>> calibration transform from one or more object points (can be 3D/5D/6D)
>>>> to another refrence point ( can also be 3D/5D/6D).
>>>
>>>
>>> I'm not sure what you mean by a 5D or 6D reference point, since a
>>> "point" is always 3D. Some of the scientific literature, especially in
>>> computer graphics, uses the term "pose" to describe the position and
>>> orientation of an object together. When you say a 5D or 6D point, do
>>> you mean a 5D or 6D position/orientation transform returned by the
>>> tracker?
>>>
>>>> The genreal diagram will be:
>>>> Input: Output:
>>>> object point->ref point
>>>> 3D->3D 3D translation
>>>> 3D->5D 3D translation
>>>> 3D->6D 3D translation
>>>> 2x3D->3D 3D translation
>>>> 2x3D->5D 3D translation + 2D rotation
>>>> 2x3D->6D 3D translation + 2D rotation
>>>> 5D->3D 3D translation
>>>> 5D->5D 3D translation + 2D rotation
>>>> 5D->6D 3D translation + 2D rotation
>>>> 6D->3D 3D translation
>>>> 6D->5D 3D translation + 2D rotation
>>>> 6D->6D 3D translation + 3D rotation
>>>>
>>>> Some further conditions is: 2x3D = 5D, 3x3D = 6D, 2x5D = 6D, ...
>>>>
>>>> So, in our tool calibration routine, we can get first 3D point from
>>>> igstkPivotCalibration, and then set second hip point as the input
>>>> together, 2x3D->5D to get the 3D translation + 2D rotation. For
>>>> example, in the PivotCalibration, we get (x, y, z) from the tip, and
>>>> then we can set (x, y, z + 100) as the hip's translation. Those two
>>>> points (x, y, z) (x, y, z + 100) will input to
>>>> igstkReferenceCalibration to get the final igstkTransform. In this
>>>> case, the default reference point is (0, 0, 0). If we input the
>>>> run-time positions as input, such as T * (x, y, z)', T * (x, y,
>>>> z+100)', we also need input the reference point which build that T
>>>> transform to get the final calibration result.
>>>
>>>
>>> This sounds good.
>>>
>>>> There is a small problem with:
>>>> 5D->5D 3D translation + 2D rotation
>>>> 5D->6D 3D translation + 2D rotation
>>>> in those two cases, we get the same 5D output, but only in 6D reference
>>>> we can the correct referenced position, Needle is a specific shape, for
>>>> we assume it has a translation like (0, 0, z) so that it can eliminate
>>>> the 6th rotation error which will propogate along x and y axies.
>>>
>>>
>>> I think that I follow what you're talking about here. Tools like
>>> needles really are only 5D, so only a 5D calibration is necessary for
>>> these tools. We don't need a 6D calibration: the third orientation angle
>>> is arbitrary. This also implies that the spatial objects for these tools
>>> must be radially symmetric, e.g. cylindrical.
>>>
>>> - David
>>>
>>>> Regards,
>>>> James
>>>>
>>>> ----- Original Message ----- From: "David Gobbi" <dgobbi at atamai.com>
>>>> To: "Patrick Cheng" <cheng at isis.georgetown.edu>
>>>> Cc: "'IGSTK-developers'" <igstk-developers at public.kitware.com>
>>>> Sent: Wednesday, November 30, 2005 2:38 PM
>>>> Subject: Re: [IGSTK-Developers] SpatialObject calibration transform
>>>>
>>>>
>>>>> Hi Patrick,
>>>>>
>>>>> Thanks for the summary. The reason that I would prefer to add the
>>>>> orientation as part of the tool calibration transform is that I think
>>>>> we should keep the number of coordinate transformations in IGSTK to a
>>>>> minimum.
>>>>>
>>>>> Each coordinate transformation is a possible source of error. Even
>>>>> worse, if two different transformations can be used to achieve the
>>>>> same result (e.g. a tool calibration transform and a spatial object
>>>>> calibration transform), then both transforms can have errors that
>>>>> cancel each other out. These sorts of errors can be very hard to
>>>>> debug.
>>>>>
>>>>> I think the best solution is if the ToolTipCalibration class has a
>>>>> method that allows you to specify the orientation of the tool that is
>>>>> being calibrated.
>>>>>
>>>>> - David
>>>>>
>>>>> Patrick Cheng wrote:
>>>>>
>>>>>> Hi everybody,
>>>>>>
>>>>>> What I was trying to say in the Tcon is:
>>>>>>
>>>>>> the cylinder object (longest axis) is align with Y axis in image
>>>>>> space (inherited from ITK by default). while the probe is aligned
>>>>>> with the tracker's X axis.
>>>>>>
>>>>>> So when we get the PatientTransform, which essentially align the
>>>>>> image space and tracker space together, but still the cylinder
>>>>>> spatialobject and the probe is not aligned correctly. We need first
>>>>>> rotate our spatial object to align with the probe, and then use the
>>>>>> pivot calibration transform to get the tip translation.
>>>>>>
>>>>>> This adjustment of the spatial object's coordinate system, can be
>>>>>> done by adding the rotational information to tool calibration
>>>>>> transform. or we can add it to a upper level transform when we
>>>>>> construct a spatial object group to model the probe.
>>>>>>
>>>>>> Patrick
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> IGSTK-Developers mailing list
>>>>> IGSTK-Developers at public.kitware.com
>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
>
More information about the IGSTK-Developers
mailing list