当一家公司有多款相机类产品时，每个产品各自维护一套系统镜像和业务代码，很快会导致驱动、算法、升级逻辑在多个仓库里分叉。本文总结一种在这类产品线上验证过的做法：做一个覆盖全系产品的统一软件平台，产品差异收敛到配置和业务包。

底座：Buildroot + ROS

平台底座用 Buildroot 定制嵌入式 Linux 系统，在其上跑 ROS 作为进程间通讯和模块组织框架。Buildroot 负责把系统裁剪到产品需要的最小集合，ROS 负责把驱动、算法、业务拆成可独立开发和部署的包。

典型的分层：

• 入口业务包：产品业务框架的入口，定义这台设备"是什么产品、有哪些业务能力"
• 调试界面包：面向研发/产线的调试 UI，与业务解耦
• 驱动层：相机、传感器等硬件驱动，按固定目录布局安装
• 算法层：SLAM 等算法组件，与驱动层分开部署，便于独立升级
• 入口脚本：系统启动后拉起整个软件栈的唯一入口
• 大包管理系统：软件以"zip 包 + info.json 描述文件"的形式组织和分发，是部署和升级的基本单元

关键设计决策

Docker 容器化编译与部署

编译环境和运行环境都用 Docker 固化。编译容器保证任何机器上构建出的镜像一致；部署侧容器化则让算法、业务这类迭代快的组件可以脱离系统底座单独发布。嵌入式平台上做容器化要付出镜像体积和启动开销的代价，但换来的是多产品共用同一套发布流水线。

业务框架用状态机而不是消息回调堆

相机设备的业务（开机自检、待连机、采集中、升级中、异常恢复……）天然是状态机。框架基于 Python 的 statemachine 库实现，把"当前处于什么状态、什么事件触发迁移、迁移时做什么动作"显式建模，而不是散落在各个 ROS 回调里的 flag 判断。好处是状态迁移可枚举、可测试，新增业务状态时框架会逼着你回答"从哪些状态能进来"。

对外通讯：ROS WebSocket + BSON

设备对 App/PC 端暴露的接口走 ROS WebSocket，序列化用 BSON 而不是 JSON。相机产品要传图像元数据、点云这类二进制内容，BSON 省掉 base64 的体积和编解码开销。

BLE + WiFi 双通道设备发现

手机 App 找设备的经典难题：WiFi 直连模式下手机没有外网，局域网发现又依赖双方同网段。做法是 BLE 和 WiFi 双通道并行发现——BLE 通道负责低速但可靠的设备广播和握手，WiFi 通道负责建立后的数据通路。任何一条通道先通都可以完成发现，互为兜底。

整机 OTA

升级单位是"整机"而不是单个包：系统底座、驱动、算法、业务作为一个有版本号的整体发布，配合上面的大包管理系统做分发。整机 OTA 的关键不在传输，而在于把多组件版本兼容性收敛成"一个整机版本号"，现场不会出现"算法是新版、驱动是旧版"的组合。

证书认证激活

设备出厂不直接可用，需经证书认证激活。每台设备有独立证书，激活流程完成设备身份与服务端的绑定。这个方案同时服务于两个目的：售后侧能确认设备合法性，商务侧能以激活为准管理授权。

这套模式的适用边界

适合"多款产品共享同一类硬件架构、同一类算法栈"的产品线。如果产品间硬件差异大到驱动层无法共用，统一底座会退化成又一个产品分支，不如分开维护。