This article is adapted from a technical post by Kachaka’s manufacturer, Preferred Robotics, written by a SLAM development engineer. It is technical in nature.
The SLAM Technology Behind Autonomous Mobile Robots
For an autonomous mobile robot like Kachaka, two capabilities are non-negotiable: building a map of the surrounding environment (Mapping), and knowing where the robot currently sits on that map (Localization).
When a robot is first deployed, it holds no map data whatsoever. It therefore needs a mechanism that builds the map and localizes at the same time — this is SLAM (Simultaneous Localization and Mapping). It is precisely because of SLAM that Kachaka requires no magnetic tape or guidance markers on site.
Preferred Robotics develops its SLAM entirely in-house, continuously tuning and refining it for Kachaka and each of its product lines.
What Is SLAM
SLAM is the problem of using sensor data — from cameras, LiDAR, IMU, wheel odometry, and more — to simultaneously estimate both a map that describes the surrounding environment and the robot’s own position within that map. Once the map is built, it becomes known information, and the task reduces to solving localization alone.
The original article proceeds in three parts: prior research, the difficulties of mapping in real-world environments, and how Kachaka addresses them.
Prior Research
Camera-Based Research
Among traditional visual localization methods that do not use deep learning (DL) are ORB-SLAM, DSO, and LSD-SLAM; deep learning approaches include Droid-SLAM.
Droid-SLAM uses a recurrent architecture to jointly estimate camera pose and object distance, delivering strong robustness and accuracy — but at a high computational cost. Separately, while not a DL method, a recent approach based on Gaussian Splatting has emerged: Gaussian Splatting SLAM approximates the world with a set of colored 3D Gaussian distributions. It is lighter than Droid-SLAM and requires no pre-training, yet computational cost remains a barrier.
Overall, visual localization is an active research area, but it commonly faces several challenges: fragility under sharp viewpoint and lighting changes, high computational cost, and difficulty guaranteeing computational stability.
LiDAR-Based Research
LOAM is a classic SLAM method for LiDAR: it extracts edge points and planar points from the point cloud based on curvature, then matches them with their respective cost functions. As a feature-point method, it is computationally light and highly accurate — but because it computes curvature, it requires observing a sufficient number of points. SuMa takes a different route: rather than feature points, it uses a normal map and a LiDAR image generated from 3D LiDAR input to estimate position, building the map with small disks called surfels and registering observations against them to localize. LO-Net forgoes hand-designed LiDAR features entirely, instead learning matching end-to-end: normals are computed directly rather than learned, mask estimation and pose estimation share network weights, and training is supervised; the mask handles dynamic objects. Its advantage is that it estimates pose through learning without feature engineering — though supervised learning carries the cost of preparing a training dataset.
LiDAR SLAM uses an active sensor, making it more robust, and its computational burden is generally lighter than visual methods. Moreover, for a robot like Kachaka that moves only on a flat plane, two dimensions are enough for localization, which can be implemented cheaply with a 2D LiDAR.
Why Mapping Is Hard
Mapping can fail for a variety of reasons, falling into four representative categories:
- Problems caused by sensors and the environment
- Problems caused by the movement path during mapping
- Problems caused by computational resource limits
- Problems caused by the difficulty of validating time-series data
The third constraint is especially severe, making it hard to apply existing research methods directly. SLAM must be adapted to the actual device and its purpose — which is exactly why Kachaka chose to develop its own SLAM.
Problems Caused by Sensors and the Environment
In general, SLAM becomes difficult when a sensor provides too little information, or when a cheap, low-quality sensor produces excessive noise. With a 2D LiDAR, for example, estimation breaks down when the observation contains too few “corner” features — because every way of overlaying the scans appears equally valid. A camera struggles along plain, low-contrast surfaces such as a bare wall, where it cannot tell which part of the image to focus on to estimate motion. Wheel odometry, too, accumulates travel error from slipping on the floor or from uneven ground.
Problems Caused by the Movement Path During Mapping
Even if localization is accurate over the short term, error accumulates over long observation periods (drift). When mapping a loop and returning to the starting point, relying only on consecutive sensor data leads SLAM to place its estimated position somewhere else entirely. The standard fix is Loop Closing: using image or LiDAR data to recognize “I’ve been here before,” then going back to correct the pose estimates made so far. But if the mapping path almost never revisits the same location, Loop Closing cannot apply in principle, and the error cannot be reduced.
Problems Caused by Computational Resource Limits
SLAM usually requires online real-time inference, which demands considerable computational ingenuity. Ideally one would use every scrap of data without exception, but large data volumes simply cannot be stored. This is even more pronounced on Kachaka: its computational resources are limited to begin with, and it must run many other modules at the same time, so neither CPU nor memory can be used freely — efficient estimation under constrained resources is mandatory.
Problems Caused by the Difficulty of Validating Time-Series Data
Validation itself is hard. SLAM handles time-series data, so verifying a feature sometimes means re-running every prior time step’s computation; and judging whether accuracy has degraded often requires running an entire sequence to completion. Kachaka sometimes has to map corridors longer than 100 meters, where even a 1-degree estimation error can heavily affect how well the map turns out — so even a minor change must be checked against a wide variety of data to confirm map quality has not regressed.
How Kachaka Solves It
Countermeasures for “Sensors and the Environment”
Like other SLAM systems, Kachaka fuses data from multiple sensors to estimate position; at the same time, it cross-checks the sensors against one another for anomaly detection, selectively using only some sensors when necessary, to keep localization running uninterrupted as much as possible.
Countermeasures for the “Mapping Path”
Loop Closing is a key way to correct map breakdown, but whether it can run depends on the mapping route. Kachaka incorporates “the shapes a map is likely to take” as prior knowledge, so that even when Loop Closing does not trigger for a long time, the map’s overall skeleton is unlikely to collapse.
The Loop Closing process itself is split into two stages by computation-time requirements: a lightweight, simplified version runs during online mapping, while at save time the system re-examines the whole map and performs full optimization to finish it cleanly. Thanks to these designs, mapping succeeds at a high rate even for large maps.
Countermeasures for “Computational Resource Limits”
Kachaka cannot fit all the information SLAM needs into memory, so during mapping it offloads all bulky data to storage as a temporary buffer. With nearly all sensor data evacuated to storage, memory usage drops sharply; CPU usage is kept low by the two-stage optimization structure described above.
Countermeasures for “Time-Series Data Validation”
Kachaka runs accuracy evaluations on real data every week, confirming that map quality has not regressed relative to the previous version. The evaluation system, artifact management, and visualization are all built in-house, and CPU usage and memory consumption are monitored at the same time — ensuring not only accuracy but also performance has not regressed.
Closing
The original article ends with this: localization is a foundational technology for autonomous mobile systems, yet it carries a wide range of challenges; this article covered only mapping, while autonomous movement itself still holds many more. SLAM is a field with a long research history that continues to evolve to this day, and Kachaka’s SLAM will keep adding new features and improving accuracy.
If you are a business or institution interested in deploying Kachaka, we would be glad to hear from you.
References
- Mur-Artal, et al. “ORB-SLAM: a versatile and accurate monocular SLAM system.” IEEE Transactions on Robotics 31.5 (2015): 1147-1163.
- Engel, et al. “Direct sparse odometry.” IEEE Transactions on Pattern Analysis and Machine Intelligence 40.3 (2017): 611-625.
- Engel, et al. “LSD-SLAM: Large-scale direct monocular SLAM.” European Conference on Computer Vision, 2014.
- Teed, et al. “Droid-SLAM: Deep visual SLAM for monocular, stereo, and RGB-D cameras.” NeurIPS 34 (2021): 16558-16569.
- Matsuki, et al. “Gaussian Splatting SLAM.” Proceedings of the IEEE/CVF CVPR, 2024.
- Zhang, et al. “LOAM: Lidar odometry and mapping in real-time.” Robotics: Science and Systems, 2014.
- Behley, et al. “Efficient surfel-based SLAM using 3D laser range data in urban environments.” Robotics: Science and Systems, 2018.
- Li, Qing, et al. “LO-Net: Deep real-time lidar odometry.” Proceedings of the IEEE/CVF CVPR, 2019.
Source: Preferred Robotics original article. Text and images are copyright of the manufacturer.