cartographer
Google 开源的工业级 SLAM 算法库，让机器人实时边移动边绘制 2D/3D 地图
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
Google 开源的工业级 SLAM 算法库，让机器人实时边移动边绘制 2D/3D 地图
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一下：你在一个完全陌生的商场地下一层，手机信号又没有，唯一的任务是从入口走到出口找到出口美食街。你会怎么做？大多数人第一步会「四处张望」——找标志性店铺、记住转角、估算距离，一边走一边在脑子里画出一张模糊的地图。走得越久，地图越清晰，导航越准确。
Cartographer 做的事情，和这几乎一模一样——只不过主角从人换成了机器。
Cartographer 是 Google 旗下由 Willow Garage 团队开发的开源 SLAM（即时定位与地图构建）系统。它让机器人在移动过程中，同时完成两件事：实时知道「自己在哪」（定位），以及实时绘制「周围环境长什么样」（建图）。这两个过程互相依赖、互相增强——你知道的越多，地图越准；地图越准，定位越准，形成一个精密的正反馈循环。
这项技术在过去十年间几乎成为了机器人、自动驾驶、AR/VR 行业的底层基础设施。一个有趣的类比：Cartographer 就是机器人世界的「高德地图」，只不过这张地图不是提前绘制好的，而是机器人自己边走边「实时手绘」出来的。
Cartographer 的故事要从 2016 年说起。。彼时，Google 的机器人团队正在内部开发多个自主移动机器人项目，核心挑战之一就是如何在没有预装地图的情况下，让机器人在复杂环境中可靠导航。团队从 ROS（Robot Operating System）社区获得了大量灵感，最终决定将内部研究成果开源，于是 Cartographer 诞生了。
项目开源后迅速走红：2016 年 GitHub stars 突破 5000，2017 年成为 ROS 官方推荐的 SLAM 方案，被 Boston Dynamics 的 Spot 机器狗、TurtleBot 等主流平台广泛采用。2019 年，Google 将 Cartographer 的维护权移交给独立的 cartographer-project 组织，项目正式从 Google 内部项目转型为社区驱动的开源项目。
一个值得关注的信号：2022 年，Cartographer 官方宣布「不再主动维护」（no longer actively maintained）。虽然代码库仍偶尔接收关键 PR，但主分支不再有新功能开发。这意味着如果你是新项目的技术选型，这个决定值得认真考量。
Cartographer 最大的技术亮点是同时支持 2D SLAM 和 3D SLAM，且实现高度统一——共用核心算法，仅在传感器处理层区分维度。
2D SLAM 适合室内平面场景，如酒店送物机器人、仓库 AMR（自主移动机器人）。想象一个扫地机器人在你家客厅工作：它只需要知道「哪里有墙」「哪里有障碍物」，在二维平面上建图就足够了。Cartographer 的 2D 实现使用激光雷达（LiDAR）扫描，输出 Occupancy Grid Map（占据栅格地图）——也就是机器人领域最经典的可视化方式：黑色格子是墙，白色是通路，灰色是未知区域。
3D SLAM 则面向更复杂的真实世界，如自动驾驶汽车、无人机勘察。机器人需要知道「前方有个低矮的树枝需要绕行」「上方有桥洞可以穿过」，这时只有二维地图不够用。Cartographer 的 3D 实现通过多传感器融合（激光雷达 + IMU 惯性测量单元 + 轮式里程计），构建稠密点云地图，能够描述三维空间中的精细结构。
关键在于：Cartographer 对这两种场景采用了几乎相同的核心算法——基于图优化的 Pose Graph（姿态图）。差异仅体现在前端传感器处理（如何把原始点云数据变成可供图优化使用的「节点」和「边」）。这种设计让 Cartographer 的核心代码高度复用，维护成本大幅降低。
如果把 Cartographer 的技术内核精简为一个词，那就是 Pose Graph SLAM（姿态图 SLAM）。
整个系统的工作流程可以这样理解：
第一步：数据获取（Sensor Input）。机器人配备激光雷达，持续向周围发射激光射线并接收反射信号，每一束激光返回一个「这里到障碍物的距离」。激光雷达每秒发射数万束射线，产生密集的距离点云（Point Cloud）。
第二步：特征提取（Scan Matching）。Cartographer 不会直接拿原始点云去建图——数据量太大，噪声太多。它会先把点云转化成更紧凑的表示：对于 2D，用「占用栅格概率」网格；对于 3D，用「子图（Submap）」方法把大空间切分成若干小局部地图。这样做的好处是：计算量骤降，同时地图精度依然可控。
第三步：姿态图构建（Pose Graph）。这是 Cartographer 最核心的部分。当机器人在移动，每新扫描一次，就在 Pose Graph 中加入一个新节点（代表这次扫描的机器人位置），并在当前节点和「看起来最接近」的之前节点之间创建一条「边」（约束）。边的类型有两种：
当机器人在某个位置「回头一看」，发现自己回到了之前到过的地方——这叫 闭环检测（Loop Closure）——Pose Graph 会瞬间收紧相关边的约束，整个地图瞬间「对齐」，漂移误差被大幅消除。这就是为什么用 Cartographer 建好的地图总是「横平竖直」，而不会像某些劣质方案那样越走越歪。
第四步：后端优化（Optimization）。Pose Graph 建立后，Cartographer 调用 Ceres Solver（Google 开源的非线性优化库）对整个图做批量优化，说白了就是：调整所有节点的位置，让所有边代表的约束尽可能同时被满足。这是一个经典的非线性最小二乘问题，也是 Cartographer 选择 Ceres 的原因——Ceres 对这类问题的求解效率极高。
Cartographer 的代码质量在开源社区有口皆碑。让我们看看它的技术构成：
语言与构建：C++14 标准，CMake 构建系统，同时支持 Bazel（Google 内部构建工具）。CMakeLists.txt 显示依赖包括：Abseil（Google 内部基础库）、Boost（文件系统/压缩）、Ceres Solver（非线性优化）、Eigen3（矩阵运算）、Lua（配置脚本）、Protobuf（序列化）。这是一套典型的工业级 C++ 依赖组合。
代码结构：cartographer/ 目录下分为几个核心模块：
mapping/：核心 SLAM 算法（2D/3D submap、pose_graph、trajectory_builder）sensor/：传感器数据抽象层（激光雷达、IMU、里程计）transform/：刚体变换（SE2/SE3）数学工具io/：输入输出（.pbstream 地图格式、Protobuf 流）cloud/：实验性的云端协同 SLAM（gRPC 支持，可选构建）代码风格：项目包含 .clang-format 和 Google C++ Style Guide 配置文件，代码风格高度统一。README 显示有完整的单元测试覆盖。
文档质量：官方文档托管在 ReadTheDocs，有详细的配置参数说明、算法术语解释、2D/3D 建图教程。对于一个学术级别的项目来说，文档深度相当可观。
Cartographer 本身是纯算法库，不包含硬件驱动或 ROS 集成——那些属于独立的 cartographer_ros 项目。因此上手分两条路：
路线一：通过 ROS 使用（最主流）。安装 ROS 2 的 cartographer_ros 包，配置 .lua 参数文件，启动 launch 文件即可。这是目前大多数用户的使用方式，适合有 ROS 基础的开发者。
路线二：纯 CMake 集成。如果你想在不依赖 ROS 的项目中使用 Cartographer，CMakeLists.txt 提供了完整的 CMake 整合方式。需要手动配置 Protobuf、Ceres、Eigen3 等依赖。
关于已停止维护的警告：Cartographer 官方明确表示「不再主动维护」。对于新项目，这是高风险选择。替代方案包括：
Cartographer 的价值不仅在于它本身，更在于它证明了「开源 + Google 背书」能催生出行业基础设施级项目。
在 Cartographer 出现之前，SLAM 算法研究多集中在学术论文，落地门槛极高。Cartographer 第一次将工业级 SLAM 代码完整开源，降低了机器人导航的技术门槛，直接加速了服务机器人行业的商业化进程。今天你在酒店、商场、医院看到的自主移动机器人，背后很可能就跑着 Cartographer 的后代代码。
从技术演进角度看，Cartographer 代表的图优化 SLAM 范式，已经成为现代机器人定位建图的标准答案。即使项目停止维护，它提出的 Pose Graph 框架、子图划分方法、闭环检测策略，仍深刻影响着 LIO-SAM、FAST-LIO 等新一代算法的发展方向。
一句话总结：Cartographer 是 Google 出品的工业级 SLAM 算法库，支持 2D/3D 实时定位建图，采用 Pose Graph 图优化为核心，提供 Dockerfile 可容器化部署，但项目已停止主动维护，适合有 ROS 经验的开发者用于服务机器人项目。