9 个递进实验、48 学时，从 R1–R12 需求分析与分层架构起步，吃透 fall_config.yaml 十四段配置，串联 XFM 六麦唤醒、sherpa-onnx zipformer 听写、YOLOv8/BlazePose 视觉感知、六状态机跌倒判定、串口告警与证据链，最终以 RKLLM Qwen3.5 对话、VLM 复核与 --mode camera/image/video 全功能验证收口 —— 每个实验均配原理讲解、动画演示与互动沙盒，并贯穿"先问后救"的人文关怀与视频隐私意识。
老人居家跌倒监护不是单点算法竞赛，而是软硬件协同的系统工程 —— 下面四个环节在 9 个实验中逐层落地。
深度摄像头（ROS2 订阅 /ascamera_hp60c 彩色图）+ XFM 六麦阵列（/dev/ttyACM0 硬件唤醒、ALSA 录音），图像帧与音频流构成系统的两条原始输入流水线。
YOLOv8 RKNN 检测 person、BlazePose/RTMPose 提取关节点，用躯干角 >50°、宽高比 <0.5 两条几何判据驱动 IDLE→FALLING→LYING→ASK→ALERT/CANCELLED 六状态机，cooldown 60s 防轰炸。
跌倒确认后先 TTS 温和询问、开启 12s 聆听窗口：老人答"救命/帮帮"立即告警，答"没事"取消，沉默超时才升级；RKLLM Qwen3.5 负责自由对话与语义兜底。
告警帧以 0xAA55 帧头 + CRC8 校验经串口发给下位机（LED/蜂鸣器/OLED），同步落盘"三件套"jpg / _post.jpg / avi 与 events.jsonl，让每一次告警都有据可查。
动手前先想清楚：把居家跌倒场景拆成可验收的需求，画出分层架构，再把全部阈值收进一份 YAML。
从老人居家跌倒监护的真实场景提炼 R1–R12 十二条需求，按输入 / 检测 / 判定 / 交互 / 告警 / 证据 / 调试七维分组，画出跌倒检测、语音询问、告警存档三条核心时序，明确"先问后救"设计与六大时序防护。
六层依赖把"摄像头/六麦进、告警出"的整条链路拆开：看懂 fall/monitor.py 三大接口（process_frame / has_ask_session / on_kws）与 voice_loop.py 语音状态机如何靠双流水线协同，理解文本通道只是同一个状态机的另一个入口。
十四段配置是整个系统的"总闸"：paths / model / detect / source / session / speech / state / interaction / alert / evidence / monitor / arm_reaction / server·display·save·log / llm。掌握 config_schema 必填与可缺省双轨、CLI > yaml > 代码默认的覆盖优先级，用 env_check 一键体检七库与模型文件。
让系统真正"看得见、听得见、判得准"：语音唤醒与听写、人体检测与姿态几何、跌倒判定状态机三线并进。
XFM 六麦硬件唤醒（/dev/ttyACM0，AIUI 0xA5 协议）→ ALSA 录音线程 → sherpa-onnx 中文 KWS（拼音@词表，阈值 0.25）→ zipformer ASR 端点断句 → Matcha-TTS + Vocos 合成；再用 feed_text 文本通道与 --text 模式在无麦克风环境下验证同一个 voice_loop 状态机。
YOLOv8 转 RKNN 在 NPU 上做 letterbox + 类别内 NMS（iou 0.45，imgsz 640）检测 person，crop_margin 1.5 裁剪后由 BlazePose 33 点（或 RTMPose 17 点，vis_threshold 0.3）提关键点，计算躯干角 θ=arctan2 与宽高比 h/w 两条跌倒几何判据 —— 这是后面状态机的全部输入。
每人一台六状态机：IDLE→FALLING（falling_window 1.5s）→LYING（lying_time 3.0s）→ASK（ask_timeout 12.0s 超时升级、confirm/cancel words 分流）→ALERT（恢复判据 aspect>1.8 或 angle<25° 持续 2s 回 IDLE）/ CANCELLED；cooldown 60s 只挡重复询问不挡新跌倒，IoU 贪心关联支撑多人跟踪。
把告警发出去、把证据留下来、把大模型接进来，最后用 image / video / camera 三种模式验证整条链路。
串口告警帧 [AA][55][Func][Len][Data][CRC8]（CRC-8/MAXIM，poly 0x8C，对 Func→Data 求校验）驱动下位机 LED / 蜂鸣器 / OLED（Func 0x01 / 0x02 / 0x0A）；证据链用 FrameRing 保留 pre 3.0s + post 2.0s 帧，落盘三件套与 events.jsonl，双节流 buzzer 5s / TTS 10s 防止告警轰炸。
RKLLM 加载 Qwen3.5-0.8B w4a16 量化模型（约 1.5G），ctypes 绑定 librkllmrt.so 起 Flask 服务（/v1/models、/v1/chat/completions，端口 8080）；LLMChat 按 max_history=6 拼接上下文。VLM 默认关闭（model.vlm.enabled=false），开启后对跌倒截图三分类 fall / not_fall / uncertain 辅助复核，优先级 ALERT > ASK > SPEAKING > LLM。
fall_app.py 以 --mode camera / image / video 三模式跑通全流程：先 env_check 体检，再按 text → audio → camera 三级递进验证；camera 模式需先 ros2 launch 拉起深度相机、等 loop.wake_seen 事件；关注内存水位（ASR+TTS+LLM+YOLO/pose 约 2.7G，再开 VLM 破 3.8G 易 OOM）与证据完整性核验。
全课程围绕工控主机 + 深度摄像头 + 六麦阵列展开，实验数据全部来自 elderly_companion 实验讲义实测。
EXP-01 的 R1–R12 与三条核心时序是全项目的"合同"：后面每一段代码、每一个阈值都能回溯到某条需求 —— 卡住时先回头对需求。
EXP-03 吃透十四段 YAML 与覆盖优先级，调参时永远先问"改 yaml 还是加 CLI 参数"，env_check 不过不动手。
先用 detect_demo / pose_demo 单图看懂几何判据，再进 fall_video_demo 看状态迁移 —— 混在一起调，出了误报永远不知道该改哪层。
LLM/VLM 最吃内存也最不稳定：先用 --text 与 --mode video 把链路跑绿，再逐级开 audio、camera，随时盯 2.7G→3.8G 的内存水位。
每个实验的核心交付物，按篇章顺序累积成期末验收拼图 —— 报告缺项可回到对应实验的「08 实操步骤 · 记录要点」补齐。
| 实验 | 学时 / 类型 | 核心交付物 |
|---|---|---|
| EXP-01 需求分析 | 4 学时 · 验证性 | R1–R12 覆盖核对表 + 三条核心时序图 |
| EXP-02 分层架构 | 4 学时 · 设计性 | 六层依赖图 + monitor 三接口调用关系笔记 |
| EXP-03 配置详解 | 4 学时 · 设计性 | env_check 全绿截图 + CLI 覆盖优先级实验记录 |
| EXP-04 语音交互 | 6 学时 · 综合性 | kws/asr/tts 三测试日志 + 唤醒词三处同步改词记录 |
| EXP-05 检测与姿态 | 8 学时 · 综合性 | detect/pose_demo 实测（延迟、score_thr 对比）+ 几何判据推演 |
| EXP-06 跌倒状态机 | 4 学时 · 综合性 | 状态迁移 EVENT 日志 + T8 用例 Pass/Fail 表 |
| EXP-07 告警证据链 | 4 学时 · 综合性 | CRC 手工对拍 + 证据四件套验证 + T9 用例表 + 清理清单 |
| EXP-08 LLM·VLM | 8 学时 · 综合性 | llm_chat_test 会话记录（含耗时）+ vlm_demo 三分类输出 |
| EXP-09 全功能验证 | 6 学时 · 综合性 | 五步手册验收表 + 证据三件套完整性确认 + 四层清理复核 |
全课程共用一套实验室基线：离线模式只需板端，实时模式补齐深度相机与六麦即可。
具身智能机器人小车 C1（RK3576 + STM32F407）；HP60C RGB-D 深度相机（ROS2 话题 /ascamera_hp60c/camera_publisher/rgb0/image）；XFM 六麦阵列（/dev/ttyACM0）；扬声器 plughw:3,0、录音 plughw:4,0；告警串口 /dev/ttyUSB0（1Mbps）。
Ubuntu 22.04 + ROS 2 Humble；板端 venv /home/iflytek/ros2_venv/bin/python3（Python 3.10），预装 rknnlite 2.3.2、sherpa-onnx 1.13.4、opencv-python 4.11.0、flask、pyserial 3.5、mjpeg_streamer；板端禁自动 pip install。
yolov8n.rknn 检测 · pose_landmark_full.rknn 姿态 · zipformer KWS（encoder/decoder/joiner）· zipformer ASR 三件套 · Matcha-TTS+Vocos 八件套 · RKLLM Qwen3.5（w4a16 ≈1.5G）· VLM 视觉模型（默认不启用）。
runs/evidence/ 存证据三件套（max_files=100 轮转）、runs/tts_cache/ 预合成缓存（二次启动零延迟）、runs/*.log 日志；三者与 testdata/ 测试视频全部 gitignore 不入库，证据增长快需定期 rm 释放磁盘。
四个出现频率最高的"拦路虎"，先查这里再翻日志。
九成是用错了解释器 —— 系统 python3 没有 rknnlite/sherpa_onnx。改用 /home/iflytek/ros2_venv/bin/python3 或先激活板端 venv，再跑自检。
查两处独占：log_server 抢了 /dev/ttyACM0（pkill -f log_server）、aplay 残留占着 plughw:3,0（pkill -9 aplay）。设备句柄排他，占着就是静默失败。
MJPEG 8088 与 LLM 8080/自定义端口撞车时启动即报错退出 —— 用 ss -tlnp 找残留进程，改 server.port 或 llm.server.port 分开配置。
只缺一步：终端 1 先 ros2 launch car1_peripherals depth_camera.launch.py，再用 ros2 topic hz /ascamera_hp60c/camera_publisher/rgb0/image 确认话题有数。
9 个实验按依赖关系分为三个篇章，建议按序推进，篇章内实验共享前序产出。
先立需求 R1-R12，再画六层架构，最后落地 fall_config.yaml 十四段 —— 不接硬件的 12 学时"纸上谈兵"，却是后续所有子系统的图纸。
语音环（XFM 六麦 + zipformer）、视觉环（YOLOv8 + BlazePose/RTMPose）、判定核心（躯干角/宽高比 + 六状态机）三条线并进，合计 18 学时重头戏。
串口告警帧 + 证据链、RKLLM 对话与 VLM 复核，最后用 --mode 三入口做 6 学时集成验收 —— 把前两章拼成一台能交付的机器。