解读 202 · 案例精读(下):结果怎么读,哪些不能照搬
解读对象:同解读 201 的审计报告 §12–§14(验证结果、已知限制、后续闭环)
需要的前置:解读 201;解读 06(训练曲线怎么读)
1. 训练产物:数字很好看,但要看全
8 小时训练(4096 环境,用户在约 16250 迭代处手动停止,目标 50000):最终平均 reward 87.4,峰值 93.0 @ 13817,episode length 983.28/1000(几乎跑满 20 秒),全程 0 NaN;fall 指标从 0.25 降到 0.167。ONNX 导出通过,输入 [1,61] 输出 [1,14]。
一个容易被忽略的好细节:最新 checkpoint 16250 不是 reward 峰值(峰值在 13817)。报告提醒"选 checkpoint 不应只取最新"——这与我们解读 06 的结论一致。
2. 但结果必须收紧:把"能走"说准
回放评测的原始数字比"基础站立/前行已稳定"的表述更保守:
| 场景 | 报告数字 | 换算成人话 |
|---|---|---|
| 定向前行(5 s,目标 0.2 m/s) | 前向误差 ≈0.045 m/s | 误差是目标的 22.5% |
| 同上,横向速度 | ≈0.168 m/s | 相当于前进目标的 84%,直行漂移明显 |
| 定向站立(5 s) | 偏航角速度 ≈0.165 rad/s | 每秒仍在转 9.5° |
| 压力回放(64 env × 10 s 推搡) | 4 次跌倒 | 鲁棒性"尚可"而非"可靠" |
所以准确结论是:短时仿真中的支撑与移动能力已形成;稳定站立、准确直行、可靠转向都还没证明。而且这一切都在同一近似仿真模型内——episode length 跑满不能等同于全向跟踪准确。给项目写结论时,这个收紧的句式值得直接抄。
3. 五件不能照搬的事
- 电机参数全是估计值。 kt/R 由堵转规格相除得到,armature/摩擦是拍估的;
200 × 0.16 = 32的 P 映射假设两家固件控制律相同——通信协议相近不等于内部控制律相同。BAM 官方要求先明确固件控制律/限幅/平滑,再采集轨迹拟合(bam.readthedocs.io:actuator_modeling)。 - 质量 +3 g、惯量同比缩放只是初版近似。 新舵机的质心、外壳尺寸、安装偏移、碰撞变化都没建模;扩大随机化覆盖不了错误的结构模型。
- 动作峰值要优先调查。 回放记录 raw action p95 ≈ 6.759、最大 ≈ 13.37,而策略侧
clip_actions=None。即使下游有限幅,上真机前必须追一遍"动作 → 目标 → 限幅 → 变化率 → 饱和比例"整条链,不能部署端临时裁剪了事。 - Kp/Kd 随机化根本没有生效。 HD 配置里写了 Kp 0.75–1.25 / Kd 0.8–1.2 的范围,但基础任务的
ENABLE_KP/KD_RANDOMIZATION=False意味着 event 压根没被创建——写了 ≠ 启用了。这是全报告最通用的教训:任何随机化都要有一道"确认它真的在跑"的检查。 - IMU 固件是它的硬阻塞,但不一定是我们的。 报告路线是"舵机和 IMU 都走 Feetech v1",所以 ID 200 转接板需要新的 v1 固件,没有它真机链路不成立。
4. 与我们项目的三条真实差异
对照本仓库代码,同一问题我们有不同的已落地答案,报告的解法不能直接搬:
| 差异点 | 报告(另一台机器) | 我们(已核实) |
|---|---|---|
| 舵机型号 | HD-1910,bus_feetech.rs + P scale 0.16 |
HL-2915 专用实现:duck-control/src/hl2915.rs(620 行),双协议——v1 读舵机、v2 读 IMU(hl2915.rs:302–344、:432);tools/microduck_learning/hl2915_bam_adapter.py 的 AdapterConfig 默认 12 V |
| IMU 接入 | 需要新写 Feetech v1 IMU 固件(硬阻塞) | 现有 v2 IMU 板继续用 v2 读,舵机走 v1——没有报告所说的固件阻塞,但仍需真机总线时序验证 |
| STS 状态初始化 | 把 q_target_smooth 重置为零 |
bam/bam/feetech/actuator.py:126 已支持按关节当前位置初始化——初始姿态非零的关节,两种做法的启动瞬态不同,按依赖版本选择 |
另外一个确认:Studio 训练入口(microduck-studio/microduck_studio/training_pipeline.py)仍限定在已核验的 XL330 接口,其他执行器需要专用任务适配——报告可以帮助设计这个适配,但不能直接解除限制。
5. 六步行动清单(报告 §14 与我们路线的合并)
- 确认实际舵机型号与规格(HL-1910 到货后实测,闭环解读 51 的"待验证");
- 单舵机台架采集与辨识,替换估计参数(我们已有
hl2915_bench.py课 6 阶跃录制); - 对齐机械模型、固件控制律映射和命令延迟——训练/部署两边用同一数值;
- 小规模训练 + 导出验证(先 smoke 后 GPU);
- 分项评测:站立、前进、横移、转向、推搡分别打分,不许用总 reward 一票通过;
- 支撑条件下真机验证:零命令、低 P、限流、悬空 → 支撑站立 → 0.05–0.1 m/s 低速 → 才谈脱离支撑。
你带走的收获
- 换舵机训练的验收标准不是"reward 高 / episode 长",而是分项误差:这篇教程给的句式——"目标 X,误差 Y,占 Z%"——请直接抄。
- 每个域随机化都要配一道"确认生效"的检查;配置写了但没挂载是最隐蔽的坑。
- 别人家的适配方案(固件、初始化、P 映射)要先对照自己仓库的已落地实现,再决定采纳还是保留——三个差异点我们全都不需要照搬。
- 下一步优先级:先提高仿真对真实舵机的描述精度(辨识),再增加训练量。 只堆 iteration 是在错误的模型上练习。