企业官网建设流程全解析

1. 项目整体认知与拆解

1.1 到底是什么样的"机器鸭"

先说结论：这不是一个摆拍的玩具，也不是概念渲染视频，而是一台真能跑、真能踢球、真能滑轮滑的桌面级双足机器人。整机高度大概25厘米，两只脚着地，走路的姿态确实带着点鸭子那种晃晃悠悠的劲儿，但核心控制逻辑用的不是传统的预编程步态，而是强化学习训练出来的运动策略。

这个项目在圈子里火起来，很大程度上是因为它踩中了两个热点：一是开源，硬件结构、电机选型、训练代码、部署代码全部放开；二是强化学习在真实机器人上的落地，不是只跑仿真，而是真的把策略部署到了实体上，让它走路、踢球、轮滑。25cm这个尺寸也很有意思，比那些动辄一两米的双足机器人门槛低得多，普通爱好者桌面就能摆，成本可控，玩起来没有心理负担。

项目的前身可以追溯到斯坦福的OpenDuck项目，但国内社区基于其思路做了不少改动和优化，尤其是强化学习训练链路和部署工具链的适配。如果你关注过"开源鸿蒙"相关的生态，可能会发现这类小尺寸机器人越来越多地在国产开发板和开源社区里出现，这个机器鸭算是其中完成度比较高的一例。

1.2 这个项目解决的是什么问题

双足机器人最大的痛点从来不是"能不能站住"，而是"怎么走得自然、走得稳、适应不同地形"。传统方法靠ZMP（零力矩点）规划、倒立摆模型、预编程步态，这套东西在平整地面上没问题，一旦遇到小扰动、斜坡、或者有人推它一把，很容易翻车。而且每换一个地形就要重新调参数，工程师的工作量巨大。

强化学习解决的是另一条路径：不手写步态，而是设计奖励函数，让机器人在仿真环境里自己"试错"，通过数百万次交互学会怎么迈腿、怎么保持平衡、怎么响应外力。这种思路在大腿机器人上已经被验证过，比如波士顿动力的Atlas后期也在往这个方向走，但小尺寸、低成本平台上完整的开源实现其实不多。

这个项目的价值就在于提供了一个完整可复现的样本：仿真用什么搭、奖励函数怎么设计、训练完的模型怎么导出、部署到实体机器人还需要处理哪些问题。它把一条原本需要博士团队才能走通的技术路径，压缩到了一个学生宿舍就能搞定的规模。

1.3 适合哪些人来参考

如果说你从来没碰过强化学习，但对机器人感兴趣，这个项目是一个很好的第一站。它不需要你从零写神经网络，也不需要你手推运动学公式，跟着教程把环境和训练脚本跑起来，你能直观看到"智能体从乱摔到稳走"的整个过程。

如果说你已经在跑一些仿真强化学习项目，但一直卡在"仿真到实物迁移"这一步，那这个项目的部署层代码值得反复看。它把sim-to-real的很多坑都比较完整地趟了一遍，比如动作延迟怎么处理、观测噪声怎么加、零位标定怎么设备。

如果说你是做ROS、嵌入式或者硬件开发的，想看看强化学习模型是怎么跟真实电机控制回路结合在一起的，这个项目的软硬件接口设计也能给你不少启发。它不是一个只能跑演示的demo，而是一个能帮你把"学习类控制"和"传统控制"打通的技术桥梁。

我不会在这篇文章里把代码一行行抄一遍，那没有意义。我尽量把整个项目的技术脉络、关键环节的原理、实操中容易踩的坑讲清楚，你拿着这份笔记去看仓库里的代码，会顺畅得多。

2. 硬件架构与技术选型解析

2.1 整机结构与自由度配置

机器鸭高度约25cm，这个尺寸的选择并不是拍脑袋定的。太小的机器人虽然成本低，但电机力矩密度不够，带不动腿部的负载，走起来会变成"抖动"而不是"迈步"；太大的机器人虽然性能上限高，但随之而来的是电机数量增加、机身结构强度要求提高、电池容量需要加大，整体成本会成倍增长。25cm这个尺寸基本落在"桌面级教学/研究平台"的最优区间。

从结构上看，单条腿配置了多个自由度，具体来说髋关节有俯仰和滚转两个方向的自由度，膝关节有一个俯仰自由度。脚踝如果是主动自由度，那整机就是每条腿3个主动关节，加上两条腿共6个；如果脚踝是被动的，靠脚掌形状和重心控制来维持稳定，那结构上会更简单，但对本体感觉和上身姿态控制的要求会更高。实际项目中不同版本有过调整，你去看仓库里的CAD文件和BOM表就能确认具体版本。

腿部结构用的是连杆+舵机的经典方案。这种方案的好处是结构简单、成本低、装配容易，舵机直接通过连杆机构驱动关节转动，不需要复杂的减速箱和轴承结构。缺点是精度和刚度不如直驱或准直驱方案，尤其是高速运动时连杆间隙和舵机背隙会导致控制误差。但考虑到25cm尺寸下这个项目的定位，连杆+舵机的选择是合理的——它把结构成本和装配难度压到了最低，把核心矛盾集中在了控制算法上。

2.2 电机、驱动器与控制板选型逻辑

电机选择是这类项目最关键也最容易让人纠结的部分。这个尺寸的仿人腿机器人，对电机的要求很具体：重量要轻，力矩要够，响应要快，还要皮实耐摔。训练过程中机器人会频繁摔倒，电机和驱动器如果不够结实，修机器的时间会比跑训练的时间还长。

常见的方案有这么几类，我简单列一下优劣：

这个项目用的方案我印象里更偏向于带位置反馈的总线舵机或近似的低成本方案。为什么这么选？因为强化学习训练出来的策略在仿真里是高频控制，输出的是目标位置或目标力矩，真实舵机越接近这个控制频率和响应特性，sim-to-real的差距就越小。总线舵机的好处是能直接读取当前角度和力矩，这个信息在部署时可以用来做状态估计和奖励校准，对调试帮助很大。

控制板方面，项目用的是主控+舵机控制板的分离结构。主控跑Linux系统（常见的是配了Debian的ARM板），负责加载强化学习策略、做状态估计、发布控制指令；舵机控制板负责底层的位置环/力矩环响应，接收目标值并驱动舵机。这种分离的好处是主控和底层控制和干扰隔离，训练好的PyTorch模型可以先转成ONNX再接TensorRT，或者直接用轻量推理框架跑，和底层硬件的耦合度很低。

2.3 传感器配置与状态观测

强化学习策略要跑起来，得先回答一个问题：策略网络的输入是什么？如果只能看到电机角度，那基本等于让一个闭着眼睛的人走钢丝。为了让机器鸭在真实环境里走得像仿真里一样好，观测空间需要包含足够的状态信息。

项目里的传感器配置大致包括：关节角度反馈（舵机自带）、IMU姿态（三轴加速度+三轴陀螺仪）、以及可选的足底接触传感器。关节角度是最基础的，拼出当前腿部构型；IMU提供躯干的姿态角和角速度，这是平衡控制的核心观测；足底接触传感器如果装了，可以实时知道哪只脚着地了，这对踢球和上下坡场景很有帮助。

这里有一个很多初学者容易忽略的细节：强化学习策略在仿真里训练时，观测是有噪声的，而且是固定噪声。真实传感器噪声的分布跟仿真里设的往往不一样，如果差太多，策略在实体上就会表现得很"神经质"——明明没动，机器人却在不停地调姿态，因为IMU的微小漂移被策略解读成了倾倒。项目中部署代码里通常会对IMU数据做滤波，同时对关节角速度做平滑处理，这些细节很不起眼，却是sim-to-real能work的关键。

3. 强化学习训练链路深度拆解

3.1 仿真环境与物理引擎选型

训练强化学习策略的第一步是把机器人放进仿真环境。这个项目早期版本适配过MuJoCo，后续也有人在Isaac Lab里迁移过，但仓库里默认的应该是MuJoCo相关的训练脚本。为什么选MuJoCo而不是Gazebo或者PyBullet？核心原因是速度。强化学习训练要跑百万级的环境交互，每一步都是一次物理引擎的仿真步进，引擎速度直接决定了训练时间。MuJoCo的软接触模型和高速求解器在这个场景下优势非常明显，同样的训练配置，MuJoCo可能几个小时就跑完，而其他的引擎可能要跑一夜。

另一个选择MuJoCo的原因是它对双足/四足机器人的支持很成熟。很多研究组都在MuJoCo里做足式机器人运动控制，相关的API、奖励函数示例和调参经验在网上能找到一大把。这意味着当你遇到问题（比如机器人训练时原地打转、翻不过来身）时，搜索解决方案的成本很低。

仿真环境的搭建不只是把CAD模型导进去那么简单。你需要给每个关节设置正确的自由度方向、力矩限制、位置/速度范围，还要给模型设置质量属性、摩擦系数、碰撞几何。任何一个参数错了，训练出来的策略在实物上都会出问题。项目仓库里提供了处理好的XML模型文件，如果你自己改结构，记得要重新做一遍这些设置。

3.2 动作空间与观测空间的设计

强化学习里，动作空间的设计决定了策略层能做什么，观测空间的设计决定了策略层能看到什么，这两个是最基本也最影响效果的设定。

动作空间的常见做法有两种：位置控制模式和力矩控制模式。位置控制模式下，策略输出目标关节角，舵机自己去闭环跟随；力矩控制模式下，策略直接输出关节力矩指令。这两种模式各有优劣：位置控制更稳，因为舵机内部的位置环会帮你抑制一些高频抖动，但缺点是策略无法精确控制力的大小，遇到障碍物时容易硬顶；力矩控制更灵活，能做更细腻的操作（比如踢球时的发力控制），但对底层驱动器的带宽和精度要求更高。

这个项目踢球和轮滑这些动作，其实对发力是有一定要求的。如果全是位置控制，踢球动作会显得很"死板"，像木棍捅球；而力矩控制允许策略在接触瞬间调整输出力矩，能踢出更自然的球路。但力矩控制对sim-to-real的要求也更高，因为真实电机的力矩响应、摩擦和仿真里的模型差异会直接体现在控制质量上。项目在具体实现上做了妥协，基本是位置和力矩混合的模式，这个你去看训练配置里的action_scale参数就能发现端倪。

观测空间的构成大致包括：躯干姿态（roll/pitch/yaw角）、躯干角速度、关节角、关节角速度、上一步动作（action history）、以及一些自定义的相位信息（比如步态周期）。给策略加上一步动作的历史非常重要，这等于给系统引入了"惯性"，能让输出更平滑，不会一帧一个样、抖得厉害。这个技巧在很多强化学习控制项目里都有用到，属于那种你不点破就不会注意、但有没有效果差别很大的细节。

3.3 奖励函数设计：从走路到踢球的关键构造

奖励函数是整个强化学习训练中最需要"手艺"的部分。写得太稀疏，智能体学不到东西；写得太密集，智能体容易钻空子找捷径。这个项目能走路、能踢球、能轮滑，其实背后是三套不同的奖励设定。

先说话步态。走路的基础奖励通常包括：前进速度奖励（往前走得越快奖励越高）、方向一致性奖励（朝目标方向走）、存活奖励（不摔倒就给个小的常驻奖励）、姿态惩罚（躯干倾斜过大扣分）、能量惩罚（关节动作过大扣分）。这里面最关键的是怎么平衡存活奖励和速度奖励——如果速度奖励权重太高，机器人会走成"小碎步冲刺"甚至直接摔倒换取前冲；如果存活奖励太高，它会原地站着不动蹭奖励。项目里用了很多约束项来压制这样的离奇行为，比如限制关节位置的最大范围、限制角速度的上限，这些约束都是带权重的软约束，不是硬限位，给策略留了探索空间。

踢球和轮滑的奖励设计就更复杂一些。踢球需要定义"脚触球那一下"的时机和方向，通常的做法是给一个稀疏奖励：只有球被踢进目标区域才给大额奖励。但这会带来稀疏奖励问题，智能体随机探索很难碰到拿球进球。所以工程上会加一个"过程奖励"：脚和球的距离缩小就给一点正奖励，脚速在接触瞬间足够大再给一点正奖励，像挤牙膏一样把策略引导出来。轮滑更麻烦一些，因为轮滑的接触模型是点接触，摩擦力方向复杂，在仿真里本来就不容易收敛，项目里能跑通轮滑，我猜测奖励里应该加了速度跟踪和身体侧倾斜角控制的耦合项。

3.4 训练流程：从弱智鸭到稳走鸭的调参记录

训练过程基本是这样的：先在CPU或GPU上起多个并行环境，每个环境里都有一只随机的机器鸭，初始位置和扰动不同。所有智能体共享一个策略网络，同时收集经验，更新网络参数。这里用的算法主要是PPO，具体实现可能基于rl_games或自研的PPO封装。PPO是上界稳定性比较好的算法，对超参不那么敏感，适合这种"不想花太多时间调参"的项目。

我自己跑这种训练的时候，习惯把整个过程分成几个阶段来观察：

1. 起步阶段（前10万步左右），机器人基本在原地乱扭，偶尔能迈出一小步但马上摔倒。这个阶段不用着急，奖励曲线波动大是正常的，你要看的不是奖励值本身，而是有没有逐步上升的趋势。
2. 中期阶段（10万到50万步），机器人开始学会迈腿序列，能走一两步再摔倒。这个时候如果出现"原地转圈"或者"躺在地上蹬腿"这种局部最优，通常需要调整奖励权重，或者给初始状态注入更多随机性。
3. 收敛阶段（50万到100万步），步态逐渐成型，摔倒频率大降。这时可以把环境里的扰动幅度增大（比如随机推一把、随机抬高地形），让策略学会应对意外情况。

训练时的一个常见坑是reward hacking，也就是智能体发现了奖励函数的漏洞。我在实际调试中就见过这样的情况：我给了一个"身体不要倾斜"的惩罚项，结果智能体贴着地面平移，躯干确实没有倾斜，但整个动作根本不是走路。这种现象在机器人控制里非常常见，解决办法通常是加更丰富的行为正则项，比如脚部轨迹的平滑度、关节加速度的受限程度。这些惩罚项往往比正向奖励更重要，二者配合才能拉出正常的步态。

4. 仿真到实物迁移与部署实操

4.1 sim-to-real的三大核心障碍

很多人在仿真里跑出了几乎完美的策略，一旦部署到实体机器人就全崩了，这并不是模型训练得不够好，而是仿真和现实之间的差距（sim-to-real gap）造成的。这个项目的部署代码里解决这些障碍的方式，有不少可以借鉴。

第一个障碍是动力学参数不匹配。仿真里设置的摩擦系数、质量分布、电机最大力矩，和实际情况是有出入的。桌面上的塑料地面、木地板、地垫，摩擦系数都不同，仿真里如果只跑了一种地面，部署到另一种地面就可能打滑或刹不住。项目里的做法多是在训练时做域随机化：在训练环境里随机改变摩擦系数、电机力矩限制、机器人质量和重心位置，让策略学到的是一个"鲁棒区域"而不是某个精确参数值，这样在实体上才能有足够的容错空间。

第二个障碍是感知噪声和延迟。真实传感器的数据有噪声、有延迟，关节反馈也不像仿真里那样"完美"地同步。项目在训练时会给观测空间注入高斯噪声，也会把动作执行延迟模拟进去，让策略适应"动作发出去之后过一两个控制周期才生效"的真实情况。部署代码里通常还会对控制频率做降频处理，比如从仿真里的500Hz降到实体的100Hz，因为只有100Hz是硬件跑得动且舵机跟得上的频率。

第三个障碍是零位标定和装配误差。仿真里的关节零位、正方向、运动范围都是精确的，实体装配稍微歪一点点，同样的关节角度指令下腿的姿态就会不同。项目部署前通常需要做一个"关节零位标定"，爬到每个关节的目标位置，把舵机码盘读数记下来，换算成偏移量，在策略输入和输出两端都进行补偿。

4.2 策略导出与推理部署流程

训练好的模型是一个PyTorch的state_dict，但实体机器人的主控上往往没有那么完整的PyTorch环境，而且为了控制延迟，走一遍完整的PyTorch推理链路太浪费了。所以部署的第一步是把模型导出成轻量格式。

项目里常见的做法是把PyTorch模型转成ONNX，再用ONNX Runtime来推理。ONNX格式的好处是跨平台、轻量、推理速度快，对嵌入式设备友好。我在实际项目中也会优先选这条链路，稳定且踩坑成本低。导出后需要处理的一个细节是，把网络里的归一化层（normalization）参数一并保存，或者直接在模型里带上前处理和后处理的逻辑，这样在推理时才不会漏掉"给输入做标准化"这一步。

控制循环的大致结构是这样：主控读取IMU和关节角度 → 做滤波和零位补偿 → 拼装观测向量 → 送入ONNX模型推理 → 得到动作向量 → 映射到舵机目标值 → 通过串口或总线发给舵机控制板。整个循环要在一帧时间（比如10ms）内完成，ONNX Runtime在小模型上通常能做到微秒级推理，瓶颈反而在传感器读取和通信上。

这里有一个很实用的经验：部署代码里建议加一个"安全看门狗"逻辑。如果连续多个控制周期内IMU读到的姿态变化异常剧烈，或者与策略输入的数据相差过大，立刻切换回安全模式，比如让舵机锁死当前姿态或者直接断电。因为强化学习策略在落地的前几分钟是最脆弱的，一个小错误可能被放大成翻跟头，看门狗能救回来。

4.3 踢球和轮滑动作的部署特殊性

踢球动作和走路最大的区别是：踢球是一个短暂的爆发性动作，需要策略在极短时间内输出一个大力矩，并且精确命中球的方向。走路策略里学到的平滑步态往往不够用，因为腿的摆动幅度和踢球时的瞬间加速不在一个量级。

项目在踢球场景里的做法，我猜测是采用了"两阶段策略"或者"技能切换"：平时跑的是行走策略，当检测到球在脚边一定范围内并且触发条件满足时，切换到踢球策略，踢完再切回来。这种方案比用一个策略同时搞定所有动作要简单可靠得多，也便于单独调试踢球动作的时机参数。

轮滑场景就更考验策略的连续性了。轮滑一旦动起来就很难停，因为地面摩擦小、系统响应快，策略需要在一个很高的控制频率下工作，对延迟极其敏感。项目里能跑通轮滑，说明部署端的控制循环是经过优化的。如果你也想复现轮滑，建议把主控的实时性提上去，比如给控制线程绑核、屏蔽中断、用共享内存传递传感器数据，任何一处引入毫秒级抖动都可能导致轮滑动作垮掉。

4.4 一次完整的部署调试实况

我自己在实际跑了类似流程之后，总结了几个部署调试时的关键检查点，不一定全对应这个项目，但方向是通用的：

先做静态测试。把机器人悬空吊起来，不给地面接触，手动掰动关节，确认每个关节的角度反馈、方向和限位都正确。这步最基础也最容易发现问题，很多"机器人莫名其妙乱动"的案例都是因为有个关节方向反了。

再做无外力状态测试。让机器人站在桌面上，不要启动策略，确认IMU读数稳定、没有明显零漂。然后启动策略但设置动作输出幅度很小，观察机器人有没有突然窜出去。如果一开始就猛冲，说明观测方向、动作方向有映射错误，需要逐帧比对仿真和实体的关节角度。

最后做带扰动测试。让人在旁边准备接住，让机器人走两步，然后用手轻推一下它的肩膀，看它能不能恢复平衡。恢复平衡的能力实际上是策略鲁棒性的直接体现，如果一推就倒，说明域随机化还不够，或者训练时缺少推力扰动。

这套流程看着笨，但真的是省时间的好方法。我见过不少朋友跳过前两步直接下地跑，结果出了故障无法判断是策略问题、硬件问题还是通信问题，排查时间反而翻倍。

5. 常见问题与排查技巧实录

5.1 训练不收敛或收敛到"躺平"怎么办

这是整个项目复现过程中被问得最多的问题。机器人在仿真里训练很久，奖励曲线一直上不去，或者走到"干脆躺在地上不动，靠存活奖励混日子"的局部最优，怎么办？

首先检查初始状态分布是不是太单一。如果每局都从同一个站立姿态开始，智能体很容易找到一个"躺平"的稳定策略，因为站着需要持续控制，躺着不用控制。要在初始状态里加入随机扰动，比如让机器人以一个随机的小角度倾斜开始，或者随机给一个关节角偏移，逼它学会主动恢复姿态。

其次检查奖励权重。存活奖励权重如果太高，智能体会选择最低能耗方式（躺着）来获取奖励。这时候应该降低存活奖励，同时提高前进速度奖励的权重，给策略更强的"必须往前走"的压力。另外可以加一个"步态检测奖励"：只有检测到两个脚交替接触地面才算有效步态，否则不给前进奖励，这样能有效抑制"蹭着地皮平移"的作弊行为。

5.2 仿真表现很好，但实体站都站不稳

这个问题排第一的原因是零位标定没做好。仿真里的零位对应腿是完全伸展的某个标准姿态，但实体舵机装上之后，同样的指令下可能腿已经弯了十几度。建议先把每个关节的零位偏移测出来，最好写一个自动标定脚本，而不是手动肉眼对。

第二常见的是延迟问题。强化学习策略在仿真里假设动作是立刻生效的，但实际的舵机指令经过串口发送、舵机内部位置环调节，会有几十到上百毫秒的延迟。如果策略是在500Hz下训练的，而实际控制只有100Hz，反馈路径完全不同。建议把训练时的action_delay参数和部署时的实际延迟对齐，或者干脆在训练时就把控制频率降到和实体制动一致的水平。

第三类可能是IMU安装方向问题。仿真里IMU的坐标轴方向通常是固定且已知的，实体上如果装反了一个轴，策略读到的姿态就是错的，机器人会觉得它一直在往一边倒。检查方法很简单：手动把机器人前倾，看IMU输出的pitch角是不是正的对应方向，每个轴都测一遍再接入策略。

5.3 踢球动作不稳定，有时踢不中

踢球不稳定，大部分原因是触球时的速度不够，或者方向角度偏差大。训练里给踢球动作设的过程奖励需要仔细调：如果"脚接近球"就给奖励，策略可能学会把脚贴在球旁边蹭，而不是发力踢；如果只在"球进门"时给奖励，学习效率又太低。折中的做法是分阶段给奖励：靠近球时给小幅距离奖励，接触球瞬间脚速超过阈值给中幅奖励，球进门再给大幅奖励。三段式奖励能让策略在"追球"和"发力"两个子目标上都得到引导。

另外注意触球之后的跟随动作。很多新手设计的踢球策略只关心脚踢到球那一下，踢完就松了，导致脚停在小球路径上反而挡住了球。要给一个"踢完缩脚"的行为正则项，比如惩罚脚在踢球后停留在球的路径上的时间，这样球路会更顺。

5.4 复现代码时的环境版本坑

这个项目仓库使用了若干Python依赖库，版本兼容性是最容易踩的坑。MuJoCo版本更新频繁，不同版本之间XML解析规则有差异；PyTorch的CPU/GPU版本也影响训练速度。如果按照仓库的requirements直接装，很容易遇到cuda版本不匹配、mujoco无法加载模型这类问题。

我的建议是严格对照仓库的说明创建conda环境，锁死版本号，不要用最新版去跑老代码。如果仓库里已经注明测试过的最低版本，就用那个版本。训练模型和部署推理尽量用同一个Python环境，避免导出ONNX时出现算子兼容问题。另外训练过程中不要手动中断再resume，PPO的replay buffer和normalizer状态很容易在这种场景下出bug，实在要中断，把整个checkpoint目录（不只是模型权重）完整保存。

6. 扩展思路与二次开发方向

6.1 加摄像头做视觉引导

原版机器鸭主要靠本体感觉（关节和IMU）行动，没有视觉输入。如果你想做更复杂的任务，比如"找到球并踢进球门"或者"沿指定路径走"，可以在头部加一个轻量摄像头（树莓派Camera模块或USB摄像头），在端侧跑YOLO做目标检测，把检测到的球的位置、距离转化成机器人坐标系下的相对位置，作为额外的观测输入给到策略网络。

这一块改动不算小，因为你需要在训练环境的仿真里也加入视觉观测的模拟，并且在策略网络里增加一个视觉编码分支。好在现在有大量视觉-运动控制（vision-based locomotion）的开源参考，可以不用从零设计网络结构。视觉模型在仿真环境里渲染需要额外算力，如果GPU不够，也可以先用无视觉策略做基础行走，视觉只用来做"踢球时机触发"，这样工程复杂度低很多。

6.2 切换到更轻量的国产主控

项目默认的主控方案不一定满足所有人的成本目标。如果你手头有合适的国产ARM开发板，比如基于瑞芯微或全志方案的板子，性能上通常够用，而且可以进一步把成本压下来。Linux环境都不用大改，把PyTorch/ONNX Runtime装好、串口驱动拉通，部署代码基本是通用的。

不过这里有几个提醒：第一，国产板子的实时性不一定有保障，如果要用它跑100Hz以上的控制循环，建议做实时性测试，必要时用PREEMPT_RT内核补丁；第二，部分国产板子的PyTorch底层没有适配NPU加速，但是ONNX Runtime在某些芯片上有专门的加速库，推理延迟反而比重型板子更好，值得试试。

6.3 多机器人交互可能性

如果你有两台甚至更多台机器鸭，可以做多智能体交互的实验。比如让两台鸭子踢同一个球，各自用独立的策略网络，但共享球和目标位置的观测。多智能体强化学习（MARL）在这个场景下是个很有趣的方向，因为两只机器鸭之间的协作/对抗会产生很多有意思的行为模式。

实现上，你不需要从头写MARL算法，可以先从简单的"独立PPO+共享奖励"开始跑通，再逐步过渡到集中式训练、分布式执行（CTDE）的框架。仿真里要处理多机器人的接触碰撞，物理引擎的求解压力会大一些，但2台机器人的规模不大，不至于跑不起来。

6.4 步态迁移到其他形态

最后说一个我自己觉得价值最大的扩展方向：这个项目的代码和技术栈是完全可迁移的，你可以把同样的训练流程套到一个四足小猫、六足昆虫甚至一条机器蛇上。硬件的自由度配置变了，但强化学习训练链路的流程几乎不变：搭仿真模型、设动作/观测空间、写奖励函数、域随机化、训练、部署。你换的只是模型文件里的关节定义和奖励函数里的运动目标，整套方法论是通用的。

我自己在跑这类项目的过程中最大的体会是：强化学习在足式机器人上做运动控制，确实比传统方法"省心"得多，但这个"省心"的前提是前面几周把仿真、奖励、域随机化这些基础打扎实了。如果你只是把官方的训练脚本跑通，那只是个开始；真正值得投入时间的，是去改奖励函数、加扰动、换地形，让策略在你自己的场景里真正“扛得住”。

从一台25cm的机器鸭身上，你能学到从仿真到实体、从算法到系统的完整链路，这是这个开源项目最值钱的地方。如果你正好手边有一套硬件，建议先把环境搭起来，照着仓库的教程把第一步走通，剩下的路会越走越顺。