Why Augmented Reality Field Apps Fail Outdoors

There is a category of augmented reality application that demos beautifully and fails in the field, and it fails for a reason that has nothing to do with AR.

We built an AR application for a UK client for visualising buried utilities — water, gas, power, telecoms — in three dimensions, so that someone standing on a verge with a phone can see what is under the tarmac before anyone breaks it. The same shape of problem turns up in construction, surveying, and any inspection workflow where a model has to line up with the physical world.

The tracking works. The registration does not.

Modern AR frameworks are good. Point a phone at the ground, and it will build a plane, hold an object on that plane, and keep it there as you walk around. That capability is essentially free now.

What the framework gives you is a local coordinate system: it knows where the phone is relative to where the session started. What it has no idea about is where that origin sits on the Earth. And a utility record is expressed in real coordinates — a national grid reference, a depth below surface.

So the actual problem is registration: aligning a local AR session to a global coordinate frame, accurately enough that the pipe drawn on the screen is over the pipe in the ground. Everything difficult about this class of application lives in that sentence.

Consumer positioning is not good enough, and it is worse than it looks

A phone's built-in positioning is accurate to a handful of metres in the open, and considerably worse next to buildings, where signals bounce. On the kind of street where somebody is about to dig, multipath error is the normal condition, not the exception.

A few metres of horizontal error is catastrophic here. Utility corridors sit within a metre or two of each other. Draw the gas main three metres from where it is and you have not built a safety tool, you have built a liability — one that is more dangerous than no tool at all, because it looks authoritative.

Heading is worse still. The magnetometer is what tells the app which way the phone is facing, and it is disturbed by exactly the things that are present at a utilities job: reinforcing bar in concrete, cast-iron covers, vehicles, and the buried metal services the app exists to display. A heading error of a few degrees rotates the whole model around the user, so the error grows with distance — the alignment can look plausible underfoot and be metres out at the end of the street.

The practical answer is to stop treating the device's own estimate as the source of truth. Take a position from an external receiver over Bluetooth where the job justifies it, or have the user register the session against known physical features — a cover, a marker post, a surveyed point — and derive the transform from those. Both approaches replace "trust the phone" with "trust something that was actually surveyed", which is the only version of this that a field engineer should rely on.

Sunlight, gloves, and a phone held at arm's length

The environmental assumptions in most AR interface design are indoor assumptions.

Outdoors, the screen is competing with the sun. Thin lines and subtle transparency — the visual language that makes AR overlays look elegant in a demo video — become invisible. What survives direct sunlight is high contrast, thick strokes, and solid fills. The overlay has to be designed for the worst lighting it will meet, not the best.

The user is also wearing gloves, possibly high-visibility clothing, standing in a live carriageway, and holding the phone one-handed because the other hand has a tool in it. Every interaction has to work with a large, imprecise touch target, and nothing important can live at the top of a large screen.

And they are looking at a road while a phone occupies their vision. An AR app here has a genuine attention-safety dimension: the interface should encourage short looks, not sustained ones, which argues for a display that can be understood in a glance rather than one that rewards study.

Battery and thermal limits set the session length

AR runs the camera, the motion sensors and the GPU continuously. On a phone in direct sun, that combination reaches thermal throttling quickly, and throttling degrades tracking before it degrades anything the user can see — so the symptom is drifting alignment, not a warning.

This shapes the workflow. An app that assumes a continuous AR session across a whole site visit will not survive one. An app that treats AR as a mode entered for a specific check and exited afterwards, with the underlying data browsable in a plain 2D view, will. The 2D view is not a fallback; on most sites it is where most of the time is spent, and it deserves the same design attention as the AR.

What this means before you commission one

If you are considering an AR field application, the questions that decide whether it will work are not about AR:

What accuracy does the decision require? Centimetres and metres are different products with different hardware.

Where does the positional truth come from? If the answer is the phone, the accuracy answer above needs to be generous.

What is the data quality? Buried-asset records vary from surveyed to approximate, and an AR overlay presents both with identical confidence. The interface has to carry the uncertainty of the underlying record, or it will launder a rough sketch into an apparent measurement.

What happens with no signal? Sites have no coverage. The data has to be on the device.

AR is a display technology. It shows the answer; it does not know it. Almost all of the engineering in a working field application is in getting the answer right before AR ever gets to draw it.

---

iLeaf has delivered AR applications for infrastructure and field-service clients alongside fifteen years of mobile engineering. See our work or tell us what you are planning.