Microduck 从零上手

这一栏按实际动手的顺序编排：拿到硬件之后先查什么、怎么给关节上电、怎么配手柄、以及什么都不动的时候该看哪里。

先建立三个概念

在敲第一条命令之前，有三件事值得先知道。它们决定了你之后所有的排查方向。

一、它靠神经网络策略行走，不是靠步态代码

Microduck 约 25 cm、800 g，主控是 Rockchip RK3566。机身上跑着一组 Rust 写的守护进程，其中 robotd 以 50 Hz 的控制循环驱动 15 个舵机——动作来自 .onnx 策略文件，不是手写的步态算法。

这一点直接改变排查思路：

“机器人不动”最常见的原因是策略没加载，而不是电机坏了。

robotctl monitor 的底部边框会显示当前加载的是哪个 .onnx。没有策略的机器人会明说，策略加载失败的会显示另一种状态——这两种在数据流里是分辨不出来的。

二、按 Start 之前什么都不会动

手柄的 Start 键切换策略开关。关闭状态下，机器人上电站着，但完全不理会摇杆。

这是最常见的“它坏了”误判。上电（robot init）和启用策略（Start）是两件独立的事。

三、功能是按守护进程切分的

排查时知道该看谁的日志，能省掉大量时间：

现象	归谁管
电机、步态、安全限制、跌倒判定	robotd
手柄读取	padd
手柄配对	configd（不是 padd——绑定设备需要 root）
wifi、机器人身份、电源	configd
摄像头、WebRTC、网页控制台	mediad
系统更新与回滚	updaterd
头部 ToF 深度传感器	tofd
手机 App 走的 BLE 通道	btd

完整的切分理由见系统架构。

三条命令解决八成问题

robotctl version    # 各进程跑的版本 vs 已装版本 —— 永远先跑这条
robotctl health     # 硬件+软件健康，不健康时非零退出
robotctl monitor    # 请求值 vs 实际值，并说明差异原因

version 排在第一不是随意的：更新之后某个守护进程仍在跑旧代码，表现出来和“你刚修的 bug 没修好”一模一样。 先排除这种情况，能避免一整轮方向错误的排查。

monitor 是信息量最大的一个。安全机制会持续钳制指令，“摇杆推到底但机器人不动”在没有原因说明时无法解读——它会直接写出来，比如 deadman — no intent arrived recently, velocity zeroed。

没有硬件也能开始

• 在线仿真器（Hugging Face Space）——直接在浏览器里看仿真环境。
• 训练环境——scripts/infer_policy.py 能在 CPU 版 MuJoCo 里用键盘驱动导出的策略，不需要机器人。
• 想先了解全貌，读官方资料入口。