Limit Valid AprilTag IDs

[hamster1147]

Feature Request: Limit which tag IDs are expected and valid, and reject potential false positives that aren't these IDs. For example, FRC 2023 we only expect to see tags 1-8. Potentially, we only expect to see the tags that are related to our team only, limiting it to only 4 tags possibly.

[mcm001]

Is there a reason this can't be done in user code?

[mdurrani808]

I wonder if we can just make a custom AprilTag dictionary in our code in order to save some performance.

[hamster1147]

Sorry for not responding.
It could be done via user software, but the idea was to potentially help with performance on the off board processor.

I wouldn't know if the performance gain is worth the effort of the task, not being an active participant of the code base, but I figured I would mention it since I didn't see mention of it in the other issues. The thought was that if there was any processing happening after the ID acquisition, like Pose estimation solving, it might be worth ignoring certain tags, or false positives to save on performance.

[srimanachanta]

Sorry for not responding. It could be done via user software, but the idea was to potentially help with performance on the off board processor.

I wouldn't know if the performance gain is worth the effort of the task, not being an active participant of the code base, but I figured I would mention it since I didn't see mention of it in the other issues. The thought was that if there was any processing happening after the ID acquisition, like Pose estimation solving, it might be worth ignoring certain tags, or false positives to save on performance.

internalizing the rejection of tags based on a field layout wouldn't be necessary as there are times, such as testing when you wouldn't want a limitation on tags. Also, correct me if I'm wrong, but it wouldn't offer any advantage on the field because no other tags would exist on the field. The only advantage would be in a testing scenario, and even then, the actual part of "detecting" the tag's id occurs at the end of tag detection, it wouldn't bring much performance benefits.

[mcm001]

Yeah it's a bit spooky that we currently have this state information spread between the coprocessor and user code, and no mechanism for feedback if the two are out of sync. But users also expect to be able to just use photon standalone and for multi-tag to work with it needing a robot program with some magic config code set.