“Augmented reality in stadiums” is not one system. It is at least three, and they share almost nothing except the word overlay: handheld single-device AR, venue-scale shared tracking, and broadcast-side AR that never touches a spectator device at all. Conflating them is what turns a working pilot into a budget line that cannot be delivered.
The concept film is familiar — player stats floating above a phone camera, a shared holographic replay hanging over the pitch for sixty thousand people. Some of that ships today. Most of it ships only in the first category, on one device, in controlled conditions.
Which three systems hide behind the phrase?
| Category | What it actually does | Primary unit of measurement | Hard dependency |
|---|---|---|---|
| Handheld single-device AR | Camera-based overlay on one phone or tablet; tracking is local to that device | Registration drift over a session; frame-to-overlay latency | On-device compute, lighting |
| Venue-scale shared tracking | Thousands of devices localised against one shared coordinate frame | Localisation error in centimetres; concurrent sessions per cell | Venue connectivity, edge compute, survey-grade venue map |
| Broadcast-side AR | Overlay composited into the video feed; no spectator device involved | End-to-end latency against the live feed; camera-pose accuracy | Instrumented cameras, production pipeline |
The middle row is the hard one. Localising many devices against a single frame in a crowded, badly lit, RF-contended bowl is a different engineering problem from tracking one device in an empty concourse — and a demo of the latter is not evidence for the former.
The units a claim has to name
A stadium AR proposal is procurement-relevant only if it states four things: the localisation error it requires, the end-to-end overlay latency budget (typically tens of milliseconds before registration drift becomes visible to the user), the concurrent-device count at peak, and the network capacity that count implies. Where a claim cannot be expressed in those units, the correct action is to exclude it from the roadmap rather than budget against it.
Note that these units split across two disciplines. Tracking, registration, and occlusion handling are computer vision problems — the same territory as visual SLAM, feature matching, and depth estimation, and the reason ARKit and ARCore exist as platform layers at all. Concurrent sessions, backhaul, and edge placement are connectivity and compute-siting problems. A vendor who is strong on one usually inherits the other as a risk, and in our experience that inheritance is where pilots stall.
What falsifies a stadium AR demo
Ask what condition would break it, then check whether the demo included that condition:
- Crowd density — bodies occlude the visual features the tracker was localising against.
- Variable lighting — floodlights, dusk kickoff, and stadium screens change the scene appearance the map was built under.
- Network contention at kickoff — the worst RF minute of the day is also the peak-session minute.
- Device heterogeneity — a fleet ranging from current flagships to five-year-old handsets does not share a latency budget.
A pilot run midweek in an empty venue on two identical loaner phones has falsified none of these. That is not a criticism of the pilot; it is a statement about what the pilot licenses you to conclude.
One more reading habit: when a claim makes no reference to spectator devices, it is almost certainly broadcast-side AR. That category is mature and shipping — and it says nothing at all about whether anyone in the stand can see an overlay.
We apply the same unit-and-falsifier discipline to trend claims generally in how to evaluate predictions about AI, and the underlying vision work sits with our augmented reality engineering practice. For the wider capability picture, start from the TechnoLynx homepage.
So the question to put to the next stadium AR pitch is not “does it work?” but “which of the three is this, and what would have to happen for it to stop working?”
