第1章：计算瓶颈分析——SLAM各模块的计算量分布
做SLAM的朋友都知道，跑在PC上是一回事，放到嵌入式平台上就是另一回事了。我最早接触这个课题时，天真地以为把算法移植过去就行，结果一跑——帧率直接掉到个位数。嗯，今天我们就来聊聊，SLAM到底“吃”在哪，以及嵌入式平台为什么“扛不住”。
1.1 SLAM各模块的计算量分布
先看一张图，这是我根据多个实际项目总结出来的计算量分布。你会发现，不是所有模块都“吃”算力，但有几个模块确实是“大户”。
你看，前端跟踪和特征提取加起来就占了55%。说白了，这两块是“每帧必做”的，优化空间最大。后端优化虽然只占20%，但一旦触发，CPU占用率会瞬间飙升。我在一个无人机项目里就遇到过——回环检测触发后，飞控直接卡死，差点炸机。
1.2 实时性要求与硬件约束
嵌入式平台做SLAM，最头疼的就是“实时性”这三个字。你想想看，一个30fps的摄像头，每帧只有33ms的处理时间。如果超了，要么丢帧，要么延迟越来越大。
| 模块 | 典型耗时（PC） | 典型耗时（嵌入式） | 实时性要求 |
|---|---|---|---|
| 特征提取 | 5-10ms | 20-50ms | 每帧 |
| 前端跟踪 | 3-8ms | 15-40ms | 每帧 |
| 后端优化 | 10-30ms | 50-200ms | 关键帧触发 |
| 回环检测 | 5-15ms | 30-100ms | 低频触发 |
看到差距了吧？嵌入式平台耗时普遍是PC的3-5倍。为什么会这样？因为嵌入式CPU主频低、没有大缓存、内存带宽也受限。我做过一个测试，同样的ORB特征提取代码，在i7上跑5ms，在RK3399上跑了35ms——差了7倍。
核心矛盾： 算法精度 vs 实时性。你不可能既要高精度特征，又要30fps实时跑。必须做取舍。
1.3 典型嵌入式平台的性能瓶颈
目前主流的嵌入式平台，我按性能分了三个梯队：
- 第一梯队： NVIDIA Jetson系列（TX2、Xavier、Orin）—— 带GPU，适合跑深度学习辅助SLAM
- 第二梯队： 瑞芯微RK3588/RK3399、树莓派4B —— 性价比高，但算力有限
- 第三梯队： STM32H7、ESP32 —— 只能跑轻量级SLAM（如UWB辅助）
每个平台的瓶颈都不一样。我拿RK3399举个例子：
// 伪代码：特征提取耗时分析
// 平台：RK3399， 分辨率：640x480
// ORB特征点：1000个
double t_start = get_time();
cv::ORB::detectAndCompute(img, mask, keypoints, descriptors);
double t_end = get_time();
printf("ORB耗时: %.2f ms\n", (t_end - t_start) * 1000);
// 实际输出：ORB耗时: 32.45 ms
// 瓶颈分析：
// 1. CPU主频只有1.8GHz，单核性能弱
// 2. 内存带宽不足，图像数据搬运慢
// 3. 没有硬件加速单元（如NEON未充分利用）
我的经验： 在RK3399上，把图像分辨率从640x480降到320x240，特征提取时间从32ms降到12ms。精度损失不到5%，但帧率从15fps提升到了30fps。这个取舍，值。
1.4 避坑指南：我踩过的三个坑
做嵌入式SLAM这几年，我踩过不少坑。挑三个最典型的分享给你：
- 内存泄漏： 我曾经在回环检测模块里，每帧都new了一个词典对象，忘了delete。跑了10分钟，内存从200MB涨到2GB，系统直接OOM。后来我改用智能指针+对象池，问题解决。
- 浮点运算陷阱： 嵌入式CPU的浮点运算能力远不如PC。我一开始用double做位姿优化，后来发现float精度完全够用，速度还快了一倍。
- IO瓶颈： 很多人只关注CPU算力，忽略了IO。我遇到过摄像头驱动没优化，每帧图像从传感器读到内存就要5ms。后来改用DMA+双缓冲，降到了1ms。
警告： 不要盲目相信“理论计算量”。实际跑起来，内存带宽、缓存命中率、中断延迟都会影响性能。一定要上板实测。
1.5 小结：瓶颈分析的三个关键点
嗯，总结一下。做计算瓶颈分析，你只需要盯住三个点：
- 找大户： 特征提取和前端跟踪是主要瓶颈，优先优化
- 看约束： 每帧33ms（30fps）是硬指标，超了就丢帧
- 测实际： 理论分析只是参考，上板实测才是王道
下一章，我们会深入特征提取的优化——怎么在嵌入式平台上把ORB跑进10ms。到时候我会分享一个我实际用过的NEON加速方案，效果很惊艳。
公众号:蓝海资料掘金营，微信deep3321