Page MenuHomePhabricator

Aurora Tracking Volume seems to be wrong
Closed, ResolvedPublic


mitk::TrackingVolume returns Surfaces of all tracking volumes. While testing, the Aurora volume seems to be way to large. The tools could only be tracked in the center area of the surface

Event Timeline

Perhaps this is because of the different aurora tracking volumes depending on the firmware. There is a so called "dome volume" and a block-shaped volume. As far as I know there is only implemented the dome volume so far.

Another reason for this bug could be a wrong size of the stl file corresponding to the aurora tracking volume.

I'll check this out as soon as possible, but I'm afraid this will be at least in the end of february 2010 because I'm not working for the next three weeks due to my exams.

Only standard volume / cube is implemented, right?

See T5297 for enhancement of NDIProtocol. Now SFLIST can be called, which returns the dimensions and the type of supported tracking volumes (for NDI/currently tested on two Aurora systems). But I have not yet seen a possibility to read out which tracking volume is used, only to define which volume to use.

Yes at the moment only the cube volume is availiable. But the stl-file of the dome volume is already created and can be found at Modules\IGT\IGTTrackingDevices\TrackingVolumeData. So as soon as there is a way to find out which volume is used one can implement this feature simply.

But nevertheless we'll have to check if the dimensions orientation of the volumes (in the stl-files) are correct.

I've discussed this with the NDI developer. The API does not offer to read out which tracking volume currently is in use. One will have to set the volume to know which is currently used.
But this can be implemented in NDITrackingDevice. By default use the first tracking volume and let the user choose if another volume shall be used. Display the default volume (first received volume) and change it if the user chooses a different one.

[SVN revision 28411]
FIX (#3261): updated Aurora tracking volume files

tracking volume is visualized right in the current version (tested it a few times), so closing this bug