需求分析：从居家场景到 R1–R12
写代码之前先把"合同"签好。本实验从老人居家跌倒监护的真实场景出发，把系统职责拆成 R1–R12 十二条可验收需求，按输入 / 检测 / 判定 / 交互 / 告警 / 证据 / 调试七个维度分组，画出跌倒检测、语音询问、告警存档三条核心时序，并明确"先问后救"设计背后的六大时序防护 —— 后面八个实验的每一段代码都能回溯到这里。
01问题引入：居家跌倒为什么必须"先问后救"
我国独居与空巢老人数量庞大，跌倒是老年人伤害致死的首因之一。跌倒后能否在黄金时间被发现，决定了预后好坏 —— 但如果系统"一惊一乍"，误报几次之后就会被家属直接拔电。一个真实的监护系统要同时满足：
02原理通俗讲解：R1–R12 像一份"养老服务合同"
把需求想象成家政服务合同的条款：每一条都能验收 —— 做到了就是做到了，没做到就是没做到，不能含糊。十二条规定七个维度：
| 维度 | 需求编号 | 通俗理解（合同条款） |
|---|---|---|
| 输入 | R1 | "眼睛"：持续接收摄像头视频流 |
| 检测 | R2、R3 | "认出人"：框出画面里的老人并持续跟踪，多人不跟丢 |
| 判定 | R4 | "下判断"：躯干角 > 50°、宽高比 < 0.5 等几何特征判定跌倒姿态 |
| 交互 | R5、R6、R9、R10 | "搭句话"：跌倒后先语音询问（R5）；未跌倒但听到呼救直接告警（R6）；播报与聆听的窗口管理（R9、R10） |
| 告警 | R7、R8 | "叫人来"：向串口/下位机发告警，触发灯光、蜂鸣等现场提醒 |
| 证据 | R11 | "留凭据"：告警前后视频、图片与事件日志落盘，事后可查 |
| 调试 | R12 | "可彩排"：--text 文本通道驱动同一台状态机，无摄像头/无麦克风也能回归测试 |
03关联知识点：需求条目 ⇄ 系统模块映射
本课程的分层架构（EXP-02）不是凭空画的，每一层都"认领"了若干需求：
视频流接入、YOLOv8 人体检测、BlazePose/RTMPose 姿态估计、躯干角与宽高比几何计算 —— 判定的全部原料在这里产出。
六状态机 IDLE→FALLING→LYING→ASK→ALERT/CANCELLED 把几何特征翻译成"要不要问、要不要报"的时序决策。
TTS 播报"您还好吗"、ASR 聆听确认词（救命/帮/疼/起不来）与取消词（没事/不用），12s 超时升级。
0xAA55 + CRC8 串口告警帧驱动 LED/蜂鸣器/OLED，证据链落盘三件套与 events.jsonl。
--text 文本输入直接喂进 voice_loop —— "小飞小飞"相当于唤醒、"救命"相当于呼救、"没事"相当于取消，与音频通道同一台状态机。
不做 ROS 业务节点、不做多人会话仲裁 —— 需求文档同样规定"什么不做什么"，防止范围蔓延。
04实验目标
- 能复述并按七个维度默写 R1–R12 十二条需求，说清每条的验收标准
- 能准确区分 R5（跌倒后询问） 与 R6（呼救直告警） 两条独立路径
- 能画出跌倒检测、语音询问、告警存档三条核心时序的关键节点（含 1.5s / 3.0s / 12s 时间参数）
- 能说出六大时序防护各自的"防的是什么"（播报竞态、迟到回复、重复询问……）
- 完成 docs/01 需求文档的覆盖核对：每条 R 编号都能指到对应模块与代码位置
05实验环境与准备
~/ros2_ws/src/xflz_eai_car1/app/elderly_companion，确认 docs/01 需求文档存在06动画讲解：需求全景与三条核心时序
上半幅是 R1–R12 的七维全景（高亮块循环点亮各维度），下半幅是"跌倒检测 → 语音询问 → 告警存档"三段时序的推进动画：
07互动讲解：R5 与 R6 分流自查台
选一个场景，看系统按哪条需求、走哪条路径决策：
08实操步骤：精读 docs/01 并做覆盖核对
# ① 进入工程目录 cd ~/ros2_ws/src/xflz_eai_car1/app/elderly_companion # ② 确认需求文档与配置存在（后续实验反复用到） ls docs/ config/fall_config.yaml # ③ state 段关键默认值 —— 三条核心时序的时间参数来源（config L57-L62 附近） # angle_thresh: 50.0 躯干角阈值（度） → 判定需求 R4 # aspect_thresh: 0.5 宽高比阈值 → 判定需求 R4 # falling_window: 1.5 跌倒窗口（秒） → 检测确认时序 # lying_time: 3.0 躺姿持续（秒） → 确认后才询问 # ask_timeout: 12.0 询问超时（秒） → 超时升级告警 R5 # cooldown: 60.0 告警冷却（秒） → 防重复轰炸
09重点与易错点
- R5 与 R6 是两条独立路径：R5 需要"跌倒确认"前置，R6 只要呼救关键词即告警
- 三条时序必须包含1.5s / 3.0s / 12s 三个时间参数，缺了就不是本系统的时序
- 六时序防护逐条能说出"防什么"：播报竞态、ASR 无 partial 兜底、2s 快答强制提交、打断 epoch 丢弃迟到回复、单次应答去重、8s 静默重播归位
- 需求有"边界"：不做 ROS 业务节点、不做多人会话仲裁同样是需求的一部分
| ⚠️ 常见坑 | 现象 → 解法 |
|---|---|
| R5 / R6 混淆 | 把"呼救直告警"也画进询问确认链 → R6 不经 ASK 确认流，单独成支 |
| 时序漏时间参数 | 流程图画了"确认后询问"但没写 1.5s / 3.0s → 验收无法判定"确认"是否达标 |
| 把实现细节当需求 | 需求里出现"用某个模型" → 需求写"检测画面中的人"，模型选型属于设计（EXP-02/05） |
| 忽略非目标 | 自由发挥出多人仲裁功能 → 先查"明确不做"清单，防止范围蔓延 |
| 需求无验收标准 | "系统要稳定"没法测 → 每条 R 必须能指出可观察的验收动作 |
10总结与思考
十二条规定、七维分组、三条核心时序手绘图与非目标边界清单。
理解为什么"确认升级"是伦理需求而非算法妥协，以及六道时序防线各防什么。
"左列需求、右列代码"的双向核对法，后续每个实验都复用。
现场发现怪行为，先问"违反了哪条 R"，再决定改需求还是改实现。