In one practitioner’s account, industrial AR programmes stalled on content prepared one asset at a time. In AR collaboration tools, session stability on spotty connectivity depends on the network carrying shared data, the tracker holding its pose and the runtime keeping the session alive. In one practitioner’s account, post-mortems blamed the hardware. That practitioner puts the stall down to content cost, and an interview study points to organisational barriers.
The demo worked; asset thirty did not
One industrial practitioner, writing in Automation World about pilots that failed to scale, puts it bluntly: what broke was the step from one machine to two hundred, and while the hardware complaints (weight, narrow field of view, short battery life) were accurate, none of them was the reason. The reason was content cost. Standing up an experience for a single piece of equipment meant converting CAD with tens of thousands of parts into something a handheld renderer could carry, a person spending days deciding which brackets and fasteners mattered, and then preparing a tracking target so the application could lock graphics onto that specific machine. Because a fleet is really equipment families, variants and years of revisions, almost none of that preparation carried over from one asset to the next.
In the author’s account, that per-asset arithmetic shut down more programmes than any headset did, and it has nothing to do with the display the picture appears on. The same author points to vision models that recognise equipment from a camera feed as the change that matters: preparation still has to happen, but it scales with equipment families instead of individual machines.
The organisational side tells a matching story. An interview study from the Technical University of Munich (TUM) describes a “Pilot Trap”, in which technically successful proofs of concept are neither moved into production nor formally stopped, and stay parked in innovation labs. The study found that change management, KPI alignment and political resistance have overtaken technological maturity as the dominant barriers. In that study, pilots succeeded on their own terms but failed strategically because they never changed the underlying processes, so everything went back to normal once the pilot ended.
A pilot built on one asset with no agreed KPI produces a convincing demo and no evidence about either the content curve or the business case. Readers who need the basics first can start with our augmented reality explainer. For the beauty vertical, see our page on AR makeup try-on on phones.
Which hardware limits actually stop an AR pilot reaching production?
Hardware was not the stall reason in that account, but thermal headroom, tracking sensors and form factor still matter.
Thermal limits show up under sustained load. The OpenXR specification says plainly that XR applications run at high performance for long periods, and that on shrinking mobile form factors, reaching die, skin or battery temperature limits makes the device cut heat generation, causing severe performance reductions in the form of dropped frames and high latency. The same specification defines a boost level that goes beyond the thermally sustainable range and is meant only for short stretches of under 30 seconds. The Fraunhofer IIS study of ARCore, ARKit and HoloLens notes that these systems limit tracking accuracy on purpose to keep frame rate up, battery drain down and hardware temperature in check, because otherwise the whole system can fail.
Tracking hardware is the second limit. A 2025 arXiv study of five commercial XR devices found performance gaps of up to 2.8 times between devices, closely tied to sensor configuration and dedicated processing units. Camera count matters: devices with fewer tracking cameras degraded badly in featureless environments, and the XR2U’s absolute pose error during high-speed inspection rose by 101% when it moved from a feature-rich to a featureless room. The older HoloLens 2, unlike devices with dedicated sensor co-processors, lagged behind ground truth during rapid head rotations.
Form factor is the third, and it changes which of these failures you are exposed to:
| Form factor | Where it fits | Failure modes it brings forward |
|---|---|---|
| Handheld (phone, tablet) | Per the Automation World author: most maintenance work, on cost, certification and lifecycle | No hands-free use |
| Headset | Per the Automation World author: jobs that need both hands and the technician’s gaze | Motion-to-photon comfort |
| AR glasses | The 2025 device study’s authors observed noticeably poorer performance in XR glasses | A growing developer burden to minimise user movement as more glasses arrive |
Projection mapping is left out here, since none of the studies cited measures it.
The latency budget: where the 20 milliseconds go
Motion-to-photon latency is the time from a tracked movement to the matching change of photons on the display, and when it is high it causes cybersickness in VR. The thresholds in the sources are close but not the same. A 2018 arXiv paper on low-latency, ultra-reliable VR says rendered-image latency above 15 ms can cause motion sickness, and elsewhere uses 20 ms or more as the sickness limit in its model. Varjo, as a headset vendor, says video pass-through latency under 20 ms is undetectable in normal interaction and good enough to avoid simulator sickness. We treat 15 ms as the conservative design target and 20 ms as the ceiling, since the stricter figure is the safer one to build against. IEEE P3079.1 specifies requirements and test methods for the motion-to-photon latency that causes VR sickness.
Worked example: splitting the budget
The 2018 paper splits end-to-end wireless VR latency into sensor sampling, compute (image processing or frame rendering), network (queuing and over-the-air) and display refresh delay.
| Stage | Contribution | Notes |
|---|---|---|
| Sensor sampling | under 1 ms | Considered imperceptible |
| Display refresh | about 10-15 ms | Expected to fall to 5 ms |
| Compute plus communication | 14 ms remaining | Assumes the display falls to 5 ms |
Working: the paper’s 14 ms of room only exists once display delay drops to about 5 ms. By our arithmetic, at the paper’s 10-15 ms of display delay, a 20 ms ceiling leaves roughly 4-9 ms for rendering and network combined (20 minus 1 minus 15, and 20 minus 1 minus 10). Offloading rendering to a remote server lightens the headset GPU but adds communication delay in both directions, and for AR, unlike VR, the uplink may have to carry video. That is why the same paper argues for mobile edge computing close to the user, which it expects to bring communication delay below 1 ms in metropolitan areas.
Averages hide the spikes that make people sick
Most latency studies add a fixed delay, but measured latency often shows irregular spikes, and occasional spikes as well as periodic latency have been shown to provoke cybersickness. VR and AR systems run on operating systems tuned for throughput rather than guaranteed response times, so unpredictable spikes can appear even in a system whose latency was acceptable before. The review notes that networked applications usually look at the 95th, 99th and 99.9th percentiles, and that more research is needed to know whether the 95th or 99th is enough. Latency also varies with device, software configuration, input method and usage pattern, and is often measured under optimised, artificial conditions.
So a pilot should report a latency distribution, not a mean, measured during the content density and movement the real job involves. Prediction and timewarp help, but the review cautions that manufacturers’ prediction can fail and introduces side effects such as over-anticipation.
How latency, tracking and content density compound during scale-up
Tracking error rises with movement speed. In the 2025 device study, faster movement increased error on every device, and the HoloLens 2’s absolute pose error in the feature-rich shift motion went from 9.80 cm to 16.06 cm, a 64% rise. Low-feature environments made the speed penalty worse. All five devices stayed within VR tolerance on average but exceeded the stricter requirements of AR work such as industrial maintenance. In a dynamic industrial setting, the Fraunhofer IIS study found out-of-the-box SLAM accumulated an average error of about 17 m per 120 m walked, with scaling error up to 14.4 cm/m. The systems tended to crash when a user moved while a nearby object such as a forklift moved alongside, and became unstable when workers walked in and out of view and hid known features. The same study concludes that these systems suit industry settings only where surroundings are static and routes between cubicles are short, with smooth changes of direction.
The 2025 study did not vary GPU load, but it cites earlier work showing that resource contention significantly affects tracking accuracy. To see how compute work competes with rendering and tracking on the headset GPU, read our guide to DirectCompute GPU compute shaders for XR workloads. OpenXR runtimes may pause tracking of a spatial entity when there are too many entities and the runtime wants to cut tracking cost. On the comfort side, Varjo lists laggy or inaccurate hand tracking as a cause of motion sickness, because the hand does not follow the user’s sense of their own limb quickly enough. The OpenXR specification states that comfortable XR depends on delivering frames quickly and consistently.
The TUM interviewees reported that a first XR experience involving cybersickness or a frustrating interface can make employees resist adoption for years.
AR collaboration tools: session stability on spotty connectivity
In a shared AR session, the app transmits shared data, the tracker can lose its pose, and the session itself can be lost. ARKit and OpenXR define what the application must handle in each case.
Apple’s ARKit collaborative session, as described at WWDC19, shares learned map information and anchors continuously for the whole session, using a peer-to-peer design with no host, so users can join or leave without interrupting others. The session generates collaboration data periodically, but it is the app’s responsibility to transmit that data to the other users over a networking layer that provides reliable communication. Anchors are stored and transmitted as positions relative to nearby views, so users with different world coordinates still see them in the right physical place. A shared experience only starts once each user has localised against another user’s map, which means seeing an area someone else has already seen, and that can take time depending on how people move. On a lossy link, the reliability of that transport and the time to relocalise are the stability budget.
On tracking loss, OpenXR says runtimes should keep providing inferred or last-known poses (from a neck model, inertial dead reckoning or a last-known position) while it is still reasonable to use them. The runtime keeps the position-valid bit set but clears the position-tracked bit, so the application can tell a measured pose from an inferred one. Applications must not read view position fields when the valid bit is unset. An application that ignores the tracked bit renders shared content confidently in the wrong place. When the runtime can no longer operate the session, for example after losing a display hardware connection, it signals a loss-pending state, and the application should destroy the session and can recreate it.
Data overlays need the same discipline. The Automation World author argues that live telemetry overlays must fail in the open: when the link drops, no technician should still be looking at yesterday’s reading, and if the software cannot identify which revision is in front of it, it should hand back the ordinary procedure. The 2018 paper models a similar fallback for rendering, where users compute a low-resolution frame locally when HD frame delivery fails. It also notes that temporary outages are common in wireless environments, and that multi-connectivity reduces dropped connections and radio-link failure. At millimetre-wave frequencies, the human body alone causes around 20-35 dB of attenuation.
Checklist for a shared session on an unreliable network
- The app transmits collaboration data over a networking layer that provides reliable communication.
- Rendering inspects the location flags to tell a tracked pose from an inferred one.
- Telemetry overlays fail in the open and hand back the ordinary procedure when the link is lost.
- A local low-quality rendering path exists for frames that miss their delivery deadline.
- Session loss-pending and instance-loss events lead to destroying and recreating the session or instance.
- Latency is reported as percentiles, not only as a mean.
Does OpenXR reduce integration debt when a pilot moves toward production?
It removes device-specific code, according to Khronos; the telemetry interface an overlay needs is separate work.
Khronos’s OpenXR spatial entities extensions, the result of over two years of cooperative design between runtime and engine vendors, cover plane tracking, marker tracking, spatial anchors and spatial persistence. Khronos says these common interfaces are portable across XR runtimes and hardware platforms and remove the need for device-specific code on each platform. Anchors counter drift: as the runtime’s map updates, virtual objects can appear to drift, and rendering each object relative to a nearby anchor keeps it in place. Objects that must stay fixed relative to each other should share one anchor, because separate anchors adjust independently.
Persistence lets content survive across sessions, but only within states the application must handle. A persisted anchor is identified across sessions by a UUID, and a lookup comes back either loaded or not found, with not-found entities marked as stopped and never tracked again. Persisting fails with an entity-not-tracking result if tracking is lost before the operation completes. Cloud persistence brings vendor risk as well: Microsoft’s sample notice states that Azure Spatial Anchors, a cross-platform service for objects that persist their locations across devices, was retired on November 20, 2024. Building on a standard interface reduces the rework when a service like that disappears, though it does not remove it. The TUM study found that providers publishing multi-year hardware roadmaps with update grace periods would ease adoption.
A live overlay needs a REST or MQTT route into the edge layer that already feeds the operator HMI, and where that interface is missing, building it tends to get billed to the AR project. In the TUM study, lack of IT integration and undefined ROI models came up as critical bottlenecks.
How should an XR pilot be scoped to deliver an honest go/no-go in 12 weeks?
An honest pilot tests the things that killed earlier ones (content cost across assets, sustained latency and tracking under real conditions, session recovery, and a KPI the business owns) and produces something useful at each milestone. The Automation World author’s advice is to build one workflow across many assets rather than many workflows on one asset, and to prefer recognition over per-asset registration even at some cost in accuracy, because registration fails at asset thirty, not asset two. The TUM study’s highest-performing programmes started from the operational problem rather than the technology, and defined KPIs that gave measurable gates from proof of concept to pilot to scale. Its interviewees said those KPIs should come from the adopter, not the provider.
Two of our working positions shape how we would set up such a pilot. Feasibility and ROI come first: we establish whether the expected outcome is plausible with current capability before scaling anything, and repeatable tasks with measurable value are far more likely to pay off than ambitious ones. Each milestone must also produce a usable artefact, because a project whose only value arrives at the end loses momentum and usually fails.
| Weeks (indicative) | What the pilot tests | Packageable output |
|---|---|---|
| 1-2 | The operational problem, the adopter-owned KPI, and the data interface available | Written go/no-go criteria |
| 3-6 | One workflow across several assets and equipment families | Content cost per asset family |
| 7-10 | Full-shift runs: thermal warnings, latency percentiles, tracking error in the real environment | Measured risk register |
| 11-12 | Drop and recovery: link loss, tracking loss, session recreation | Recommendation with evidence |
The week split is our scoping judgement, not a published benchmark. A “no-go” backed by those four outputs is a good result. It ends the pilot instead of leaving it to drift on for years, waiting for better times.
FAQ
What are the disadvantages or problems of using VR?
High latency, low refresh rates and laggy hand tracking can all cause simulator sickness, according to Varjo’s guidance. The Frontiers in Virtual Reality review (2020) adds that latency jitter and periodic latency patterns also contribute to cybersickness.
Is high latency good or bad?
In VR it is bad: the same review states that low latency increases usability and safety, while high motion-to-photon latency can provoke cybersickness.
How do you minimise latency in a network for VR or AR?
The 2018 arXiv paper on ultra-reliable VR points to mobile edge computing close to the user, proactive caching of predicted frames, and multi-connectivity to cut dropped links.
