机器人系统 架构模板

代表产品 / 原型:扫地机器人、仓储 AGV / AMR、配送机器人、无人机;开源原型 ROS 2、PX4、Nav2 一句话定位:让机器在物理世界里感知 → 定位 → 规划 → 控制毫秒级闭环地跑起来——传感器全在撒谎、动作无法撤销,还要一个人管一百台。

---

1. 一句话定位

机器人系统 = 一条「感知→规划→控制」的实时流水线 + 一条独立的安全旁路 + 一个云端车队大脑。

它和普通后端系统的根本区别有两条:① 物理世界没有 Ctrl+Z——数据库写错可以回滚,撞上货架就是撞上了;② 输入永远是脏的——激光有噪声、轮子会打滑、GPS 会漂移,整个系统建立在「用概率对抗不确定」的地基上。架构的全部使命,是让「聪明但慢」的决策和「简单但快」的反射各就各位。

2. 业务本质:它在解决什么问题

机器人卖的是把人力从重复、繁重、危险的物理劳动中换出来:仓库搬运、地面清洁、末端配送、巡检。账很好算:一台机器人替 0.5~2 个人力,回本周期 1~3 年。

但生意的成败不在「能不能动」,而在**「无人化率」**:一台需要每小时人工救援一次的机器人,省下的钱全赔给运维。所以架构的真实考题是:异常情况下机器自己能恢复多少?恢复不了时,一个远程操作员能同时管多少台? 这决定了单位经济模型是否成立。

3. 核心需求与约束

功能性需求:

• [ ] 感知与状态估计:我在哪?周围有什么?(定位、建图、障碍检测)
• [ ] 规划:全局路径 + 局部避障
• [ ] 控制:把规划变成电机指令,毫秒级闭环
• [ ] 任务执行:接单 → 导航 → 作业(抓取 / 清扫 / 投递)
• [ ] 安全:急停、避碰、异常降级
• [ ] 车队管理:调度、监控、远程接管、OTA

非功能性需求 / 质量属性:

质量属性	目标	为什么对这类系统重要
控制实时性	控制环 100Hz~1kHz 稳定节拍	节拍抖动 = 动作抖动 = 撞击风险
安全性	任何单一故障不伤人	机器人和人共享物理空间
自治率	无人干预时长越长越好	决定单位经济模型(见上)
可测试性	仿真可复现真实问题	实机测试又贵又慢又危险

关键约束(不可逾越的边界):

• 🔴 物理不可撤销:执行了的动作收不回来,「先跑起来再修 bug」在这里会撞坏东西。
• 🔴 传感器不可信:一切观测都带噪声,「当前位置」永远是概率估计而非事实。
• 🔴 车载算力 / 电量有限:算力预算和电池预算同 嵌入式设备 一样是硬约束。
• 🔴 网络不可依赖:仓库有信号死角、路上有隧道——安全闭环必须完全在机上。

4. 架构全景图

 云端(车队层,可离线)   调度派单 │ 车队监控 │ 远程接管 │ OTA │ 数据回传
                          ▲
                          │ 无线网络(时断时续,只传任务与状态,不传安全)
 ─────────────────────────┼─────────────────────────────────────
 机器人本体(自治闭环)      ▼
   ┌─────────────────────────────────────────────────┐
   │ 任务层(~1Hz):任务状态机(接单/导航/作业/充电)      │
   ├─────────────────────────────────────────────────┤
   │ 规划层(~10Hz):全局路径规划 + 局部避障重规划        │
   ├─────────────────────────────────────────────────┤
   │ 感知层(10~30Hz):传感器融合 → 状态估计(我在哪)     │
   │   激光/相机/IMU/轮速 ──▶ 滤波融合 ──▶ 位姿+障碍地图  │
   ├─────────────────────────────────────────────────┤
   │ 控制层(100Hz~1kHz):轨迹跟踪 → 电机指令(实时OS)    │
   └─────────────────────────────────────────────────┘
      各层之间:消息中间件(pub/sub,可录制可回放)
   ═══════════════════════════════════════════════════
   安全旁路(独立于上面一切):
   急停按钮 + 安全激光/碰撞条 ──▶ 安全控制器 ──▶ 断力矩 + 弹簧抱闸
   (不依赖主控计算机、不依赖非安全软件、不依赖网络)

灵魂在于两条:① 频率分层——越往下越快越笨,越往上越慢越聪明,指挥链只有「任务→规划→控制」一条(感知层不发号施令,它是喂给规划和控制的数据源),谁也不越级摸电机;② 安全旁路独立——急停走独立安全回路切断动力,主软件栈整个死掉也停得下来。(注:安全控制器本身也有软件,但那是经过安全认证、独立冗余的软件;停止方式可以是立即断力矩,也可以是先受控减速再断——关键是「独立」,不是「无软件」。)

5. 组件职责

• 传感器融合 / 状态估计:把互相矛盾的观测(轮子说走了 1m,激光说走了 0.95m)融合成位姿的最优估计。为什么需要:单一传感器都有致命盲区(轮子打滑、激光遇玻璃、相机怕逆光),互补融合是「传感器都在撒谎」的唯一解法。
• 全局规划器:在地图上算一条从 A 到 B 的路。为什么需要:局部视野会走进死胡同,需要全局视野定大方向。
• 局部规划器 / 避障:高频重算眼前几米怎么走,躲开突然出现的人和货。为什么需要:世界是动态的,全局路径秒级就过时;「大方向不变、小动作实时改」是分层规划的精髓。
• 控制器(实时环):把轨迹变成每个电机每毫秒的指令。为什么需要:物理系统的稳定性靠固定节拍闭环维持,这一层必须跑在实时环境,和「聪明但抖」的上层隔离。
• 任务状态机:管理「接单→去 A→作业→回充」的业务流程与异常分支。为什么需要:同 嵌入式固件——显式状态机是驯服异常分支的武器,机器人的异常分支尤其多(卡住 / 迷路 / 低电 / 人闯入)。
• 消息中间件(pub/sub):各模块通过话题解耦通信,支持录制回放。为什么需要:见决策 2——「能把现场录下来回放」是机器人研发效率的命脉。
• 安全控制器(独立):急停、安全区域检测,硬件级切断动力。为什么需要:安全不能依赖「软件都正常」这个假设。
• 车队云平台:调度派单、状态监控、远程接管、OTA。为什么需要:规模化的钥匙——100 台机器人靠 1~2 个远程操作员兜底,而不是 10 个现场跟班。

6. 关键数据流

场景一:一次避障(感知→规划→控制的闭环节拍)

1. 激光扫到 3m 外出现行人 → 感知层更新局部障碍地图(30Hz)
2. 局部规划器发现原轨迹撞人 → 10Hz 重算:减速 + 绕行轨迹
3. 控制器以 200Hz 跟踪新轨迹,平滑输出电机指令
4. 全程 <200ms;若行人突然贴身(安全激光近距触发)
   → 安全旁路动作:断力矩 + 弹簧抱闸,不等任何上层反应
   ── 常规避让走「聪明的慢路」,极限避碰走「愚蠢的快路」

场景二:一次任务(云端派单,机上自治)

1. 云调度:「3 号机,去 B7 货架取货送打包台」(只下任务,不遥控)
2. 任务状态机接单 → 全局规划 → 边走边避障(全程无需网络)
3. 途中网络断了:任务照常执行,状态本地缓存,恢复后补报
4. 到点作业 → 完成上报 → 低电则自动插入回充任务
   ── 云是「派工头」不是「遥控器」:断网只影响接新单,不影响干当前活

场景三:一个 bug 的一生(录制→回放→仿真回归)

1. 现场机器人在某转角反复卡死 → 运维一键导出现场数据包
   (全部传感器话题 + 内部状态,黑匣子式)
2. 工程师本地回放数据包:完整重现当时机器人「看到的世界」
3. 定位是局部规划参数问题 → 修复 → 在仿真里跑 1000 个同类场景回归
4. 通过 → OTA 灰度到 10 台观察 → 全量
   ── 没有「录制回放 + 仿真」,每个 bug 都要人跑现场蹲守复现

7. 数据模型与存储选择

核心数据:地图(占据栅格 / 语义地图);实时话题流(传感器 / 位姿 / 指令);任务与轨迹日志;现场数据包(bag);车队状态。

数据	存储类型	为什么
地图	文件 / 对象存储,版本化	环境变了要重建图,多机共享同一版地图
实时话题	不落盘,内存 pub/sub	毫秒级生命周期;需要时按话题选择性录制
现场数据包	机上环形缓冲 → 云对象存储	出事前后几分钟最值钱,黑匣子思想
任务 / 事件日志	云端关系型 + 时序	运营报表(自治率 / 里程 / 救援次数)的原料
车队实时状态	内存级 KV	调度要秒查全场机器人位置与电量

8. 关键架构决策与权衡 ⭐

决策 1:智能放机上,还是放云端?⭐

• 云端大脑:算力无限、算法好迭代、多机全局最优;但网络延迟和断网直接威胁安全。
• 机上自治:安全闭环不依赖网络;但算力受限、更新要走 OTA。
• 取向:安全与运动闭环 100% 机上;全局调度、多机协同、学习训练放云端。 划线标准和 工业边缘 同款:晚了会出事的,不许过网络。

决策 2:模块间用 pub/sub 中间件,还是直接函数调用?

• 函数调用:延迟最低、无中间件成本;但模块死绑,无法单测、无法录制回放。
• pub/sub 话题:模块解耦、可录制、可回放、可仿真替换(仿真器发布假激光话题,下游无感);代价是序列化开销和调度不确定性。
• 取向:研发主体用 pub/sub(录制回放是效率命脉),控制内环(电机级)用共享内存 / 进程内直调。 ROS 生态的成功证明了前者,无数「话题延迟导致控制抖动」的坑证明了后者。

决策 3:先仿真,还是先实机?

• 实机为主:最真实;但一次实验半小时、坏一台几万块,危险场景(撞人)根本不能测。
• 仿真为主:并行上千个仿真实例(等效千倍速)跑万次、危险场景随便造;但仿真和现实永远有差距(sim-to-real gap)。
• 取向:仿真当 CI 门禁(每次改动跑回归场景库),实机做最终验收;现场数据包回灌仿真,持续缩小差距。同 评测驱动 的思想,只是评测对象是物理行为。

决策 4:多机协同——中心调度,还是分布式协商?

• 中心调度:全局最优(路口谁先过、任务怎么分),逻辑好懂好调。
• 分布式协商:无单点、断网健壮;但难调试、难保证全局最优。
• 取向:任务级中心调度 + 运动级本地避让。仓库百台 AGV 的主流答案:云端排班,狭路相逢时机器人自己让——中心管「战略」,本地管「战术」。

9. 规模化与瓶颈

机器人的规模化 = 台数 × 场景多样性 × 无人化率:

• 第一个瓶颈:人机比。 10 台靠现场跟班可以,100 台就必须远程化——仓库等结构化场景可以做到 1~2 个远程操作员兜底(公开道路场景的人机比会低得多)。→ 破解:车队平台 + 远程接管工位 + 异常自恢复策略库(卡住自动后退重试、迷路自动重定位)。
• 第二个瓶颈:长尾场景。 常规场景 99% 好办,剩下 1%(反光地面、临时施工)吃掉全部运维。→ 破解:现场数据包自动回流 → 场景库 → 仿真回归,把每次翻车变成一条永久测试用例。
• 第三个瓶颈:多机拥堵。 台数上去后,狭窄通道和充电桩成了「热点资源」。→ 破解:调度层做流量整形(错峰 / 单行道规则 / 充电排队),和城市治堵一个思路。
• 第四个瓶颈:地图维护。 环境天天变(货架挪位、节日装饰),旧地图 = 集体迷路。→ 破解:边跑边更新的终身建图 + 多机地图众包合并 + 变更检测告警。

10. 安全与合规要点

• 安全的层次:硬件急停(最后防线,直接断电)> 安全控制器(独立回路,近距即停)> 软件避障(常规礼让)。上层可以聪明,底层必须可靠;认证只认独立回路,不认「AI 说它会躲」。
• 人机共存区域:限速、声光提示、安全距离分级降速——法规(如机械安全标准)对协作场景有硬性要求。
• 远程接管的安全边界:遥操作有网络延迟,只允许低速;接管指令要鉴权 + 审计,防止「远程劫持」。
• 数据合规:机器人相机在仓库 / 街道采集的影像涉及人脸和位置隐私,回传要脱敏;测绘级地图数据在部分国家(如中国)受严格管制。
• OTA 安全:同 车载:签名、灰度、条件闸门(充电桩上才升级)、失败回滚。

11. 常见误区 / 反模式

• ❌ 急停 / 安全停止依赖 Wi-Fi 或软件主链路 → ✅ 安全旁路独立成环,主栈全挂也停得下来。
• ❌ 相信单一传感器(只靠轮速计推位置)→ ✅ 多传感器融合;里程计漂移是必然,不是意外。
• ❌ 控制环和业务逻辑跑在一起(规划卡顿导致电机指令断流)→ ✅ 频率分层 + 实时环隔离,控制节拍神圣不可侵犯。
• ❌ 只在实机上测试 → ✅ 仿真回归当 CI 门禁,实机是验收不是主战场。
• ❌ 不做录制回放,bug 靠现场蹲守复现 → ✅ pub/sub + 黑匣子数据包,把现场「带回」工位。
• ❌ 把云当遥控器,网络一断机器人趴窝 → ✅ 云只派任务,自治闭环全在机上。

12. 演进路线:MVP → 成长期 → 成熟期(不同阶段怎么设置)

阶段	规模量级	怎么设置(具体)	此时该操心什么
MVP / 样机	1~3 台	ROS 2 全家桶(建图 / 导航 / 避障用现成栈),一个固定场景跑通全流程;安全旁路从第一天就要有	证明单机闭环能力;别急着自研规划算法
小批量部署	10~50 台	任务状态机打磨异常分支、车队平台(监控 + 远程接管)、仿真回归库、OTA 通道	自治率与人机比——运维成本决定生死
规模化运营	数百台+	中心调度 + 流量整形、数据闭环(现场包→场景库→仿真→OTA)、多机地图协同、控制环深度优化	长尾场景收敛速度、单台经济模型、多场景复制能力

13. 可复用要点

• 💡 频率分层:快的笨、慢的聪明,各守节拍互不越级——高频交易(撮合内环 vs 策略外环)、游戏引擎(渲染帧 vs 逻辑帧)都是同构。
• 💡 安全旁路独立于主链路:兜底机制不能和被兜底的系统共享失效模式——数据库最后一道备份不放同一朵云,同理。
• 💡 pub/sub + 录制回放 = 把生产现场变成可重放的测试用例,对一切「难以复现现场」的系统(交易撮合、实时风控)都是效率杠杆。
• 💡 用概率语言对待脏输入:观测 ≠ 事实,估计 + 置信度才是一等公民——风控反欺诈、传感数据分析同款世界观。
• 💡 每次翻车沉淀为一条回归用例:长尾问题不是靠聪明修完的,是靠「场景库只增不减」熬干的。

🎯 随堂检验

🤔机器人的急停链路应该怎么设计?

• AApp 下发急停指令,经云端转发到机器人
• B独立安全回路直接切断动力,不经过软件主栈和网络
• C在导航模块里加一个最高优先级的停止函数

---

参考原型与延伸阅读

本模板基于以下真实开源项目整理。

🔧 开源原型(可直接读代码):

• ros2/ros2 — 机器人事实标准中间件:pub/sub 话题、录制回放、组件化节点,本模板「消息中间件」一节的原型。
• ros-navigation/navigation2 — ROS 2 官方导航栈:全局规划 / 局部避障 / 恢复行为的分层实现,对应第 6 节场景一。
• PX4/PX4-Autopilot — 开源无人机飞控:实时控制环 + 状态估计(EKF)+ 安全失效保护的教科书,「频率分层」的极致样本。

📖 设计文档:

• ROS 2 设计文档 — 官方设计论证集:为什么用 DDS、实时性如何保障、和 ROS 1 的架构差异——读架构决策原文比读结论有营养。

---

📌 一句话记住机器人系统:它是「聪明但慢」与「简单但快」的分层同居——感知规划在上层用概率思考,控制反射在底层守死节拍,安全旁路独立于一切之外。所有设计都在回答:『传感器在撒谎、网络会断、动作收不回,机器怎么还能又快又稳又不伤人?』