Skip to content

Fiducial and Corner Localization

Fiducial and Corner Localization curated visual

Visual: fiducial and corner localization chain from image evidence through marker decoding, planar PnP, map-frame composition, estimator factors, and release diagnostics.

Fiducial and corner localization uses deliberately placed visual targets to turn image measurements into pose evidence. A camera detects a marker or board, extracts corners, associates them with known target geometry, solves a 3D-to-2D pose problem, and hands the result to localization, SLAM, calibration, or docking logic with uncertainty and health metadata.

This page is the runtime measurement-model companion to Camera Projective Geometry, PnP, and Triangulation, Epipolar Geometry, Homographies, and Two-View Verification, Sensor Calibration and Time Synchronization, Active Calibration Experiment Design, Infrastructure-Aided Localization, and Calibration Bay Fixtures.


1. Scope

This page covers visual fiducials and calibrated corner targets used as pose evidence:

  • AprilTag and AprilGrid targets
  • ArUco and ChArUco markers and boards
  • checkerboards and chessboard corners
  • surveyed marker maps in managed sites
  • planar PnP and IPPE-style square-marker pose estimation
  • factor-graph handoff for localization, loop closure, docking, and calibration

It does not replace general feature-based visual SLAM. Tags and boards are useful because they encode identity, scale, and geometry, but that usefulness depends on target installation, survey quality, camera calibration, and runtime health checks.


2. Inputs and Outputs

ItemContract
Image evidenceImage timestamp, exposure state, camera ID, image frame, lens/rolling-shutter model, and preprocessing history.
Camera calibrationIntrinsics, distortion model, image size, camera-to-base extrinsic, and calibration package ID.
Target definitionMarker family or dictionary, tag ID, tag size, board layout, corner order, target coordinate frame, and printable revision.
Target surveyT_site_target, survey covariance, map tile/version, inspection date, and health state.
Detection outputCorner pixels, decoded IDs, corner order, decision margin or confidence, rejected candidates, and reprojection residuals.
Pose outputT_camera_target, optional T_site_base, covariance or quality class, ambiguity flag, timestamp, and rejection reason.

The consuming estimator should know whether a measurement is a precise pose factor, a weak pose prior, a bearing/landmark factor, an identity cue, or only a diagnostic observation.


3. Measurement Chain

3.1 Detect and Identify

A square fiducial provides corner correspondences and an encoded identity. ArUco documentation describes binary square markers where the four corners are enough to obtain camera pose, while the internal binary code supports ID checks and error detection. AprilTag adds robust tag families and detector tooling that are widely used in robotics. ChArUco boards combine marker IDs with chessboard-like corner refinement so partially observed boards can still produce ordered corner measurements.

The detector should output more than a pose:

  • detected tag or board ID
  • image-space corner coordinates and ordering
  • corner quality or subpixel refinement status
  • decode margin, Hamming/error-correction result, or marker confidence
  • rejected candidate count and reason when available
  • image timestamp and camera frame

3.2 Build 3D-to-2D Correspondences

For a square marker with side length s, the marker-frame points are usually the four target corners:

text
P0 = [-s/2,  s/2, 0]
P1 = [ s/2,  s/2, 0]
P2 = [ s/2, -s/2, 0]
P3 = [-s/2, -s/2, 0]

For a ChArUco or AprilGrid target, each detected corner has a board-frame point from the target definition. The target definition is therefore a safety-relevant artifact: wrong tag size, wrong spacing, wrong corner order, or a mismatched print revision creates a systematic pose error that can look like camera noise.

3.3 Solve the Pose

The pose estimate minimizes reprojection residuals:

text
z_i ~= project(K, distortion, T_camera_target * P_i)
r_i = z_i - project(...)

For square planar markers, OpenCV exposes SOLVEPNP_IPPE_SQUARE as a marker pose-estimation option. IPPE-style solvers are useful because planar pose can have ambiguous solutions, especially when a tag is nearly fronto-parallel, small, far away, or observed with few pixels. Production systems should keep ambiguity and residual diagnostics instead of accepting only the lowest-cost pose.

3.4 Compose Into the Vehicle and Site Frames

A marker pose becomes localization evidence only after the transform chain is explicit. With the convention T_a_b maps coordinates from frame b into frame a, one common chain is:

text
T_site_base =
  T_site_target *
  inverse(T_camera_target) *
  inverse(T_base_camera)

Here T_camera_target is the PnP output, T_base_camera is the calibrated camera extrinsic, and T_site_target is the surveyed target pose. The exact notation can differ by library, and some APIs return the inverse transform. The release artifact should state the frame convention and transform direction so a tag observation is not silently inverted.

3.5 Hand Off to Estimation

Common handoff patterns:

PatternUseReview question
Pose priorStartup, bay entry, charger approach, docking reset candidateIs it covariance-bounded and compatible with current map version?
Landmark factorSLAM or localization graph with known target poseAre ID, survey covariance, corner residuals, and camera calibration included?
Loop-closure factorVisual relocalization or TagSLAM-style graph constraintWas the association verified against geometry and zone policy?
Calibration checkCompare expected and observed target poseDoes residual drift trigger maintenance rather than silent calibration rewrite?
Identity cueSelect dock, stand, shelf, charger, fixture, or map tileIs semantic identity separated from metric pose confidence?

4. Failure Modes

Failure modeHow it appearsMitigation
Planar ambiguityTwo plausible poses from a nearly fronto-parallel or low-pixel markerUse IPPE/generic multi-solution checks, distance limits, multi-marker boards, and estimator priors.
Wrong tag size or board layoutConsistent but biased translation or scaleVersion target definitions and print manifests with the map/calibration package.
Reused or ambiguous IDsVehicle localizes to the wrong dock or aisleUse site-unique ID namespaces, zone gating, and map-version compatibility checks.
Corner blur or rolling shutterHigh residual, yaw bias, pose jitterGate by corner quality, exposure/motion state, and rolling-shutter timing evidence.
Bad intrinsics or distortionResiduals vary by image region and rangeRevalidate camera calibration and use holdout views at multiple depths.
Marker damage or contaminationIntermittent detection, wrong decode, biased corner fitInspect targets, log rejected candidates, and remove unhealthy targets from active manifests.
Survey driftA moved marker remains visually detectable but map-inconsistentTreat target pose as a versioned surveyed asset with covariance, inspection, and rollback.
Map-version mismatchTag observation is fused against the wrong site frameBind marker manifests to map tiles and reject incompatible versions.
Overconfident single-tag updateEstimator jumps from one visually clean but wrong observationUse robust factors, covariance inflation, multi-sensor agreement, and no-hard-reset policy.

5. Domain Fit

DomainFitNotes
Warehouses and indoor AMRsStrongTags, ChArUco boards, shelf markers, dock markers, and charger targets are easy to survey and maintain.
Loading docks and logistics yardsStrong in controlled zonesDoor markers and dock boards help final approach, but weather, truck occlusion, and dirt require health checks.
Airport aprons and hangarsStrong for managed bays, weak as global truthHangars, calibration bays, stands, chargers, and docking funnels can use surveyed tags; open aprons still need LiDAR/GNSS/map fallback.
Ports and minesModerateMarkers work around workshops, chargers, portals, and controlled entrances, but dust, vibration, and large equipment increase maintenance burden.
Outdoor campusesModerateUseful for building entrances, robots docks, gates, and service corridors; less reliable under glare, vandalism, and weather.
Public-road AVsLimitedRoadside marker ownership and coverage are inconsistent; treat tags as local aids or work-zone fixtures, not the default localization backbone.

6. Implementation Notes

  1. Keep tag maps in the same artifact system as map tiles, calibration packages, and route releases.
  2. Store target size, spacing, layout, dictionary/family, printable revision, and physical installation record.
  3. Log accepted and rejected detections, not only fused poses.
  4. Publish covariance or quality classes that distinguish high-resolution board observations from distant single-tag observations.
  5. Reject observations with unknown camera calibration, unknown map version, stale timestamp, unhealthy target, or repeated ID outside the expected zone.
  6. Use multi-marker boards or multiple viewing poses when the update can change a safety-relevant vehicle pose.
  7. Treat automatic calibration updates as proposals unless a release workflow has explicitly approved online calibration changes.
  8. Test failure cases: partially occluded tags, dirty tags, wrong tag size, duplicate IDs, rolling shutter, low light, motion blur, and map rollback.

7. Release Evidence

A reviewable release package should include:

  • camera calibration package and timestamp policy
  • target manifest with surveyed poses and covariance
  • marker dictionary/family and board definition files
  • transform-direction convention for each output pose
  • replay logs with accepted, rejected, and ambiguous detections
  • residual and corner-quality distributions by target, range, and image region
  • estimator innovation/NIS or factor residual checks after fusion
  • maintenance state for each physical target
  • rollback behavior when a target or map tile is retired

8. Boundaries With Adjacent Pages


Sources

Public research notes collected from public sources.