Visual SLAM — how it works, and where it fits in RTLS.

Visual SLAM (Simultaneous Localization And Mapping using vision) is a class of algorithms that take a stream of camera frames and produce two outputs at once: a 3D map of the surrounding environment, and the camera's pose (position and orientation) inside that map.

No anchors, no tags, no pre-survey. The system learns the space and learns where it is in the space at the same time — which is exactly what its name says, and exactly what makes it powerful for moving robots, AR devices and dynamic environments.

There are four computational pieces. First, feature extraction — the algorithm detects distinctive points in each camera frame (corners, edges, learned features).

Second, pose estimation — by tracking how features move between frames, it triangulates the camera's motion. Third, mapping — accumulated 3D feature positions build the world model.

Fourth, loop closure — when the camera revisits a previously-seen place, the algorithm recognises it and corrects accumulated drift across the whole map.

Modern systems use a stack like ORB-SLAM3, OpenVSLAM, or learned-feature SLAM, often combined with inertial measurement (IMU) for visual-inertial SLAM that handles brief feature loss.

Three deployment categories are mature today.

AMRs and AGVs increasingly use visual SLAM (often combined with 2D LiDAR for safety) as their primary navigation stack — every modern HIK Robot, MiR, Locus and OTTO platform ships with vision-based localisation as part of the sensor fusion.

AR and XR devices — Apple Vision Pro, Meta Quest, Microsoft HoloLens, every ARKit and ARCore phone — all rely on visual-inertial SLAM for pose tracking.

Indoor mapping and survey — drones, handheld scanners and robot floor-mappers use visual SLAM to build the 3D models that retrofit RTLS deployments use as their basemap.

These technologies answer different questions, despite being lumped together as 'indoor positioning'. UWB and BLE-AoA give you precise position of tagged assets relative to infrastructure you've installed.

Visual SLAM gives you precise position of the camera-equipped device itself relative to a map it built.

RFID confirms presence at read points. The right architecture for most enterprises is hybrid: visual SLAM on every mobile robot to handle navigation, UWB anchors where you need to track tagged assets in real time, RAIN RFID at choke points for inventory and dock verification.

None of these technologies replace each other — they solve different sub-problems.

Within the SLAM family, the most common comparison is visual versus LiDAR. LiDAR SLAM uses laser rangefinders to build a precise 3D point cloud; visual SLAM uses cameras to build a feature-based or dense-photometric map.

LiDAR is robust to lighting variation, accurate to centimetres on geometric structure, and expensive.

Vision is cheap, captures semantic information (textures, signs, identifiable objects), and degrades in low-light or featureless environments.

Hybrid sensor-fusion stacks (LiDAR + camera + IMU) are now standard on serious industrial AMRs because each modality covers the other's blind spots. Most consumer AR devices use vision + IMU only, because cost and form-factor rule LiDAR out.

Visual SLAM is not magic. Featureless walls (think clean white warehouses with bare metal racking), low-light or strongly-varying lighting (loading docks at dawn),

highly-dynamic environments (every box on every shelf moved between visits), and reflective surfaces all degrade performance.

Compute requirements remain non-trivial — even modern embedded vSLAM stacks need a meaningful GPU or NPU on board.

Map management at scale (multiple floors, large warehouses, change over time) is a real engineering problem, not a solved one.

And visual SLAM by itself does not give you asset tracking — only device tracking. To know where a forklift is, you put visual SLAM on the forklift; to know where a tagged pallet is, you still need RFID or UWB.

Three layers matter. Algorithm and library layer: ORB-SLAM3 and OpenVSLAM (open source, research-grade), VINS-Fusion, Kimera, and commercial alternatives from Slamcore, Augmented Pixels, Microsoft (HoloLens stack), Apple (ARKit), Google (ARCore), and Meta (Quest SDK).

Hardware layer: Intel RealSense depth cameras, Luxonis OAK-D, StereoLabs ZED, Orbbec and many cheap embedded camera modules — these are the sensors that feed the SLAM stack.

Robotics layer: NVIDIA Isaac Robotics platform (Isaac SLAM, Isaac Perceptor) and ROS 2 navigation stacks bundle visual SLAM into AMR deployment toolchains.

For enterprises, the right question is rarely 'which SLAM library' — it's 'which AMR vendor, and what does their navigation stack include'.

We design visual SLAM into RTLS architectures when the use case is device self-localisation in environments where installing fixed infrastructure is impractical, expensive, or unwanted.

AMR and AGV navigation is the most common case (and it's not really a TRACIO recommendation — it's the default on every modern AMR).

Drone-based indoor mapping for retrofit RTLS deployments is a credible secondary use. AR overlays for maintenance and operator guidance — emerging.

We do not recommend visual SLAM as a replacement for tag-based RTLS when the requirement is to track assets, people or vehicles that don't carry their own camera. Different problems, different tools.