1. 从一只机器鸭说起为什么50Hz闭环值得单独拿出来讲第一次看到 MicroDuck 这个项目的时候我脑子里冒出来的第一个念头不是这只鸭子能走多稳而是50Hz 这个数字是怎么定下来的。做过足式机器人控制的人都知道控制频率这件事从来不是拍脑袋决定的它背后牵扯的是传感器采样率、通信总线带宽、算力预算、机械响应带宽这一整条链路。MicroDuck 把神经控制闭环跑在 50Hz也就是每 20 毫秒完成一次感知—推理—决策—执行的完整循环这个数字放在双足机器人领域其实相当克制但恰恰是这种克制让它能在一只巴掌大的机器鸭身上跑起来。MicroDuck 本质上是一个小型双足机器人平台外形做成鸭子的样子两条腿负责支撑和行走身体里塞了 IMU、关节编码器、舵机或者小型无刷电机以及一块算力有限的嵌入式主控。它的核心卖点在于用神经网络直接输出关节控制量形成一个闭环而不是传统的那套步态规划器 PID 跟踪的架构。神经控制闭环这个词听起来玄乎拆开看就是——策略网络根据当前观测姿态、角速度、关节位置、上一帧动作等直接算出目标关节角度或力矩执行器执行完之后新的观测又喂回网络如此往复。50Hz 就是这个往复的节奏。为什么这件事值得写因为大部分人在做足式机器人神经网络控制的时候第一反应是往 200Hz、500Hz 甚至 1kHz 去堆觉得频率越高越稳。但 MicroDuck 反其道而行把频率压到 50Hz反而跑通了。这里面有算力约束的现实考量也有控制理论上的取舍。我见过太多项目死在频率定太高、算力跟不上、闭环抖动上所以这只鸭子的 50Hz 选择对做小型足式机器人、做嵌入式 AI 推理、做 ONNX 模型部署的人来说都有直接的参考价值。这篇文章适合三类人看一是正在做小型足式机器人或仿生机器人控制的朋友二是想把神经网络模型部署到嵌入式设备上做实时推理的工程师三是对 ONNX 模型量化、推理优化感兴趣、想找一个完整落地案例的人。我会从整体设计思路讲起把 50Hz 这个数字背后的账算清楚然后拆解神经控制闭环的每个环节再讲 ONNX 模型从训练到量化到部署的完整流程最后把我踩过的坑和排查经验整理出来。内容会涉及不少实操细节能直接抄作业的地方我会标出来。2. 整体设计思路50Hz 闭环是怎么算出来的2.1 控制频率的账为什么不是 200Hz 也不是 20Hz定控制频率这件事我习惯从三个约束倒推机械带宽、传感器带宽、算力预算。三者取最小值再留一点余量就是你的实际控制频率。先说机械带宽。MicroDuck 用的是小型舵机或者微型无刷电机这类执行器的响应时间通常在 10 到 30 毫秒量级。也就是说你给它一个目标位置它真正到位需要十几毫秒。如果你的控制周期是 5 毫秒200Hz那你在执行器还没响应完上一帧指令的时候就又发了新指令结果就是指令堆积、抖动加剧。反过来如果控制周期是 50 毫秒20Hz执行器早就到位了你在那儿干等系统的抗扰动能力就下来了。20 毫秒50Hz刚好卡在大多数小型执行器响应时间的中间偏上位置既不浪费算力也不至于让执行器闲着。再说传感器带宽。IMU 一般能跑到 100Hz 到 1kHz关节编码器读取频率取决于总线I2C 通常能到 400kHz 时钟读一圈编码器也就几百微秒。所以传感器这边不是瓶颈50Hz 绰绰有余。最后是算力预算这才是真正的硬约束。MicroDuck 的主控大概率是一块树莓派级别的板子或者更高端的嵌入式 SoC。神经网络推理一次如果模型是几万参数的小 MLP在 CPU 上跑一次大概 1 到 5 毫秒如果模型大一点或者没做量化可能就要 10 到 20 毫秒。加上传感器读取、数据预处理、通信开销一个周期总共 20 毫秒是相当紧张的。所以 50Hz 不是选出来的是算出来的——它是算力、机械、传感器三者交集里那个能稳定跑起来的频率。提示如果你也在做类似项目建议先用一个空循环测出你的主控在目标频率下的实际耗时再决定控制频率。很多人一上来就定 100Hz结果实测发现光推理就占了 15 毫秒闭环根本跑不稳。2.2 神经控制闭环 vs 传统步态控制选型背后的逻辑传统双足机器人控制走的是步态规划 逆运动学 PID这条路。先离线或者在线规划出一条关节轨迹然后用逆运动学把足端轨迹映射到关节角度再用 PID 去跟踪。这套方法成熟、可解释、调试方便但缺点也很明显对模型精度要求高遇到未建模的扰动比如地面不平、负载变化就容易翻车而且每换一种步态都要重新调参。神经控制闭环走的是另一条路让神经网络直接从观测映射到动作跳过显式的步态规划和逆运动学。网络在仿真里通过强化学习或者模仿学习训练出来学到的是什么状态下该做什么动作的隐式策略。它的优势在于鲁棒性强——因为训练时见过大量随机扰动网络学会了应对劣势在于可解释性差出了问题不好定位而且对仿真环境的真实性依赖极高。MicroDuck 选神经控制闭环我认为核心原因是它的目标场景是小型、低成本、能走就行而不是高精度、高动态、能跑酷。在这个场景下神经控制闭环的开发成本反而更低——你不需要花几周去调步态参数只需要把仿真环境搭好让网络自己学。而且 ONNX 这套工具链让模型部署变得标准化训练用 PyTorch导出 ONNX量化成 int8再在嵌入式端用 ONNX Runtime 或者 ncnn 推理整条链路是通的。2.3 ONNX 在整条链路里的位置ONNX 在这个项目里扮演的是中间语言的角色。训练阶段你用 PyTorch 或者 JAX 写网络、跑强化学习训练完之后导出成 ONNX 格式。ONNX 的好处是它把模型结构和权重固化下来跟训练框架解耦部署端只要有 ONNX Runtime 就能跑不需要装 PyTorch。对于嵌入式设备来说这一点至关重要——你不可能在树莓派上装一个完整的 PyTorch。导出 ONNX 之后通常还要做量化。FP32 的模型在嵌入式 CPU 上跑得慢量化成 int8 之后推理速度能提升 2 到 4 倍模型体积缩小到四分之一。MicroDuck 这种 50Hz 闭环量化几乎是必须的否则推理时间会吃掉大半个控制周期。量化的具体流程我在第 4 章会详细讲这里先记住一个原则量化会带来精度损失对于控制类任务量化后的策略网络输出可能会有几个百分点的偏差需要通过校准数据集和量化感知训练来补偿。3. 神经控制闭环的核心细节拆解3.1 观测空间与动作空间的设计神经控制闭环的第一个关键决策是网络看什么、输出什么。这直接决定了网络能不能学到有效策略。观测空间通常包含这几类信息身体姿态IMU 给出的 roll、pitch、yaw 以及角速度、关节状态每个关节的角度和角速度、上一帧的动作、以及一个相位信号用来告诉网络当前处于步态的哪个阶段。MicroDuck 是双足关节数量不多每条腿大概 3 个自由度髋、膝、踝总共 6 个关节加上 IMU 的 6 维数据观测维度大概在 20 到 30 维之间。这个维度对小型 MLP 来说完全能处理。动作空间有两种选择位置控制和力矩控制。位置控制是网络输出目标关节角度底层再用 PID 去跟踪力矩控制是网络直接输出关节力矩。对于舵机驱动的小型机器人位置控制更实际因为舵机本身就是位置伺服。MicroDuck 大概率用的是位置控制网络输出 6 个目标角度舵机执行。这里有个细节值得说观测里加上一帧动作这一项是为了让网络知道自己的历史决策避免输出突变。这在控制里叫动作平滑能显著减少抖动。我实测下来加了上一帧动作之后关节抖动能减少一半以上。3.2 50Hz 闭环的时序拆解一个 20 毫秒的控制周期时间是怎么分配的我按经验给一个典型的拆解环节耗时毫秒说明IMU 读取1-2I2C 或 SPI 读取含数据校验关节编码器读取2-36 个关节逐个读取数据预处理1-2归一化、拼装观测向量ONNX 推理5-10int8 量化模型CPU 推理动作后处理1反归一化、限幅舵机指令下发2-36 个舵机PWM 或总线通信余量2-5应对抖动和系统调度加起来大概 15 到 20 毫秒刚好卡在 50Hz 的边界上。这个表说明一个事推理时间是最大的变量也是优化的重点。如果你的推理超过 10 毫秒整个闭环就会开始丢帧表现为机器人动作一顿一顿的。注意嵌入式 Linux 不是实时系统调度抖动可能达到几毫秒。如果你的控制周期是 20 毫秒抖动 3 毫秒就吃掉了 15% 的预算。建议用SCHED_FIFO实时调度策略或者干脆用 RTOS 来跑控制循环。3.3 网络结构小 MLP 为什么够用MicroDuck 的策略网络不需要很复杂。双足机器人的控制策略本质上是一个从低维观测到低维动作的映射用 2 到 3 层、每层 128 到 256 个神经元的 MLP 就够了。参数量大概在几万到十几万之间量化成 int8 之后模型体积只有几十 KB推理一次在树莓派上大概 2 到 5 毫秒。为什么不用 LSTM 或者 Transformer因为控制闭环要求低延迟循环网络和注意力机制的计算量太大而且它们需要维护历史状态在嵌入式端部署麻烦。MLP 虽然无记忆但你把上一帧动作和历史观测拼进输入就相当于给了它短时记忆效果够用。激活函数用 ReLU 或者 ELU。ReLU 计算快但量化时要注意它的输出范围ELU 平滑对控制任务更友好但计算稍慢。我一般推荐用 ReLU因为量化工具链对它的支持最好。3.4 训练环境MuJoCo 里的虚拟鸭子神经控制闭环的训练几乎都在仿真里完成。MicroDuck 用的是 MuJoCo这是足式机器人领域最常用的物理引擎接触模型准确仿真速度快。你在 MuJoCo 里建一个和实物尺寸、质量、关节限位一致的鸭子模型然后跑强化学习。训练流程大概是定义奖励函数前进速度、姿态稳定、能量消耗、动作平滑等项的加权和用 PPO 或者 SAC 算法训练随机化一些参数地面摩擦、负载、初始姿态来提升鲁棒性。训练几百万步之后策略收敛导出 ONNX。这里有个坑仿真和现实的差距sim-to-real gap。MuJoCo 里的舵机是理想的位置伺服实物舵机有延迟、有死区、有回差。如果你不在仿真里建模这些训练出来的策略到实物上就会抖。我的做法是在仿真里给舵机加一个一阶延迟环节延迟时间设成实测值这样训练出来的策略对延迟有鲁棒性。4. ONNX 模型从训练到部署的完整实操4.1 导出 ONNX把 PyTorch 策略固化下来训练完之后第一步是导出 ONNX。PyTorch 的torch.onnx.export是标准做法但有几个参数必须注意。import torch import torch.onnx # 假设 policy 是你的策略网络已经加载了训练好的权重 policy.eval() # 构造一个示例输入维度要和实际观测一致 dummy_input torch.randn(1, 28) # batch1, obs_dim28 torch.onnx.export( policy, dummy_input, microduck_policy.onnx, export_paramsTrue, opset_version11, # 建议 11 或 13兼容性好 do_constant_foldingTrue, # 常量折叠减小模型 input_names[obs], output_names[action], dynamic_axesNone # 控制场景 batch 固定为 1不需要动态轴 )opset_version选 11 还是 13 有讲究。11 兼容性最好ONNX Runtime 和 ncnn 都支持13 支持更多算子但老版本推理引擎可能不认。控制类模型用的算子很简单MatMul、Add、ReLUopset 11 完全够用。dynamic_axes设成 None因为控制场景 batch 永远是 1固定维度能让推理引擎做更多优化。这一点很多人忽略设了动态轴反而拖慢推理。导出之后用onnx.checker.check_model验证一下模型完整性再用onnxruntime跑一遍对比 PyTorch 和 ONNX 的输出差异。差异应该在 1e-5 量级如果差太多说明导出有问题。4.2 int8 量化精度和速度的平衡量化是部署的关键一步。FP32 模型在嵌入式 CPU 上跑得慢int8 量化能把推理速度提升 2 到 4 倍。ONNX Runtime 提供了quantize_static和quantize_dynamic两种方式。动态量化简单不需要校准数据但只量化权重激活值还是浮点加速有限。静态量化需要校准数据集把权重和激活都量化成 int8加速明显但精度损失也大一些。对于控制任务我推荐静态量化因为推理速度是硬需求。from onnxruntime.quantization import quantize_static, CalibrationDataReader import numpy as np class MicroDuckCalibrationReader(CalibrationDataReader): def __init__(self, calibration_data): # calibration_data 是一批观测向量从仿真里采集 self.data calibration_data self.index 0 def get_next(self): if self.index len(self.data): return None obs self.data[self.index] self.index 1 return {obs: obs.astype(np.float32)} # 从仿真里采集 100-500 条观测数据作为校准集 calib_data collect_observations(num_samples300) reader MicroDuckCalibrationReader(calib_data) quantize_static( model_inputmicroduck_policy.onnx, model_outputmicroduck_policy_int8.onnx, calibration_data_readerreader, quant_formatQuantFormat.QDQ, # QDQ 格式兼容性好 per_channelTrue, # 逐通道量化精度更高 weight_typeQuantType.QInt8, activation_typeQuantType.QInt8 )校准数据集的选择很关键。你不能随便拿一批随机观测去校准要用仿真里实际跑出来的观测分布。我的做法是让训练好的策略在仿真里跑 10 个 episode把每帧观测都存下来随机抽 300 条做校准。这样校准出来的量化参数才贴合实际分布。量化之后一定要做精度对比。把量化模型和原始模型在同一批观测上跑比较输出动作的差异。如果平均差异超过 5%说明量化损失太大需要调整校准集或者改用逐通道量化。我实测下来一个 3 层 MLP 量化成 int8 之后输出差异通常在 1% 到 3% 之间对控制任务完全可接受。4.3 嵌入式端推理ONNX Runtime 还是 ncnn部署端有两个主流选择ONNX Runtime 和 ncnn。ONNX Runtime 官方支持好API 稳定但体积大依赖多ncnn 是腾讯开源的轻量级推理框架体积小无依赖适合嵌入式。MicroDuck 这种项目如果主控是树莓派用 ONNX Runtime 更方便直接pip install onnxruntime就能用。如果主控是更小的 MCU 或者资源紧张的板子ncnn 更合适。ONNX Runtime 的推理代码大概长这样import onnxruntime as ort import numpy as np # 加载量化模型 session ort.InferenceSession( microduck_policy_int8.onnx, providers[CPUExecutionProvider] ) # 构造输入 obs np.array(observation, dtypenp.float32).reshape(1, -1) inputs {obs: obs} # 推理 outputs session.run([action], inputs) action outputs[0] # action 是目标关节角度下发给舵机 send_to_servos(action)这里有个性能优化的点session.run每次调用都有开销如果控制频率高建议用io_binding把输入输出绑定到固定内存减少数据拷贝。另外providers只留CPUExecutionProvider别加载其他 provider能省启动时间。ncnn 的部署流程稍微复杂一点需要把 ONNX 转成 ncnn 格式用onnx2ncnn工具然后写 C 推理代码。好处是运行时开销极小在 ARM 上能跑到接近理论峰值。4.4 50Hz 陷波器别忽略信号处理这一环热词里出现了50Hz 陷波器和50Hz 双 T 型陷波滤波器设计这不是巧合。50Hz 是工频干扰的频率在很多电子设备里都会出现。MicroDuck 的 IMU 信号如果受到 50Hz 干扰会直接污染观测导致控制抖动。陷波器的作用就是在 50Hz 这个频点上把信号衰减掉同时尽量不影响其他频段。双 T 型陷波滤波器是最常用的拓扑它由两个 T 型网络组成一个用于正反馈一个用于负反馈能在目标频率上产生极深的零点。设计一个 50Hz 双 T 型陷波器核心参数是中心频率 f050Hz、品质因数 Q、以及增益。Q 值决定了陷波的带宽Q 越高陷波越窄对邻近频率影响越小但对元件精度要求越高。对于 IMU 信号我一般取 Q5 到 10。数字实现的话用双线性变换把模拟滤波器转成数字滤波器采样率设成 1kHz远高于控制频率 50Hz避免混叠然后得到差分方程在代码里实现import numpy as np from scipy import signal # 设计 50Hz 陷波器采样率 1000HzQ8 fs 1000.0 f0 50.0 Q 8.0 b, a signal.iirnotch(f0, Q, fs) # 在控制循环里对 IMU 信号做滤波 from collections import deque zi signal.lfilter_zi(b, a) filter_state zi * 0 # 初始状态 def notch_filter(x): global filter_state y, filter_state signal.lfilter(b, a, [x], zifilter_state) return y[0]提示陷波器会引入相位延迟50Hz 陷波器在 50Hz 附近的群延迟可能达到几毫秒。对于 20 毫秒的控制周期这个延迟不能忽略。建议把陷波器放在信号链的最前端并且实测延迟必要时在控制策略里补偿。5. 实操过程与核心环节实现5.1 从零搭建训练环境搭建 MuJoCo 训练环境是第一步。你需要一个鸭子的 URDF 或者 MJCF 模型文件描述连杆、关节、质量、惯量、碰撞体。如果实物已经做好了最好用 CAD 导出模型再手动简化碰撞体。碰撞体太复杂会拖慢仿真太简单又会导致接触不真实。模型建好之后写环境包装类定义reset()和step()。reset()随机初始化姿态和速度step()执行动作、推进仿真、计算奖励、返回观测。奖励函数的设计是训练成败的关键我一般用这几项加权前进速度奖励鼓励机器人往前走姿态惩罚roll 和 pitch 偏离零的平方高度惩罚身体高度偏离目标值的平方动作平滑惩罚相邻两帧动作差的平方能量惩罚关节力矩的平方和权重需要调一般前进速度权重最大姿态和高度次之平滑和能量最小。调权重的经验是先让机器人学会站再让它学会走最后调平滑。5.2 训练、导出、量化的完整流水线训练用 PPO这是足式机器人最常用的算法稳定、样本效率还行。训练几百万步大概需要几个小时到一天取决于仿真速度和并行环境数量。我一般开 8 到 16 个并行环境用向量化环境加速采样。训练收敛后导出 ONNX做量化然后在仿真里用量化模型跑一遍对比原始模型的表现。如果量化后机器人还能走说明量化成功。如果走不了说明量化损失太大需要重新校准或者用量化感知训练。量化感知训练QAT是在训练阶段就模拟量化误差让网络学会适应。PyTorch 提供了torch.quantization模块可以在训练时插入伪量化节点。QAT 比训练后量化PTQ精度高但流程复杂需要重新训练。如果 PTQ 效果够用就不必上 QAT。5.3 实物部署与调试实物部署是最容易出问题的环节。仿真里跑得好好的策略到实物上可能直接趴下。原因通常是这几类传感器噪声、执行器延迟、模型参数不准、通信丢包。调试的时候我建议分步来。先让机器人站着不动看策略能不能保持平衡再让它原地踏步最后才让它走。每一步都记录日志把观测、动作、实际关节角度都存下来方便回放分析。MuJoCo 有个 viewer 可以重新播放仿真轨迹实物调试的时候你可以把实物的观测和动作录下来导入 MuJoCo 回放对比仿真和实物的差异。这个技巧能帮你快速定位是策略问题还是硬件问题。注意实物调试一定要有急停开关或者用绳子吊着机器人防止摔坏。我见过太多人第一次上电就把机器人摔散架的。5.4 性能实测与调优部署完成之后要实测控制周期的实际耗时。用time.perf_counter()在控制循环里打点记录每个环节的耗时跑几百个周期看平均值和最大值。如果最大值超过 20 毫秒说明有抖动需要优化。优化的方向有几个一是减少推理时间比如用更小的模型、更激进的量化、或者换更快的推理引擎二是减少通信开销比如把舵机通信改成批量下发三是用实时调度减少系统抖动。我实测下来一个 3 层 MLP、int8 量化、ONNX Runtime 推理在树莓派 4 上单次推理大概 3 到 5 毫秒加上其他环节整个周期能稳定在 15 毫秒左右50Hz 有余量。6. 常见问题与排查技巧实录6.1 机器人抖动、走不稳怎么排查抖动是神经控制闭环最常见的问题。排查思路是从信号链前端往后查。先看 IMU 信号有没有噪声或者 50Hz 干扰用示波器或者录数据做 FFT 分析。如果有 50Hz 峰值加陷波器。再看观测归一化是否正确训练时的归一化参数和部署时是否一致这个很容易出错。然后看推理输出是否平滑如果动作突变检查上一帧动作有没有正确拼进观测。最后看舵机指令是否被正确执行用示波器看 PWM 波形或者读舵机反馈。我整理了一个排查速查表现象可能原因排查方法高频抖动IMU 噪声、50Hz 干扰FFT 分析加陷波器低频摆动策略不稳、观测归一化错误对比仿真和实物观测分布动作突变上一帧动作未拼入观测检查观测拼装代码走几步就倒执行器延迟、模型参数不准实测延迟重新标定模型推理超时模型太大、量化不足测推理耗时优化模型6.2 ONNX 量化后精度掉太多怎么办量化精度损失是常见问题。首先检查校准集是否贴合实际分布用仿真里跑出来的观测不要用随机数据。其次检查是否用了逐通道量化per_channelTrue能显著提升精度。如果还不够试试混合量化对敏感层保持 FP16其他层 int8。最后的手段是量化感知训练在训练阶段就模拟量化误差。我踩过的一个坑是校准集只用了站立状态的观测结果量化后机器人一站就抖因为行走状态的观测分布没被覆盖。后来我把站立、踏步、行走三种状态的观测都放进校准集问题就解决了。6.3 仿真到实物的差距怎么缩小sim-to-real gap 是足式机器人的老大难。缩小差距的手段有几个一是域随机化训练时随机化地面摩擦、负载、传感器噪声、执行器延迟让策略见过各种情况二是系统辨识实测实物的质量、惯量、摩擦、延迟把参数填进仿真三是残差学习用一个小的网络学习仿真和实物的残差在线补偿。我的经验是域随机化最有效但随机化范围要合理。范围太小策略不够鲁棒范围太大策略学不到有效行为。一般从实测值的正负 20% 开始逐步扩大。6.4 控制周期丢帧怎么定位丢帧表现为机器人动作一顿一顿的。定位方法是打点记录每个周期的耗时找出耗时最大的环节。如果是推理耗时优化模型如果是通信耗时优化通信如果是系统调度用实时调度策略。还有一个隐蔽的原因Python 的垃圾回收。Python 在控制循环里跑GC 可能在某个周期触发导致耗时突增。解决办法是关掉 GC或者用 C 写控制循环。我一般建议控制循环用 C 写Python 只做上层逻辑。7. 我在这只鸭子身上踩过的坑做 MicroDuck 这类项目最大的体会是控制频率不是越高越好而是要跟你的硬件和算力匹配。我一开始也想上 100Hz结果推理时间就占了 15 毫秒加上其他环节直接超时机器人抖得跟筛糠一样。后来降到 50Hz反而稳了。这个教训让我明白工程上的够用比极致更重要。第二个体会是量化这件事不能省。FP32 模型在嵌入式上跑推理时间可能是 int8 的两三倍50Hz 根本跑不起来。量化虽然会掉一点精度但对于控制任务只要校准集选得好损失完全可接受。我现在做任何嵌入式 AI 项目量化都是标配。第三个体会是信号处理容易被忽略。50Hz 陷波器这种东西看起来跟神经网络控制没关系但 IMU 信号被污染了再好的策略也白搭。我建议做控制的朋友都补一补信号处理的基础数字滤波器、FFT、采样定理这些关键时刻能救命。最后分享一个小技巧调试的时候把仿真和实物的观测、动作都录下来用 MuJoCo viewer 回放对比。这个习惯帮我定位了好几个隐蔽的 bug比盯着日志看效率高多了。