1. 从一只会走路的鸭子说起MicroDuck 到底在解决什么问题第一次看到 MicroDuck 这个项目名我以为是某个玩具厂商的营销噱头。直到把它的控制链路拆开看了一遍才发现这只鸭子背后藏着一套相当完整的双足机器人神经控制闭环方案而且跑在 50Hz 这个非常接地气的频率上。它要解决的问题其实很朴素如何用一套轻量化的神经网络让一个只有两条腿、没有轮子、没有大尾巴保持平衡的机械体稳定地走起来、站得住、摔了还能爬起来。双足机器人这个领域过去十年基本被两类方案统治。一类是传统的 ZMP零力矩点加 MPC模型预测控制靠精确的动力学模型和在线优化求解稳是稳但算力开销大参数调起来像在绣花。另一类是近几年的强化学习端到端方案比如各种 sim-to-real 的 locomotion 策略效果惊艳但训练成本高、部署链路长一个策略动辄几百万参数塞进嵌入式板子就开始喘。MicroDuck 走的是第三条路用相对小的网络、明确的控制频率、清晰的观测-动作接口把神经控制闭环这件事做得足够透明、足够可复现。所谓50Hz 神经控制闭环拆开看是三个关键词。50Hz指的是控制回路每 20 毫秒跑一次这个频率在足式机器人里属于经典区间——太低比如 10Hz会导致姿态修正滞后机器人走起来像喝醉太高比如 500Hz对神经网络推理和传感器同步都是压力而且对双足这种惯性大的系统收益并不明显。神经控制指的是策略网络直接输出关节目标而不是传统控制里的力矩或位置增量。闭环则强调观测进来、动作出去、状态再反馈回来的完整回路中间没有开环的盲走阶段。这只鸭子适合谁来研究我的判断是三类人。第一类是刚入门足式机器人、想找一个完整但不臃肿的参考实现的学生或爱好者MicroDuck 的链路足够短能让你在一周内把仿真训练到实机部署整条路走通。第二类是做边缘 AI 部署的工程师项目里涉及 ONNX 导出、INT8 量化、推理引擎选型这些实打实的工程问题比很多论文里的我们部署到了嵌入式平台要具体得多。第三类是想理解神经控制闭环本质的开发者50Hz 这个频率逼着你去思考延迟、观测对齐、动作平滑这些平时容易被忽略的细节。我后面会按控制频率为什么是 50Hz神经网络怎么设计和导出ONNX 量化与推理引擎怎么选闭环里那些没人告诉你的坑这几条线把 MicroDuck 这套方案从头到尾捋一遍。中间会穿插我自己在类似项目里踩过的坑以及从热词里能看出的一些行业关注点比如 50Hz 陷波器、ONNX INT8 量化、MuJoCo 回放这些具体问题。2. 50Hz 这个数字不是拍脑袋定的控制频率背后的取舍2.1 为什么足式机器人偏爱 50Hz 到 200Hz 这个区间很多人第一次做足式控制会本能地觉得频率越高越好恨不得跑到 1kHz。我早年也这么想过结果在实机上被现实教育了一顿。控制频率的选择本质上是三件事的平衡传感器采样与同步的可行性、神经网络推理的耗时、机械系统本身的响应带宽。先看机械侧。一个中小型双足机器人腿部惯量决定了它的姿态变化时间常数大概在几十毫秒量级。也就是说你给它一个关节目标它真正跟上需要几十毫秒。如果你的控制周期是 1ms那意味着你在机械还没响应完之前就已经发了 20 次新指令这些指令之间高度相关等于在做无用功还会放大传感器噪声。反过来如果周期是 100ms10Hz那机械响应完了你才更新一次姿态修正明显滞后走起来就会晃。50Hz 对应 20ms 周期恰好落在一个舒服的位置比机械时间常数略快能及时修正又不至于快到让推理和同步成为瓶颈。MicroDuck 选 50Hz我认为还有一个很实际的原因——它要让神经网络推理和传统控制律在同一个周期里跑完。20ms 的预算里推理可能占 5 到 10ms剩下的留给状态估计、滤波、通信刚好够用。如果提到 200Hz5ms 周期里推理就吃掉大半留给其他环节的余量太薄实机上稍微有点抖动就超时。2.2 50Hz 陷波器为什么会成为热搜词热词里出现了50Hz 陷波器50Hz 双 T 型陷波滤波器设计这个其实和 MicroDuck 的控制频率是两码事但放在一起看很有意思。50Hz 在电力系统里是工频很多传感器、电源、电机驱动会引入 50Hz 的干扰。做机器人控制的人尤其是用应变片、电流采样做力控的经常会遇到 50Hz 及其谐波的噪声。陷波器Notch Filter就是专门用来挖掉某个特定频率成分的滤波器。双 T 型Twin-T陷波器是模拟和数字里都很经典的结构它的传递函数在目标频率处有一个很深的零点能把 50Hz 干扰压下去同时对其他频率影响较小。为什么强调双 T因为单 T 结构的 Q 值不好调双 T 通过反馈可以独立调节陷波深度和带宽。在数字实现里通常用双线性变换把模拟双 T 转成差分方程然后以控制周期为采样率跑。这里有个容易混淆的点如果你的控制频率正好是 50Hz那 50Hz 陷波器就没法用了因为陷波频率等于采样频率时滤波器会退化。所以实际项目里陷波器针对的 50Hz 是干扰频率而控制频率往往远高于它比如 1kHz 采样、50Hz 控制。MicroDuck 的 50Hz 是控制频率两者不要混为一谈。我在做力控的时候就吃过这个亏一开始把采样率设成 100Hz想滤 50Hz 干扰结果发现根本滤不掉后来才明白采样率至少要是干扰频率的 4 到 10 倍才有意义。2.3 20ms 周期里到底塞了哪些事把 50Hz 落到工程上就是每个 20ms 周期要完成一串固定动作。我按 MicroDuck 这类项目的常见做法把这一周期拆成几个阶段阶段典型耗时主要工作传感器读取与同步1-2msIMU、关节编码器、足底接触状态估计2-4ms姿态解算、速度估计、滤波观测构造1ms归一化、拼装网络输入向量神经网络推理3-8msONNX Runtime 前向动作后处理1-2ms限幅、平滑、映射到关节目标通信下发1-2ms发给电机驱动器加起来大概 10 到 18ms留一点余量给抖动。这个表不是死的具体项目差异很大但它说明一个道理50Hz 不是随便定的是被整条链路的耗时倒推出来的。如果你把推理换成更大的网络或者状态估计用了更重的滤波器20ms 就不够用了这时候要么降频要么优化。提示做实时控制时永远不要假设每个环节的耗时是固定的。我习惯在代码里给每个阶段打时间戳跑一段时间后看最坏情况worst-case而不是平均值。平均值 8ms 的推理最坏情况可能是 15ms超时往往就发生在最坏情况。3. 神经网络从训练到 ONNX一只鸭子的大脑是怎么炼成的3.1 策略网络的设计取向小、快、可解释MicroDuck 的神经网络不是那种动辄几百万参数的巨型策略。从项目定位看它更偏向小网络 明确接口的路线。观测空间通常包括机身姿态roll、pitch、yaw 或四元数、角速度、线速度估计、各关节角度与角速度、上一时刻的动作、以及一个相位或时钟信号用来给步态提供节律。动作空间就是各关节的目标角度或位置增量。为什么强调可解释因为双足控制里一旦机器人摔了你得能快速判断是观测有问题、网络输出异常还是后处理把动作搞坏了。如果网络是个黑盒排查起来就是噩梦。我见过一些项目策略网络输入了上百维观测里面混了各种历史帧结果实机一抖根本不知道是哪一维引起的。MicroDuck 这种偏小的观测设计好处就是每一维你都能对应到物理量出问题能定位。网络结构上常见的是几层 MLP全连接激活函数用 ReLU 或 ELU输出层用 tanh 把动作限制在 [-1, 1]再线性映射到关节范围。也有用 GRU 或 LSTM 加历史信息的但对 50Hz 实时推理来说循环网络的状态管理会复杂一些尤其是导出 ONNX 时要注意隐藏状态的输入输出。如果追求部署简单纯 MLP 是更稳的选择。3.2 ONNX 导出那些导出后才发现的坑训练框架PyTorch 居多到 ONNX 的导出看起来就一行torch.onnx.export实际上坑不少。我按经验列几个 MicroDuck 这类项目最容易遇到的动态维度问题。如果你的网络输入 batch 维是动态的导出时要显式指定dynamic_axes。但机器人推理通常是 batch1我建议直接固定 batch1省得推理引擎在动态 shape 上做额外处理反而更慢。算子兼容性。不是所有 PyTorch 算子都能干净地转成 ONNX。比如某些自定义激活、复杂的索引操作、torch.where的某些用法导出后可能变成一堆碎算子或者直接不支持。导出后一定要用onnx.checker校验再用onnxruntime跑一遍对比 PyTorch 和 ONNX 的输出差异。我一般要求两者最大误差在 1e-4 以内超过就说明某个算子转换有问题。数值精度。训练用 FP32导出默认也是 FP32。但如果你后面要量化成 INT8导出时的一些细节比如是否折叠 BatchNorm、是否常量折叠会影响量化效果。建议导出时开启常量折叠把能提前算的都算掉。输入输出命名。别用默认的input.1、output.1这种名字实机部署时你会感谢自己给它们起了有意义的名字比如obs、action。import torch import torch.onnx # 假设 policy 是训练好的策略网络obs_dim 是观测维度 dummy_obs torch.randn(1, obs_dim) torch.onnx.export( policy, dummy_obs, microduck_policy.onnx, input_names[obs], output_names[action], opset_version17, do_constant_foldingTrue, dynamic_axesNone, # 固定 batch1 )导出后我会写个小脚本做一致性校验这一步千万别省import numpy as np import onnxruntime as ort sess ort.InferenceSession(microduck_policy.onnx) test_obs np.random.randn(1, obs_dim).astype(np.float32) onnx_out sess.run([action], {obs: test_obs})[0] torch_out policy(torch.from_numpy(test_obs)).detach().numpy() print(max diff:, np.abs(onnx_out - torch_out).max())3.3 INT8 量化省下来的算力值不值热词里.onnx 量化 int8onnx 模型出现频率很高说明大家对量化很关注。INT8 量化的核心动机是把 FP32 的权重和激活压到 8 位整数模型体积缩小约 4 倍推理速度在支持 INT8 指令的硬件上能提升 2 到 4 倍。对 MicroDuck 这种要在嵌入式板子上跑 50Hz 的场景量化确实有吸引力。但量化不是免费的午餐。精度损失是第一个问题。神经网络对量化误差的敏感度因层而异第一层和最后一层通常最敏感。ONNX Runtime 提供动态量化和静态量化两种。动态量化只量化权重激活在运行时动态量化实现简单但加速有限静态量化需要校准数据集能同时量化权重和激活加速更明显但校准集选不好会掉点。我的经验是对控制策略网络量化后一定要在仿真里重新跑一遍完整任务不能只看单步输出的误差。因为控制是闭环的单步小误差会在闭环里累积放大。我见过量化后单步误差只有 0.01但机器人走两步就摔的情况原因是误差方向恰好和步态相位耦合了。如果量化后掉点严重有几个补救方向一是对敏感层保持 FP32混合精度二是用 QAT量化感知训练在训练时就模拟量化误差三是干脆放弃量化用 FP16 或者优化推理引擎。对 50Hz 这个频率其实 FP32 在很多板子上也够用量化的收益要具体测过才知道。方案模型体积推理速度精度风险实现难度FP32基准基准无低FP16约 1/21.5-2x低低INT8 动态约 1/41.5-2x中中INT8 静态约 1/42-4x中高高4. 推理引擎选型ONNX Runtime、NCNN 还是别的4.1 为什么 ONNX 成了中间格式的事实标准热词里既有onnx runtime / ncnn也有java onnx runtimepp-ocrv6 onnx 推理这些说明 ONNX 生态已经渗透到各种语言和场景。ONNX 的价值在于它把训练框架和推理引擎解耦了。你可以在 PyTorch 里训练导出成 ONNX然后根据部署平台选不同的引擎服务器上用 ONNX Runtime移动端用 NCNN 或 MNN英伟达平台用 TensorRT。对 MicroDuck 这种项目ONNX 还有一个隐性好处它逼你把网络接口定义清楚。导出 ONNX 时你必须明确输入输出的 shape 和类型这反过来会促使你检查观测构造和动作后处理是否和训练时一致。我见过太多 sim-to-real 失败案例根源就是训练时的观测顺序和部署时的观测顺序不一致而这种错误在纯 Python 环境里很难发现一旦导出 ONNX、写死输入维度问题就暴露了。4.2 ONNX Runtime 在 50Hz 闭环里的实际表现ONNX Runtime 是我在桌面和边缘设备上最常用的引擎原因是它跨平台好、API 稳定、社区活跃。在 50Hz 闭环里它的表现取决于几个配置执行提供器Execution Provider。CPU 上默认用 MLAS如果有 GPU 可以用 CUDA EPARM 板子上可以用 ACL 或 XNNPACK。选错 EP 可能慢好几倍。我一般会先跑个 benchmark把可用的 EP 都试一遍。线程数。intra_op_num_threads控制算子内并行inter_op_num_threads控制算子间并行。对 batch1 的小网络线程开太多反而因为调度开销变慢。我通常设成 1 到 2实测比默认值快。图优化级别。graph_optimization_level设为ORT_ENABLE_ALL能开启常量折叠、算子融合等优化。但要注意某些优化在量化模型上可能不生效或引入误差需要实测。import onnxruntime as ort options ort.SessionOptions() options.intra_op_num_threads 1 options.inter_op_num_threads 1 options.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL sess ort.InferenceSession( microduck_policy.onnx, sess_optionsoptions, providers[CPUExecutionProvider], )在树莓派这类板子上一个几万参数的小 MLPONNX Runtime 单次推理大概 2 到 5ms完全能塞进 20ms 周期。如果网络更大或者板子更弱就要考虑 NCNN 这类更轻量的引擎。4.3 NCNN 和其他轻量引擎的取舍NCNN 是腾讯开源的推理框架主打移动端和嵌入式无第三方依赖编译出来就一个库。它的优势是启动快、内存占用小、对 ARM 优化好。缺点是算子覆盖不如 ONNX Runtime 全某些新算子可能不支持需要自己写。如果你的部署目标是手机或者资源极受限的 MCU 级板子NCNN 值得考虑。但 MicroDuck 这种跑在 Linux 板子上的项目ONNX Runtime 的便利性通常更划算。我的建议是先用 ONNX Runtime 跑通测出实际推理耗时如果满足 50Hz 预算就不折腾如果不满足再考虑换 NCNN 或做量化。不要一上来就追求极致优化先把闭环跑起来更重要。热词里还有yolo12 onnx 转 tensorrt 推理这类说明目标检测场景下 TensorRT 很流行。TensorRT 在英伟达平台上确实快但它的转换链路更重对控制策略这种小网络收益不一定明显而且 TensorRT 引擎和硬件绑定换设备要重新构建。MicroDuck 这种项目我倾向于保持 ONNX 的通用性。5. 闭环里的那些坑从仿真到实机的完整排查链路5.1 观测对齐最隐蔽也最致命的错误闭环控制里观测是网络的眼睛。如果观测错了网络再强也没用。我踩过最惨的一次坑是训练时用的角速度是机体坐标系部署时忘了转换直接用了世界坐标系的值。结果仿真里走得稳稳的实机上机器人一启动就往一个方向偏最后撞墙。排查了两天才发现是坐标系问题。MicroDuck 这类项目观测对齐要检查的点包括坐标系定义机体还是世界、单位弧度还是角度米还是厘米、顺序关节顺序是否和训练一致、归一化训练时的均值方差是否在部署时同样应用、时间对齐IMU 和编码器的时间戳是否同步。我建议写一个观测回放工具把实机采集的观测喂给仿真里的策略看输出是否合理这样能快速定位是观测问题还是动力学差异。5.2 动作后处理限幅、平滑与延迟补偿网络输出的是归一化动作要经过后处理才能变成关节目标。这一步看似简单坑却不少。限幅。网络输出理论上在 [-1, 1]但量化或数值误差可能让它略微超出映射到关节范围后可能超出机械限位。一定要做硬限幅否则电机可能撞限位或者触发保护。平滑。50Hz 下相邻两帧的动作如果跳变太大电机会有冲击。常见做法是加一阶低通滤波或者斜率限制。但平滑会引入延迟滤波越重延迟越大。我一般用很轻的滤波截止频率远高于步态频率或者只在动作变化率超阈值时才限速。延迟补偿。从观测采集到动作下发中间有推理耗时和通信延迟加起来可能 10ms 以上。对 50Hz 控制这相当于半个周期。如果不管机器人会反应慢半拍。补偿方法有两种一是用状态估计预测未来时刻的状态二是把动作下发时间对齐到下一个控制周期。我倾向于后者实现简单效果也够用。5.3 MuJoCo 回放把实机数据搬回仿真里复现热词里microduck mujoco viewer 重新播放很有意思说明大家很关注回放调试。MuJoCo 是足式机器人仿真里最常用的物理引擎之一它的 viewer 能实时显示机器人状态。把实机采集的关节轨迹、IMU 数据导入 MuJoCo 回放是排查问题的利器。具体做法是实机运行时记录每个周期的观测、动作、时间戳存成日志。然后写个脚本在 MuJoCo 里加载同样的模型把记录的关节目标按时间轴喂进去看仿真里的机器人是否复现实机行为。如果仿真里也摔说明是控制逻辑问题如果仿真里稳、实机摔说明是动力学差异或传感器问题。这个二分法能快速缩小排查范围。注意MuJoCo 回放时要注意时间步长和实机控制周期一致。如果仿真步长是 1ms 而控制周期是 20ms要在仿真里每 20 步才更新一次动作否则回放出来的行为和实机对不上。5.4 实机调试的几条血泪经验最后分享几条我在实机调试里总结的经验都是文档里不会写的先吊起来再落地。第一次跑新策略一定把机器人吊在支架上让腿悬空。这样即使策略输出异常也不会摔坏机器。确认关节动作方向正确、幅度合理后再放到地面上。从站立开始不要直接走。很多策略是站立和行走一起训的但实机调试时先只测站立确认平衡能力再测原地踏步最后才测行走。每一步都确认稳定后再进下一步。准备一个急停。可以是物理开关也可以是键盘快捷键。一旦发现机器人动作异常立刻切断电机使能。我见过太多因为反应慢半拍而摔坏机器的案例。记录一切。每个周期的观测、动作、推理耗时、通信延迟全部记下来。出问题时日志是你唯一的线索。我习惯用二进制格式记录避免文本 I/O 拖慢控制循环。温度会改变一切。电机跑一会儿会发热发热后摩擦力、电阻都变策略可能就不稳了。如果发现机器人跑一会儿就摔很可能是热漂移。解决办法是在训练时加入电机参数随机化或者实机上做温度补偿。6. 从 MicroDuck 延伸出去这套方案还能怎么用MicroDuck 虽然是一只鸭子但它这套小网络 50Hz 闭环 ONNX 部署的框架其实可以迁移到很多场景。比如小型四足机器人、机械臂的视觉伺服、甚至无人机的姿态控制。核心思想是一样的用神经网络替代部分传统控制律用 ONNX 统一训练和部署用明确的控制频率保证实时性。如果你想在这套框架上做扩展我建议几个方向。一是加入视觉观测把摄像头图像经过轻量 CNN 编码后拼进观测向量让机器人能感知环境。这时候 ONNX 模型会变大50Hz 可能保不住需要考虑降频或者把视觉推理放到单独的线程。二是多步预测让网络输出未来几步的动作序列用 MPC 的思路滚动优化能提升步态平滑度。三是在线自适应用实机数据微调网络的部分参数应对负载变化和地面差异。热词里还有java onnx 车牌识别rmbg-2.0 人物抠图这些说明 ONNX 的应用场景非常广。如果你做的是视觉类项目MicroDuck 这套部署思路同样适用训练、导出、量化、选引擎、测延迟、闭环调试。区别只是控制频率和观测类型不同。我个人在实际操作中的体会是做这类项目最忌讳一步到位。不要想着一次把网络、量化、部署、实机全搞定。正确的节奏是先在仿真里把闭环跑通再导出 ONNX 验证一致性再上实机做站立再做行走最后才优化性能和量化。每一步都留好回退路径出问题能快速定位。这套流程看起来慢实际上比一把梭然后花几周排查要快得多。最后再分享一个小技巧给每个版本的策略网络和配置打上版本号实机日志里也记录版本号。这样当你发现某个版本表现好或坏时能准确回溯到当时的网络和参数。我吃过太多次改了参数忘了记录结果好结果复现不出来的亏后来养成习惯后调试效率提升非常明显。