复刻 Microduck 双足机器人：从仿真逆向重建到实物校准

来源：X @tspy

复刻 Microduck 的过程，先从纸面信息入手。Microduck 是一只 25 cm 高、重量不到 800 g 的双足机器鸭，配置为 15 个舵机、一颗摄像头、一个小型深度传感器（官方页面称 LiDAR）和两颗 IMU，可以行走、坐下、蹲下、从多数常见摔倒姿势中自行站起，也能轮滑 ^[5,7,11]。它的步态由 MuJoCo 仿真中的强化学习（PPO）训练而来，并不依赖预设程序；部署时由机身上的 50 Hz 控制环每 20 ms 执行一次 ^[0,5,7]。官网预售价 399 美元（税前），发布方为 Pollen Robotics（Hugging Face 旗下），SDK、仿真与完整训练栈都能在 GitHub 上找到 ^[5,7,11]。

复刻的第一个前提是搞清官方给了什么、没给什么。软件以 Apache-2.0 协议开源，硬件并未开源——官方没有提供 BOM、可编辑 CAD、PCB 原理图或装配文档 ^[2,4]。microduck_rl 训练仓库随强化学习代码发布了完整的 MJCF 仿真模型和 47 个 STL 网格 ^[2,4,18]。MJCF 中恰好包含了官方未公开的机械信息：每个零件的挂载关系、0.1 mm 精度的相对位置、旋转轴、行程、质量与惯量张量 ^[2,4]。因此复刻 Microduck 不能按图生产，只能从仿真模型反向提取装配关系，并让实物与训练体系共用同一套关节顺序、零位、观测布局和控制频率；这个契约若是两端不齐，仿真里练出的步态不会在真机上出现 ^[0,8]。

从 MJCF 能反向读出哪些硬件事实

第三方项目 microduck-replica 做的事情正是这种逆向推导：它从官方 MJCF 反推出零位姿态下的运动学装配关系，把 47 个带局部坐标系的网格按刚体归并为 15 个装配部件，输出装配图、爆炸图以及应用了世界变换、可直接导入 CAD 的 STL ^[2,17,18]。反推结果给出的硬件事实不少。15 个舵机全部属于 ROBOTIS Dynamixel XL330 级别 ^[2,4,10]。每条腿有 5 个自由度（hip_yaw、hip_roll、hip_pitch、knee、ankle），头颈有 4 个（neck_pitch、head_pitch、head_yaw、head_roll），其中 14 个受策略控制；第 15 个舵机驱动喙/下颚，通过被动连杆运作，不进入动作空间 ^[2,4,10]。模型也定义了关节行程：hip_yaw −25°~~+30°、hip_roll ±22°、hip_pitch/knee/ankle/head_pitch ±90°、neck_pitch −90°~~+60°、head_yaw ±170°、head_roll ±25° ^[4]。另外，电池为 NP-F550/F970 2S 锂电，主控是市售 Radxa Zero 3W（Rockchip RK3566），运动 IMU 为 LSM6DSV16X，另有一颗 IMX219 摄像头和 VL53L8CX 测距传感器 ^[4,6,10]。第三方还推断了轴承尺寸（22×16×4）、M2 紧固系统和自研 PCB 的用途，同时注明 PCB 无原理图、整机无走线方案 ^[4]。

第三方“仿真口径”统计给出的整机数据为：零位外包约 144×141×264 mm，刚体总质量 737.2 g，合并网格 796,792 个三角面；其中躯干主体 199 g，头部总成加喙 189 g ^[2,17,18]。头部质量约占整机四分之一且重心高，这使行走策略难以训练 ^[2,17]。737.2 g 与官方“不到 800 g”的说法并不冲突 ^[7,11]，因为前者只是第三方脚本针对特定版本 MJCF 的统计，并不代表官方制造尺寸或成品称重 ^[0,2]。

这批 STL 不能直接当工程图纸。仿真只关心外形和惯量，不承担配合公差、螺纹孔、热熔螺母座或走线空间 ^[18]；microduck-replica 在构建日志中验证了“仿真网格 ≠ 可打印工程件” ^[2]。要得到可装配零件，仍需用参数化实体重画舵机支架、轴承座、壳体分缝与紧固结构，并重新从 MJCF 建立 14 个受控旋转副和单独的嘴部机构。定位用 STL 本身不保存 joint pos、axis 或 range ^[0]。

控制链的结构与约束

真机运行时由七个纯 Rust 守护进程组成：robotd、updaterd、configd、btd、padd、mediad、tofd，彼此通过 Unix socket 上的 JSON-RPC 通信 ^[5]，并非以 ROS 为核心框架 ^[0]。官方设计文档把每个控制周期的时序写得很具体：Dynamixel 总线上执行一次 sync_read，同时读回 IMU 板和 15 个舵机；状态与命令被组装成 61 维观测 [f32; 61]；策略推理输出 [f32; 14]（不含嘴部），再换算为 15 个电机目标 [f64; 15]，对头部与腿部低通滤波后下发 ^[8]。

最容易错位的是两个数组：策略输出 14 个动作，运行时要插入含嘴部槽位的 15 元目标数组；官方实现中，15 个槽位的 index 9 保持为零 ^[8]。顺序一旦错位，网络照样能推理，但动作会送达错误关节——把右髋命令写到 index 9，等于把右腿动作发给嘴部 ^[0]。ID 分布也分段规定：15 个关节的 ID 位于 10–14、20–24、30–34 三段 ^[8]。

输入输出形状、单位、符号、home pose 与动作缩放必须两端一致 ^[0]。观测归一化器要固化到 ONNX 导出文件；推理前做一次 warm-up，避免首次调用延迟落入控制周期 ^[0]。这里有一个隐蔽陷阱：仿真环境里直接播放策略，框架会替你应用训练时的归一化器，因此错误导出的网络在仿真中可能一切正常；真机没有这一层辅助，必须走官方导出路径，不能把 .pt checkpoint 手工转成 ONNX 就上线 ^[0]。

训练设置里已经给出这条链的物理前提：官方执行器模型详细到 XL330 的电压控制律、反电动势、库仑/Stribeck 摩擦与负载相关摩擦，还建了齿轮间隙模型，并针对电池电压、负载压降、指令延迟与摩擦系数逐个做随机化 ^[5]。官方给出的解释很直接：在不到 800 g 的小舵机双足机器人尺度上，执行器精度构成了仿真与现实差距的主要来源 ^[5]。

先在仿真中“看见”策略

做硬件之前，先在本机跑通官方训练环境，直接观察策略的输入、输出和关节对应关系 ^[0]。microduck_rl 用 uv 管理依赖（要求 Python ≥3.12 且 <3.13）。先安装 uv，再进入仓库，后续命令会依照锁文件自动同步环境 ^[0,1]。训练主路径要求 NVIDIA CUDA GPU；查看任务、运行 CPU 测试和 ONNX CPU 复演则不需要本地 CUDA ^[0]。仓库目前包含行走、行走加跌倒恢复、起身、坐站、触地拾取、踢球、前滚翻和多种轮滑任务 ^[0,6]。低成本冒烟测试是“64 个环境、5 次迭代”，目标是提前暴露配置、观测和导出问题 ^[0]。训练时间参考：现代 CUDA GPU 上约 1–2 小时能得到可用步态，但这取决于 GPU 型号、代码版本与训练配置，不能当作保证 ^[0]。若没有本地 CUDA GPU，同一条命令可提交到 Hugging Face Jobs 提供的托管云执行——该服务省去自建 GPU，但需要账号、权限与配额 ^[0,27]。

这里有一个反直觉的结论：仿真里那些看似拖慢训练的随机化和执行器细节，不能为了训练指标好看而删除。删掉电压随机化、摩擦、命令延迟等内容，仿真中的策略可能更顺眼，但迁移到真机通常更差 ^[0,5]。

电气先行：先台架，别急着装整机

供电与总线是最容易烧板子的环节，且材料中存在一处矛盾：官方 RL 执行器模型的输入电压被随机化为 6.5–8.2 V，运行时也从舵机回报值估计 2S 电池电压；而市售 XL330-M288-T 输入范围标称 3.7–6.0 V、推荐 5.0 V ^[0]。满电 2S 电池约 8.4 V，直接接母线会超出市售舵机手册允许值 ^[0]。公开资料没有说明量产机是否使用特殊版本舵机，也没有说电源路径是否包含未公开设计，所以复刻时不能将 RL 参数当作电气规格。应当按实物数据手册设计稳压，实测母线与执行器响应后回填模型并重训；若想复用官方 ONNX，还要先独立确认原机舵机版本与供电路径 ^[0]。

总线物理层的官方基线是 TTL 半双工、单线数据、Dynamixel Protocol 2.0、1,000,000 baud、端口 /dev/ttyS2。这里 3.3 V 是数据线逻辑电平，不是舵机供电电压 ^[0]。每颗舵机必须有唯一 ID；重复 ID 会使回复碰撞，症状看起来可能与电源或串口噪声近似 ^[0]。台架测试按“不接舵机看串口 → 单颗舵机读写 → 加入第二颗做 sync_read → 扩展一条腿 → 上满 15 颗 → 再接入 ID 200 的 IMU 板”的次序推进 ^[0]。采购次序与之类似：第一版只围绕“能站、能走”买主控、1–3 颗舵机、总线接口和限流电源；摄像头、ToF、音频和 NFC 等扩展件等步态稳定后再加 ^[0,7]。

运动 IMU 不像常规外设那样通过另一条 USB 或 I²C 读取，而是被封装成 ID 200 的 Dynamixel 从设备（imu_to_dxl 板，核心为 LSM6DSV16X），与舵机共用同一条总线 ^[8,0,10]。自制替代板需要复现它的 ID、寄存器布局、采样频率和坐标方向 ^[0]。素材提醒，基本行走不能长期依赖与训练模型不匹配的 USB IMU 临时方案 ^[0]。

主控与校准：机械零位必须等于仿真的 home pose

官方部署目标板是 Radxa Zero 3W（RK3566）^[4,6,10]。素材中官方文档要求该板使用 Armbian 26.2.1 Minimal，但又提醒：官方安装文档与发布系统仍在演进，不要机械执行旧教程里的命令 ^[0]。Armbian 官方目录当前为 Radxa Zero 3 推荐更新的稳定镜像（如 26.8.1 Minimal）^[3]。配置阶段有两个已知问题：Armbian 默认可能在 /dev/ttyS2 上启动 serial-getty，从而占住舵机串口，需要确认占用者后禁用 ^[0]；robotd、旧运行时、调试脚本和 USB 适配器不能同时控制同一条串口，两个进程交错发包会表现为随机硬件故障 ^[0]。

校准是 Sim-to-Real 中最“软”也最关键的一步：它建立的是舵机编码器读数、机械安装角和 MJCF 关节角之间的准确对应，这个对应关系比视觉上的站直与否更深一层 ^[0]。官方运行时的控制目标是 target = home_pose + action_scale × action ^[8]。若某个关节的零位偏差 5°，策略会以为它已在正确位置，真实机械却是歪的，于是策略调用其他关节补偿，典型表现是抖动、歪站、膝盖过热或一迈步就倒 ^[0]。校准应从单颗舵机入手：设置唯一 ID、方向、限位和零位偏移，做无负载小幅运动，核对仿真中的正方向与真实正方向，最后再在吊架或支架承托下让整机逐步回到 home pose ^[0]。

真机调试按分级顺序推进：单舵机 → 一条腿 → 15 颗舵机扭矩关闭 → 接入 IMU 后一次 sync_read 能稳定读取 → 缓慢回 home pose → 脚离地运行策略 → 双脚着地且外部扶持 → 保护绳下独立站立 → 扶持行走 → 短距离自由行走（从 0.2 m 开始）^[0]。任何一级出现方向、限位、供电、温升、时序或通信异常，都应停在该级解决，不要带病进入下一级 ^[0]。每次测试保存日志，包括 61 维观测、14 维动作、目标与实测位置、母线电压、舵机温度、总线时序和视频；记录完整的摔倒过程才能与 MuJoCo 同步对比，缺失日志时只能靠视频推测 ^[0]。

策略是“认硬件”的：硬件一变就要重训

强化学习策略所适应的是训练模型中的重量、惯量、摩擦、回差和执行器响应 ^[0]。换舵机型号、改变关节减速比/速度/力矩曲线、回差变化、通信延迟变化、整机增重或质心移动、腿长和足底摩擦的改变、IMU 安装角度变化、控制频率或电池电压范围改变，都会破坏既有策略的迁移前提 ^[0]。microduck-replica 提醒，官方策略 ONNX 只对原本体有效，更换电控后需重训 ^[4]。因此正确步骤是按“测量新硬件 → 更新 MJCF 的质量/惯量/几何/限位 → 辨识执行器摩擦、回差与延迟 → 更新 domain randomization → 冒烟测试 → 重训 → 导出 ONNX → CPU 复演 → 真机扶持测试”完整走一遍，而不能靠调大 action_scale 硬撑 ^[0]。

项目验收不以“能走起来”为终点。仿真、机械、电气、软件与真机各有可重复检查项：CPU 测试与 64 环境冒烟测试通过；ONNX 由官方脚本导出且 CPU 复演正常；CAD 中重建了 joint pos/axis/range，没有把定位 STL 当成运动装配体；母线电压实测落在所购舵机手册允许范围；UART2 无第二占用者；home pose 与实物零位一致；50 Hz 运行一小时无持续错误；真机按吊架 → 扶持 → 保护绳 → 短距离自由行走逐级通过，并且每次测试留有日志和视频 ^[0]。