Mining & quarry

Three things, none of them on a spec sheet.

No GNSS underground. A handheld SLAM scanner estimates its own position from geometry and image features as you walk. There are no satellites in a decline, so nothing corrects that estimate and error accumulates over distance. This is drift, and it is the practical ceiling on how far you can walk before the cloud stops being trustworthy.

Feature-poor geometry. SLAM works best where there is structure to lock onto. A smooth uniform drive with no side openings gives the algorithm very little, which is exactly where drift accelerates. A cluttered plant room is easier for a scanner than a clean tunnel.

Access windows. You rarely get the site to yourself. Capture happens between shifts, around traffic, inside a permit, and often once.

Plan before you walk. Break the underground portion into segments with deliberate loop closures. A loop lets the SLAM solution correct itself against a place it has already been, which is the main defence against drift. Mark tie-in points at the portal and at intervals along the drive.

Fly the surface first, with RTK. Open ground has sky view, so capture it in real-world coordinates. That gives you a georeferenced surface model and known points at the portal to bridge from.

Walk the enclosed sections. Steady pace, planned segments, live preview on. Fill gaps while you are still standing near them.

Tie in. Bring the underground segments onto the surface control. Once both halves share a coordinate system they merge into one continuous model.

Verify before you demobilise. Independent check shots on anything with a stated tolerance.

Relative accuracy holds tight underground. Cloud thickness stays within about a centimetre, which governs volumes, clearances and geometry extraction.

Absolute accuracy is a different number and depends entirely on your tie-in, because nothing underground is correcting position. If your deliverable carries a stated tolerance, budget for control at the portal and at intervals, then verify with independent check shots.

Three separate figures get quoted in this category and they measure different things: RTK positioning accuracy, point cloud absolute accuracy, and relative accuracy or cloud thickness. When comparing against a survey spec use the absolute figure. When comparing two scanners, compare the same figure.

Most mining deliverables land as a registered point cloud in LAS or LAZ, tied to the mine grid, plus whatever is extracted from it: volumes against a previous surface, as-built geometry, clearance checks, or a change comparison.

The recipients are mine surveyors and geotechs working in mine planning software, so formats and coordinate systems matter more than colour fidelity. Clouds that arrive in the wrong grid, or that cannot be verified against control, get sent back regardless of density.

Two things get a deliverable rejected: coverage gaps that were not flagged, and an absolute position nobody can check.

A side drive you walked past. A stope you could not get an angle on. A wing of the plant you assumed someone else had covered.

Miss it and it stays missing. There is no post-processing fix for data you did not capture, and the second mobilisation usually costs more than the whole capture did.

The other common one is trusting brochure range on a feature-poor drive. Published range assumes something to range against. A smooth tunnel with nothing in it is the hardest case for SLAM, and it is exactly where crews assume they can walk furthest.