Tool tracking breaks with two or more tools in view (Suggestion for fix)

[BowMonk]

Hello everyone!

When testing out Slicer and tracking some tools through the OpenIGTLink modules I ran into issues with tracking two or more tools at once.

After building everything from source, I managed to isolate the issue. I already wrote about this at https://discourse.slicer.org/t/issues-tracking-two-tools-at-once/41870/4 , so I will be brief here.

What steps should I take next to introduce a pull request and hopefully get this fixed for later Slicer versions? I would also love some suggestions on different methods to solve this issue.

Thank you in advance.

(I have also mirrored this issue in the OpenIGTLinkIO github, since a possible fix could also be introduced in the igtlioTrackingDataConverter.h and igtlioTrackingDataConverter.cxx files)

[adamrankin]

From discourse:

I have figured out the issue after building everything from source and doing some debugging.

To give a summary of everything once again, I was trying to track two tools, Tool1 and Tool2 using information obtained from OpenIGTLink. Separately they are both tracked fine, however the moment they both come into view at the same time, the tracking for Tool2 (when Tool1 is not in view) is broken. It does not update its transform data anymore (even though the MTime variable does). After some debugging, I figured out that the positioning of the data inside the igtlioTrackingDataConverter::ContentData object alongside how the transforms are updated to be the cause of this issue.

ContentData has a map which carries the information for each tracked tool.

struct ContentData
{
  std::map<int, ContentEntry> trackingDataElements;
};

However when multiple tools apear, the position of those tools in that map changes. They are seemingly sorted alphabetically, so if both tools appear at once, then the map updates to show Tool1 first then Tool2. However, if Tool1 goes out of view and Tool2 remains, the map still has a version of Tool2 at its old position. So if we loop through the map, we would get the new and updated Tool2 with the correct transform, then the old Tool2 with the old and wrong transform.

Due to how iterating and updating is currently handled in void vtkMRMLIGTLConnectorNode::ProcessIncomingDeviceModifiedEvent at the moment (coming from SlicerOpenIGTLink/OpenIGTLinkIF/MRML) , the correct version is handled first, the tool position is updated correctly, and then the old version is handled after and simply reverts the position back. This keeps happening until Tool1 comes back into view with Tool2, where now Tool2 updates normally again (as the maps only version of Tool2 is now correct).

At the moment I have remedied this by adding the following code:

for (int b = 0; b < content.trackingDataElements.size()-1; b++) {
    if (content.trackingDataElements[b].deviceName.compare(content.trackingDataElements[b + 1].deviceName) == 0)
    {
        content.trackingDataElements.erase(b + 1);
    }
}

This is placed between
igtlioTrackingDataConverter::ContentData content = tdataDevice->GetContent(); and
for (auto iter = content.trackingDataElements.begin(); iter != content.trackingDataElements.end(); iter++) inside the else if case handling “TDATA” in the void vtkMRMLIGTLConnectorNode::ProcessIncomingDeviceModifiedEvent function.

I think the easiest way to solve this would be to have the map keys be something other than integers, since they have no guarantee that the same tool is not updated twice.

I would love to get some suggestions on this as I plan to make a pull request to hopefully fix this issue in a later version of Slicer.