1. 项目缘起与整体设计思路1.1 为什么选择双足鸭形这个形态第一次看到“微小型双足鸭形机器人”这个组合的时候我脑子里冒出来的第一个念头是为什么是鸭子做双足机器人大家第一反应要么是类人形态要么是鸵鸟、袋鼠这种跑跳型。鸭形其实是一个被低估的选择。从机械结构上讲鸭子的身体重心天然靠后、腿部相对短粗、步幅小但步频高这种形态对微小型机器人特别友好。微小型意味着舵机扭矩有限、机身空间紧张、电池容量受限如果硬上类人形态光是保持直立就要消耗大量算力去维持平衡。而鸭形步态本身容错率高重心低即便控制精度差一点也不至于一摔就散架。我实际拆过几款市面上的微型双足套件类人形态的机器人在低速行走时抖动非常明显因为踝关节需要持续做微调来对抗重力矩。鸭形结构可以把大部分重量压在髋部膝关节和踝关节的负担小很多。这个设计取舍背后的逻辑就是用形态换控制余量把有限的算力留给强化学习策略本身而不是浪费在底层平衡维持上。另一个考量是开源社区的传播性。类人机器人项目已经卷得不行了各种开源方案满天飞新人想找一个有辨识度、又能快速跑起来的项目并不容易。鸭形自带话题性同时结构简单3D打印件少装配门槛低特别适合作为强化学习入门到进阶的实战载体。1.2 强化学习为什么比传统控制更适合这个项目传统双足控制走的是ZMP零力矩点、MPC模型预测控制这条路需要精确的动力学模型。你得知道每个连杆的质量、惯量、摩擦系数还得在线求解优化问题。对于微小型机器人来说算力根本扛不住MPC的实时求解而且3D打印件的公差、舵机的回差、地面的微小变化都会让模型失配。强化学习的思路完全不同。它不要求你精确建模而是让机器人在仿真里反复试错自己学出一套策略。你只需要定义好状态空间、动作空间和奖励函数剩下的交给算法去磨。对于微小型双足这种模型不确定性强、算力受限的场景RL的优势非常明显。但这里有个关键点Sim2Real。仿真里学出来的策略直接搬到真机上往往会崩。原因很多比如舵机的响应延迟、传感器的噪声、地面的摩擦差异、机身重量的微小偏差。这个项目在Sim2Real上做了不少工程上的处理后面我会详细拆解。1.3 为什么用Rust而不是Python这是很多人看到这个项目的第一反应强化学习不都是用Python吗PyTorch、TensorFlow、JAX生态全在Python这边。用Rust做RL是不是自找麻烦我一开始也这么想但仔细琢磨之后发现这个选择其实很有道理。Python在训练阶段确实无敌但部署到真机上就是另一回事了。微小型机器人的主控往往是一块性能有限的嵌入式板子跑Python解释器本身就占资源再加上GIL的限制实时性很难保证。Rust没有GC内存占用可控编译后直接跑机器码延迟稳定在微秒级。更重要的是Rust的类型系统和所有权模型能在编译期就帮你排除掉大量并发和内存安全问题。机器人控制代码最怕的就是数据竞争和野指针一旦在运行中出问题机器人直接摔给你看。Rust把这些风险前置到了编译阶段对于需要长时间稳定运行的机器人来说这个价值非常大。当然训练阶段还是可以用Python。这个项目的架构是Python负责训练和策略导出Rust负责推理和真机控制。两者之间通过ONNX或者自定义的权重格式做桥接。这样既享受了Python的生态又保证了部署端的性能。2. 核心架构拆解与关键技术选型2.1 整体软件架构分层这个项目的软件架构我把它分成四层从下到上依次是硬件抽象层、实时控制层、策略推理层、训练与仿真层。硬件抽象层负责跟舵机、IMU、电池管理这些外设打交道。Rust这边用的是embedded-hal这套trait好处是换硬件平台的时候上层代码基本不用动。比如你从STM32换到ESP32只需要重新实现一遍HAL控制逻辑和策略推理完全不用改。实时控制层跑的是一个固定频率的控制循环典型值是500Hz到1kHz。这一层负责读取IMU数据、做姿态解算、执行策略网络输出的动作、下发舵机指令。所有操作都是确定性的不允许有动态内存分配避免不可预测的延迟。策略推理层加载训练好的神经网络权重做前向推理。这里用的是ONNX Runtime的Rust绑定或者自己手写一个轻量级的推理引擎。网络本身很小输入是IMU和关节角度的历史窗口输出是目标关节角度或者关节力矩。训练与仿真层就是Python的地盘了。用PyBullet或者MuJoCo搭仿真环境用Stable-Baselines3或者自己写的PPO实现来训练。训练完之后把策略导出成ONNX再通过一个转换脚本变成Rust能读的格式。2.2 状态空间与动作空间设计状态空间的设计直接决定了策略能不能学到有用的东西。这个项目里状态向量大概包含以下几类信息机身姿态roll、pitch、yaw的角度和角速度来自IMU关节状态左右髋、膝、踝的角度和角速度历史信息过去若干帧的姿态和关节状态用来给策略提供时序信息相位信息一个周期性的时钟信号帮助策略学习步态节律动作空间有两种选择位置控制和力矩控制。位置控制简单但灵活性差力矩控制更接近生物的运动方式但对舵机要求高。微小型机器人用的舵机大多是位置伺服所以这个项目默认用的是目标关节角度作为动作输出但预留了力矩控制的接口。奖励函数的设计是RL里最玄学的部分。这个项目的奖励大概由这几项组成前进速度奖励、姿态保持奖励、能量消耗惩罚、关节平滑度惩罚、摔倒终止惩罚。每一项的权重都需要反复调调不好就会出现机器人原地抖腿或者直接躺平的情况。2.3 Sim2Real的关键技术处理Sim2Real是这个项目最核心的工程难点。仿真里跑得再好真机上一步就摔这种情况太常见了。项目里用了几个手段来缩小差距域随机化在训练的时候随机化地面的摩擦系数、机身的质量分布、舵机的响应延迟、IMU的噪声水平。这样策略见多识广到了真机上遇到没见过的参数也能扛一扛。执行器建模仿真里的舵机不能简单当成理想的位置伺服。要加入延迟、死区、回差、最大速度限制。这些参数可以通过实验测量也可以在训练时随机化。观测历史真机上的IMU噪声很大单帧观测不可靠。用多帧历史做输入相当于给策略一个低通滤波的效果能显著提升鲁棒性。策略平滑训练时加一个动作变化率的惩罚项让策略输出的动作尽量平滑。真机上舵机最怕的就是高频抖动不仅耗电还容易损坏齿轮。3. 实操过程与核心环节实现3.1 仿真环境搭建与训练流程先说仿真环境。这个项目默认用的是PyBullet因为它是开源的安装简单跟Python的集成也好。MuJoCo精度更高但配置起来麻烦一些。对于入门来说PyBullet足够了。搭建环境的步骤大概是这样的import pybullet as p import pybullet_data # 连接物理引擎 physics_client p.connect(p.GUI) p.setAdditionalSearchPath(pybullet_data.getDataPath()) # 加载地面和机器人URDF plane_id p.loadURDF(plane.urdf) robot_id p.loadURDF(duck_robot.urdf, basePosition[0, 0, 0.15]) # 设置物理参数 p.setGravity(0, 0, -9.81) p.setTimeStep(1.0 / 500.0) # 500Hz仿真步长URDF文件是机器人的描述文件里面定义了连杆、关节、质量、惯量、碰撞体这些信息。对于鸭形机器人URDF的编写有几个坑关节的旋转轴方向要跟实际舵机的安装方向一致否则仿真里走得好好的真机上直接反关节。碰撞体的形状要尽量简化用胶囊体或者盒子代替复杂的网格不然仿真速度会慢到没法训练。训练用的是PPO算法这是目前连续控制任务里最稳的选择。相比SAC和TD3PPO对超参数没那么敏感训练过程也更稳定。网络结构用的是两层MLP每层256个神经元激活函数用Tanh。输入是状态向量输出是动作的均值和标准差。训练的超参数大概是这样参数取值说明学习率3e-4经典取值稳定批量大小4096根据显存调整折扣因子0.99关注长期回报GAE lambda0.95偏差方差权衡裁剪范围0.2PPO的核心参数训练步数5e6-1e7视任务复杂度训练过程中要盯着几个指标平均回报、策略熵、价值函数损失。平均回报上升说明策略在进步策略熵下降说明策略在收敛价值函数损失如果一直很大说明网络容量不够或者学习率太高。3.2 策略导出与Rust端推理训练完之后把PyTorch的模型导出成ONNX格式import torch import torch.onnx # 假设policy是训练好的策略网络 dummy_input torch.randn(1, state_dim) torch.onnx.export( policy, dummy_input, duck_policy.onnx, input_names[state], output_names[action], dynamic_axes{state: {0: batch}, action: {0: batch}} )Rust这边用ort这个crate来加载ONNX模型use ort::{Session, SessionBuilder, Value}; let session SessionBuilder::new()? .with_optimization_level(ort::GraphOptimizationLevel::Level3)? .with_model_from_file(duck_policy.onnx)?; let input Value::from_array(session.allocator(), state_array)?; let outputs session.run(vec![input])?; let action outputs[0].try_extract::f32()?;这里有个细节要注意ONNX Runtime的版本要跟导出时的opset版本匹配不然会报错。我一般导出的时候指定opset_version11兼容性最好。推理频率要跟控制循环对齐。如果控制循环是500Hz推理也要跑到500Hz。ONNX Runtime在ARM上跑一个小MLP单次推理大概在几百微秒完全来得及。如果实在跑不动可以降频到250Hz或者把网络量化成int8。3.3 真机部署与调试真机部署的第一步是校准。每个舵机的中位、方向、行程范围都要标定。IMU的零偏也要校准不然机器人会以为自己在倾斜然后拼命往一边倒。校准完之后先做静态测试把机器人架起来让腿悬空跑策略看关节动作是否合理。如果动作幅度特别大或者频率特别高说明策略有问题可能是仿真和真机的观测分布差太多。然后做动态测试放到地面上用手扶着看它能不能迈步。这个阶段最容易出现的问题是机器人往前扑或者往后仰。往前扑一般是重心太靠前往后仰是重心太靠后。可以通过调整机身的配重或者修改URDF里的质心位置来解决。最后是自主行走测试。一开始在平整的地面上跑然后逐渐增加难度地毯、斜坡、小障碍物。每次失败都要记录下当时的观测和动作回头分析是哪个环节出了问题。4. 常见问题与排查技巧实录4.1 仿真训练不收敛怎么办这是新手最常遇到的问题。训练了几百万步平均回报还是原地踏步或者忽上忽下。排查思路大概是这样的先看奖励函数。奖励函数设计得太复杂各项权重不平衡策略会不知道该优化什么。建议先用最简单的奖励前进速度减去能量消耗其他项先不加。等策略能走起来了再逐步加姿态惩罚、平滑惩罚这些。再看观测归一化。神经网络的输入最好归一化到[-1, 1]或者[0, 1]之间。如果IMU的角度是弧度制范围在[-π, π]直接喂给网络梯度会很不稳定。用运行均值方差做归一化效果立竿见影。还有可能是网络太小。两层256的MLP对于简单步态够了但如果状态维度很高或者任务很复杂可能需要加到512甚至1024。不过网络越大训练越慢要权衡。最后检查仿真步长。步长太大物理仿真会不稳定机器人会抖。步长太小训练速度慢。500Hz是个比较平衡的选择。4.2 Sim2Real迁移后机器人抖动严重仿真里走得稳稳当当真机上抖得像筛糠这个问题太典型了。原因通常是仿真里的舵机太理想没有延迟和回差。解决办法是在仿真里给舵机加模型。最简单的做法是加一个一阶延迟环节class ServoModel: def __init__(self, delay0.02, max_speed10.0): self.delay delay self.max_speed max_speed self.prev_target 0.0 self.prev_output 0.0 def step(self, target, dt): # 一阶延迟 alpha dt / (self.delay dt) output self.prev_output alpha * (target - self.prev_output) # 速度限制 max_delta self.max_speed * dt delta output - self.prev_output if abs(delta) max_delta: output self.prev_output max_delta * (1 if delta 0 else -1) self.prev_output output return output把这个模型加到仿真循环里策略就会学会适应有延迟的执行器迁移到真机上抖动会小很多。另外策略输出的动作可以做低通滤波。但滤波会引入相位滞后滤波太狠机器人会反应迟钝。我一般用一阶低通截止频率设在20Hz左右能滤掉大部分高频抖动又不至于影响步态。4.3 机器人走几步就摔倒摔倒的原因很多按概率从高到低排重心位置不对、关节零位没校准、地面摩擦系数差异大、策略过拟合仿真环境。重心位置是最容易被忽略的。仿真里的URDF质心是理想值真机上电池、主控板、舵机的实际重量分布可能跟仿真差很多。解决办法是在真机上做配重实验找到实际的重心位置然后修改URDF里的质心参数重新训练。关节零位校准也很关键。如果某个关节的零位偏了5度策略输出的动作就会整体偏移机器人会往一边歪。校准的时候要用高精度的角度传感器或者用机械限位做参考。地面摩擦系数的影响在光滑地板上特别明显。仿真里默认的摩擦系数是1.0实际地板可能只有0.3。训练的时候把摩擦系数随机化到[0.2, 1.5]之间策略就能适应不同的地面。4.4 常见问题速查表问题现象可能原因排查方法解决措施训练不收敛奖励函数设计不合理打印各项奖励的数值简化奖励逐步增加训练不收敛观测未归一化检查观测数值范围加运行均值方差归一化训练不收敛学习率太大观察策略熵变化降低学习率到1e-4真机抖动舵机延迟未建模对比仿真和真机动作加执行器延迟模型真机抖动策略输出高频变化打印动作序列加动作平滑惩罚走几步摔倒重心位置偏差做配重实验修改URDF质心走几步摔倒关节零位偏移用角度传感器测量重新校准零位走几步摔倒地面摩擦差异在不同地面测试域随机化摩擦系数推理延迟大网络太大测单次推理时间量化或裁剪网络推理延迟大ONNX Runtime配置不当检查优化级别开启Level3优化5. 工具链与开发环境配置5.1 Rust开发环境搭建Rust的安装很简单一条命令搞定curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh安装完之后把~/.cargo/bin加到PATH里。然后装几个常用的工具rustup component add rustfmt clippy cargo install cargo-watch cargo-expandrustfmt用来格式化代码clippy做静态检查cargo-watch在文件变化时自动重新编译cargo-expand用来展开宏调试的时候很有用。嵌入式开发的话还要装交叉编译工具链。比如目标是STM32就装thumbv7em-none-eabihfrustup target add thumbv7em-none-eabihf然后配置.cargo/config.toml指定链接器和运行器[target.thumbv7em-none-eabihf] runner probe-run --chip STM32F407 rustflags [-C, link-arg-Tlink.x] [build] target thumbv7em-none-eabihf5.2 Python训练环境配置Python这边建议用conda建一个独立环境避免跟系统Python冲突conda create -n duck-rl python3.10 conda activate duck-rl pip install torch pybullet stable-baselines3 onnx onnxruntimePyTorch装CPU版就够了训练这个小网络不需要GPU。如果要用GPU加速装CUDA版但要注意跟驱动版本匹配。PyBullet的安装有时候会出问题特别是在Windows上。如果pip install pybullet失败可以试试从源码编译或者用conda装conda install -c conda-forge pybullet5.3 硬件选型建议微小型双足机器人的硬件选型有几个关键点舵机、主控、IMU、电源。舵机方面推荐用数字舵机比如Dynamixel XL330或者Feetech的STS系列。数字舵机响应快、精度高、支持总线通信比模拟舵机好太多。扭矩方面鸭形机器人每个关节大概需要0.5到1.5 kg·cm的扭矩具体看机身重量和腿长。主控推荐用STM32F4或者ESP32-S3。STM32F4的定时器资源丰富适合做多路PWM控制ESP32-S3自带WiFi和蓝牙调试方便。如果算力要求高可以上树莓派Pico或者更高级的板子。IMU推荐用BNO085或者ICM-20948这两款都带硬件融合直接输出四元数省去了自己写姿态解算的麻烦。MPU6050便宜但噪声大需要自己做卡尔曼滤波。电源方面用2S锂聚合物电池配一个5V的UBEC给舵机和主控供电。电池容量根据续航要求选一般1000mAh能跑20到30分钟。6. 强化学习算法调优经验6.1 PPO的超参数调优PPO虽然稳但超参数没调好照样翻车。我踩过的坑大概有这些学习率是最敏感的。3e-4是经典值但如果训练不稳定可以降到1e-4。如果训练太慢可以升到1e-3但再高就容易发散。可以用学习率衰减前期大后期小。裁剪范围默认是0.2这个值控制策略更新的幅度。太小了学得慢太大了容易崩。如果训练曲线震荡厉害降到0.1试试。GAE lambda默认0.95这个值权衡偏差和方差。如果奖励信号很稀疏可以降到0.9让策略更关注近期回报。如果奖励很密集可以升到0.98。批量大小对训练稳定性影响很大。太小了梯度噪声大太大了更新次数少。4096是个不错的起点根据显存和训练速度调整。6.2 奖励函数设计的经验奖励函数设计是RL里最像艺术的部分。我的经验是从简单开始逐步增加。第一版奖励只包含前进速度其他什么都不加。策略会学出一种很丑但能走的步态。然后加姿态惩罚让机身保持直立。再加能量惩罚让步态更省电。最后加平滑惩罚让动作更自然。每一项的权重需要反复调。前进速度的权重设为1.0作为基准姿态惩罚大概0.1到0.5能量惩罚0.01到0.05平滑惩罚0.001到0.01。具体值要看机器人的实际表现。还有一个技巧是用课程学习。先在一个简单的环境里训练比如平整地面、固定摩擦系数。等策略能稳定行走了再逐步增加难度随机摩擦、随机质量、随机延迟。这样训练出来的策略鲁棒性更好。6.3 置信区间曲线的绘制训练过程中要监控策略的性能通常用平均回报的置信区间曲线来表示。用Python的matplotlib就能画import numpy as np import matplotlib.pyplot as plt # 假设有多个随机种子的训练数据 # rewards shape: (num_seeds, num_episodes) mean np.mean(rewards, axis0) std np.std(rewards, axis0) confidence 1.96 * std / np.sqrt(rewards.shape[0]) plt.figure(figsize(10, 6)) plt.plot(mean, labelMean Reward) plt.fill_between(range(len(mean)), mean - confidence, mean confidence, alpha0.3) plt.xlabel(Episode) plt.ylabel(Reward) plt.legend() plt.savefig(training_curve.png, dpi300)置信区间能告诉你策略的性能是否稳定。如果区间很宽说明不同随机种子的结果差异大策略对初始化敏感。如果区间很窄说明训练很稳定。7. 项目扩展与进阶方向7.1 从仿真到真机的完整部署流程把训练好的策略部署到真机上大概需要这几步第一步导出ONNX模型验证推理结果跟PyTorch一致。可以用ONNX Runtime的Python API跑一遍对比输出。第二步把ONNX模型转换成Rust能读的格式。如果直接用ortcrate不需要转换直接加载就行。如果要用自己的推理引擎需要把权重提取出来写成Rust的数组或者二进制文件。第三步在Rust端实现控制循环。读取IMU和关节角度组装状态向量跑推理输出动作下发给舵机。控制循环的频率要跟训练时一致不然策略的行为会变。第四步做静态测试和动态测试逐步增加难度。每次失败都要记录数据回头分析。7.2 多机器人协同的扩展单机器人走稳了之后可以试试多机器人协同。比如两只鸭子一起走保持一定的距离和队形。这就涉及到多智能体强化学习MARL。MARL的难度比单智能体高不少。每个智能体的观测空间里要加入其他智能体的信息奖励函数要考虑协同目标。训练的时候可以用集中式训练、分布式执行的框架比如MADDPG或者MAPPO。通信是个大问题。真机上多个机器人之间怎么交换信息WiFi延迟大蓝牙带宽小有线又限制活动范围。一个折中方案是用UWB做相对定位每个机器人只知道邻居的位置不需要全局通信。7.3 从双足到多足的形态扩展鸭形双足走稳了可以试试扩展到四足。四足的稳定性比双足好很多但控制复杂度也高。状态空间和动作空间的维度翻倍训练时间也会翻倍。四足的步态更多样walk、trot、pace、bound每种步态适合不同的速度。可以让策略自己学出步态切换也可以手动设计步态控制器让RL只负责平衡和适应。从双足到四足最大的挑战是协调。四条腿要配合好不然会自己绊自己。奖励函数里要加腿间协调的惩罚项或者用相位信号来引导步态。8. 个人实操心得与避坑建议8.1 硬件装配的坑3D打印件的公差是个大问题。同一个模型不同的打印机、不同的材料、不同的层高打出来的尺寸能差0.2mm。对于微小型机器人来说0.2mm的间隙就足以让关节晃动。解决办法是在设计的时候预留公差补偿。比如轴承孔设计成负公差打印出来稍微小一点用砂纸打磨到合适。或者用热熔铜螺母比直接攻丝可靠得多。舵机的安装方向也要注意。舵机的输出轴有顺时针和逆时针两种装反了会导致控制逻辑全乱。装配前一定要确认舵机的旋转方向在代码里做好映射。线缆管理经常被忽略。微小型机器人空间紧张线缆如果太硬或者太长会限制关节活动甚至把舵机插头扯掉。用硅胶线柔软又耐弯折。线缆要走内部用扎带固定好。8.2 调试工具的选择调试机器人串口打印是最基本的。但串口带宽有限打印太多会影响控制循环的实时性。建议用二进制协议把关键数据打包成结构体一次性发出来。无线调试可以用ESP32的WiFi或者蓝牙。但无线延迟不稳定只适合看数据不适合做实时控制。控制循环还是要跑在本地。可视化工具推荐用PlotJuggler能实时画曲线支持多种数据源。把IMU数据、关节角度、策略输出都发到PlotJuggler里一眼就能看出问题在哪。8.3 心态与迭代节奏做机器人项目心态很重要。第一次跑不起来太正常了我见过太多人因为机器人摔了几次就放弃。其实每次摔倒都是数据记录下当时的观测和动作回头分析下次就能改进。迭代节奏要控制好。不要一次改太多东西不然出了问题不知道是哪个改动导致的。每次只改一个变量验证有效后再改下一个。训练RL策略也是不要指望一次就训出完美的策略。先训一个能走的再慢慢优化。训练过程中要保存checkpoint万一后面训崩了还能回滚到之前的状态。最后分享一个小技巧在仿真里训练的时候把真机的观测噪声也加进去。IMU的噪声、舵机的回差、地面的不平整这些在仿真里都可以模拟。虽然训练会慢一点但迁移到真机上会顺利很多。我试过在仿真里加噪声和不加噪声迁移后的表现差距非常大加了噪声的策略明显更抗造。