Does a handheld LiDAR scanner need RTK?

This is the question that decides a $9,000 difference between two handheld scanners, and most of the answers you will find online confuse two things that are not the same. Accuracy is not one number. A cloud can be beautifully accurate and completely lost.

Relative accuracy is not absolute accuracy

Every handheld SLAM scanner quotes a relative accuracy figure. The Trion P2 publishes 1.2 cm; the P1 publishes up to 2 cm. Those numbers describe how well the cloud agrees with itself. Measure between two points inside the scan and the distance will be right to about that tolerance.

Absolute accuracy is a different question: how well does the cloud agree with the rest of the world? Put it on a national grid, overlay it on a site plan, hand it to an engineer who will set out from it, and now the question is not whether the internal geometry is consistent but whether the whole thing is in the right place and the right orientation.

What an RTK module actually does here

An RTK module on a handheld scanner receives satellite signals and a correction stream, and continuously tells the SLAM solution where it is in real world coordinates. Two things follow.

The cloud is born georeferenced. There is no fitting to control afterward, no targets to place, no registration step. You walk, and the output is already on the grid.

Drift gets constrained. This is the part people miss. SLAM drifts: the solution accumulates small errors, and over a long walk, particularly through featureless space, the end of the trajectory disagrees with the start. A positioning fix that keeps arriving from outside the system pulls the solution back and stops that accumulating. On a long linear survey, a corridor or a perimeter, that matters more than the georeferencing does.

The FJ Dynamics Trion S2 carries an integrated IMU and an RTK module for exactly this. It is the only one of the three Trion scanners that does, and it is why it costs roughly $9,000 more than the Trion P2.

When you genuinely need it

• The deliverable goes on a national grid, or ties to existing survey control, or will be set out from.
• Somebody else will use the data. An engineer, a planning authority, a contractor. The moment a cloud leaves your hands, its coordinate system becomes a shared problem.
• The survey is long and linear. Corridors, perimeters, roads, pipelines. This is where drift does the damage and where a continuous outside fix earns its price.
• You are combining it with aerial data, a drone LiDAR flight or photogrammetry. Two datasets in two coordinate systems is a day of work you did not plan for.
• The scan will be repeated. Volume change, progress monitoring, deformation. Repeat surveys are worthless unless they land in the same place.

When you do not, and should not pay for it

• Interiors. There is no satellite signal indoors, so the RTK module contributes nothing for most of the walk. Our own interior sample capture was taken with no satellite signal and no control network at all.
• Floor plans, room schedules and scan to BIM, where the model lives in its own coordinate system.
• Volumes and stockpiles measured within a single scan. A volume is a relative measurement.
• As-built records that will be read rather than built from.
• Anywhere the sky is genuinely blocked. Under canopy, in a street canyon, against a cut face, inside a plant room. If the receiver cannot hold enough satellites, the RTK figure on the specification sheet describes a condition you do not have.

The routes to a georeferenced cloud without an RTK scanner

If you have a P1 or a P2 and occasionally need a georeferenced result, you are not stuck. You are just doing more work.

The honest arithmetic: if you need a georeferenced result more than a handful of times a year, the S2 is cheaper than the time. If you need it twice, an Emlid Reach RS3 at $2,999 and an afternoon of control work is the better buy, and it gives you a GNSS receiver you will use for other things. That combination is what system two on our complete systems page is built around.

A number to be suspicious of

RTK accuracy is quoted as a base figure plus a parts-per-million term, for example 0.8 cm RMS + 1 ppm. The ppm part grows with the distance from the correction source: at a 10 km baseline it adds a centimeter on its own.

So a quoted RTK accuracy without a stated baseline length is unfinished arithmetic, and the same applies to a scanner specification that quotes RTK performance without saying what it was corrected against. Ask. We publish the conditions on our own product pages for the same reason, and how we specify sets out why.

The short answer

No, a handheld LiDAR scanner does not need RTK. It needs RTK when the deliverable has to be in the right place, and it does not when the deliverable only has to be the right shape. Work out which of those two you are being paid for, and the $9,000 decision makes itself.