AprilTag Print Size and Glare Can Break a Robot Demo Before the Code Does

AprilTag demos can fail for reasons that have nothing to do with the detection library. The tag may be too small for the camera distance. The border may be cropped. Glossy lamination may create glare. The target may be mounted at a bad height, the camera may be out of focus, or the lighting may change between practice and the final demo.

FIRST Tech Challenge documentation emphasizes camera calibration for AprilTag use, and OpenCV’s camera-calibration tutorial explains the broader geometry problem. TVG’s earlier AprilTag layout mistakes checklist covered field placement. This support guide narrows in on print size and glare because they are easy to overlook and easy to fix.

Quick answer

Before rewriting AprilTag code, verify the printed tag size, border quality, matte finish, camera distance, lighting, focus, and calibration. A reliable vision demo starts with a target the camera can actually see.

The paper target is part of the system

A fiducial marker is not just an image on paper. It is a physical object in a lighting environment. If a team scales the tag in a print dialog, trims the border, tapes it to a shiny surface, or mounts it where the robot sees it at a steep angle, the detector may produce inconsistent results even when the software is unchanged.

That is frustrating for students because the symptom looks like a code bug. The better habit is to treat the target, camera, lens, lighting, and course layout as one measurement chain.

Checklist before model or code changes

• Confirm printed size: measure the physical tag after printing, not only the file size.
• Keep the border clean: do not crop or cover the quiet zone around the marker.
• Use matte mounting: glossy tape or lamination can create detection-breaking glare.
• Test real distance: place the robot at the farthest distance expected during the demo.
• Lock focus and exposure when possible: automatic settings can change the target between frames.
• Repeat under demo lighting: practice-room lighting may not match event lighting.
• Save failed frames: bad images are better debugging evidence than memory.

A useful failure log

When detection fails, write down the distance, angle, lighting, exposure mode, tag size, and whether the robot was moving. Save one good frame and one bad frame from the same setup. If the bad frame is blurred, washed out, cropped, or reflecting overhead lights, the next fix is physical setup before software.

Teams can make this a quick pre-match routine. Photograph the tags, run the robot at the longest expected distance, check the camera view, and verify that the same target is detected several times in a row. That simple discipline often catches the problem before the pressure of a live demo and creates evidence the next student can understand.

TVG Take

AprilTag reliability is a systems problem. The code matters, but so do print size, glare, target mounting, camera calibration, lighting, and course geometry. Teams that document those variables will debug faster and build better robot-vision habits than teams that only keep changing software.

Sources

• FIRST Tech Challenge: AprilTag camera calibration
• OpenCV: camera calibration tutorial
• TVG Report: AprilTag layout mistakes checklist