AR Marker Tracking: Homography Pose Estimation

Marker Placement

Distance from camera 1.40 m

Viewing tilt (foreshortening) 15°

Camera / Sensor

Detection noise σ 3.0 px

Tracking Telemetry

Tracking confidence100%

Reprojection error

0.0 px

Position error

0.0 cm

Rotation error

0.0°

Corners locked

4 / 4

How it works

A square fiducial marker (like an ArUco tag) has four known corners in its own local plane. The camera detects those corners as noisy pixel coordinates and recovers the marker's 3D pose with a planar homography:

[u]       [X]
[v] ~ H · [Y]      H is 3x3, solved from 4
[1]       [1]      point correspondences (DLT)

Given camera intrinsics K, the homography columns decompose into rotation and translation:

h1,h2,h3 = columns of H
λ  = 1 / |K⁻¹h1|           (scale from calibration)
r1 = λ·K⁻¹h1,  r2 = λ·K⁻¹h2
r3 = r1 × r2                (right-handed basis)
t  = λ·K⁻¹h3

This is exactly how single-marker AR anchoring works in engines like ARKit's image tracking or OpenCV/ArUco: [r1 r2 r3 | t] places the virtual game object in the camera's coordinate frame every frame. Detection noise (motion blur, low light, glare) perturbs the corner pixels, which propagates through the same math into position and rotation jitter — the reprojection error readout is the pixel gap this produces, and confidence is derived from it.

Distance / tilt — move the physical marker; a shallower viewing angle shrinks the marker in the image and makes the homography more sensitive to noise.
Noise σ — simulated corner-detection jitter (pixels), added independently to each of the 4 corners every frame.
Tracked vs. Ground truth — compare the algorithm's recovered pose against the marker's real transform.

green = true · red = detected

Virtual game object (tracked) Fiducial marker

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.