无人车设计参数
工作环境：展厅
载重：300kg
底盘：四轮转向(霍尔传感器驱动电机 + 编码器转向电机)
传感器：
- Gemini 335 全场景双目结构光3D相机深度相机(自带IMU)
- 对角 双 蓝海光电 2D 激光雷达
ROS 主机： RK3588
电机控制MCU： T113-S3
ChatGPT 方案设计
Cartographer
|
↓
地图
+
AMCL
|
↓
我在哪里
+
Nav2
|
↓
我要怎么走
+
Gemini335
|
↓
眼前有什么
行业演进趋势
第一代：几何感知
LiDAR
|
距离
|
地图
|
导航
第二代：多传感器融合
LiDAR
|
|
Camera ---- EKF/融合 ---- IMU
|
Wheel Odom
上述方案就属于第二代
LiDAR:
定位
Gemini335:
3D障碍
IMU:
姿态
Wheel:
运动
第三代：视觉语义智能
Vision Foundation Model
|
|
Camera ------------ World Model
|
|
LiDAR ----------- Geometry Safety Layer
|
IMU ------------- State Estimation
|
Wheel ----------- Motion Model
|
↓
Robot Brain
RtabMap
RTAB-Map 不属于“第三代”，它更接近第二代向第三代过渡阶段的技术。
它本质是：基于视觉外观的SLAM系统
Camera / RGB-D
|
↓
视觉特征提取
|
↓
视觉里程计
|
↓
回环检测
|
↓
图优化
|
↓
地图
RTAB-Map技术层次更高，但工程调试难度反而比第二代LiDAR SLAM大很多。
本质区别：第二代是“测量”，RTAB-Map是“推理”
第三代和RtabMap的关系
| RTAB-Map | 第三代 | |
|---|---|---|
| 看到 | 像素 | 物体 |
| 地图 | 几何地图 | 语义地图 |
| 目标 | 定位 | 理解 |
| 输出 | Pose | 决策 |
RTAB-Map最大的问题：承担太多角色
一个系统里面：
RTAB-Map
├──视觉里程计
├──建图
├──回环
├──定位
├──地图管理
ABB 视觉SLAM
Vision SLAM 已经有不少公司做到商业可用，甚至在仓库、工厂、配送机器人上部署，但核心算法基本都是闭源。
为什么公司做出来了，却不开源？
核心原因：真正有价值的不是 SLAM 论文里的算法，而是大量工程细节。
开源视觉 SLAM 选择
| 路线 | 成本 | 研发风险 | 适合初创 |
|---|---|---|---|
| 纯视觉自研SLAM | 最低 | 极高 | ❌ |
| ORB-SLAM3二次开发 | 低 | 高 | △ |
| RTAB-Map | 中低 | 中 | ✅ |
| Isaac ROS + Jetson | 中高 | 中低 | ✅（资金充足） |
| LiDAR传统方案(3D激光雷达SLAM) | 较高 | 低 | ✅ |
路线1：ORB-SLAM3
优点：
- 算法强
- 学术地位高
问题：
- 工程化不足
- 地图管理弱
- ROS2集成需要自己补
- 长期运行困难
路线2：RTAB-Map
优点：
- ROS生态成熟
- 支持RGB-D
- 支持多传感器
- 有数据库
- 有地图管理
这就是为什么很多机器人团队会选择它。
路线3：NVIDIA Isaac ROS
这是未来方向。
但是：成本高。
生态：绑定NVIDIA。
视觉补充定位的原理是什么？
建图阶段：建立视觉地标数据库
机器人位置：
A点 -------- B点 -------- C点
每隔0.5m保存一张图片：
A:
camera.jpg
特征点:
● ● ● ●
● ● ●
B:
camera.jpg
特征点:
▲ ▲ ▲ ▲
C:
camera.jpg
特征点:
■ ■ ■ ■
同时记录：
图片
+
当时机器人坐标
例如：
image_001.jpg
对应:
map坐标:
x=5.2m
y=3.8m
yaw=90°
每0.5m或者2秒采集关键帧，提取ORB特征，保存全局位姿。
数据库类似：
keyframe_db
├── vocabulary
├── feature index
└── pose metadata
运行阶段：机器人迷路
例如：
机器人正在：
地图:
+----------------+
| |
| 展柜 |
| |
| X | 机器人
| |
+----------------+
但是：
人群移动
LiDAR看到相似墙面
AMCL粒子散开
AMCL认为：
我不知道在哪里
covariance ↑
触发视觉。
当前图像提取特征
当前图像提取特征
当前相机：
当前图片:
+----------------+
| 柱子 |
| |
| 展柜 |
| |
+----------------+
提取：
ORB:
当前:
● ● ▲ ▲ ■ ■
数据库:
A:
● ● ● ●
B:
▲ ▲ ▲ ▲
C:
■ ■ ■ ■
图像匹配
DBoW负责快速搜索：
类似：
当前图片
|
v
搜索1000张历史图片
结果:
top1:
keyframe_235
top2:
keyframe_240
top3:
keyframe_236
你的方案：
ORB + DBoW 查询关键帧数据库，取 top-3 候选帧。
PnP计算相机姿态
这是核心。
假设历史图片：
历史:
相机位置:
X=10m
Y=5m
Yaw=45°
现在看到同样特征：
当前相机:
看到这些点：
P1
P2
P3
利用：
3D空间点
+
2D图像点
↓
PnP
↓
相机姿态
得到：
camera:
x=10.3m
y=5.2m
yaw=43°
再转换：
camera坐标
↓
base_link
↓
map坐标
得到机器人:
x=10.1
y=5.0
yaw=44°
发布给AMCL
发布：
/initialpose
告诉AMCL：
“你不要在整个地图随机找了，机器人应该在这里附近。”
然后：
AMCL粒子:
原来:
********************
********************
********************
收到视觉:
***
*****
***
快速收敛
这种方案相比RTAB-Map有什么优势？
当前方案
LiDAR
|
v
AMCL
|
map -> odom
|
Nav2
视觉模块：
Camera
|
v
ORB/DBoW
|
v
找到历史关键帧
|
v
计算机器人位置
|
v
/initialpose
|
v
AMCL重新收敛
地图已经有了，视觉只是告诉 AMCL 我在哪里
Rtabmap方案
RTAB-Map不是这么简单。
RTAB-Map本质：
一个视觉SLAM系统。
它维护：
视觉地图
Node1
|
Node2
|
Node3
|
Node4
每个节点：
图像
RGB-D
特征
位姿
类似：
Node5
|
Node1---Node2---Node3
|
Node4
这是一个Pose Graph。
运行时：
相机输入：
当前图像
|
v
找历史节点
|
v
闭环匹配
|
v
图优化
|
v
当前位姿
所以 RTAB-Map 不只是：
“告诉你在哪”
而是：
“持续跟踪你怎么运动”。
| 你的方案 | RTAB-Map | |
|---|---|---|
| 定位依据 | 已有LiDAR地图 | 视觉地图 |
| 视觉作用 | 辅助 | 主导 |
| 是否持续运行 | 否 | 是 |
| 是否维护视觉地图 | 简单关键帧库 | 完整图优化数据库 |
| 是否做SLAM | 否 | 是 |
| 是否需要调参数 | 少 | 多 |
| 长期运行 | 稳定 | 数据库增长 |
| 依赖光照 | 低 | 较高 |
| 换环境 | 容易 | 需要重新建图 |
RTAB-Map 中的 Localization Mode（纯定位模式）
RTAB-Map 的 Localization Mode（纯定位模式） 可以理解为：
关闭建图，只使用已经建立好的 RTAB-Map 视觉地图，让机器人在这个地图里面定位自己。
它和 SLAM 模式最大的区别是：SLAM Mode：边走边建图 + 定位
RTAB-Map 三种常见模式
RTAB-Map
|
----------------------
| | |
Mapping Localization Database
模式 模式 管理
Localization Mode（纯定位模式）
假设已经有：
rtabmap.db
现在机器人重新启动。
不再创建新地图。
流程：
已有地图
rtabmap.db
|
|
机器人Camera |
|
v
提取当前图像特征
|
v
查询历史Node
|
v
找到相似位置
|
v
计算当前Pose
|
v
输出定位结果
0
次点赞
