解读 71 · 阶段 G:装配、部署与测试金字塔
解读对象:
docs/HL-2915路线全流程教程.md(380 行)§8,对照microduck-replica/docs/换舵机重训全流程.md§6(完整七层金字塔)
需要的前置:解读 09(robotd 主循环)、解读 18/解读 19(OTA 机制)
阶段 G 是前六个阶段验收的叠加:15 只舵机(阶段 A 已分好 ID、贴好标签)+ 阶段 D 的电控 + 3S 电池 + 阶段 F 的策略。教程 §8 只有一页,但每一句都是一次"曾经摔过的跟头"。
1. 装配与第一次上电
装配顺序里有个容易被略过的动作:每只舵机装完先手掰全行程听有没有碰壳——ID 和标定在台架阶段就做完了,此刻唯一还能免费发现的故障是机械干涉。第一次上电的姿势也有规定:只接总线不装腿(或吊装),然后 robotctl health → robotctl monitor,确认 16 个读块全回(教程口径:15 舵机+各自遥测;注意官方路线里第 16 个读块来自挂在总线上的 imu_to_dxl,HL 路线 IMU 已走 I²C,总线上只剩 15 只——这一口径差验收时要心里有数)。robotctl health 真能当闸门用:robotctl 源码注明它在不健康或不可达时以非零码退出,"so it can gate a script"。
2. 部署:三条命令
scp alpha_walking.onnx microduck@<IP>:/home/microduck/
sudo robotctl policy load walk /home/microduck/alpha_walking.onnx
robotctl policy list
policy load 是官方 CLI 的真实子命令(docs/进阶学习文档-训练仿真与部署.md §3 同款)。robotctl 源码里还有一条值得知道的语义:"a load that fails anyway leaves the policy that was running"——加载失败不会留下一个空转的机器人。维度不对的策略在这之前就会被拦:manifest 的 incompatibility() 只强制 obs/action/型号(见解读 69),教程 §10 速查表"policy load 被拒"一行给出的动作就是先跑 inspect_onnx.py 验 61/14,再对 manifest schema。
3. 测试金字塔:一层过了才准上一层
教程 §8 列的是整机三层(换舵机重训全流程.md §6 是完整七层:L1 单舵机台架/L2 旧策略仿真评估/L3 重训后仿真评估/L4 总线联调——15+1 台设备一次 sync_read 全回——是它的前置):
| 层 | 环境 | 通过标准 |
|---|---|---|
| L5 吊装 | 悬空跑策略 | 14 关节按策略运动、无超温、电流正常 |
| L6 软垫 | 低重心、软垫、手扶 | 站立稳定、可从坐姿站起 |
| L7 平地 | 开阔平地、低重心 | 直线走 ≥2m、可停止可急停、连续 3 次成功 |
两条铁律:第一次上电必须手扶;每层的视频、电流/温度曲线、失败回放全部进 构建日志.md——教程原话,"这是整个复刻项目最值钱的资产"。
4. OTA 机制在新路线上的复用
部署不是一次性的:9 个技能逐个训出来,每个新策略都要走到板上。这套流程官方已经建好——updater crate 的 manifest/verify/preflight(解读 18 的对象)与 reconcile/orphan/faults(解读 19 的对象)是仓库里真实存在的模块,deploy/updater.toml 是它的配置入口。换舵机重训全流程.md §4.3 一句话把两件事接上:"9 个文件命名对齐运行时清单,放进更新包结构即可被 updaterd 分发"。换句话说:换舵机改的是 duck-control 总线层与 ONNX 的参数,分发、验签、回滚机制原样复用——这正是接缝设计的红利。
你带走的收获
- 整机阶段的验收是叠加式的:每层通过标准都能追溯到某个前期阶段的验收项;跳过任何一层,出问题时你就少了定位的坐标系。
- "加载失败保留原策略"与"健康检查可当脚本闸门"是部署安全的两颗定心丸,写自动化脚本时要主动利用。
- 测试金字塔的本质是风险成本排序:吊装、软垫、平地,物理世界的 undo 一次比一次贵。
- OTA 管线(验签、门控、回滚)与策略内容解耦,换硬件平台时它是最应该原样保留的部分。