A device resolving its absolute position against a shared map on a tablet

VPS vs SLAM: Why You Almost Certainly Need Both

One tracks how you moved. The other tells you where you are. They are not competing.

Relative versus absolute. That is the whole distinction.

A device running SLAM is confident about its position and cannot tell anything else where it is. That is the gap a visual positioning system fills.

The Distinction In One Paragraph

SLAM builds a map as it moves and tracks against it. The coordinate frame starts wherever the device powered on, so it is private to that session, it drifts as sensor error accumulates, and it resets when the session does. A visual positioning system matches what the camera sees against a map that already exists, and returns position and orientation in that map's frame.

Relative against absolute. Everything else follows from that one line: whether two devices agree, whether content comes back tomorrow, and whether the error grows or gets reset.

The test that settles which one you need
Ask whether anything other than this device needs to understand the position. If the answer is no, and the session is short, SLAM alone is fine and cheaper. If a second device, a fleet manager, a work order or tomorrow's session needs to read that position, it has to be expressed in a frame that outlives the session, and no amount of improving the tracking will produce one.

SLAM alone is enough: one device, one session, nothing shared
You need an absolute fix:

- Content that has to be in the same place tomorrow
- Two or more devices that have to agree with each other

How They Run Together In Production

On-device SLAM tracking continuous frame-to-frame motion
SLAM handles the motion
Keep whatever is already running on the device for frame-to-frame tracking. It is smooth, it is fast, it works between fixes, and replacing it is not the goal. On a phone or headset this is the platform tracker; on a robot it is the existing stack.
A visual positioning query returning an absolute 6-DoF fix in a shared frame
The VPS supplies the fix
Query the map on a timer, or whenever tracking confidence drops, and get position and orientation in the shared frame back at sub-5 cm median. The drift is then corrected against ground truth rather than against the device's own history.
SLAM and visual positioning running together, with the fix correcting accumulated drift
Gate on confidence
Every response carries a confidence value, and a correct integration acts on it rather than trusting every pose. A wrong position stated confidently is worse than no position, so decide up front what the system does when confidence is low.

The Four Things SLAM Cannot Do Alone

Two Devices Cannot Agree

Each device's frame starts where it powered on, so two machines in the same aisle hold two different origins. Both are internally correct and neither can read the other. On a mixed fleet this is not a software problem you can solve above the stack.
Nothing Survives The Session

An anchor placed against a relative frame does not come back, because the frame it referred to no longer exists. Persistent content needs a coordinate system that outlives the app being closed.
Drift Has No Ceiling

Any system that integrates motion without observing a known reference drifts without bound. Loop closure helps when you revisit somewhere you have been, and a long one-way traverse never gets that chance. An absolute fix resets the error instead of slowing its growth.
Cold Start, Every Start

Relocalizing after a restart means finding yourself in a map you built yourself last time, if it was kept at all. Against a prebuilt shared map, the first frame returns a position, which is why first lock is the metric that decides whether people keep using a deployment.
Where SLAM Wins Outright

Worth saying plainly. SLAM needs no prior map, works in a space nobody has captured, runs at high frequency on-device, and handles obstacle avoidance and local planning. In an unmapped environment it is the only option, and a VPS has nothing to offer until the space has been captured once.
The Standard Production Arrangement

On-device tracking for smooth continuous motion, periodic absolute fixes to correct the accumulated drift. In ROS 2 the pose arrives through the transform tree alongside odometry rather than as a parallel system somebody has to reconcile.

Side By Side

Read the second row first. Everything else in the table is a consequence of it.
Talk It Through
DIMENSION
SLAM
Visual positioning system
Needs a map first
No. It builds one as it goes
Yes. The space must be captured once
Coordinate frame
Relative, private to the session, gone on restart
Absolute and shared. The same frame next month
Error behaviour
Drifts with distance travelled
Does not accumulate. Each query is independent
Can two devices agree
No, not without an external reference
Yes. That is the point of it
Update rate
Continuous, every frame
On demand. Queried periodically, not every frame
Role in the stack
Local motion, obstacle avoidance, path planning
The absolute reference everything else resolves into
Frequently asked questions
What is the difference between VPS and SLAM?

SLAM builds a map as it moves and tracks against it, in a coordinate frame that starts wherever the device started. A visual positioning system matches the camera view against a map that already exists and returns position and orientation in that map's frame. Relative against absolute. It follows that SLAM drifts and is private to the session, while a VPS does not accumulate error and can be read by anything else using the same map.

Does a VPS replace SLAM?

No, and a vendor telling you it does is describing a different problem. SLAM handles continuous frame-to-frame motion at high frequency on the device, which is what obstacle avoidance and local planning need. A VPS supplies periodic absolute fixes. The standard production arrangement runs both, with the fix correcting the accumulated drift.

Why does SLAM drift?

Because each estimate is built on the one before it, so small errors compound. Any system that integrates motion without observing a known external reference drifts without bound. Loop closure corrects it when the device revisits somewhere it has already been, which does not help on a long one-way traverse. An absolute fix resets the error rather than slowing its growth.

When is SLAM alone the right answer?

When the space has never been captured, when one device works alone, and when nothing has to persist beyond the session. In an unmapped environment it is the only option available, and it is cheaper because there is no capture step. The moment a second device, a work order or tomorrow's session needs to read the position, you need a shared frame.

How do visual SLAM and LiDAR SLAM differ?

Visual SLAM uses camera images, which is cheap and depends on visible texture, so it degrades in the dark or against blank walls. LiDAR SLAM uses laser ranging, which is more geometrically precise and indifferent to lighting, at the cost of a sensor on every device. Both are relative, so fusing them produces a better relative estimate and still not an absolute one.

How often should a device query the VPS?

Not every frame, which is the common misunderstanding. Query on a timer, on entering a new area, or whenever tracking confidence drops. Between queries the on-device tracker carries the motion. How often depends on how fast drift accumulates on your hardware and how much error the application tolerates.

How does this integrate with ROS 2?

The absolute pose is published into the transform tree, so it arrives as a standard frame alongside odometry and the existing SLAM output rather than as a parallel system somebody has to reconcile. Every response carries a confidence value, and the integration should gate on it rather than trusting every pose.