Ghost tag detection

[manan-peppermint]

Describe the bug
The AprilTag detection code correctly identifies tags in images, but it randomly and frequently detects tag IDs on the ground or on various objects, even when no tags are present at those locations.

To Reproduce
Steps to reproduce the behavior:

Run the opencv_demo from the examples folder with provided images.
Observe the detection results for instances where non-existent tags are identified.

Expected behavior
No ghost tags should be detected; the algorithm should only identify actual tags present in the images.

Input Image

Screenshots

Operating Sytem
Ubuntu 22.04

Installation Method
I built AprilTag from source following the instructions in the README.

Code version
Current GitHub HEAD

Additional context
To troubleshoot the issue, I initially used a static image and tuned the parameters to minimize faulty tag detection. This approach worked with other images captured simultaneously. However, upon deploying the detection on fresh images, the issue of detecting ghost tags reappeared. Despite using the same commit from the AprilTag main branch, the problem persists.

[christian-rauch]

opencv_demo uses the live feed from the webcam. Can you provide a reproducible example with the apriltag_demo on those images?

Generally, false positive detections are always possible, and some tag families work better than others. For example, the tag16h5 has a higher false positive rate than tag36h10. There are also some parameters to pre-process the images and fine-tune the detection. If this is not a regression (it does not perform worse than before), I would not consider this a bug.

[manan-peppermint]

I am attaching an image with the same issue by using apriltag_demo with default parameter. In the image there is tag with id 2 which the scripts detects correctly but it also detects ghost tag with id 43.

[mkrogius]

I'm surprised that detection is showing up, I would have expected the min corner angle check to invalidate it.

I don't think I have time to look deeper into this right now, but here are some workarounds for this issue:

1. Switch to using the tagStandard41h12 family, or any other family with even more bits. This is usually not necessary, normally 36h11 is a very reliable family.
2. Set the min_white_black_diff param higher
3. Set the min corner angle threshold higher. It's in the quad thresh params

[christian-rauch]

I can reproduce this with essentially the default arguments for apriltag_demo. Changing the decimate to 1 or at least 3 fixes the problem:

apriltag_demo -d -x 1 383553803-9a099836-dc32-4a86-9d1a-4f21aa5c0688.jpg

[christian-rauch]

If you need a quick solution for your application and want to keep the decimate of 2, you can filter the detections by their decision_margin. This is the last value in the output and is higher the better the detection is:

detection   0: id (36x11)-2   , hamming 0, margin   62.838
detection   1: id (36x11)-43  , hamming 1, margin    1.125

So if you just set a threshold of e.g. 10 there, you can ignore tag 43 and keep tag 2.

[finickyDrone]

decision_margin

Hi Christian, thank you for this suggestion. We are running into this exact same issue with tag family 16h5 and cannot change to a different family.

Your idea of setting a threshold for decision_margin should fix our problem since the mis-detections are all below 2.

What do you think is the most straight forward set a decision_margin threshold in the Apriltag library? Ideally we'd like to be able to set this value from a yaml configuration file or command line, but it doesn't seem like that is something currently supported? Would it make sense to add a threshold here?:
https://github.com/AprilRobotics/apriltag/blob/master/apriltag.c#L953

Thanks!

[christian-rauch]

What do you think is the most straight forward set a decision_margin threshold in the Apriltag library? Ideally we'd like to be able to set this value from a yaml configuration file or command line, but it doesn't seem like that is something currently supported?

The apriltag library does not have a function to load parameters via a yaml file in general. And as you can see from the example programs, only those have to option to read command line arguments via the getopt_t structure.

Then, a threshold on the decision_margin is currently not supported. You have to add this functionality manually.

When you check how parameters are passed to the detector, you will find the apriltag_detector_t structure, which also contains the apriltag_quad_thresh_params structure. So in general, the best way to pass another argument to the detection pipeline would be somewhere there.

See where this fits best in the pipeline. Maybe we need another parameter subset in apriltag_detector_t, next to apriltag_quad_thresh_params.

[manan-peppermint]

Thank you, Christian, for suggesting the fix of using the decision margin, which worked perfectly for our requirements. Also, thank you, Max, for recommending parameter tuning for improved detection—it was very helpful.

[christian-rauch]

If you use such a parameter, can you send a PR that with some documentation?