Problem
RTAB-Map is currently one of the largest CPU consumers in a Robonix deployment. CPU load and memory usage increase as the map grows, which eventually reduces the resources available to navigation, perception, and higher-level services.
We need to measure which RTAB-Map stages grow with map size, apply bounded-memory / bounded-map policies, and determine where SIMD or GPU acceleration is actually useful.
Research notes
RTAB-Map already exposes controls that are currently unbounded by default:
Rtabmap/TimeThr: transfer nodes from Working Memory to Long-Term Memory when update time exceeds a limit.Rtabmap/MemoryThr: bound the number of nodes in Working Memory.Rtabmap/DetectionRate: bound processing frequency.GridGlobal/MaxNodes: bound how many nodes are assembled into the published global occupancy map.
See the upstream parameter definitions for Working Memory bounds and global occupancy-map bounds.
The current Robonix template tunes sensor range, grid resolution, node distance, and detection rate, but does not set Rtabmap/TimeThr, Rtabmap/MemoryThr, or GridGlobal/MaxNodes. Localization also uses Mem/InitWMWithAllNodes=true, so loading a larger saved graph can directly increase startup memory.
GPU boundary
RTAB-Map does have GPU-enabled paths, but they are feature-specific:
- CUDA/OpenCV implementations for visual ORB, FAST, GFTT, SURF, optical flow, and brute-force descriptor matching.
- CudaSift and CUDA-backed SuperPoint when the corresponding optional dependencies are built.
- OpenMP and optional FastCV support.
Upstream references:
This is not a general GPU switch for pose-graph management, SQLite/database access, 2D occupancy-grid assembly, or the default PCL-based LiDAR pipeline. On a LiDAR + external-odom profile, enabling visual CUDA parameters may provide no benefit at all.
SIMD / vectorization boundary
RTAB-Map relies heavily on OpenCV, PCL, Eigen, and OpenMP. Those libraries can use SIMD and parallelism when compiled appropriately, but upstream does not expose a single runtime “vectorize” option. Architecture flags must also remain ABI-compatible across PCL/Eigen users; RTAB-Map explicitly warns about inconsistent -march=native builds.
Therefore, compiler/SIMD work should be treated as a measured build profile, not as an unchecked flag change.
Proposed scope
1. Attribute the cost
Add a reproducible profiling path that separates at least:
- sensor conversion / deskewing / filtering;
- ICP or visual feature extraction and matching;
- loop-closure retrieval;
- graph optimization;
- occupancy-grid assembly and publication;
- database I/O;
- WebUI / visualization publication.
Record wall time, CPU time, RSS, map nodes, Working Memory nodes, database size, and occupancy-grid dimensions over increasing map sizes.
2. Add bounded profiles
Investigate and expose deployment-level controls for:
Rtabmap/TimeThr and Rtabmap/MemoryThr;GridGlobal/MaxNodes or a local/rolling occupancy publication mode;- node creation thresholds and
Rtabmap/DetectionRate;
- LiDAR range, voxel size, and occupancy-grid cell size;
- localization startup without loading every map node when a separate global localizer is available;
- lower-rate or on-demand global map/point-cloud publication.
The saved map must remain complete even if the live published occupancy view is bounded.
3. Evaluate acceleration by hotspot
- CPU build: Release/LTO where supported, OpenMP policy/thread limits, and architecture-safe PCL/Eigen SIMD settings.
- Visual/RGB-D path: benchmark the upstream CUDA feature options only when visual feature extraction is a measured hotspot.
- LiDAR path: evaluate accelerated registration backends separately; do not describe external CUDA ICP/GICP libraries as RTAB-Map-native acceleration.
- Preserve a portable CPU fallback and identical capability semantics.
4. Publish performance profiles
Provide named profiles such as quality, balanced, and bounded-edge, with documented trade-offs for mapping quality, relocalization recall, CPU, and memory. Robot manifests should select a profile and override only hardware/sensor-specific values.
Expected outcome
Mapping resource use should stay within an explicit budget as the saved map grows, or fail with a clear budget diagnostic instead of gradually consuming all available CPU and memory. GPU and SIMD options should only be enabled where profiling proves an end-to-end benefit, with mapping quality and relocalization behavior checked for regressions.
Problem
RTAB-Map is currently one of the largest CPU consumers in a Robonix deployment. CPU load and memory usage increase as the map grows, which eventually reduces the resources available to navigation, perception, and higher-level services.
We need to measure which RTAB-Map stages grow with map size, apply bounded-memory / bounded-map policies, and determine where SIMD or GPU acceleration is actually useful.
Research notes
RTAB-Map already exposes controls that are currently unbounded by default:
Rtabmap/TimeThr: transfer nodes from Working Memory to Long-Term Memory when update time exceeds a limit.Rtabmap/MemoryThr: bound the number of nodes in Working Memory.Rtabmap/DetectionRate: bound processing frequency.GridGlobal/MaxNodes: bound how many nodes are assembled into the published global occupancy map.See the upstream parameter definitions for Working Memory bounds and global occupancy-map bounds.
The current Robonix template tunes sensor range, grid resolution, node distance, and detection rate, but does not set
Rtabmap/TimeThr,Rtabmap/MemoryThr, orGridGlobal/MaxNodes. Localization also usesMem/InitWMWithAllNodes=true, so loading a larger saved graph can directly increase startup memory.GPU boundary
RTAB-Map does have GPU-enabled paths, but they are feature-specific:
Upstream references:
This is not a general GPU switch for pose-graph management, SQLite/database access, 2D occupancy-grid assembly, or the default PCL-based LiDAR pipeline. On a LiDAR + external-odom profile, enabling visual CUDA parameters may provide no benefit at all.
SIMD / vectorization boundary
RTAB-Map relies heavily on OpenCV, PCL, Eigen, and OpenMP. Those libraries can use SIMD and parallelism when compiled appropriately, but upstream does not expose a single runtime “vectorize” option. Architecture flags must also remain ABI-compatible across PCL/Eigen users; RTAB-Map explicitly warns about inconsistent
-march=nativebuilds.Therefore, compiler/SIMD work should be treated as a measured build profile, not as an unchecked flag change.
Proposed scope
1. Attribute the cost
Add a reproducible profiling path that separates at least:
Record wall time, CPU time, RSS, map nodes, Working Memory nodes, database size, and occupancy-grid dimensions over increasing map sizes.
2. Add bounded profiles
Investigate and expose deployment-level controls for:
Rtabmap/TimeThrandRtabmap/MemoryThr;GridGlobal/MaxNodesor a local/rolling occupancy publication mode;Rtabmap/DetectionRate;The saved map must remain complete even if the live published occupancy view is bounded.
3. Evaluate acceleration by hotspot
4. Publish performance profiles
Provide named profiles such as
quality,balanced, andbounded-edge, with documented trade-offs for mapping quality, relocalization recall, CPU, and memory. Robot manifests should select a profile and override only hardware/sensor-specific values.Expected outcome
Mapping resource use should stay within an explicit budget as the saved map grows, or fail with a clear budget diagnostic instead of gradually consuming all available CPU and memory. GPU and SIMD options should only be enabled where profiling proves an end-to-end benefit, with mapping quality and relocalization behavior checked for regressions.