MLMarkerTracker seems to be disregarding ArUcos with duplicated IDs

Give us as much detail as possible regarding the issue you're experiencing.

Unity Editor version: 2022.3.13f1
ML2 OS version: 1.4.1
MLSDK version: 1.4.0
Host OS: (Windows/MacOS) Windows

I'm trying to recognize many Aruco (5x5_1000) markers with the strong possibility of reused IDs. In my testing, it appears that markers with duplicated IDs conflict, and I only get callbacks for one of the markers with the duplicated IDs.

Is this by design? Is there a setting in the TrackerSettings to enable multiple tracked markers with a single ID?

Hi @dave.lecompte

this is a limitation of the ArUco detector. Two identical markers would conflict when we cache their poses and track and update them over time because there is no way to distinguish the two.

Hmm, that's bad news for us. Sounds like it's a limitation imposed by the caching layer, keying off the IDs.

It'd be nice if we could get callbacks prior to the caching, so we could distinguish between markers that have the same IDs but different poses.

It's not that easy, several optimizations for both performance and pose estimation accuracy assume there are unique IDs.

Does your use case have static markers only? If not the pose wouldn't be a reliable identifier either.

How many markers are you planning to detect at once in your scenario?

Does your use case have static markers only? If not the pose wouldn't be a reliable identifier either.

Short answer: I think we can think of the markers as static. Longer answer below.

How many markers are you planning to detect at once in your scenario?

We'd like to be doing around 70 markers at once, based on real world testing, but we could probably live with around 35.

Longer answer describing our use case:

We expect to have "sessions" of around 5 minutes. During these sessions, some of the markers (4 or 6) will be totally static, essentially bolted to the floor. Of the remaining markers, the user will physically manipulate the environment, removing typically two at a time from the environment, and moving around 10 of the markers into new poses. We are interested in seeing the "quiescent"/stable poses of the markers, and our use case does not need to track the markers frame to frame as they move. These operations probably will take around 30 seconds for the user to complete, so if it takes a second to reacquire a marker in a new location, that's still fine for us.

Hope this provides some useful context on what we're trying to do.