做机器人这行的朋友应该都有印象,双足机器人一直是门槛比较高的方向:机械结构要紧凑、关节要足够灵活、控制算法还得同时处理平衡和步态。以前大多数人会直接上ZMP(零力矩点)或者倒立摆模型,但这类方法非常依赖精准的动力学建模,稍微有一点装配误差、重心偏移,算法就“破功了”。这两年强化学习(RL)在机器人控制里火起来之后,事情开始变得不一样:你可以让机器人在仿真环境里自己“摔打”几百万次,学出一套能抗干扰的控制策略,再迁移到实体上。
今天就拿“微小型双足鸭形机器人系统”这个项目来做个深度拆解。它不只是一只外形讨喜的鸭子,而是一套完整的、由强化学习驱动的开源机器人系统:单板控制、串行总线舵机、轻量化结构、PPO训练框架,从仿真到实物全部打通。这套东西既能用来做教学、做算法验证,也能作为低成本双足平台进入各种比赛和科研场景。如果你正在研究双足步态、想迈入 sim-to-real(仿真到实物迁移)方向,或者只是被这种小型机器人吸引,想搞清楚它背后到底怎么运作,这篇内容应该都比较对胃口。
1. 项目整体定位与架构拆解:一台能自己学会走路的鸭子
1.1 这个迷你双足机器人系统的核心定位
先说这个项目的本质:它是在小型化、低成本的双足平台上,用强化学习替代传统模型控制的一次完整落地尝试。项目选择“鸭形”外观并不是单纯为了可爱,而是有工程上的考虑。鸭子的身体重心偏低、腿部短粗,这种结构天然比细长腿的人形机器人更适合小尺寸双足平衡,对舵机的扭矩和响应速度要求也相对宽松。微小型这个定语也很关键,意味着它的关节尺寸、舵机选型、控制板功耗都被限制在一个很小的范围内,整个结构的刚性和重心分配必须做得很精细。
从功能上看,这套系统能做什么?初期版本通常可以实现原地站立、抗扰动恢复、直线行走、转向,再进阶一些可以做到原地转圈、小步幅越障。对教育场景来说,它是最好的强化学习入门平台之一,因为学生可以直接看到算法输出的策略变成真实动作,而不是只在屏幕上看到一个奖励曲线。对研究人员来说,它可以作为一个低成本基线平台,用来验证新的奖励函数、新网络结构或者新的域随机化方案,不用像大型人形机器人那样动辄几十万成本并且还有很高安全风险。
这个项目的开源属性同样重要。所谓开源架构,意味着除了硬件图纸之外,还应该包括仿真环境配置、训练脚本、策略导出工具和底层驱动。用户拿到的不是一个只能按固定动作表演的玩具,而是一整套“自己也有能力去改”的系统。你可以替换掉默认的鸭子外壳,改装腿部结构,更改关节限位,或者把姿态传感器从单颗IMU升级成带视觉的模块,整套软件框架仍然可以复用。
1.2 架构选择:为什么采用强化学习而不是传统控制
这里需要花点篇幅解释一下“为什么是强化学习”这个问题。在传统双足控制方案里,工程师需要把机器人建模成多连杆系统,然后在线性化之后用LQR、MPC或者ZMP规划器生成步态。这个方法在结构对称、参数明确的机器人上效果很好,但一旦模型参数不准,比如电池电量变化导致输出电压降低、舵机实际扭矩曲线非线性、装配时某个关节多了半毫米间隙,整套算法就会变得非常脆弱,通常需要工程师在现场花大量时间调参才能再次站稳。
强化学习解决的是“隐式建模”的问题。比如PPO这类算法,让策略网络直接学习“状态到动作”的映射关系。网络在学习过程中会自己找到抗扰动的方式,不需要系统显式地知道精确的质心位置或腿部惯性矩。如果配合域随机化,训练时每次随机化机器人的质量分布、关节摩擦、舵机延迟等参数,学出来的策略自然具备较强的抗不确定性能力。这也是为什么现在很多高校和公司的足式机器人团队,都开始把RL作为默认方案。
不过,RL不是万能的。它最大的问题在于训练过程不透明、调试困难、计算资源需求高,而且纯数据驱动策略在遇到训练分布之外的极端情况时可能表现很差。因此,在实际项目中比较合理的做法是“传统为底、强化学习为主”:底层仍然用PID或闭环步进控制来驱动舵机到达目标角度,高层用RL策略输出动作目标。这个项目也是沿用了这个混合架构,把RL的灵活性和底层的稳定性结合了起来。
1.3 整体系统流程与数据闭环
把一个强化学习驱动的双足机器人系统拆开来看,它其实就是一个闭环优化系统,核心流程是四步:仿真采集、策略训练、模型导出、实物部署。仿真阶段,机器人模型被导入到物理引擎里,每一幕(episode)开始时重置姿态,然后从随机初始状态出发,策略网络通过观测机器人状态输出动作,物理引擎计算出下一步状态,同时根据奖励函数给出反馈。训练阶段,PPO算法利用这些轨迹数据更新策略网络的参数,不断优化累计奖励。模型导出阶段,把训练好的PyTorch网络权重转换为轻量部署格式,比如ONNX、TensorFlow Lite或者直接转为C数组。实物部署阶段,控制板上的推理引擎接收IMU数据和关节编码器数据,经过归一化处理后送入网络,得到动作信号,再经过映射转换为舵机角度指令。
这个闭环里最容易被忽视的是“数据格式一致性”。在仿真里,观察值包括机身倾角、倾角速度、各关节角度、各关节角速度;在实物上,如果IMU安装方向不同、编码器零位不同,同一个状态向量含义就不一样。很多迁移失败的项目都死在这一步。所以,优秀的开源项目从第一天起就会规定好传感器坐标系、关节零位约定和数据平滑方式,让仿真和实物的数据流严格对齐。这也是我评估一个开源机器人项目成熟度的关键指标。
2. 强化学习训练框架详解:算法选型与仿真环境搭建
2.1 算法选型对比:PPO为什么是这个小机器人的主力
现在强化学习算法很多,做足式控制时最常被拿出来对比的是PPO、SAC、TD3,以及被热炒的IQL(离线强化学习)和基于模型的强化学习。对于这个微小型双足鸭形机器人系统,我推荐的默认选择是PPO,理由可以展开说一说。
PPO(Proximal Policy Optimization,近端策略优化)是一种基于策略梯度的在线强化学习算法,核心思想是在每次更新时限制新旧策略的差异程度,防止更新步长过大导致训练崩溃。它实现简单、超参数鲁棒性相对好,而且对CPU多进程并行采样非常友好。由于那双足鸭子的动作空间维度并不高(通常是8到12个关节),状态空间也就是几十维,PPO完全够用。
相比之下,SAC(Soft Actor-Critic)在样本效率上通常优于PPO,但由于它包含熵正则项,在训练初期容易出现探索过猛的问题,而且Q网络的收敛性对超参数更敏感。TD3对连续控制本身是不错的,但它偏保守,更新机制复杂,调参成本更高。IQL这类离线强化学习算法通常需要先有一批高质量数据,适合数据受限或不允许在线探索的场景,对于一台可以在仿真里无限试错的鸭子来说意义不大。基于模型的强化学习理论上有更高的样本效率,但训练流程复杂、更依赖精确的动力学模型,在这个项目里收益不明显。所以,开源项目选择PPO作为主算法是一个非常合理、接地气、且易于扩展的决定。
| 算法 | 样本效率 | 调参难度 | 在线采样要求 | 适合当前场景吗 |
|---|---|---|---|---|
| PPO | 中 | 低 | 需要 | 非常适合 |
| SAC | 高 | 中 | 需要 | 可以,但需要细致调参 |
| TD3 | 中高 | 中高 | 需要 | 可作为备选 |
| IQL | 高(离线) | 中 | 不需要 | 不适合作为初始方案 |
| 基于模型RL | 高 | 高 | 需要 | 复杂,性价比低 |
还有一个原因是社区生态。PPO几乎在所有主流RL框架中都有高度优化过的实现,比如Stable-Baselines3、RLlib、CleanRL。对开源项目来说,选择PPO可以大幅降低用户的二次开发成本。
2.2 仿真环境怎么搭:物理引擎、模型导入和状态观测
训练一套双足策略,第一步不是写算法,而是搭一个能跑得动的仿真环境。比较常见的选择有MuJoCo、PyBullet、Gazebo和Isaac Gym。对这个微小型鸭形机器人,我需要根据它的规模来选。Isaac Gym强在GPU并行大规模训练,适合一次跑几千个并行环境,但对硬件要求高,配置也复杂。Gazebo适合做ROS2集成和传感器仿真,但物理引擎的稳定性和训练速度都一般。MuJoCo经过DeepMind优化之后免费开放,物理仿真精度高、速度快、模型描述简洁,是目前学术界做足式RL用的最多的仿真环境。PyBullet则胜在纯Python安装方便、可视化简单,非常适合新手快速验证训练配置。
实际项目里,我自己的习惯是先用PyBullet或MuJoCo跑通环境逻辑,再根据训练规模决定是否需要迁移到Isaac Gym。对鸭子这样的简单结构,MuJoCo在CPU上跑几百个并行环境已经很快,完全没有必要上GPU并行框架。
在仿真环境里,机器人的URDF/MJCF模型文件是基础。这里面要特别注意关节限位、摩擦力参数和碰撞网格的导入。如果仿真模型里关节的限位设置和实物不一致,训练出来的策略很可能让舵机被“逼”到物理极限,轻则堵转,重则烧舵机。另一个常见的坑是碰撞网格过于精细,导致仿真速度极慢。对于这种小型机器人,我通常会把碰撞体简化成球体和长方体组合,只要能覆盖主要外形,没必要用精密的外壳网格。
状态观测(observation)的设计对训练收敛速度影响极大。默认观测向量通常包括:机身的roll和pitch角度及角速度、每个关节的当前角度和角速度、上一步动作值、脚底接触开关状态。这些信息加在一起差不多40到60维。有一点容易被忽略:不应该把绝对的yaw角度放进观测,因为机器人只需要知道相对朝向,并不关心自己面朝哪个绝对方向。如果强行加进去,策略会试图记住一些绝对位置信息,在实物上反而会造成泛化性能下降。
动作空间的设计上,最常用的是关节目标位置(position target)。也就是说,策略网络输出的不是舵机的PWM值,而是“这个关节下一步应该转到哪个角度”。底层闭环控制器负责用PID把当前角度平滑地送到目标位置。这种设计的好处是,低层控制器可以独立调试,策略输出的动作天然就是平滑且有物理含义的角度指令。在实际部署时,输出延迟和底层跟踪效果是影响迁移成功率的重要因素,这一点我在后面会详细说。
2.3 奖励函数设计:让鸭子自己学会平衡和前进
如果说仿真环境是训练的地基,那奖励函数就是训练的“指挥棒”。奖励设计不合理,策略就会展现出各种令人啼笑皆非的“作弊行为”,比如原地打转获得正奖励、疯狂抖动关节换取轻微前进、甚至降低身体接触地面来“装死”。对于双足行走,奖励函数通常可以拆成五个部分。
姿态保持奖励:希望机身尽量保持直立,通常用当前roll/pitch与目标角度的差值来构造。常见形式是r_posture = exp(-α * (|roll|^2 + |pitch|^2)),α是一个可调系数。这个指数形式的好处是自然平滑,偏差小时奖励接近1,偏差大到一定程度时迅速趋向0,能让训练早期更快地收敛到直立姿态。但要注意,α不宜过大,否则网络对微小倾斜过度敏感,走路时会显得僵硬。
前进速度奖励:希望机器人有目的地移动,所以会计算机身前进方向上的实际速度与目标速度的偏差。比如r_vel = exp(-β * (v_target - v_actual)^2)。这比直接给一个“前进就+1”的离散奖励更平滑,也支持连续速度指令。转向则通过偏航角速度的误差来驱动。
能耗惩罚:不希望动作过于剧烈,否则会对舵机造成很大压力且姿态容易失控。我一般会用r_energy = -γ * Σ(τ_i * ω_i)或者r_action = -δ * ||a_t - a_{t-1}||^2(动作变化量惩罚)。前者约束力矩,后者约束动作平滑度,两者可以同时使用。动作变化量惩罚尤其重要,因为策略如果直接输出剧烈抖动的角度指令,实机看起来就像抽风,很容易把齿轮打坏。
朝向奖励:如果机器人被要求走直线,那么需要惩罚朝向和前进方向的夹角过大。这个奖励不需要一直很强,只在机器人明显“跑偏”时起作用。
存活奖励与终止条件:每一步只要还没跌倒就给予一个小正奖励,一旦机身倾角超过阈值或者脚底接触异常则终止当前幕。这个设计会让策略自己学习到“保持不跌倒”是长期最优目标。
这些奖励项要按权重叠加起来,形成总奖励R = w1*r_posture + w2*r_vel + w3*r_energy + w4*r_yaw + w5*r_survive。权重的设置需要反复实验。一个比较省力的初始方案是:先把姿态和前进权重设高,其余项设得非常低甚至为零,跑通之后再加惩罚项,这样可以避免多个目标互相干扰导致训练不收敛。我训练这种双足平台的经验是,大概需要50到200万步采样才能获得一个可用的行走策略,训练时间在单张主流GPU上大约1到3小时,CPU多核并行可能要多花几倍时间。
2.4 域随机化:从仿真走向实物的关键一步
现在可以聊sim-to-real了。直接把仿真里训练好的策略搬到实物上,几乎注定失败,因为仿真环境永远无法精确复现实物特性。域随机化(Domain Randomization, DR)是解决这个问题的有效手段之一。它的思路很简单:别让策略只见过“一个世界”,把它扔进“一堆世界”里训练,每次重置环境参数都随机变化。这样策略只能学会一套在各种条件下都通用的策略,而不会过度拟合某一组物理参数。
对这台鸭形机器人,需要随机化的参数有哪些?第一是电机相关,包括舵机的最大扭矩、响应延迟、死区范围;第二是质量相关,机身重量、重心偏移方向;第三是接触相关,脚底摩擦系数、碰撞恢复系数;第四是传感器噪声,IMU的角度噪声、关节编码器的量化误差。把这些参数在每个训练幕开始时都从某个分布里抽样,让策略见过足够多变的“世界”之后,再拿到现实世界里去验证,成功率会高很多。
域随机化策略与之前提到的奖励函数设计是一体的。奖励告诉机器人“什么状态是好的”,域随机化告诉机器人“真实世界有很多种可能”。两者配合好,迁移成功率才有保障。实际测试中我发现,摩擦系数的随机化范围千万别设得过大,否则策略会学得太保守,宁可站在原地都不敢迈步,看起来就像一只被冻住的鸭子。合理做法是先从小范围开始,逐步扩大,以实物表现为准来调整。
3. 实物平台搭建与软硬件适配:从仿真模型到真实鸭子
3.1 机械结构设计要点:短腿、重心与舵机选型
硬件层面前期设计是否合理,直接决定了后续训练和部署是否顺利。这个鸭形机器人的两条腿一般每条设计4到5个自由度,分别是髋关节(横滚和俯仰)、膝关节(俯仰)、踝关节(横滚和俯仰),这样每条腿4到6个自由度,整机8到12个自由度。对微小型平台,自由度太少步态会很僵硬,太多则舵机数量增多、重量上升、电池负担加重。用4个自由度每条腿是比较均衡的选择。
重心设计上,鸭形结构有一个天然优势:尾巴可以做成配重。仿真里常见的做法是把电池放在身体后侧偏下位置,让重心尽量落在两脚支撑多边形中心附近。如果重心太靠前,行走时就会有一股向前栽倒的趋势,策略需要持续输出较大的补偿力矩来维持平衡,既费电又容易超限。在结构上,我建议把机身的扁平宽度适当加大,这样横向抗扰动能力更强,训练时摔倒概率更低。
舵机选型是最影响成本也是最多新手容易犯错的环节。很多迷你机器人项目会用9g或20g的微型舵机,但这类舵机扭矩大都在0.4到1.2 kg·cm之间,带载能力弱、齿轮强度也不足,做摆臂可以,做下肢承载基本是走几步就抖舵,换成金属齿轮大扭矩舵机又往往超重。算一笔账:假设鸭子重量控制在400g左右,每条腿承担200g,髋关节需要支撑整条腿摆动和机身倾斜产生的力矩。粗略估算,髋关节所需的峰值扭矩通常在3到6 kg·cm,额定连续扭矩在1.5到3 kg·cm左右,所以选择标称4 kg·cm左右、金属齿轮、带速度反馈或位置反馈的舵机比较稳妥。
硬件总线的选择也值得说。现在很多微小型机器人开始使用串行总线舵机,比如SCS、LX系列或者国人用得很多的OpenRB、Feetech产品。串行舵机的好处是只需一根信号线就可以串联控制所有关节,反馈角度、电压、温度信息,并且支持设置PID参数,比PWM舵机的排线简洁得多。这样做还降低了整机线束重量和故障点。但如果预算更紧,PWM舵机配一个舵机驱动板也能用,只是无法方便地获得关节角速度反馈,这在训练去迁移时是个劣势。因为没有真实关节速度反馈,状态观测就会缺一组关键信息,策略的稳定性会受影响。
3.2 主控方案与底层控制链路
主控方面,推荐选择STM32F4/F7系列单片机、ESP32或者树莓派Pico级别的芯片。具体选哪个,取决于算力需求和开发效率。如果只是弹性部署一个轻量级MLP策略网络,输出8个关节角度,那么STM32F405配合一个TFLite Micro或者直接自写矩阵乘法就足够,主频168MHz完全能跑。ESP32的好处是有WiFi和蓝牙,可以直接无线调试、无线改参数,对快速迭代非常方便。树莓派Pico则胜在极低成本和MicroPython生态,但推理性能相对弱一些,比较适合做原型验证而不是最终部署。
控制链路的时序设计要特别重视。整个控制循环大致是这样的:首先读取IMU数据(通过SPI或I2C),然后读取所有串行舵机的当前角度和速度,等待数据稳定;接着把状态向量归一化后送入神经网络做推理;最后把输出的关节目标角度映射成舵机指令,通过串行总线发出,同时等待下一次循环。这个循环的频率对机器人稳定性至关重要。步态控制通常要求控制频率不低于50Hz,也就是20ms一个周期;如果条件允许,100Hz更好。频率再低的话,姿态信息过期太久,一个简单的蹬腿动作都可能引发振荡。
IMU的数据质量怎么处理也是一门学问。低成本IMU原始数据往往混杂大量噪声和温漂,直接用它的角度值来做状态观测,策略基本会学到一个“看到的世界在抖动”的模型。正确的做法是先用一阶互补滤波或Madgwick算法来融合陀螺仪与加速度计数据。互补滤波的好处是计算量小、在STM32上也很容易跑,Madgwick则能够输出四元数,姿态解算更稳定。注意:IMU安装位置也有讲究,一般装在机身几何中心附近,与质心偏差越小,姿态数据的解释性就越好。
3.3 小型平台的动力与电源系统
小型双足机器人最容易出现的现象是,训练时奖励曲线稳步上升,一上实物就原地抖,动作看起来有气无力。这时候很大概率不是算法问题,而是电源系统垮了。微小型平台使用3.7V锂电池或2S LIPO电池,当六个舵机同时启动时,瞬时电流可能冲到3到5A,如果电池内阻大、供电线细,电压会被拉到很低的水平,舵机得不到足够电压就会扭矩不足、响应变慢。
所以,电源设计上一定要做好局部闭环:主控单独稳压,舵机总线使用大容量电容储能,再给舵机单独供电。一个实操技巧是,在舵机电源入口并接一颗470uF到1000uF的电解电容,或者用4颗100uF的MLCC并联,可以显著减小瞬时压降。另外,导线要尽量加粗,至少使用AWG22以上的硅胶线,而不是跳线排针那种细线。电池电量管理同样要注意,策略训练时往往默认电压是恒定的,但实物上电量从4.2V降到3.7V的过程中,舵机特性会发生明显变化。更稳的做法是让策略在观测向量中加入当前电压值,或者在控制板上做电压补偿。
4. 从训练到实物部署全流程:实操细节与常见问题速查
4.1 模型导出与实机部署的流程参考
训练阶段的终点是拿到一个sac_actor.pt或者best_model.zip,这时候要做的是把PyTorch模型导出为部署格式,并嵌入控制板。这里给出一个可以直接参考的流程。
第一步,输出为ONNX或TFLite格式。如果是PyTorch训练的PPO,导出时可以选择把整个Actor网络导出,也可以只导出权重矩阵,然后在单片机上用C语言手写矩阵乘法推理。对小型双足机器人来说,策略网络通常是两层或三层的MLP,每层64或128个神经元,总参数量在1万到5万之间。这个规模在STM32F405上跑一次推理大约需要0.5到2ms,完全来得及。
第二步,浮点转定点或量化。为了在单片机上稳定运行,通常把浮点权重缩放到int16或者int8范围。量化之后模型体积更小、推理更快,但精度会有损失。对双足步态这种对输入噪声本身就有一定鲁棒性的任务,量化损失影响通常不大,不过务必要在实物测试前做一遍量化前后一致性验证。
第三步,编写部署推理代码。主要完成三个功能:加载权重表、实现前向计算、把输入输出进行归一化和反归一化。很多开源项目会直接提供一个可以被C调用的推理C文件,里面包含固定的输入层尺寸和输出层尺寸,用户只需要确认神经网络的维度即可。
第四步,实机联调。通常建议先用悬挂绳把机器人吊起来,让脚部刚刚能接触地面,这样可以安全地测试策略是否会让腿部按预期摆动。确认步态正常后,再尝试自由站立。这一步看起来简单,实际上能避免大量因策略输出异常导致的舵机损坏。
部署过程中有一个我反复踩过的坑:关节方向约定不一致。在仿真里定义的正方向可能和实物舵机安装方向相反,如果不加修正直接在实物上推理,策略可能会让鸭子往相反方向蹬腿,结果就是机器人越走越往后栽。所以部署之前,一定要在仿真和实物两边都把关节角度零位定义为机器人自然站立时的姿态,然后对着舵机逐一确认旋转方向。
4.2 常见问题速查表与解决思路
下面这份速查表来自我自己测试这类小双足平台的经历,写的都是大概率会遇到的共性问题,可以直接抄作业自查。
| 现象 | 可能原因 | 排查思路与解决办法 |
|---|---|---|
| 仿真里能走,实物上刚站起来就倒 | sim-to-real差距太大 | 增大域随机化强度,检查IMU方向,调整关节零位,降低步幅并提高控制频率 |
| 站立时高频抖动 | 控制频率太低或PID参数不合理 | 提高控制频率到100Hz以上,适当增加舵机PID的阻尼项,检查舵机死区 |
| 策略输出动作剧烈 | 动作平滑惩罚不够 | 增加动作变化量的惩罚项,在输出端加低通滤波或指数平滑 |
| 越走越偏,无法保持直线 | 转向奖励权重不足或结构重心偏移 | 调整重心配重,加大yaw误差惩罚,检查两条腿机械长度是否一致 |
| 脚底接触地面时姿态突变 | 踝关节刚性不足或脚底摩擦力模型不准 | 增加踝关节刚度,更换高摩擦脚垫,摩擦系数的仿真范围进一步增大 |
| 电池掉电快 | 动作过于激进,舵机堵转频繁 | 检查关节限位是否设置在物理极限附近,增加能耗惩罚,适当降低步态频率 |
| 推理延迟高,动作有滞后感 | 主控性能不足或传感器采集串行化过于耗时 | 先把IMU和舵机读取改成DMA方式,再把神经网络推理函数做耗时压测 |
还有一些小技巧对提高迁移成功率帮助很大。比如,训练时给观测向量添加一个小的高斯噪声,相当于正则化,可以提高策略对传感器噪声的鲁棒性。又比如,部署到实物前,先在仿真里做“摔倒恢复测试”:把机器人初始姿态设为随机倾斜角度,比如20到30度,让它学会从倾斜状态自己站稳。这样实物上一个推力过来,鸭子就不会直接摔懵。
4.3 一些个人积累的经验体会
做小型双足机器人最折磨人的环节通常不是训练本身,而是视觉上“看起来没问题”但实物上“就是不行”的调试循环。训练出的策略在仿真里完美行走,搬到实物上只要有一点装配间隙,关节的响应就和仿真差了一截。这时候我通常会先检查实物硬件的机械基准,再怀疑算法。很多初学者恰恰反着来,一失败就跑去调算法参数,结果调来调去还是不行,最后发现是舵机零位偏了或者IMU装反了。
还有一个我在项目里反复验证有效的经验:把控制频率和舵机的真实响应速度匹配好。这套小鸭子用的串行舵机内部位置环刷新率通常也就是100到200Hz,而它的位置环又是芯片内部算法算出来的,实际到达目标位置需要几十毫秒。如果上层控制频率太高,策略每10ms就下发一个新目标,舵机根本追不上,反而造成相位滞后,导致机器人越控制越糟糕。比较合理的设置是上层控制频率50到100Hz,同时让底层PID有足够时间把舵机带到目标位置。在仿真里不需要考虑这个问题,因为仿真中电机没有“追不上”的概念,但在实物上是实打实的性能瓶颈。
另外也想特别提一下开源项目的价值。这类鸭形机器人之所以适合学习,除了成本低之外,还因为它提供了完整的可复现路径:仿真配置、训练脚本、硬件图纸、部署代码都是开放的。你拿到之后可以把训练过程中的每一步都复跑一遍,再逐步修改,而不是拿到一堆理论文档或未经验证的草稿。从入门的角度来说,把一个已有的开源RL机器人平台跑通,再把自己的实现加进去做对比,比从零造轮子要高效得多。
这套系统后续可以扩展的方向也很多,比如加一个摄像头做视觉目标跟随,或者把单鸭改成双鸭协作搬运,又或者更换更强大的训练算法来做多任务学习。但不管怎么扩展,底层那套“仿真训练-域随机化-实物部署”的闭环框架是不变的。如果你也正在折腾双足机器人,希望这篇拆解能帮你少走几个弯路。