# Open-Source Software for Localization and Mapping: Research Report
*Generated: 2026-08-09 | Sources: live GitHub API pulls + official docs | Confidence: High*
## Context
Broad survey of the open-source localization/mapping landscape for a ground rover / robotics platform — SLAM, odometry, sensor fusion, and terrain/occupancy mapping. Scoped to the general technology space, not tied to any specific competition team's past choices.
## Executive Summary
The open-source stack for "where am I and what does the world look like" splits into four layers that are typically combined, not chosen from exclusively: **SLAM/odometry frontends** (turn raw sensor data into pose + a map), **sensor fusion backends** (combine multiple noisy sensors into one clean state estimate), **mapping representations** (turn sensed geometry into a usable map format for planning), and **supporting point-cloud tooling** (the shared math/processing libraries underneath most of the above). For a wheeled ground rover specifically, LiDAR-inertial approaches (Cartographer, FAST-LIO, LIO-SAM) and the ROS/ROS2 ecosystem's `robot_localization` + Nav2 stack are the most battle-tested combination; camera-based visual(-inertial) SLAM (ORB-SLAM3, VINS-Fusion, RTAB-Map) fills in where LiDAR isn't available or budget is tighter.
## 1. SLAM & Odometry Frontends
These take raw sensor streams (LiDAR scans, camera frames, IMU) and produce a real-time pose estimate plus a map.
| Project | Stars (live) | Sensors | License | Notes |
|---|---|---|---|---|
| [Cartographer](https://github.com/cartographer-project/cartographer) | **7,935** | LiDAR (+ optional IMU/odom) | Apache-2.0 | Google-originated, real-time 2D and 3D SLAM, well-documented ROS integration, the closest thing to a "default" LiDAR SLAM choice |
| [ORB-SLAM3](https://github.com/UZ-SLAMLab/ORB_SLAM3) | **8,921** | Camera (mono/stereo/RGB-D), optional IMU | GPL-3.0 | Feature-based visual/visual-inertial SLAM, supports multi-map (re-localizes after tracking loss), academic gold-standard for camera-only SLAM |
| [FAST-LIO](https://github.com/hku-mars/FAST_LIO) | **5,039** | LiDAR + IMU | GPL-2.0 | Tightly-coupled LiDAR-inertial odometry, built for computational efficiency (runs on modest onboard compute), very actively used in current robotics research |
| [LIO-SAM](https://github.com/TixiaoShan/LIO-SAM) | **4,879** | LiDAR + IMU (+ optional GPS) | BSD-3-Clause | Factor-graph-based (built on GTSAM below), tightly-coupled lidar-inertial odometry with smoothing/mapping — natively supports fusing in GPS factors when available |
| [VINS-Fusion](https://github.com/HKUST-Aerial-Robotics/VINS-Fusion) | **4,659** | Camera + IMU (mono or stereo) | GPL-3.0 | Optimization-based visual-inertial state estimator, widely used on drones and ground robots alike, pairs naturally with PX4/ArduPilot-style flight/nav stacks |
| [RTAB-Map](https://github.com/introlab/rtabmap) | **3,937** | RGB-D, stereo, or LiDAR | Other (permissive) | Appearance-based SLAM with strong loop-closure detection, ROS/ROS2 native, actively maintained (commits within the last day at time of writing) |
**How to think about the split:** LiDAR-based approaches (Cartographer, FAST-LIO, LIO-SAM) tend to be more robust to lighting changes and give metrically accurate maps directly; camera-based approaches (ORB-SLAM3, VINS-Fusion, RTAB-Map) are cheaper in hardware terms but more sensitive to lighting/texture-poor environments (a real concern on featureless terrain). Several of these are explicitly designed to fuse GPS/GNSS in when it's available (LIO-SAM) and gracefully fall back to pure dead-reckoning when it isn't.
## 2. Sensor Fusion & State Estimation Backends
Rather than trusting one sensor, these combine multiple noisy sources (wheel odometry, IMU, GPS, SLAM output) into a single best-estimate pose over time.
| Project | Stars (live) | What it does | License |
|---|---|---|---|
| [robot_localization](https://github.com/cra-ros-pkg/robot_localization) | **1,939** | ROS/ROS2 package of EKF/UKF nonlinear state estimation nodes — the standard way to fuse GPS + IMU + wheel odometry into one continuous pose | Permissive (Other) |
| [GTSAM](https://github.com/borglab/gtsam) | **3,621** | Factor-graph-based smoothing and mapping library — the math engine underneath many modern SLAM systems (including LIO-SAM above); lets you build custom fusion problems (add a GPS factor here, a loop-closure constraint there) | Permissive (Other) |
| [Kalibr](https://github.com/ethz-asl/kalibr) | **5,622** | Camera-IMU (and multi-camera) calibration toolbox — a prerequisite most people underestimate: visual-inertial SLAM/odometry accuracy depends heavily on precise sensor-to-sensor calibration, which this handles rigorously | Permissive (Other) |
**Practical note:** `robot_localization` is the lower-effort, "just fuse my sensors" option (drop-in EKF/UKF nodes, minimal math required). GTSAM is the higher-ceiling, more flexible option if you want to build a custom fusion pipeline (e.g., combining LiDAR odometry + GPS + loop closures in one optimization) — most of the LiDAR-inertial SLAM packages above are themselves built on GTSAM under the hood.
## 3. Mapping Representations (Occupancy, Terrain, Elevation)
Once you have geometry from sensors, these turn it into a map format usable for path planning and obstacle avoidance.
| Project | Stars (live) | Map type | License |
|---|---|---|---|
| [OctoMap](https://github.com/OctoMap/octomap) | **2,350** | Probabilistic 3D occupancy mapping via octrees | None listed (open, no SPDX license file) |
| [Nav2 (navigation2)](https://github.com/ros-navigation/navigation2) | **4,565** | Full ROS2 navigation framework — includes 2D costmaps, path planning, recovery behaviors, built to consume the outputs of the SLAM/fusion layers above | Permissive (Other) |
| [grid_map](https://github.com/ANYbotics/grid_map) | **3,204** | Universal 2.5D grid map library (elevation, cost, traversability layers all in one structure) | BSD-3-Clause |
| [elevation_mapping](https://github.com/ANYbotics/elevation_mapping) | **1,841** | Robot-centric elevation mapping specifically for rough terrain navigation | BSD-3-Clause |
**Why this matters for a rover on uneven ground:** OctoMap and Nav2's built-in costmaps are the standard choice for "flat-ish ground with obstacles." `grid_map` + `elevation_mapping` (both from ANYbotics, the company behind the ANYmal legged robot) are specifically built for **rough/uneven terrain** — tracking actual elevation, not just binary occupied/free — which is a closer match to Mars-analog desert terrain than a simple 2D occupancy grid.
## 4. Supporting Point-Cloud / 3D Processing Libraries
Shared infrastructure most of the above either depends on or is commonly paired with.
| Project | Stars (live) | Purpose | License |
|---|---|---|---|
| [PCL (Point Cloud Library)](https://github.com/PointCloudLibrary/pcl) | **11,088** | The foundational C++ library for point cloud filtering, registration (ICP), segmentation, feature extraction — many SLAM systems use PCL internally | Permissive (Other) |
| [Open3D](https://github.com/isl-org/Open3D) | **13,871** | Modern 3D data processing library (Python + C++), strong for offline map post-processing, visualization, and increasingly for learning-based 3D perception; more actively developed/higher star velocity than PCL currently | Permissive (Other) |
## Key Takeaways
- **No single tool does everything** — a real system typically stacks a SLAM/odometry frontend (Cartographer/FAST-LIO/ORB-SLAM3/etc.) + a fusion backend (robot_localization or GTSAM) + a mapping representation (OctoMap/grid_map/Nav2 costmaps), not one library replacing all the others.
- **LiDAR-inertial odometry is the current center of gravity in the field** — FAST-LIO and LIO-SAM both sit in the 4,800-5,000 star range and are actively developed; they're the most-cited approach in current LiDAR-equipped ground robotics work.
- **`robot_localization` is the standard entry point for GPS+IMU+odometry fusion** in the ROS/ROS2 ecosystem specifically — lower setup cost than building a custom GTSAM factor graph, though less flexible.
- **Rough-terrain-specific mapping exists as a distinct category** (grid_map / elevation_mapping) separate from generic occupancy mapping (OctoMap) — worth knowing this split exists if the terrain isn't flat.
- **Calibration tooling (Kalibr) is easy to overlook** but directly determines how accurate any camera+IMU-based system (VINS-Fusion, ORB-SLAM3 visual-inertial mode) actually is in practice.
## Sources
1. [Cartographer](https://github.com/cartographer-project/cartographer) — live GitHub star/license/activity data
2. [ORB-SLAM3](https://github.com/UZ-SLAMLab/ORB_SLAM3) — live GitHub star/license/activity data
3. [RTAB-Map](https://github.com/introlab/rtabmap) — live GitHub star/license/activity data
4. [FAST-LIO](https://github.com/hku-mars/FAST_LIO) — live GitHub star/license/activity data
5. [LIO-SAM](https://github.com/TixiaoShan/LIO-SAM) — live GitHub star/license/activity data
6. [VINS-Fusion](https://github.com/HKUST-Aerial-Robotics/VINS-Fusion) — live GitHub star/license/activity data
7. [robot_localization](https://github.com/cra-ros-pkg/robot_localization) — live GitHub star/license/activity data
8. [GTSAM](https://github.com/borglab/gtsam) — live GitHub star/license/activity data
9. [Kalibr](https://github.com/ethz-asl/kalibr) — live GitHub star/license/activity data
10. [OctoMap](https://github.com/OctoMap/octomap) — live GitHub star/license/activity data
11. [Nav2 / navigation2](https://github.com/ros-navigation/navigation2) — live GitHub star/license/activity data
12. [grid_map](https://github.com/ANYbotics/grid_map) — live GitHub star/license/activity data
13. [elevation_mapping](https://github.com/ANYbotics/elevation_mapping) — live GitHub star/license/activity data
14. [PCL](https://github.com/PointCloudLibrary/pcl) — live GitHub star/license/activity data
15. [Open3D](https://github.com/isl-org/Open3D) — live GitHub star/license/activity data
## Methodology
Pulled live GitHub API data (`api.github.com/repos/...`) for star counts, forks, license, and last-push date on 2026-08-09 for all 15 named repos, rather than relying on stale blog-post numbers. Selection covers the four functional layers of a localization/mapping stack (SLAM/odometry frontends, sensor fusion backends, mapping representations, supporting point-cloud tooling) with broadly-known, actively-maintained projects in each. Per standing research-scope preference, no comparison against what any specific competition team has used — scope stays general across the technology space.