05-从MuJoCo到真鸭子：PPO策略训练与ONNX端侧部署
引子：这只会走路的鸭子，不是"编"出来的
大家好，我是黒漂技术佬。
前面四篇文章，我们把 microduck 的架构、控制环、进程通信、OTA 都拆了一遍。现在还剩一个最神奇、也最值得玩味的问题：
一只鸭子怎么会走路？
如果放在 20 年前，答案很可能是：程序员写了一段又一段的步态逻辑——先抬左脚 30 度，再迈出 5 厘米，重心前移……每个动作都是人肉调出来的。双足机器人的步态调试，是机器人工程师职业生涯里最痛苦的部分之一，因为一个参数不对，机器人就摔，摔一次调一次，调一次摔一次。
microduck 给出了一个完全不同的答案：
它不是在代码里"写"出走路，而是在仿真里"练"出走路。
这个"练"的过程，用到的是一套名为 sim2real（仿真到现实） 的技术路线：在 MuJoCo 物理仿真器里用 PPO 强化学习算法训练神经网络策略，训练好的策略导出成 ONNX 格式，部署到真鸭子上的 robotd 里，以 50Hz 实时运行。
今天这篇，我们就来拆这条"从仿真到真机"的完整流水线。这不仅是 microduck 的技术，也是当下四足机器人、双足机器人、机械臂灵巧手共同依赖的核心方法论。
一、先建立直觉：强化学习怎么"学会走路"
在进入 microduck 之前，先用一个最朴素的方式理解强化学习（RL）。
想象你教一只真的小鸭子学走路，你会怎么做？
你不会给它一本《鸭子走路姿势图解》让它照着摆 pose。你会：
- 让它自己尝试各种动作（迈腿、摆重心、扇翅膀）——这叫探索；
- 走得好（没摔、前进得多）就给奖励（好吃的），摔了就不给奖励（甚至惩罚）——这叫奖励信号；
- 反复试，让"走得好的动作组合"出现的概率越来越高——这叫策略优化。
强化学习在计算机里复刻的就是这个过程，只是把"小鸭子"换成了神经网络，把"好吃的"换成了数值奖励：
┌────────────────────────────────────────────────────┐
│ 强化学习训练循环 │
│ │
│ ┌───────┐ 观察(observation) ┌─────────────┐ │
│ │ 环境 │ ◄──────────────────── │ │ │
│ │ MuJoCo│ │ 策略网络 │ │
│ │ 仿真器 │ ────────────────────► │ (PPO训练) │ │
│ └───────┘ 动作(action) └─────────────┘ │
│ │ │
│ └──► 奖励(reward) ──► 更新网络参数 │
└────────────────────────────────────────────────────┘
状态（observation）：机器人当前"看到/感觉到"的一切——15 个舵机的角度、IMU 的姿态角、上一时刻的动作等； 动作（action）：决策输出——每个舵机的目标角度（或目标力矩）； 奖励（reward）：一个标量函数，告诉策略"刚才这一步走得好不好"——比如前进距离 + 1、摔倒 -10、保持直立 + 0.1。
PPO（Proximal Policy Optimization） 则是优化算法——它负责根据奖励信号调整神经网络参数，让策略越来越"会走路"。PPO 是 OpenAI 2017 年提出的算法，因为实现简单、训练稳定，成了机器人 RL 的事实标准。microduck_rl 项目用的正是 PPO。
二、仿真环境：MuJoCo 里的"虚拟鸭子"
2.1 为什么必须在仿真里训练？
训练一只真鸭子走路，成本高得离谱：真机跑一个 episode（从站立到摔倒）要几秒钟，而训练要跑上百万个 episode——换算成真机时间，够鸭子摔到零件报废几百次，够工程师累到怀疑人生。
仿真器把这一切加速了：
- 快：仿真比实时快几百倍，一台 GPU 一天能"虚拟地摔"几十万次；
- 安全：摔一百万次也就是内存里的一堆数字；
- 可重复：同样的初始条件，跑一百次结果一样，方便调参；
- 可并行：同时开几百个并行的虚拟鸭子一起练。
2.2 MuJoCo 是什么？
MuJoCo（Multi-Joint dynamics with Contact） 是 DeepMind 开源的物理仿真引擎，专门为机器人/物理系统的接触动力学设计。它为什么适合机器人 RL？
- 接触仿真精度高：走路本质是"脚与地面的接触"，MuJoCo 的接触模型在速度和精度之间取得了很好的平衡；
- 速度快：纯 C 实现，支持 GPU 批量仿真（这是大规模 RL 训练的关键）；
- 行业标准：DeepMind 的强化学习生态（dm_control）基于它，2022 年开源后更是成为机器人 RL 的首选仿真器。
microduck_rl 项目的技术栈就是：MuJoCo（仿真）+ PPO（训练）+ ONNX（导出）。
2.3 仿真里的鸭子模型
仿真里的"虚拟鸭子"必须和真鸭子长得一样（动力学意义上）：同样的质量分布、同样的关节位置、同样的舵机扭矩限制、同样的 IMU 传感器位置。
这个建模过程叫 URDF（Unified Robot Description Format，统一机器人描述格式）——用 XML 描述机器人的连杆（link）、关节（joint）、质量、惯量等。microduck 团队要做的第一件事，就是把真鸭子的几何和动力学参数精确地搬进 MuJoCo。仿真和真机的差距越小，后面 sim2real 的鸿沟越小。
三、sim2real 的核心：域随机化（Domain Randomization）
这是整篇最核心、最值得展开的概念。
仿真再精确，也不可能 100% 还原真机——摩擦系数、电机延迟、舵机响应误差、电池电压变化、地面硬度……仿真里的一丁点误差，放大到真实世界里可能就是"一走路就摔"。
怎么解决？microduck 用的方法是 域随机化（Domain Randomization）：
在训练时故意给仿真"加噪音"——随机化各种物理参数，让策略在"各种乱七八糟的世界"里都练过，这样到了真实世界，无论环境怎么变化，策略都能应付。
具体随机化什么？举几个例子：
| 参数 | 随机化方式 |
|---|---|
| 摩擦系数 | 地面摩擦在某个范围内随机 |
| 舵机延迟 | 电机响应延迟随机 |
| 舵机误差 | 舵机实际角度与目标角度的偏差随机 |
| 质量分布 | 连杆质量轻微扰动 |
| 初始姿态 | 鸭子每次起步的姿势略有不同 |
| 传感器噪声 | IMU 读数加高斯噪声 |
直觉理解：域随机化像"压力训练"——让模型在 1000 种不同的"虚拟世界"里都练过走路，那么它在真实世界这个"第 1001 个世界"里，大概率也能走。
这套方法论的提出者之一（OpenAI 用它在仿真里训练机械手解魔方，直接 zero-shot 迁移到真机）早已证明了它的威力。microduck 站在了这套成熟方法论的肩膀上。
除了域随机化，sim2real 还有别的招：系统辨识（把真机参数精确测出来填进仿真）、课程学习（从简单任务逐步过渡到难任务）。但域随机化是"用最小的工程成本获得最大鲁棒性"的一招，是当前的主流。
四、奖励设计：怎么告诉 AI"你走得好"
奖励函数是 RL 训练的"指挥棒"。设计得好，训练顺利；设计得差，策略会钻空子（reward hacking）。
microduck 这类行走任务的奖励函数一般长这样：
reward = 前进速度奖励 + 保持直立的奖励 + 动作平滑惩罚 - 摔倒惩罚
具体拆解：
+ 前进奖励： 机器人前进速度越快，奖励越高（这是核心目标）
+ 直立奖励： 身体姿态接近竖直，奖励越高
+ 平滑惩罚： 动作变化太剧烈（抖动）会扣分
- 摔倒惩罚： 摔倒（身体触地）给大额负奖励
有几个经典的设计陷阱，microduck 这类项目一定会遇到：
- 奖励稀疏问题：如果只有"走完 10 米 +100 分"，前期随机探索时几乎永远拿不到分，训练无法起步。所以要给密集的中间奖励（每一步前进都给一点分）；
- 动作平滑：如果不加平滑惩罚，策略会学到"疯狂抖动舵机"来骗过仿真器的物理——真机上根本做不到这种抖动的频率，sim2real 必失败；
- 摔倒了要让它能爬起来：只惩罚摔倒不奖励"站起来"，策略学到的是"躺平最安全"。
奖励工程是 RL 落地里最吃经验的环节——它决定了策略的"性格"。
五、从训练到部署：ONNX 导出与端侧推理
训练在 GPU 服务器上进行（Python 生态，PyTorch + MuJoCo），但部署目标是一块 RK3566 开发板（Rust 生态，50Hz 控制环）。训练环境和部署环境差了十万八千里，怎么把模型搬过去？
答案是 ONNX（Open Neural Network Exchange）——一个开放的神经网络交换格式，可以把 PyTorch 训练好的模型导出成"语言无关、框架无关"的中间格式，再由目标平台的推理引擎加载运行。
┌─────────────── GPU服务器 ──────────────┐ ┌───────── 真鸭子 RK3566 ─────────┐
│ │ │ │
│ PyTorch 训练 PPO 策略 │ ONNX │ Rust 控制环（50Hz） │
│ (MuJoCo 仿真，训练出网络权重) │─────►│ robotd 加载 ONNX 模型 │
│ │ 导出 │ 每 20ms 推理一次 │
│ policy.pth ──► 转换 ──► policy.onnx │ │ 输出 15 个舵机的目标角度 │
└───────────────────────────────────────┘ └────────────────────────────────┘
部署侧的关键约束：
- 模型要小：MLP（多层感知机）网络的参数量在几万到几十万级别，ONNX 文件通常几百 KB——这是它能塞进嵌入式系统的前提。RNN/LSTM 也能用，但推理更复杂，MLP 是首选；
- 推理要快：50Hz 控制环里，单次推理必须在几毫秒内完成。RK3566 的 CPU（四核 A55）跑一个小型 MLP 完全够用——实测这类模型 CPU 推理 1~3ms 级别；
- 部署格式：RK3566 有 NPU（0.8 TOPS），但当前方案主要走 CPU 推理（NPU 优先留给视觉模型如鸭子检测器）；CPU 上 ONNX Runtime 或直接用 Rust 的 ONNX 推理库加载。
顺带一提：microduck 项目还计划把"鸭子检测器"（识别画面里有没有鸭子，用于自主行为）部署到 RK3566 的 NPU 上——NPU 留给视觉，CPU 留给控制，这是嵌入式 AI 资源分配的经典方案。
六、把整条流水线串起来
microduck 的完整 RL 落地流程，就是当下机器人强化学习的标准范式：
① URDF 建模 ──► ② MuJoCo 仿真 ──► ③ 域随机化 ──► ④ PPO 训练 ──► ⑤ ONNX 导出 ──► ⑥ 端侧部署 ──► ⑦ 真机测试
(虚拟鸭子) (物理引擎) (加噪音) (学会走路) (格式转换) (50Hz推理) (验证/回滚)
这条流水线有四个关键的成功因素：
- 仿真精度：URDF 动力学参数越准，sim2real 越顺；
- 域随机化：仿真与现实的"鸿沟"，靠训练时的"广度"来填——让策略见过足够多不同的世界；
- 奖励设计：决定策略学到的行为是不是"真机友好"的（平滑、不钻空子）；
- 部署链路：ONNX 导出的兼容性、端侧推理性能、与控制环的集成——模型再好，部署不进去等于零。
最后一步"真机测试"还要接上第 04 篇的 OTA——新策略作为固件的一部分，通过 updaterd 的分发和健康门控上线。训练→部署→验证→回滚，整条链路闭环。
七、我们能学到什么？
结合你的项目场景，这篇的收获可以落成四点：
- RL 不是"玄学"，是一条工程流水线。 仿真建模、域随机化、奖励工程、ONNX 部署，每一环都是标准工程活。别被"强化学习"四个字吓住——它的难点不在理论，而在工程闭环。
- sim2real 的核心是"让策略见过足够多的世界"。 域随机化的本质是数据增强的物理版——训练时的多样性，换来部署时的鲁棒性。这个思想对做视觉的同学同样适用：训练集里加入各种扰动，模型在真实场景才扛得住。
- 训练和部署要"对胃口"。 模型结构、推理延迟、控制频率是绑定的。设计模型时要先问：目标平台能在 20ms 里跑完吗？不能，就换更小的模型。
- 奖励工程 = 定义产品的"性格"。 平滑惩罚、防钻空子、稀疏奖励变密集——这些细节直接决定策略在真机上好不好用。
小结
从 MuJoCo 里的虚拟鸭子，到桌面上真会走路的小鸭子，中间隔着一条"仿真与现实的鸿沟"。microduck 用域随机化填平了它，用 ONNX 架起了桥，用 50Hz 控制环接上了地。
"会走路"不再是人类一行行写出来的代码，而是算法在一个虚拟世界里自己练出来的技能——再把这份技能，原封不动地搬运到现实世界。
这就是 sim2real 的浪漫：让机器人在想象中练习一万次，只为在现实里稳稳走出第一步。
到这里，microduck 的技术分析系列（系列一）就告一段落了：架构、控制、IPC、OTA、RL 部署，五篇文章覆盖了这只鸭子的全部技术精髓。
但分析完了，很多读者可能已经在摩拳擦掌："我也想做一只自己的 microduck！"
下一篇开始，我们进入系列二——如何做自己的 microduck：从硬件选型、舵机总线、软件骨架，到一步步把一只会走路的鸭子造出来。
我是黒漂技术佬，咱们下篇见。
