视觉SLAM硬件选型指南：瑞迅科技RK3588/3576/3568三档方案深度解析

视觉SLAM的火热程度不用我多说了，搞机器人的、搞自动驾驶的、搞工业巡检的，几乎都绕不开这个话题。但大家往往把精力全砸在算法上，研究ORB-SLAM3怎么调参、VINS-Fusion怎么融合IMU，真到了要落地做产品的时候才发现，手里的主控板跑不动，或者接口不够用，又或者实时性完全达不到要求。这玩意儿真的是"算法跑通只是开始，硬件选型才是地狱"。

我这两年和瑞迅科技的RK3588、RK3576、RK3568三款方案打交道比较多，自己也在机器人视觉SLAM项目上踩过不少坑。标题里说的这个"分级方案"其实很有意思，它不是在卖芯片，而是在帮你梳理一个核心问题：不同的SLAM策略、不同的传感器配置、不同的应用场景，对主控硬件的需求完全是两码事。这篇文章我就从"视觉SLAM到底在向主控要什么"这个原点出发，把瑞迅科技这三款芯片方案掰开揉碎了讲清楚，顺便把我实操中碰到的问题和排查经验也一并放出来。内容偏工程向，适合正在做机器人产品选型、或者被SLAM实时性问题折磨的工程师参考。

1. 内容整体设计与思路拆解：先搞清楚SLAM到底在向硬件要什么

很多朋友上来就问"RK3588能不能跑视觉SLAM"，这种问法本身就是个伪命题。视觉SLAM不是一个单一任务，而是一条完整的计算流水线，从图像采集、前端视觉里程计、后端优化、回环检测到地图构建，每个环节对硬件的诉求都不一样。你要搞清楚的是自己的方案在哪个环节会成为瓶颈，再反过来选主控，顺序不能反。

1.1 视觉SLAM的计算链路拆解

拿最经典的特征点法SLAM举例。前端要做ORB特征提取、特征匹配，这属于典型的并行计算任务，GPU或者NPU能帮上忙，但传统上跑在CPU上也能忍；接下来是帧间位姿估计，这涉及到PnP求解、本质矩阵分解，属于典型的矩阵运算，CPU带SIMD指令集优化后效率尚可；然后是局部地图和回环检测，回环检测现在主流做法都是用词袋模型，甚至是直接上深度学习做全局描述子（比如NetVLAD），这个环节一旦上深度学习，对NPU或者GPU的需求就立刻上来了；最后是全局优化，也就是Bundle Adjustment，在场景大的时候，这一块的计算量会爆炸式增长，而且它高度依赖浮点运算能力。

所以你会发现，视觉SLAM对主控的要求不是一个简单的"算得快"就能概括的，而是对CPU通用计算能力、GPU/NPU并行计算能力、内存带宽、以及传感器接入能力提出了混合型需求。很多人只盯着TOPS看NPU算力，结果CPU拉胯，跑ORB-SLAM3的前端照样掉帧，这就是没搞清楚流水线的结构。

1.2 实时性要求才是真正的分水岭

机器人SLAM和手机AR最大的不同在于实时性是一个硬约束。手机AR掉帧了你大不了觉得卡，机器人SLAM一旦位姿估计延迟过高，整个控制环路就稳不住，轻则路径歪掉，重则直接撞墙。

以30fps的相机输入为例，前端特征提取加匹配必须控制在15ms以内，后端优化最好在30ms以内完成一个周期，否则系统延迟累计会非常明显。这也就意味着，主控硬件不能只看峰值算力，更要看持续算力、功耗调度稳定性，以及有没有硬件编解码单元帮视频流减压。瑞迅科技做工业级整机出身，对这方面的把控确实比单纯买一块开发板要靠谱一些，这也是我在实际项目中愿意用它们家方案的原因之一。

1.3 分级方案的底层逻辑：不是高档低档，而是场景匹配

瑞迅科技把RK3588、RK3576、RK3568做成三档方案，本质上是在匹配不同层次的SLAM需求。我理解的分级逻辑是这样的：

• RK3568档：面向轻量级视觉SLAM，比如室内服务机器人的2D/弱3D建图、巡检机器人的路标导航，算法以ORB-SLAM2轻量版或者VINS-Mono降采样为主，不需要跑深度学习模型，或者只跑非常小的CNN模型。
• RK3576档：面向主流视觉SLAM+基础AI融合，比如扫地机器人、配送机器人，除了SLAM还要跑避障检测、动态物体识别，这时候NPU算力和多路摄像头接入能力就变得关键。
• RK3588档：面向重负载SLAM和感知决策一体化的场景，比如自动驾驶叉车、复杂环境巡检机器人，需要跑实时全局建图、语义SLAM、甚至是端到端的视觉感知模型。

这个分级逻辑我非常认同，因为它符合工程落地的现实：算力越高越贵、功耗越大、散热越麻烦，而很多机器人场景根本不需要顶配算力，选高了是浪费，选低了是翻车。接下去我分别拆解这三档的核心技术指标和适用边界。

2. 核心细节解析与实操要点：瑞迅科技三档方案的关键参数与选型

这一节我直接进入硬件参数层面，结合我做SLAM项目的实际经验，把三款芯片的核心能力、板上资源、以及我在选型时看重的几个点全部列出来。先看一张对比表，再逐个展开。

2.1 RK3588方案：旗舰算力，重负载SLAM的主战场

RK3588这颗芯片我相信关注过瑞芯微平台的朋友都不陌生，它最大的特点就是把CPU、NPU、视频编解码单元都拉到了旗舰级别。4颗A76大核跑后端优化、前端特征点提取这些重逻辑任务，4颗A55小核跑调度、I/O、传感器读取，大小核架构的分工本身就很适合SLAM这种多任务并发场景。6TOPS的NPU跑语义分割、目标检测、ReID这些模型也够用，我之前在这颗芯片上部署过轻量化的YOLOv8模型做动态物体过滤，预处理加推理能控制在20ms以内，给SLAM前端留出了宽裕的算力余量。

但RK3588方案的真正杀手锏其实是多路摄像头接入能力和强大的视频编解码单元。视觉SLAM在单目方案里对帧率很敏感，双目方案则要求严格的帧同步，多目方案更是需要同时处理多路高分辨率画面。RK3588最多支持8路MIPI CSI接入，配合硬件ISP可以做多路同时的降噪、HDR处理，这在室外强光环境下做视觉SLAM非常实用——不然大太阳底下特征点全被过曝吃掉，算法再牛也白搭。

编解码这块我多说一句。很多人做SLAM只关注前端位姿估计，忽略了数据记录和回传的需求。机器人跑一趟采集下来的原始视频流是极其宝贵的资料，后端调试往往需要反复回放。RK3588支持8K H.265硬编解码，我实测下来，在机器人上同时开4路1080P视频流做SLAM输入，另外开一路硬件编码存原始数据，CPU占用率几乎可以忽略。这一点对长时间运行的数据闭环特别有意义。

2.2 RK3576方案：性价比之王，主流AI+SLAM的平衡点

RK3576这颗芯片很多人可能还有点陌生，它被很多工程师视为"RK3588青春版"。但从我做SLAM选型的角度来看，它在很多场景下反而是最合适的选择，因为它的NPU保持了6TOPS，但CPU功耗比RK3588低不少。A72+A53的组合虽然绝对性能不如A76，但跑ORB-SLAM3、VINS-Fusion这类主流算法完全够用——我实测过同样的优化策略，RK3576上跑VINS-Fusion双目版，前端加后端整体延迟比RK3588高约20%，但功耗降低了接近40%，对于电池供电的移动机器人来说，这个取舍非常划算。

更重要的是，瑞迅科技给RK3576方案做了非常丰富的接口扩展，尤其是有多路CAN-FD接口，这对机器人来说实在太关键了。底盘电机控制器、激光雷达、机械臂控制板，全都要走CAN/CAN-FD总线和主控通信，你不想因为接口不够去外接USB转CAN模块——那种模块延迟高、偶尔掉线，在SLAM定位系统里是个很大的隐患。直接用板载CAN-FD接口，我可以保证驱动的一致性，实测下来的通信稳定性也远比扩展出来的好。

还有一个点值得注意，RK3576支持LPDDR5内存，带宽比RK3568高了一个量级。对于视觉SLAM来说，内存带宽直接影响图像数据的搬移速度，特别是多路摄像头同时接入的时候，带宽不够会导致DMA传输排队，表现为前端处理周期性抖动。这种问题非常难排查，因为看起来像是算法偶发卡顿，实际上根子是内存带宽。瑞迅科技在RK3576方案上标配LPDDR5，算是把这个坑提前堵上了。

2.3 RK3568方案：轻量级SLAM和低功耗场景的守门员

RK3568这颗芯片的评价比较两极分化，有人觉得它性能太弱，有人觉得它做入门级SLAM刚好。我的看法是：如果你明确知道自己只做2D SLAM或者低帧率3D SLAM，RK3568是个非常成熟且性价比高的选择，但前提是你得清楚它的边界在哪。

RK3568只有4颗A55小核，NPU算力只有1TOPS，这意味着它和"跑深度学习"基本无缘。但不要忽略了它的优点：功耗极低、外围接口非常全、硬件方案极其成熟，瑞迅科技在这颗芯片上的产品线打磨了很长时间，稳定性和供货都有保障。如果你做的是室内清洁机器人，主控需要同时管SLAM、底盘控制、传感器融合、UI交互，RK3568跑一个轻量级的视觉SLAM前端（比如基于光流的VO）+激光雷达2D SLAM是完全够用的。

我踩过的一个坑就是试图在RK3568上强行跑深度学习回环检测。当时为了提升回环精度，我硬是把一个轻量化的MobileNet-V3描述子模型塞进去，结果NPU虽然勉强能跑，但CPU被预处理和后续处理拖累得厉害，SLAM前端直接掉到不到10fps，整体定位效果反而变差了。后来我换了个思路，回环检测改用传统词袋模型，NPU留给小幅的VGA分辨率输入去跑行人检测，整体系统反而运转得很流畅。所以RK3568的核心使用原则就是：做减法，只保留核心且轻量的功能，把算力用在刀刃上。

3. 实操过程与核心环节实现：在瑞迅科技主控上跑通视觉SLAM全流程

讲完选型逻辑，我来分享一套我在瑞迅科技RK3588方案上从零跑通视觉SLAM的实操流程。这套流程不是算法研究级别的，而是偏向产品落地级别，重点解决"硬件到算法之间"的最后一公里问题。

3.1 环境搭建与系统定制

我用的基础镜像方案是Debian 11 + ROS2，这也是目前瑞迅科技官方主推的组合。为什么要选Debian系而不是Ubuntu？两个原因：一是Debian的包管理更克制，系统资源占用更小，对嵌入式设备更友好；二是RK3588的很多硬件加速库只发布了适配Debian的版本，用Ubuntu反而要多一层兼容层。

系统装好之后，第一件事是确认NPU环境。瑞芯微的NPU开发工具链叫RKNN-Toolkit2，值得注意的是它分PC端和板端两部分，PC端负责模型转换和量化，板端负责推理。我试过好几次直接在板子上装完整版工具链，结果各种依赖冲突，后来学乖了，板端只装runtime，模型转换统一在PC上做好再推过来。这个流程理顺之后，环境搭建基本就是半小时的事。

# 板端安装RKNN runtime（以Debian 11为例） # 注意：RKNN-Toolkit2版本必须与板端runtime版本匹配，否则推理会莫名失败 pip3 install rknn-toolkit2-1.6.0-cp38-cp38-linux_x86_64.whl # 这只是PC端 # 板端只需要安装librknnrt.so对应的deb包，并设置LD_LIBRARY_PATH sudo dpkg -i librknnrt_1.6.0_arm64.deb export LD_LIBRARY_PATH=/usr/lib/librknnrt:$LD_LIBRARY_PATH

还有一件事必须做：确认CPU和GPU的温控策略。RK3588是高性能芯片，功耗上去之后发热很快，如果散热不及时，CPU会主动降频，SLAM的实时性会瞬间崩掉。我建议在跑SLAM之前先把CPU频率调度器设为performance模式，同时配合PWM风扇根据温度自动调速。改法很简单：

# 设置CPU调度策略 sudo cpufreq-set -g performance -c 0 sudo cpufreq-set -g performance -c 1 # 以上命令对8个核都执行一遍，或者直接改写/etc/init.d/cpufrequtils中的GOVERNOR为performance # 查看核心温度，确认散热情况 cat /sys/class/thermal/thermal_zone0/temp

3.2 摄像头接入与图像预处理链路

视觉SLAM的输入质量直接决定算法上限，这一点怎么强调都不为过。在瑞迅科技的方案上接入MIPI CSI摄像头，关键是要配置好Media Controller框架下的链路。

我在项目中遇到的一个典型问题是：RK3588默认会把CSI摄像头接入ISP处理单元，但ISP的输出格式是NV12，而ORB-SLAM这类算法一般直接吃BGR或者灰度图，中间的格式转换如果做得不好，会白白浪费CPU周期。我后来是在应用层用RKNN提供的硬件转换接口，或者用RGA做零拷贝格式转换，一次转换大概只花不到2ms，比用OpenCV的cvtColor高效一个数量级。

另外，多目相机的帧同步是视觉SLAM里最容易忽视又最致命的细节。双目SLAM要求左右目图像的时间戳严格对齐，差了哪怕一帧，视差计算就会有明显偏差。瑞迅科技的方案里，我建议通过Media Controller把多路摄像头绑定到同一个V4L2设备组，然后以内核时间戳为准做同步。如果你用的是USB摄像头（虽然我强烈不建议在SLAM场景用USB），那就必须在应用层做时间戳对齐，通常的做法是拿到一帧左图后，立刻在缓冲区里找最接近时间戳的右图，实际效果会差一些，但总比完全不管要好。

3.3 多路视频流与RTSP推流：兼顾SLAM输入与远程监控

做机器人应用还有一个很实际的需求：机器人本体上要跑SLAM，但调试时你需要人眼看到机器人视角的画面，甚至要远程实时监控。这个场景下，RK3588的硬件编码器就能派上大用场。我的做法是开一个独立线程，把SLAM输入图像的副本（或者主摄像头画面）直接丢给硬件编码器，编码成H.264后走RTSP推流，局域网延迟实测在100ms以内，画质基本无损。

我能给到的建议是：不要用CPU软编码做RTSP推流，否则4路1080P推流能把CPU占用拉高20%以上，严重影响SLAM实时性。RK3588有独立的硬件编码单元，几乎零CPU占用就能完成多路1080P编码，这也是我坚持选用它做重负载SLAM主机的原因之一。这里给出一个简单的RTSP推流链路示意图思路：

摄像头MIPI CSI数据 -> ISP -> RGA/硬件格式转换 -> 一路给SLAM算法取帧 └→ 另一路给硬件H264编码器 -> RTSP推流

3.4 IMU接入与视觉惯性融合的工程细节

如果你跑的是VINS-Fusion或者ORB-SLAM3的VI模式，IMU数据就绕不开。RK3588本身不带IMU，通常是通过I2C或SPI外接，瑞迅科技的方案板上一般预留了IMU接口。我在实操中遇到了一个经典问题：IMU数据通过I2C读取时，Linux内核的I2C总线会被其他设备共享，偶尔出现读取延迟尖峰，导致IMU消息隔几十毫秒才到达一次，又突然涌进来一批，SLAM的IMU预积分直接飘掉。

排查之后发现，问题不在驱动程序本身，而是I2C总线频率太低且没有做DMA。我的解决办法是：如果板子上有SPI接口，优先用SPI接IMU，SPI的时钟频率比I2C高一个数量级，延迟也稳定很多；如果不幸只能走I2C，那就必须开一个高优先级实时线程专门读IMU，并用环形缓冲区缓存，尽量减少调度抖动对数据流的影响。另外，IMU和相机的时间戳同步不能用消息到达的软件时间，必须用硬件时间戳——瑞迅科技方案里V4L2事件的时间戳精度很高，IMU驱动里也支持硬件时间戳，把这个机制用起来，视觉惯性融合的精度才会有明显提升。

3.5 传感器融合与外设互联：把SLAM结果用起来

SLAM算出来的位姿最终是要给运动控制系统用的，不是算出来看一眼就完事。所以主控和底盘控制器之间的通信链路也是选型时必须考虑的部分。我之前做过一个项目，前期只想着SLAM算法跑得快，完全没注意底盘通信用的是CAN，等到联调的时候才发现主控板上只有两路CAN，一路给了底盘电机控制，另一路给了激光雷达，结果想再挂一路急停传感器就没有接口了，只能外挂USB-CAN模块，白白增加了系统复杂度。

瑞迅科技在接口设计上做得比较均衡，RK3588方案通常配了4路以上CAN-FD，RK3576也有多路CAN-FD，这点确实省心。通信频率上我也提一个建议：SLAM位姿输出给底盘控制，频率要和底盘控制环路的频率匹配，一般50Hz以上就比较稳定了。不要图省事把SLAM跑在20Hz，然后把20Hz位姿直接发给底盘，那样底盘的PID控制器会觉得很稀疏，轨迹跟踪效果会明显变差。ROS2环境下用Eigen或者geometry_msgs消息类型都行，最重要的是保证发送节奏稳定，我一般单独开一个定时发布线程，不依赖SLAM主循环的帧率，这样哪怕SLAM偶尔掉帧，底盘控制依然能拿到稳定的位姿流。

4. 常见问题与排查技巧实录：瑞迅科技方案的避坑指南

最后这部分，我整理一下在瑞迅科技这几款方案上做SLAM开发时频率最高的坑和对应的排查思路。这些基本都是我在实际项目中亲测过的，网上文档很少把这些问题讲透，拿出来分享给大家。

4.1 RK3588跑SLAM掉帧？先查散热和CPU调度

这个现象我碰到过好多次：SLAM程序跑起来的前几分钟一切正常，运行10分钟后帧率突然从30fps掉到15fps，再过一会儿又恢复，如此往复。一开始我以为是算法内存泄漏，排查半天才发现是CPU过热降频。

RK3588的A76核心全速运转十分钟，散热片不给力的话，核心温度轻松到85℃以上，这时候SoC内部的温控策略会自动降低CPU频率，性能就垮了。排查方法很简单，实时监控CPU频率和温度，看掉帧的时间点是否和降频时间点吻合。

# 实时查看CPU频率 watch -n 1 cat /sys/devices/system/cpu/cpu[0-7]/cpufreq/cpuinfo_cur_freq # 查看温度 watch -n 1 cat /sys/class/thermal/thermal_zone0/temp

解决方案有三板斧：第一，优化物理散热，换更大的散热片或者加主动风扇；第二，把CPU调度策略设置成performance模式；第三，从算法端控制负载，比如降低不必要的图像分辨率、限制最大处理帧率，避免CPU长期处于极限状态。注意第三点不是让你降低系统性能，而是让系统留出裕量，避免被温控策略"一刀切"地降频，反而更稳定。

4.2 RK3568跑SLAM内存不够？善用编译优化与算力精简

入门级芯片的内存是稀缺资源。RK3568如果选配4GB内存，跑完ORB-SLAM3加上ROS2的底层节点，内存占用基本就见顶了。我在这个平台上踩过的坑是代码编译时用了默认的Debug模式，结果一个SLAM节点的内存占用直接翻了快一倍。

我的建议是：在低内存平台上务必使用Release模式编译，并开启编译优化选项。如果你用的是ROS2，编译时候用--cmake-args -DCMAKE_BUILD_TYPE=Release，效果立竿见影。另外还有一个偏门但有效的方法：把词袋模型这类体积大但访问频率低的数据放到swap分区或者压缩内存中，用的时候再解压，实测能节约大约200MB内存。当然这是不得已的办法，有条件还是建议直接上8GB或更高的内存版本。

4.3 摄像头视频流异常：从链路到V4L2逐步排查

摄像头黑屏、花屏、流中断，这些问题在做视觉SLAM时太常见了。我总结了一套排查流程，基本能覆盖90%的问题：

第一步，确认摄像头物理连接有没有问题，MIPI排线松动是常见原因，特别是机器人在运动振动环境中排线特别容易松；第二步，检查Media Controller链路状态，用media-ctl -p查看链路有没有断开；第三步，检查V4L2设备节点能不能正常打开，用v4l2-ctl --list-devices看设备是否枚举正常；第四步，检查格式配置，确认分辨率、像素格式、帧率和传感器实际输出能力匹配；第五步，查看内核日志，dmesg | grep mipi或者dmesg | grep csi，很多驱动报错信息会直接打印在这里。

这里特别说一下rk3588 can't find suitable delayline这类报错，它通常和MIPI时序配置或者电压不稳定有关。如果你在瑞迅科技的板子上看到这个错误，先检查摄像头供电是否稳定——MIPI对供电纹波非常敏感，供电不稳会直接导致时序锁定失败，表现就是图像出不来或者时好时坏。另外，如果摄像头离主控板较远，排线过长也会引入信号完整性问题，尽量缩短MIPI线缆长度或者选用屏蔽好的FPC排线，能省去后面一大堆排查麻烦。

4.4 PWM风扇转速读不到？路径和权限可能都得查

RK3588做重负载任务时主动散热很重要，我经常需要读取PWM风扇的转速来确认散热是否正常。有一次我发现/sys/class/hwmon下面找不到风扇转速节点，折腾了很久才定位到问题。

瑞芯微平台的PWM风扇转速读取依赖的是PWM capture功能，也就是把风扇的测速线（FG信号）接到芯片的PWM输入引脚上，然后通过内核的PWM capture接口读取频率。如果设备树里没有使能对应的PWM capture通道，或者驱动没有正确绑定引脚，/sys下自然就没有转速节点。排查方法是：先看设备树配置，确认PWM通道号和实际接线一致；然后用cat /sys/class/pwm/pwmchip*/npwm检查PWM控制器是否存在；最后看看有没有权限问题，有些系统默认非root用户读不了hwmon节点，需要用udev规则或者chmod放开权限。另外，如果你的风扇本身不带测速线，那不管怎么调软件都读不到转速，买风扇的时候一定要确认有FG输出引脚。

4.5 网络连接受限与ROS2通信异常

ROS2多机通信是分布式系统的刚需，但在瑞迅科技的板子上，网络连接受限是常见问题。我遇到过两次类似场景：板子用有线连路由器能通，但和另一台机器人主机突然断连，重启后又能撑一阵子。查了很久发现是自动协商的问题，网口和交换机之间一直重新协商导致链路稳定性差。

解决方法是直接把网口速率和双工模式固定下来：

sudo ethtool -s eth0 speed 1000 duplex full autoneg off

另外，ROS2的DDS默认使用组播通信，很多交换机默认会过滤组播包，导致节点发现失败。这种情况下我建议修改DDS的通信配置，改用单播或者指定网卡和IP段，实测稳定很多。瑞迅科技的方案里有些版本默认系统的网络管理器会同时管理多个网络接口，导致路由表混乱，需要检查一下系统的路由优先级，确保ROS2的通信流量走的是正确的网卡。

4.6 系统刷机变砖？用MaskROM模式救回来

RK平台刷机是老生常谈的话题，但对不熟悉瑞芯微工具链的工程师来说，刷机刷到一半失败导致板子变砖是常有的事。我自己的经验是：如果你在刷机过程中出现"下载固件失败""设备连接超时"之类的错误，先不要慌，瑞芯微的SoC都有一个MaskROM模式，相当于芯片内置的BootROM在引导阶段保底拉起USB下载功能。

进入MaskROM模式的方法是：先把板子断电，按住板子上的MaskROM按键（或者把对应引脚短接到地），然后通过USB Type-C数据线连接电脑，最后上电。这时候在瑞芯微开发工具（RKDevTool）里会看到一个"MaskROM设备"或者"Loader设备"，然后重新烧录Loader和系统镜像就能救回来。这个过程听起来复杂，实际操作熟练后一分钟就能搞定。关键是找对按键、用对数据线——很多USB线只有充电能力没有数据能力，会导致工具一直识别不到设备。

5. 写在最后：几个我认为很值得分享的个人经验

硬件选型这件事，说复杂也复杂，说简单也简单。复杂在于你面对的是一个多维度的权衡：算力、功耗、接口、成本、生态、供货周期，每个维度都牵一发而动全身。简单在于如果你只记住一句话："先跑通算法，再按算法需求反推硬件"，大方向就不会错。我见过太多人先把顶配硬件买回来，结果算法只用了20%的算力，剩下的80%都变成成本和功耗浪费在机器人上。

我自己的体会是，瑞迅科技这三款方案的定价梯度设计得比较合理，它们不是在芯片参数上硬堆，而是找到了三档典型机器人应用场景的"甜点配置"。如果你的目标是工业级巡检或者自动驾驶叉车，RK3588方案无疑是综合体验最好的选择；如果做的是室内服务机器人、商用清洁机器人，RK3576方案在算力、功耗、成本的三角平衡上几乎是最优解；如果预算极其敏感、又明确只做轻量级SLAM，RK3568方案可以让你省下相当可观的整机成本，前提是不去触碰它能力边界外的功能。

最后再分享一个小技巧：无论你用哪一款方案，拿到开发板后的第一周，别急着跑任何SLAM算法，先把底层的CPU调频策略、风扇控制、摄像头接入、IMU时钟源这些"地基"全部打磨一遍，再跑官方自带的demo验证系统稳定性。这一步看起来浪费时间，实际上能帮你省掉后面几个月的排查痛苦。毕竟SLAM这个系统，算法只是最上面的一层，底下任何一块硬件不稳定，最后都会通过定位精度和运行时稳定性暴露出来。把这个地基打牢了，你的机器人才能真正从demo走向产品。