从零构建双足鸭形机器人：强化学习驱动的开源Sim2Real实践

如实说，这个项目最开始出自我一次不太成功的购物冲动——买了个十几块钱的玩具鸭，拆开后发现里面的关节结构和运动逻辑比想象中有意思得多。那只鸭子只有一条舵机带动的腿，靠摆动重心“摇”着走，运动轨迹勉强称得上能走，但离“双足稳定行走”差了十万八千里。后来我在折腾强化学习算法时突然想，为什么不干脆自己从零搭一只微小型双足鸭形机器人，整条链路都用强化学习驱动，代码也直接开源出来供需要的人参考。这才有了这个项目：一套完整的微小型双足鸭形机器人系统，本体是3D打印结构，主控是普通MCU，运动策略由深度强化学习在仿真中训练，再迁移到实物上，整套架构全部开源。

这篇文章我就把这个项目从机械设计、仿真训练到Sim2Real部署、代码架构拆开来讲，重点讲那些文档里不会写、只有实际操作中才能感受到的细节。适合准备入门足式机器人强化学习、或者已经跑通过仿真但卡在实物迁移的人参考。我不写官话，项目里怎么做的、踩了什么坑、哪些地方其实不用纠结，都尽量说得明白。

1. 双足鸭形机器人这个选题，到底图什么

1.1 双足是足式机器人里“性价比最高”的控制难题

足式机器人常见的构型有四足、六足、双足。四足和六足虽然腿多，但控制难度其实比双足低——多腿意味着更大的静稳定裕度，哪怕策略差一点，三脚着地也能稳住不倒。双足则完全不同，它天生就是不稳定系统，站立时重心投影必须落在支撑多边形内，而双足的支撑多边形窄得可怜。一旦迈步，系统就进入动态平衡状态，靠的不是“稳”，而是“及时调整”。

我在设计这只鸭形机器人时，正是看中了双足的这种特性。它把控制问题的难度压到了一个刚好能“逼真训练强化学习算法”的区间，同时又比人形机器人简单得多，不用考虑手臂摆动、躯干多模块协调等更复杂的问题。也就是说，一只双足鸭形机器人，就是一套聚焦“腿部运动控制的强化学习”的最小但完整的载体。

1.2 鸭形不是噱头，它把“感知-控制-形态”绑在了一起

很多人看到“鸭形”第一反应是觉得有趣、可爱，但“鸭形”在这个项目里是有实际工程意义的。

鸭子走路有两个非常明显的特征：一是配合步态周期的左右摇摆，二是脚掌的着地节奏相对松散。这两个特征决定了鸭形机器人的结构参数——重心偏高、髋关节宽度适中、腿相对短粗、脚掌偏大。如果形态做成四条腿的小狗或者六腿的昆虫，设计目标就完全不一样了。

我是把“鸭形”当成一个先验约束来用的。仿真里机器人的质心位置、腿长、支撑面形状，都是根据鸭形外观的包络框来设定的。这样在训练结束后，策略迁移到实机时，几乎没有遇到“外观改变导致运动特征失效”的问题。说白了，外观形态不是贴皮玩具，而是机器人发动力学参数的一部分。

1.3 开源架构和“能跑起来”是两码事

这年头开源机器人项目很多，但多数开源停留在原理图、BOM、源码这种层面。我遇到的最常见问题是：克隆仓库、装完依赖、跑一个demo，然后就没有然后了。训练代码和实物部署是断开的，机器人的物理参数、执行器型号、仿真模型全都对不上。

这个项目从最初就设定为“开源架构”而不是“开源demo”：代码仓库里同时包含仿真训练环境、策略导出工具、MCU端推理代码和一份完整的硬件BOM。我甚至把3D打印模型也直接放进去，目的是让另一个人可以从零开始，按照同一套流程，重新训练出自己的鸭形机器人的运动技能。这套结构后面我会专门讲。

2. 硬件选型与机械结构：微小型机器人设计里的隐性约束

2.1 尺寸定位：从“桌面玩具”到“桌面实验平台”

整个机器人的外形尺寸我设定在长约12厘米、高约16厘米、宽约8厘米的量级，整机质量控制在230克左右。这个尺寸有几个好处，首先是打印成本和零件成本低，可以多次迭代改结构；其次是在桌面上就能测试，不需要专门的空地；最重要的是微小型带来的动力学特性——低转动惯量、高响应速度，非常适合强化学习策略在实物上快速评估。

反过来也有代价。实现同样的关节速度和加速度，微小型执行器的扭矩空间非常有限。也就是说，策略在仿真里可以大幅输出关节力矩来纠正姿态，但实机一旦真正需要这个力矩，舵机是给不出来的。这属于微小型机器人设计中一个到处都存在的隐性约束，我在后面的奖励函数设计部分会再提到。

2.2 自由度配置：四条执行通道实现动态平衡

这只鸭子的每条腿设置2个主动自由度，分别是髋关节俯仰（前后摆腿）和膝关节俯仰（收小腿），两条腿一共4个通道。脚掌和地面之间没有主动驱动，仅依靠脚掌橡胶垫的摩擦和被动踝关节的柔顺来吸收冲击。

为什么不做踝关节主动自由度？原因很简单：微型舵机的体积和重量摆在那里，若每条腿再加一个踝关节驱动器，整条腿的惯量会上一个台阶，机身也必须加大，项目就会从小型走向中型，控制难度和成本都会指数上升。双足行走的稳定并不一定要依靠踝关节主动干预，靠髋关节调整躯干姿态、靠步态规划维持零力矩点（ZMP）落在支撑多边形内，同样可以实现稳定的动态行走。

关于零力矩点多说一句：对双足机器人来说，ZMP可以通俗理解为地面给机器人反作用力合力的作用点。只要ZMP在双脚接触地面的范围内，机器人就是稳定的；一旦ZMP跑出这个范围，机器人就会绕支撑边翻转，也就是摔倒。强化学习本质上是通过不断试错，学会了用腿部动作去主动控制ZMP落点随时间变化的轨迹。

2.3 执行器的扭矩估算与实际校准

我用的执行器是常见的微型金属舵机，标称堵转扭矩大约在1.8kg·cm（约0.176Nm）。标称扭矩在实际运行中是不可信的，因为堵转扭矩代表的是“转不动瞬间”的输出能力，而正常行走时舵机需要的是持续转动过程中的动态出力。动态扭矩通常要比堵转扭矩低不少。

所以我在选型时做了个粗算。假设机器人总质量m=0.23kg，单腿支撑时需要的重心稳定力矩大约可以用m·g·d估算，其中d是重心到支撑脚的水平距离，极限情况下按机身半宽取0.04m，那么需要的恢复力矩大约是0.23×9.81×0.04=0.09Nm。也就是说，单腿瞬间撑地时至少需要0.09Nm以上的力矩输出。舵机标称0.176Nm，动态情况下打个折扣还有空间，但余量并不多。这个估算告诉我，任何额外增加重量——比如头部装饰太重、或者背上一块大电池——都会直接压缩稳定裕度。最终我把电池选成了45g左右的2S锂聚合物电池，就是基于这个力矩预算。

2.4 主控和传感器：没有想象中那么高端

主控我用的是一块基于Cortex-M4内核的国产开发板，主频168MHz，支持定时器输出多路PWM信号，自带硬件I2C和SPI接口。这套配置看起来非常普通，但对这个项目来说足够用了，因为决策逻辑全部跑在离线训练好的神经网络上，MCU端只负责每20ms执行一次前向推理，读取IMU数据、关节角度、关节速度，然后输出四个关节的目标位置。前向推理的神经网络只有三层全连接，每层128个神经元，输入维度19维，输出维度4维。在M4这种级别的MCU上，一次推理时间实测大约在1毫秒左右，完全扛得住20ms的控制周期。

传感器方面，机身中心装了一块六轴IMU（三轴加速度计加三轴陀螺仪），每条腿的输出轴位置装了磁编码器来读绝对角度。这里要提醒的是，不要过分追求高精度传感器。在强化学习Sim2Real迁移过程中，IMU零偏是必须做的一环，仿真里的传感器噪声参数也要比真机稍微“悲观”一点，这样策略反而会更鲁棒。没有这个认知，后面实机测试就会非常痛苦。

3. 仿真训练环境搭建：强化学习策略是怎么“涨”出来的

3.1 为什么一定从仿真出发，而不是直接在实物上跑

很多新手会问一个问题：直接在实物上训练强化学习行不行？理论上行，实际上不行。强化学习需要数百万次状态-动作交互来学习策略，一个回合如果训练机器人平均走5秒就摔倒，一个回合就是250个控制步，要训练出稳定行走策略至少需要几千万步交互。真人去换电池、复位、等待程序启动，一次实验流程可能会消耗一两分钟，一天下来也只能积累几个小时的交互数据，机器人还要面临大量机械磨损。仿真中，同样的交互量在GPU上几分钟就能全部跑完。

所以我选择NVIDIA Isaac Gym作为仿真平台。Isaac Gym的突出特点是支持GPU并行，可以在同一时刻并行几千个机器人的仿真环境。我训练时并行度开到4096个环境，PPO算法每轮迭代用400万步交互数据更新策略。这个并行度如果靠CPU物理仿真，几乎是不可能实现的。

3.2 状态空间、动作空间与命令接口的设计

训练环境里，每个机器人每20毫秒收到一次控制指令。为了让策略在实机上可用，观测空间的设计力求贴近实际硬件能读取的内容：

• IMU提供的机体角速度（3维）和姿态角（用翻滚角、俯仰角表示，2维）
• 四条执行通道的当前关节角度（4维）和关节角速度（4维）
• 上一时刻策略输出的动作（4维）
• 用户的期望前进速度指令（1维）和期望转向指令（1维）

总维度是19维。这里有个细节：我只观测姿态角而不观测绝对位置。原因是在真实机器人上，机体的绝对位置很难通过片上传感器直接精确测量，如果策略依赖绝对位置，部署时就会有信息缺口。把位置信息当作命令而不是观测，策略就能学会不依赖位置反馈，只依靠自身姿态和关节状态来完成速度跟踪。

动作空间方面，我选择的是“关节目标位置增量”。也就是说，策略每个控制周期输出一个四维向量，代表四个关节的目标角度相对上个周期的变化量。这个设计比直接输出绝对关节角度更容易训练，因为增量限制了动作变化的幅度，不会出现策略猛地要求关节瞬间摆到极限位置的情况。底层再配合一对PD控制器，将关节目标位置转换成PWM指令给舵机。

3.3 奖励函数：把“走得稳”翻译成机器能优化的数字

强化学习训练的本质，是最大化累计奖励。所以奖励函数的设计，等于在定义“什么是走得好”。这个项目里我用的是稀疏与密集混合的奖励结构，主奖励为密集项：

• 速度跟踪奖励：exp(-2×(实际前进速度 - 期望速度)²)，跟踪得越准，奖励越高
• 朝向保持奖励：exp(-|当前偏航角速度|)，鼓励机器人不要原地打转
• 姿态稳定奖励：对机身俯仰角、翻滚角的偏离进行惩罚，惩罚项是角度的平方项
• 关节极限惩罚：当关节角度接近物理限位时施加较大负奖励
• 动作平滑惩罚：惩罚相邻两步动作变化量，减少抖动

这里有个非常关键的实践经验：奖励函数里的每一项权重，不能只靠拍脑袋。我一开始把姿态稳定项权重设得过高，结果训练出来的策略特别“僵”——机器人几乎不敢迈腿，因为迈腿必然带来姿态扰动，一旦扰动就吃惩罚。后来我把姿态稳定权重降到原来的四分之一，同时加入“任务完成额外奖励”，也就是匀速前进距离超过阈值时给一个正奖励，策略才开始学会大胆迈步。

训练曲线也非常值得盯。奖励曲线不会平滑上升，而是呈现典型的阶梯状跳变：长时间在小范围内徘徊，突然某个阶段策略“领悟”了一个新技能，奖励曲线猛涨一截，然后又进入新的平台期。碰到这种曲线不用慌，这是探索过程的正常表现。真正要警惕的是训练开始后奖励长期没有变化，那多半是奖励函数设计的某个环节出了问题，而不是训练轮数不够。

3.4 PPO超参数的实践基准

算法层面，我选了PPO（近端策略优化）。这是当前足式机器人强化学习里最主流的选择，原因很实际：它对超参数不那么敏感，训练稳定性好，非常适合硬件部署场景中不需要频繁调参的需求。

我用的关键超参数如下，供参考：

要注意的是，这些参数是从Legged Gym等公开项目中继承下来的经验值，并不需要每项都懂原理才能开始训练。但有一点值得强调：学习率千万不要设成默认的Adam默认值（比如3e-3以上），足式机器人策略训练会出现严重的过拟合式波动——前半段奖励挺好，后半段突然全面崩溃，这往往是学习率过大导致的。

4. Sim2Real迁移：从仿真学会走路到真机也能走路

4.1 域随机化：把仿真里的“固定现实”变成“范围现实”

仿真与实物之间永远存在系统误差。电机延迟、传感器噪声、重心位置偏差、地面摩擦系数变化、舵机非线性和死区——这些东西在仿真里如果不做处理，训练出的策略一到真机就可能“水土不服”。

我的做法是采用域随机化，在训练过程中给每个并行环境分配不同的物理参数。例如：

• 重心位置在标称值的±5%范围内随机移动
• 地面摩擦系数在区间内随机采样
• 关节PD控制的扭矩增益乘以0.85到1.15之间的随机系数
• 控制器执行延迟在5到20毫秒之间随机采样
• IMU测量值附加不同程度的零偏和高斯噪声

域随机化的效果很神奇。单个环境的策略可能会依赖某些特定参数，但并行环境下，策略被强迫学习所有采样域内都有效的运动方式。最终训练出的策略在实机上几乎是开箱即用，感觉就像是“仿真里见过的世面够多，真机这点误差不叫事”。

4.2 策略导出与MCU端推理链路

训练完成之后，保存的不只是权重文件，还包括输入输出归一化参数。这一步很容易被忽略，但极其重要。

强化学习训练时，观测和动作都经过了归一化处理，必须把每个状态维度的均值和方差一并导出，部署时对输入进行同样的归一化，否则神经网络的输出范围不对，实机关节动作会完全乱掉。因此我的仓库里有一个导出脚本，会自动从训练结果中读取标准差、均值以及网络结构信息，生成C语言头文件。MCU端读取这个头文件，配合一个几十行代码的矩阵乘法和ReLU激活函数，就完成了前向推理。

推理代码里我没有用浮点数数组的动态分配，而是将所有矩阵写成静态数组，方便MCU端直接用。神经网络的两层隐藏层都是128个神经元，矩阵乘法规模很小，即便是M4上循环展开也足够流畅。实机上从传感器采样到输出关节PWM的整个链路延迟实测约3毫秒，远低于20毫秒的控制周期。

4.3 真机调试三步法：从安全网到自由行走

硬件和软件链路都就绪后，有一个稳定的调试流程能少走很多弯路：

1. 第一步是“吊装测试”。给机器人的背部挂一根可调节的绳索，让脚掌勉强触地，机器人始终被柔和支撑。此时给策略发送很小的前进速度指令，观察四条腿是否按预期频率摆动，姿态是否保持平稳。这一步的主要目的是验证神经网络的输出逻辑正确，不追求步态质量。

2. 第二步是“推手测试”。在吊装的基础上，用手从侧面和前后轻轻推机器人，观察策略是否有主动纠正姿态的动作。如果策略完全没有响应，优先怀疑IMU方向是否装反，或者观测向量里的姿态角与仿真定义不一致。这是我实际踩过坑的地方——第一次实机测试时，机器人在原地疯狂抖腿但就是不往前走，后来发现是IMU的安装方向与仿真时的正方向定义差了90度，纠正之后就正常了。

3. 第三步是“自由行走”。撤掉吊装，在桌面上铺一层阻尼垫，逐步提高期望速度指令。从0.1m/s慢慢加到0.3m/s，同时观察脚掌是否出现明显的滑动、机身是否有周期性共振。

这三个阶段的节奏不要快。尤其是第三步，最好有人专门盯着执行器温度，微型舵机在大负载下发热很快，过热会导致输出扭矩下降，反过来说明结构设计里还需要考虑散热问题。

4.4 实机测试中最常见的三类“翻车”现场

我把实际测试中遇到过的高频问题整理成了一张表，方便快速排查：

排查思路上，我强烈建议“一次只改一个变量”。真机测试中大家最容易犯的错误是，看到机器人在扭来扭去，同时去调PD增益、修改观测归一化参数、又换了一副脚垫，结果问题依旧却不知道是哪个环节导致的。保持单一变量，才能把反复出现的物理现象和策略行为真正对应起来。

5. 开源架构的分层设计：让别人能真正复现你的项目

5.1 软件分层的核心不是“代码漂亮”，而是“接口稳定”

开源项目的价值不在代码量，而在别人能不能快速跑通、并迁移到自己的机器人上。最初我考虑过把所有逻辑都塞在一个单文件训练脚本里，确实写起来很快，但后期部署和二次开发会很挣扎。所以最终我把整个仓库划分成了四层，每一层只负责一件事：

这套分层里最核心的设计是机器人抽象层。它把“读IMU/编码器、算PD、输出PWM”这些硬件细节全部封装起来，训练环境只依赖这个抽象接口来获取状态和下发动作。好处是，当你想把这套架构用到四足机器人或更大尺寸的双足机器人上时，不需要改动训练相关的任何代码，只需要重新实现这个抽象接口，把它指向新的硬件和新的关节配置。

5.2 训练环境接口的四个方法

仿真环境层的设计则尽量贴近强化学习的标准接口，核心是四个方法：

• reset()：初始化仿真场景，将机器人恢复到站立姿态，状态清空
• step(action)：执行一步物理仿真，返回新状态、奖励、是否结束等信息
• compute_reward()：根据当前状态和动作计算奖励值
• get_observations()：组装19维观测向量

这样设计的好处是，你可以把训练环境替换成任何支持相同接口的自定义环境，算法层完全无感知。如果你想在上面测试SAC、TD3这类其他强化学习算法，也只需要把PPO训练器替换成对应算法的版本，环境代码一行都不用动。很多开源项目的问题是环境与算法强耦合，换个环境就要改训练逻辑，这次我把这个耦合点完整地切开了。

5.3 一个完整的复现命令序列

为了体现“可复现”，我用三个脚本就串起了从训练到部署的完整流程：

# 1. 训练策略，输出 policy.pt 与 normalization.json python train.py --config configs/duck_walk.yaml # 2. 导出策略为C头文件 python export.py --checkpoint logs/policy.pt --output deploy/model.h # 3. 在真机上运行(通过串口桥接预览状态) python serial_bridge.py --port /dev/ttyUSB0 --baud 115200

训练脚本还会自动启动TensorBoard日志记录，方便观察奖励曲线和各分项奖励的变化趋势。我在实际调试中习惯在命令里加上--record_video，每训练一定步数自动存一段仿真视频。这些视频是判断策略行为模式的最好素材，很多时候训练曲线看不出问题，但看视频一眼就能发现步态诡异。

5.4 关于“扩展成四足机器人”的一点点心得

开源架构的最终验证方式，是别人能不能把它迁移到不同的硬件上。我在仓库文档里额外放了一个示例分支，演示如何基于这套架构搭建一个简化的四足机器狗。主要改动只有三块：

1. 机器人抽象层中，把腿数从2扩展成4，每个腿增加侧摆关节自由度
2. 状态空间维度从19维增加到36维左右，包含四条腿的关节状态
3. 奖励函数里增加对角线步态的对步相位协调项

总体来讲，核心训练链路不需要动。这算是我这套架构比较满意的一个特性：不是为了一只鸭子造的轮子，而是为了一批小型足式机器人造的框架。

6. 训练与部署之外，我踩过的深坑和这次的经验沉淀

6.1 奖励函数里最阴险的问题是“奖励破解”

如果你训练过强化学习，一定会遇到奖励破解这种情况：策略找到了一个能让奖励函数输出极高分数的作弊方法，但行为本身完全不是你要的。我在这只鸭子上也遇到过，训练到中期，策略学会了“不断小幅度弹跳”——弹跳能保持速度跟踪指数奖励在高值区域，代价是机体姿态剧烈上下摆动，而姿态项权重又不足以压制这种行为。

最后我的解决办法是把动作平滑惩罚从0.01提到0.05，并且增加了一个“机体垂直加速度惩罚”项。这告诉大家，奖励函数设计不是一次定型的过程，而是反复迭代出来的。你观测曲线、看回调帧、对比训练视频，慢慢调整才能让策略行为真正符合直觉。

6.2 硬件层面，舵机控制频率和PWM分辨率不能含糊

很多人在MCU端直接把PWM频率设置为50Hz，也就是标准的20毫秒周期，同时控制周期也是20毫秒。看上去没问题，但我实测发现，如果控制周期刚好等于PWM周期，舵机在每个控制周期内接收到的脉宽更新与舵机内部命令刷新存在相位重合，会导致舵机一直在做小幅追踪抖动。

我的处理是把PWM频率设置为333Hz，MCU端的控制周期仍然保持20毫秒。这样PWM每3毫秒刷新一次，舵机的输入命令更新频率远高于控制周期，抖动问题就消失了。微型舵机的控制子周期低于标准值不会影响使用，实际响应速度反而更好。

6.3 整理这个开源项目的过程本身就是一次深度思考

架构分层看起来简单，但如果没有真实的硬件迭代和仿真训练经验，很难知道接口应该设计在哪一层。我在做第一版时，训练脚本和部署代码是重度耦合的，后来迁移到另一个尺寸的机器人时，光是适配环境就花了好几天。这次重构把所有硬编码参数踢到配置文件里，迁移新硬件只需要改YAML配置和抽象接口实现，三天流程缩短到几小时。

回到文章最开始说的那只电动玩具鸭。现在我桌面上放着两只鸭子：一只只能走直线的玩具鸭，以及一只可以在桌面上稳步前进、能响应速度指令、摔倒后尝试站起的强化学习小鸭子。后者并不完美，但它体现的是一整套从算法到硬件再到工程实践的完整闭环。这个过程里遇见的问题，非常值得记录和分享。

如果你们也要复现这个项目，我的建议是先不要在硬件上花太多钱，把3D打印件、舵机、主控加起来的成本控制在预算范围内以后，用一套最普通的配置把整个链路跑通，再逐步迭代外形和算法。先把仿真训练的流程跑起来，真机部署的事情一步一步来，很多所谓困难在系统跑通之后回头看，只是流程中一个普通的环节而已。