PhotonVision / photonvision

PhotonVision is the free, fast, and easy-to-use computer vision solution for the FIRST Robotics Competition.
https://photonvision.org
GNU General Public License v3.0
275 stars 190 forks source link

Limit Valid AprilTag IDs #729

Open hamster1147 opened 1 year ago

hamster1147 commented 1 year ago

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 commented 1 year ago

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

mdurrani808 commented 1 year ago

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

hamster1147 commented 1 year ago

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 commented 1 year ago

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 commented 1 month ago

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.