需求分析：把用户的话变成 R1-R10 工程条款
"让机器人在工厂里装货、分拣、码垛，还要听得懂话、保得了命"——这样一句话怎么做成交付系统？本实验从需求的模糊性出发，逐条吃透 R1-R10 需求体系，画出三大任务的物流链，厘清 R8 语音打断与 R9 雷达急停的优先级分层，并完成一份结构化需求阅读笔记。
01问题引入：一句话需求为什么做不成系统
项目启动会上，需求往往只有一句话："做一个会装货、分拣、码垛的智能工厂机器人，能语音控制，要注意安全。"把它直接交给程序员会发生什么？
02原理通俗讲解：开餐厅，先定菜单再排厨房工位
需求工程听起来抽象，其实和开一家餐厅一模一样——没有人先买锅碗瓢盆再想卖什么菜：
菜单没定就采购，食材全浪费。菜单就是需求边界：装货、分拣、码垛三道"菜品"（R4-R6），点菜方式是"语音"（R1-R3）。
切配、掌勺、传菜各司其职（EXP-02 的五节点）。工位安排错了，再好的菜单也出不了菜——这就是"先需求后架构"的顺序。
传菜条上写什么（口味、桌号）就是接口的消息字段（EXP-03）。写模糊了，传错菜是常态。
R3/R7 约束：大模型只负责把"顾客的话"翻译成点菜动作，"您的菜好了"永远是固定话术——后厨不即兴发挥，上错的风险就小。
R9：有人靠近灶台 20cm 内停留 0.5 秒，整锅立刻停火——来不及请示，量化阈值才是保命的。
EXP-09 按 TS 测试用例逐条过——菜单、工位、急停全部演练一遍，才敢开门迎客。
03关联知识点：R1-R10 体系与两大打断
知识点 1.1.1 · R1-R10 需求体系（前置：ROS 2 话题/服务/参数基础）。按四个维度分组，逐条标注"可量化约束"：
| 分组 | 条款 | 一句话要点 | 可量化约束 |
|---|---|---|---|
| 交互 | R1-R3 | 单轮语音闭环：唤醒→ASR→LLM 意图→执行→播报 | 意图枚举 load/sort/palletize；一律走大模型意图解析、不用关键词匹配；大模型只做功能映射，播报用固定文案 |
| 任务 | R4-R6 | 装货 / 分拣 / 码垛三大任务 | R4.1：每步操作完成后必须先回 work 姿态才能进行下一步 |
| 播报打断 | R7-R8 | 固定文案播报；语音唤醒打断四步复位 | 中断动作 → 回 work → 流水线停止 → 取消任务 |
| 安全 | R9-R9.1 | 雷达危险检测释放力矩；打断分层 | 前方 60°（0° 为中心 ±30° 跨 0° 环绕）+ 20cm 内 + 持续 0.5s → 释放 6 个总线舵机力矩 + danger=true；雷达打断 > 语音打断 |
| 工程 | R10 | 工程组织与文档结构 | docs/01 需求总览等文档行号可追溯 |
知识点 1.1.2 · 三大任务流程——物流链总览（docs/05_流程与安全.md）：
# 物流链（每个阶段收尾都有"回 work"这一步安全握手） 装货区 → 分拣区 → 流水线（定点停靠） → 码垛区 R4 视觉抓取 R5 抓取放流水线 送料+光电定点停 R6 定点取料码放 ⟳ 回work ⟳ 回work ⟳ 回work ⟳ 回work (R4.1)
知识点 1.1.3 · 安全联锁：R9 检测基于激光雷达自身坐标系 laser_link（不依赖车身 TF），触发动作是话题直发释放力矩（最快路径）；危险解除后恢复力矩 + 调 /arm_controller/go_work + danger=false，随后需重新唤醒才执行任务。R8 是用户主动打断的四步复位，两者优先级不同。
04实验目标
- 理解 R1-R10 需求体系，能逐条复述每个需求的约束要点（唤醒词集合、任务指令集合、安全阈值等）
- 掌握装货/分拣/码垛三大任务的物流走向与执行顺序，能独立绘制含"回 work"状态的任务流程图
- 理解安全联锁机制（雷达危险检测 → 释放机械臂总线舵机力矩），以及 R8 语音打断与 R9 雷达打断的分层关系
- 理解语音 + 大模型驱动的单轮闭环（唤醒 → ASR → LLM 意图 → 执行 → 播报），并解释"大模型只做功能映射、不生成应答文案"的设计理由
- 独立完成一份结构化需求阅读笔记，能标注【待定】项与隐含约束
- 迁移："需求总览 → 流程梳理 → 安全约束"的分析方法可迁移到其他具身智能/智能制造场景
05实验环境与准备
| 类别 | 内容 |
|---|---|
| 硬件 | B2 麦克纳姆底盘、C1 五自由度机械臂 + 夹爪（本实验仅阅读文档，无需上电）；涉及传感器：激光雷达、RGB-D 深度相机、语音阵列麦克风、光电传感器、AprilTag 标签（tag36h11） |
| OS / ROS | Ubuntu 22.04 + ROS 2 Humble |
| Python | 3.10（语音/视觉/抓取节点运行时使用 /home/iflytek/ros2_venv 虚拟环境；本实验仅需理解概念） |
| 核心库 | rclpy、std_msgs、std_srvs、geometry_msgs、sensor_msgs（仅需理解消息类型概念） |
| 阅读对象 | app/eai_factory/ 包内 docs/01_需求总览.md、docs/05_流程与安全.md、README.md |
06动画讲解：物流链与打断分层
上半部分：货物流经四个工区，每一步收尾都先回 work 再进入下一步（R4.1）；下半部分：两类打断的分层仲裁——雷达打断（R9）优先级高于语音打断（R8），危险期间语音的"回 work"被抑制。
07互动讲解：需求裁剪实验台
假设你是项目经理，想"砍掉"某条需求省成本——点击按钮看看裁掉它会坏什么：
08实操步骤：五步吃透需求文档
# ① 在 eai_factory 包目录下：快速定位各条款行号 ls docs/ grep -n "R[0-9]" docs/01_需求总览.md # 定位 R1-R10 各条款 grep -n "R8\|R9" docs/05_流程与安全.md # 定位打断与安全章节 # L62-L68(R8) L70-L78(R9) L80-L88(R9.1) ... # ② 架构速览与关键决策（只记录，不执行） head -50 README.md # 架构速览：N1 语音 / N2 调度器 / N-grasp 双模式 / N3 安全 / N-conveyor 流水线 # 复用清单：car1_bringup / car1_arm_controller / car1_peripherals / apriltag_detector # ③ 一键启动命令（本实验仅记录语法，7 个开关 EXP-02 展开） ros2 launch eai_factory eai_factory.launch.py # 7 开关：start_base / start_viz / start_voice / start_vision # / start_grasp / start_conveyor / start_radar
09重点与易错点
config/eai_factory.yaml 为准）。| ⚠️ 常见坑 | 现象 → 解法 |
|---|---|
| 分不清 R8 与 R9 | 两类打断都叫"打断"但触发源不同 → 按触发源 / 动作 / 解除条件三列做对比表：语音唤醒→复位动作；雷达危险→释放力矩 |
| 流程图漏掉回 work | 未注意到 R4.1 是显式需求 → 用 docs/01_需求总览.md L52-L55 的适用清单逐项核对每个任务的收尾 |
| 把【待定】坐标当实现值 | 需求文档与配置文档混读 → 以【待定】标记为准，坐标类数值以 config/eai_factory.yaml 为准 |
| 误以为危险解除会自动续跑 | 漏读 R9.1 → 危险解除进 work 后需等待重新唤醒再执行任务，不会自动继续 |
| 把复用节点记成自家模块 | README 已给出复用清单 → car1_bringup / car1_arm_controller / car1_peripherals / apriltag_detector / visual_grasp 是"复用不改" |
- 能列出 R1-R10 每条一句话要点，并说出哪几条属于交互 / 任务 / 安全分组
- 能画出 装货区 → 分拣区 → 流水线(定点停靠) → 码垛区 物流链，并标注每阶段的回 work（R4.1）
- 能说出雷达危险触发三个量化条件（60° 扇区、20cm、0.5s）与触发动作（释放 6 个总线舵机力矩 + 发 danger）
- 能说出语音打断（R8）四步复位：中断动作 → 回 work → 流水线停止 → 取消任务
- 需求笔记含文档行号引用、【待定】标注与需求→模块映射
10实验总结与思考
R1-R10 梳理表（含量化约束与【待定】）、三大任务流程图（含回 work）、R8/R9 分层时序图、需求阅读笔记（含行号引用）。
交互/任务/播报打断/安全/工程五组结构；雷达打断 > 语音打断的仲裁逻辑与"危险期间抑制回 work"边界。
分组 → 量化约束 → 待定项三步法；流程图显式画安全状态；grep 行号定位文档条款。
梳理表 40 分、流程图 30 分、打断分层分析 20 分、笔记规范与行号引用 10 分，合计 100。