VINS-Mono / VINS-Fusion 这类视觉惯性 SLAM 算法，论文和开源代码都默认跑在 x86 工作站上。把它落到 ARM 嵌入式平台做成手持建图设备，算法本身基本不用动，工作量全在"适配"上。本文按部署顺序总结各环节的要点，基于 RK3588 + ROS Noetic 的实践。
平台与系统
RK3588（4×A76 + 4×A55）的 CPU 算力跑 VINS 前端特征提取 + 后端优化是可行的，但没有 GPU 加速余量，图像预处理要靠 NEON/多线程自己挤性能。系统侧用 ROS Noetic 作为框架——VINS 系列代码本身就是 ROS 包形态，沿用其原生框架比重写成裸进程省太多事。
第一步永远是传感器时间同步
VINS 是紧耦合视觉惯性融合，IMU 和相机时间戳对不齐，算法直接发散，而且现象是"轨迹慢慢飘"而不是立刻报错，很隐蔽。所以部署顺序上，先花大力气做硬件打通：
- IMU 与导航相机的时间同步：让两者的采样时刻可换算到同一时间域，优先走硬件触发而非软件补戳
- 拍照控制：主控侧主动控制曝光时机，而不是被动接收相机自由运行的帧
这一步没过，后面标定和调参都是白做。
标定：Kalibr
相机内参、IMU-相机外参、时间偏移都用 Kalibr 标定。嵌入式部署要注意的是标定数据采集本身就要在目标设备上做——时间偏移（td）和链路延迟强相关，在 PC 上采数据标出的参数搬到设备上不一定成立。
部署形态：ROS + Docker
设备端用 Docker 容器化部署 ROS 环境：算法包、依赖、启动脚本打进镜像，设备系统底座保持干净。好处在现场升级和回滚——算法迭代远快于系统底座，两者解耦后算法可以单独发版。这套"容器化部署 + 统一底座"的做法后来独立演化成了覆盖多款产品的软件平台，VINS 部署是它的第一个真实负载。
业务层配合：自动拍照
手持建图设备的相机不仅服务 SLAM，还要产出照片成果。两者节奏不同（SLAM 要稳定帧率，拍照要按间隔/触发），需要一个自动拍照算法在 SLAM 取流之外独立控制拍照时机，避免互相抢占传感器。
调试期的高频问题
- 时间戳问题居首：轨迹漂移先查 IMU/相机时间对齐，再查标定，最后才怀疑算法参数
- 性能瓶颈在图像通路：VINS 本体 CPU 占用可控，大头在图像采集、格式转换、传输，优先优化这条链路
- ROS 在嵌入式上的开销：节点多、消息序列化频繁时 CPU 开销可观，部署形态上尽量合并进程