# 机器人系统 架构模板

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

---

## 1. 一句话定位

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

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

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

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

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

## 3. 核心需求与约束

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

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

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

## 4. 架构全景图

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

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

## 5. 组件职责

- **传感器融合 / 状态估计**:把互相矛盾的观测(轮子说走了 1m,激光说走了 0.95m)融合成位姿的最优估计。*为什么需要*:单一传感器都有致命盲区(轮子打滑、激光遇玻璃、相机怕逆光),互补融合是「传感器都在撒谎」的唯一解法。
- **全局规划器**:在地图上算一条从 A 到 B 的路。*为什么需要*:局部视野会走进死胡同,需要全局视野定大方向。
- **局部规划器 / 避障**:高频重算眼前几米怎么走,躲开突然出现的人和货。*为什么需要*:世界是动态的,全局路径秒级就过时;「大方向不变、小动作实时改」是分层规划的精髓。
- **控制器(实时环)**:把轨迹变成每个电机每毫秒的指令。*为什么需要*:物理系统的稳定性靠固定节拍闭环维持,这一层必须跑在实时环境,和「聪明但抖」的上层隔离。
- **任务状态机**:管理「接单→去 A→作业→回充」的业务流程与异常分支。*为什么需要*:同 [嵌入式固件](../embedded-device/README.md)——显式状态机是驯服异常分支的武器,机器人的异常分支尤其多(卡住 / 迷路 / 低电 / 人闯入)。
- **消息中间件(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% 机上;全局调度、多机协同、学习训练放云端。** 划线标准和 [工业边缘](../industrial-edge/README.md) 同款:晚了会出事的,不许过网络。

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

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

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

## 9. 规模化与瓶颈

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

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

## 10. 安全与合规要点

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

## 11. 常见误区 / 反模式

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

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

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

## 13. 可复用要点

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

## 🎯 随堂检验

<Quiz
  question="机器人的急停链路应该怎么设计?"
  :options="['App 下发急停指令,经云端转发到机器人', '独立安全回路直接切断动力,不经过软件主栈和网络', '在导航模块里加一个最高优先级的停止函数']"
  :answer="1"
  explanation="安全不能依赖『软件都正常、网络都通畅』这个假设——急停必须走独立硬件回路,主软件栈整个死掉也停得下来。兜底机制与被兜底系统共享失效模式,等于没有兜底。"
/>

---

## 参考原型与延伸阅读

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

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

**📖 设计文档:**
- [ROS 2 设计文档](https://design.ros2.org/) — 官方设计论证集:为什么用 DDS、实时性如何保障、和 ROS 1 的架构差异——读架构决策原文比读结论有营养。

---

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