What RTK actually does inside a SLAM scanner, and why pseudo-fix is the silent killer

No audio available for this content.

Ask a room of surveyors what the RTK module in a handheld SLAM scanner does, and most will give the rover answer: it tells the scanner where it is. It is a reasonable guess, and it is wrong in a way that matters. Inside a SLAM scanner, RTK is not a positioning device. It is a global anchor — and understanding the distinction is the difference between a point cloud that lands on datum and one that is quietly warped from end to end.

Why SLAM needs an anchor at all

A SLAM engine estimates its own motion from what its sensors see. Every frame, the front end compares new lidar, IMU, and camera data against the previous frame and answers one question: how did I just move? Stitch those estimates together and you get a trajectory and a growing point cloud.

Each estimate is off by a tiny amount — a fraction of a millimeter. Over one second, invisible. Over a hundred meters of walking, those fractions accumulate into centimeters; in feature-poor environments, much more. This is drift, and it is not a bug. It is the fundamental cost of computing “where am I?” from scratch, and every SLAM system on earth pays it.

Loop closure is the classic remedy: when the scanner recognizes a place it has seen before, the back end pulls the whole trajectory back into self-consistency. But loop closure only makes the model agree with itself. It says nothing about where the model sits in the real world, or whether it is level, or whether north is north. For that, the engine needs information from outside its own sensors — an anchor.

What a genuine fix contributes

That is the actual job of RTK in this architecture. When the receiver is in a genuine Fixed state, each sample hands the SLAM engine a centimeter-level absolute position: at this instant, I know exactly where I am. The engine treats it as a constraint in its optimization — implementations differ in whether the fusion consumes computed positions or raw observations, but the principle is the same — and the accumulated drift is continually reset against it. Walk a kilometer of open road with steady Fixed corrections and the trajectory never gets the chance to wander; the cloud lands on datum without a single ground control point.

When the receiver drops to Float or Single, the absolute accuracy is too poor to trust, and a well-designed fusion de-weights or ignores it. This is why losing RTK indoors is normal and harmless. The scanner walks through the door, the sky disappears, the engine falls back on LiDAR, IMU, and cameras — which is exactly what SLAM is built to do. Operators sometimes panic at the “RTK lost” banner in a stairwell. They shouldn’t. Indoors, silence from the GNSS module is the correct behavior.

The asymmetry is worth stating plainly: no fix is a manageable condition. A false fix is not.

The silent killer

Pseudo-fix is field shorthand for a failure mode every RTK surveyor knows by its formal name: an incorrect integer ambiguity resolution. The receiver reports Fixed, but the carrier-phase ambiguities have locked onto the wrong integers, and the position is wrong by decimeters or more. The mechanism is familiar — multipath in an urban canyon, attenuated and re-radiated signals under dense canopy, reflections beneath metal gantries and bridges, a narrow valley masking half the sky. What makes it dangerous is that the validation step can be fooled too: under strong multipath, the ratio test that guards ambiguity resolution can pass on the wrong candidate, so the receiver flags centimeter confidence for a solution that does not deserve it.

A rover operator with local knowledge catches this: the shot lands somewhere implausible, the resection doesn’t check, suspicion kicks in. A SLAM engine has no such intuition. It receives a centimeter-confidence position and does what it is designed to do — it trusts the anchor and bends the map to honor it. The result is not a bad point here or there. It is large-scale warping: walls that layer into parallel sheets, a trajectory with a kink that matches nothing in the building, an outdoor scan whose two ends will not meet. In our support experience, pseudo-fix sits alongside missed loop closures as one of the two most common root causes of layered outdoor scans — and of the two, it is by far the harder one to diagnose after the fact, because the log says everything was Fixed.

This is why experienced operators treat RTK status as a live instrument, not a startup checkbox. Confirm a genuine Fixed in open sky before pressing start, and let it hold through a short stabilization pause — a fix that has been stable for thirty seconds with healthy satellite counts and correction age under a few seconds is a different animal from one that flashed up a moment ago. Watch the status through the run — the app shows it continuously for a reason. Treat a fix that survives under a tree line or between tall buildings with suspicion, and treat a status that flickers between Fixed and Float as a warning that the next “Fixed” may not deserve the name.

Knowing when to turn it off

The counterintuitive discipline is that the best RTK decision is sometimes no RTK at all. If the route runs mostly under canopy or through an urban canyon — environments where pseudo-fix thrives — switching RTK off and anchoring the scan with ground control points is the more defensible workflow. Five or six well-distributed GCPs, measured with a rover in genuinely open sky or by total station, give the post-processing an absolute frame that no false fix can corrupt.

The same logic applies after the fact. If a processed cloud shows layering and the RTK log reveals long stretches of implausible Fixed states, the standard recovery is to reprocess with the RTK constraints disabled and let GCP calibration pull the cloud into the correct frame. The data is often salvageable; the anchor was the problem, not the scan.

Configuration deserves the same respect as a rover setup, because it is one: NTRIP host, port, mountpoint, and credentials entered correctly; correction age and satellite counts checked when the app provides them; the connection confirmed stable before the job, not during it. A SLAM scanner with RTK is a survey instrument on one side and an autonomous mapper on the other, and it inherits the operating discipline of both.

Four rules to carry to the field

First: RTK is an anchor, not a positioner — its job is to reset drift, and only a genuine fix earns that trust. Second: losing RTK indoors costs you nothing; a pseudo-fix outdoors can cost you the dataset. Third: watch the status for the whole run, and plan routes so the receiver works in sky conditions where Fixed means Fixed. Fourth: in environments built for multipath, have the confidence to switch RTK off and let ground control do the anchoring.

The RTK module is the reason a handheld SLAM scanner can deliver survey-grade absolute accuracy without a control network. Used with the same skepticism a good surveyor already applies to any fix, it is the most valuable sensor on the instrument. Trusted blindly, it is the only sensor on the instrument that can ruin every other sensor’s work — silently, and with the log insisting everything was fine.