从英伟达 GPU 的仿真训练环境，到 RK3566 这块典型边缘芯片的实机推理，Microduck 这条 25 厘米的强化学习小机器人，几乎把“训练到部署”这条链路里能踩的坑都让我踩了一遍。这篇手记不聊概念，只讲实操：怎么把强化学习策略从 GPU 上搬下来、如何在 RK3566 上跑满控制频率、以及在泰山派这类开发板上遇到的“识别为 ADB 设备”之类的诡异问题，我都会把解决方案和排查思路写清楚。
如果你手上正好有一块 RK3566 开发板，又对 Microduck 这类开源强化学习四足机器人感兴趣，这篇内容应该能帮你节约至少一周的试错时间。它适合已经跑通过仿真训练、但还没真正把策略部署到实体机器上的读者，也适合正在纠结“RK3566 到底能不能跑强化学习策略”的人。
1. 项目背景与整体思路拆解
1.1 为什么是 Microduck：一个把仿真和实机打通的开源平台
Microduck 是一个 25 厘米级别的开源四足机器人项目，硬件结构、训练代码、部署代码都放出来了。和很多只提供仿真环境的项目不同，Microduck 从设计之初就考虑了“训练完怎么往实体上搬”的问题。官方的 GitHub 仓库里不仅有 rsl_rl 这种常用的强化学习训练框架配置，还有针对嵌入式平台的推理示例，这是它最大的价值所在。
选它的原因很简单：我需要在真实硬件上验证强化学习运动控制策略，而不是永远停留在仿真动画里。Microduck 这种尺寸和结构，既不像大型机器狗那样需要昂贵的伺服电机和结构件，也不会因为太小而难以承载运控板和电池。25 厘米这个尺寸，电机选型、结构强度、控制板算力之间的平衡已经有人帮你趟过了。
不过 Microduck 默认的运控平台算力并不算强，它更偏向 MCU 级别的实时控制。我这次的工作量主要在于：在英伟达 GPU 上训练策略、把训练好的策略网络转换成适合边缘推理的格式、然后在 RK3566 上做实时推理并输出控制指令。
1.2 整体技术路线：GPU 训练加边缘推理的双层架构
强化学习运动控制有个特点：训练阶段需要大量采样和反复试错，必须靠 GPU 的并行算力才能把时间压到可接受范围。但实机部署时，机器人本体根本背不了一块大显卡，所以训练和推理必须拆成两层：
- 训练层：英伟达 GPU（我用的是 RTX 4090），跑 rsl_rl 训练框架，仿真环境用 Isaac Gym 或 MuJoCo，训练目标是让策略网络学到“在平坦地形上稳定行走”的控制策略。
- 部署层：RK3566，作为边缘推理单元，加载训练好的策略网络，实时读取电机编码器和 IMU 数据，推理出关节目标位置并下发到电机驱动板。
这里很多人会问：为什么不用树莓派或者干脆用 Jeston Nano？因为 RK3566 有独立的 NPU，虽然我最终选择了 CPU 推理方案（原因后面细说），但从成本和国产供应链的角度看，RK3566 是一个很稳妥的选择。它还有丰富的外设接口，串口、I2C、SPI 都有，接电机驱动板和 IMU 都方便。
1.3 方案选型的取舍：为什么不用 Jetson
我最初想过直接上 Jetson Orin Nano，毕竟它在生态上对 AI 推理更友好。但最终放弃，原因有三：
第一是功耗。Microduck 是 25 厘米级别的小型机器人，电池容量有限，Jetson 的高功耗会严重影响续航。RK3566 的典型功耗只有几瓦，对小型机器人来说压力小很多。
第二是成本。一张 Jetson 开发板的价格能买好几块 RK3566 开发板，而这个小机器人对推理算力的需求真的不高。
第三是启动和调试效率。RK3566 可以跑精简的 Linux 系统，通过 SSH 登录调试，和服务器端训练环境无缝衔接。这比在 MCU 上把 C 代码烧进去调试要舒服得多。
2. 核心硬件与原理解析
2.1 RK3566 的性能边界：跑强化学习策略够不够
RK3566 是瑞芯微推出的一款四核 Cortex-A55 处理器，最高频率 1.8GHz 左右，集成 Mali-G52 GPU 和 0.8TOPS 算力的 NPU。单看算力，和英伟达的 GPU 完全不是一个量级，但要说跑强化学习运动控制策略，它其实是绰绰有余的。
强化学习运动控制策略的网络结构通常很轻量：一个两层的 MLP（多层感知机），输入维度 30 到 40 左右，隐藏层 128 到 256 个神经元，输出维度是关节数量（Microduck 是 12 个）。这种网络在 CPU 上跑一次前向推理，耗时通常在 1 毫秒以内，完全能满足 500Hz 甚至 1000Hz 的控制频率。
真正决定系统能不能跑稳的，不是 CPU 算力，而是推理延迟的一致性。也就是说，你不能这次推理 0.5 毫秒、下次突然变成 20 毫秒，这种抖动对控制稳定性是致命的。RK3566 在跑裸机 Linux 的前提下，通过 CPU 亲和性设置和实时线程优先级，可以把推理延迟稳定控制在 2 毫秒以内，这是能实现稳定步态的关键前提。
2.2 Microduck 本体的控制链路：从策略输出到关节动作
Microduck 的本体采用典型的串行总线舵机方案，每个关节电机通过串行总线连接到驱动板。控制链路大致如下：
- RK3566 上的主程序读取 IMU 数据（包括四元数、角速度）和各关节编码器角度。
- 将观测向量拼接后送入策略网络推理，得到 12 个关节的目标位置（或者目标扭矩，取决于训练时的动作空间定义）。
- 通过串口或总线发送指令给电机驱动板，驱动板完成底层的位置环或扭矩环控制。
这中间的关键在于观测向量的构建。Microduck 的策略输入通常包括：本体线速度估计、角速度、IMU 姿态四元数、上一时刻的动作输出、以及目标速度指令等。这些数据必须在每次控制循环内统一采集，时间戳要对齐，否则策略网络的输入分布和训练时不一致，实机表现会明显劣化。
2.3 为什么低延迟推理是强化学习机器人落地的生命线
强化学习运动控制的策略网络本质上是一个“状态到动作”的映射函数。它不像传统 PID 那样有明确的物理模型支撑，而是完全依赖训练时学到的映射关系。如果推理延迟过大，控制器看到的状态就已经“过时”了，输出的动作自然也不匹配当前实际状态，形成恶性循环——机器人会开始抖动甚至摔倒。
我在实测中发现，当控制频率从 500Hz 降到 200Hz 时，Microduck 的行走姿态会肉眼可见地变差，出现明显的点头动作和侧向漂移。所以部署阶段的首要任务，就是保证推理能在一个稳定且足够高的频率下运行。这也是为什么我不建议在 RK3566 上用 Python 直接做推理的原因——Python 的解释执行开销和内存管理不确定性，很难保证实时性。
3. 英伟达 GPU 训练阶段的实操记录
3.1 训练环境搭建：从零到出策略的完整流程
训练阶段我用的是 Ubuntu 22.04 加 RTX 4090，CUDA 12.1，PyTorch 2.1。训练框架方面，Microduck 官方推荐的是 rsl_rl，配合 Isaac Gym 或 MuJoCo 仿真环境。我这次用的是 Isaac Gym，因为它的并行环境数量多，训练速度更快。
环境搭建有几个容易出问题的地方：
- Isaac Gym 需要单独下载安装包，pip 直接装没有。安装后记得跑一下示例脚本确认渲染和物理引擎都能正常工作。
- rsl_rl 的版本和 Isaac Gym 的版本需要匹配，否则会出现 API 不兼容的报错。官方仓库里通常会锁版本，建议严格按 requirements 来。
- 训练配置里有个
num_envs参数，决定了并行环境的数量。4090 这种卡可以开到 4096，性能差一点的卡建议降到 2048 或更低，否则会显存溢出。
安装完依赖后，我直接用了官方仓库里 Microduck 的训练配置。这个配置已经写好了足式机器人的基本奖励函数和地形参数，不需要从零调参。
3.2 训练命令与关键参数解读
启动训练的命令很简单，本质上是调用rsl_rl的训练入口，指定 Microduck 的配置文件：
python train.py --task microduck_flat --num_envs 4096 --max_iterations 5000 --headless几个关键参数的含义：
--task microduck_flat：指定任务名称，这里对应平坦地形行走。如果要训练上坡或者其他地形，需要换对应的任务配置。--num_envs 4096：并行环境数，直接影响训练速度和显存占用。数值越大，单次迭代采集的样本越多，训练越稳定。--max_iterations 5000：最大迭代次数。实际上我在 3000 多步时策略就已经收敛了，后面继续训练收益不大。--headless：关掉渲染，加快训练速度。
奖励函数这块我没有做调整，直接用官方的。值得说明的是，强化学习训练出来的策略并不是每一步动作都“合理”，它只是在最大化累计奖励的意义上表现良好。所以训练完一定要在仿真环境里跑几个回合，观察步态是否自然、是否有异常抖动，再决定是不是要部署到实机。
3.3 训练观测与策略收敛判断
训练过程中要盯几个关键指标：平均奖励、平均 episode 长度和策略熵。平均奖励应该是总体上升趋势，中间有波动是正常的，因为强化学习本身就有探索噪声。平均 episode 长度如果长期打不满，说明机器人经常摔倒或提前终止。策略熵如果骤降，说明策略过早地锁死在了某个局部最优解。
我在训练时把日志输出到了 TensorBoard，每 50 次迭代刷新一次。大约在 2500 次迭代左右，平均奖励进入平台期，机器人已经能稳定走完全程不摔倒。这时候就可以停掉训练，开始跑测试：
python play.py --task microduck_flat --load_run /path/to/logs --num_envs 16测试没有问题后，训练模型会保存在logs/目录下，通常是一个.pt格式的 PyTorch 模型文件，里面包含策略网络的权重。
3.4 训练阶段我踩过的坑：奖励异常和仿真实机差异
训练过程中我遇到过一个很典型的问题：策略在仿真里走得很好，放到实机上就瘫了。原因是仿真和实机的动力学参数存在差异，比如电机的响应延迟、关节的摩擦力、IMU 的噪声特性。这不是训练代码的问题，而是 sim-to-real 的经典难题。
缓解办法有几个：
第一是训练时引入随机化，也就是 domain randomization。在 Isaac Gym 的配置里，可以把电机的最大扭矩、摩擦力、IMU 噪声等参数设置一个随机范围，让策略学会在参数不确定的情况下也能保持稳定。
第二是降低控制频率到和实机一致。如果你仿真里跑 1000Hz，实机只能跑 500Hz，那策略在实机上大概率表现不佳。训练前先确认好部署端的控制频率，仿真里就按这个频率来。
第三是动作空间的选择。位置控制模式比扭矩控制模式更容易迁移到实机。因为位置环由电机驱动器完成，对模型的准确性要求相对低一些。Microduck 官方方案倾向于用位置控制，实机调试会省很多事。
4. 从 GPU 模型到 RK3566 实机部署
4.1 模型格式转换：PyTorch 转 ONNX 再转 RKNN 的完整流程
训练得到的模型是 PyTorchnn.Module，不能直接在 RK3566 上跑。我的转换链路过一遍大致是：PyTorch 导出 ONNX，再把 ONNX 转成 RKNN 格式用 NPU 推理；如果只想用 CPU，ONNX Runtime 就够了。
先看导出 ONNX 的代码。注意要指定输入输出的维度，并用训练时的观测维度做 dummy input：
import torch from rsl_rl.networks import ActorCritic # 加载训练好的模型 model = ActorCritic(num_obs=38, num_actions=12) checkpoint = torch.load("model.pt", map_location="cpu") model.load_state_dict(checkpoint["model_state_dict"]) model.eval() # 导出 ONNX dummy_input = torch.randn(1, 38) torch.onnx.export( model.actor, dummy_input, "microduck_policy.onnx", opset_version=11, input_names=["obs"], output_names=["actions"], dynamic_axes={"obs": {0: "batch_size"}, "actions": {0: "batch_size"}} )这里有几个关键点：
- 导出的是
model.actor而不是整个ActorCritic，因为部署时只需要策略网络，不需要 critic。 opset_version=11是一个兼容性比较好的选择，RKNN 工具链对高版本 opset 的支持有时会滞后。dynamic_axes设置成动态 batch，这样推理时既能用 batch=1 做单帧推理，也能用 batch 为 8 或 16 做批量推理（比如同时仿真多个机器人）。
4.2 RK3566 上的部署方案：CPU 推理还是 NPU 推理
这里我做了两种方案的对比测试，结论可能和你想的不一样：在 Microduck 这个场景下，CPU 上用 ONNX Runtime 推理，比用 NPU 的 RKNN 推理更加稳定可控。
| 方案 | 单次推理耗时 | 稳定性 | 部署复杂度 |
|---|---|---|---|
| ONNX Runtime (CPU) | 0.6 - 1.2 ms | 稳定 | 低 |
| RKNN (NPU) | 0.4 - 0.8 ms | 偶发波动 | 高 |
NPU 推理的优势在于释放了 CPU 资源，但 RK3566 的 NPU 在跑这个极小网络时，优势并不明显，反而引入了额外的转换和调试成本。CPU 推理 1 毫秒以内的耗时已经是控制周期的零头了，用 CPU 方案反而让整体链路更简单。
如果你后续要把视觉模型也部署上来，那 NPU 就值得用了。但就纯运动控制策略而言，CPU 推理完全够用。
ONNX Runtime 在 RK3566 上的安装很简单，直接 pip 装就行：
pip install onnxruntime推理代码核心逻辑如下：
import onnxruntime as ort import numpy as np sess = ort.InferenceSession("microduck_policy.onnx", providers=["CPUExecutionProvider"]) obs = np.random.randn(1, 38).astype(np.float32) actions = sess.run(None, {"obs": obs})[0]在 RK3566 这种低算力设备上，推理延迟的关键因素除了网络结构本身外，还包括：
- 输入数据必须是
float32且连续内存，避免不必要的类型转换和复制。 - 线程数设置为 2 到 4 即可，不用全开。全开反而会因为线程切换开销增加延迟抖动。
- 用
sess.run的返回值直接复用缓冲区，避免每次推理都重新分配内存。
4.3 实机联调的软件架构：控制主循环和实时性设计
RK3566 上的主程序我写了一个简单的控制循环，用 C++ 调用 ONNX Runtime 的 C API 做推理，控制频率设定在 500Hz。整个循环大致是：
- 读取 IMU 数据（通过 I2C 或 SPI 接口）。
- 读取电机编码器反馈（通过串口总线）。
- 构建观测向量。
- 调用 ONNX Runtime 推理得到 12 个动作值。
- 通过串口总线下发到电机驱动板。
关键的设计考量是：把实时性要求高的控制循环绑定到指定的 CPU 核心上，避免被 Linux 内核调度到其他核心上引入延迟抖动。在 RK3566 上可以用pthread_setaffinity_np实现 CPU 亲和性绑定，再用sched_setscheduler提高线程优先级到实时级别。
代码片段大致如下：
cpu_set_t cpuset; CPU_ZERO(&cpuset); CPU_SET(3, &cpuset); // 绑定到核心 3 pthread_setaffinity_np(pthread_self(), sizeof(cpuset), &cpuset); struct sched_param param = {.sched_priority = 80}; sched_setscheduler(pthread_self(), SCHED_FIFO, ¶m);这个优化非常重要。不绑核的时候，推理延迟偶尔会飙到 10 毫秒以上，机器人走几步就开始抖；绑核之后，延迟稳定在 2 毫秒以内，步态明显稳了很多。
4.4 部署后的性能实测数据
完成部署后，我记录了一组实际的性能数据：
- 控制频率：500Hz（周期 2ms）
- ONNX Runtime CPU 单次推理耗时：平均 0.82ms，最大 1.4ms
- IMU 读取耗时：约 0.3ms
- 串口通信下发耗时：约 0.5ms
- 整机累计功耗：约 6W 左右
这个数据意味着，整个控制循环的耗时在 2 毫秒以内，有接近一半的时间余量。当我要加入额外的状态估计或者滤波算法时，也还有足够的算力冗余。
5. 实机调试、常见问题与排查实录
5.1 电机驱动使能异常：上电没反应怎么办
Microduck 上电后，如果你发现电机完全没有响应，先别急着查代码。这类问题 70% 出在供电上。Microduck 的电机峰值电流不小，如果电池内阻大或者电源线太细，电机一启动就会把电压拉低，导致驱动板自动保护。
我的排查顺序是：
- 先量电池电压，确认在正常范围。
- 接上电机后电压是否有瞬态跌落。如果跌落超过 0.5V，基本可以确定是电源线过细或者电池老化。
- 用示波器抓驱动板的供电波形，确认没有高频振荡。
如果供电没问题，再看看驱动板是否正常识别串口总线上的电机。很多串行总线舵机需要在驱动板上设置 ID 和波特率，ID 冲突或者波特率不匹配都会导致电机无响应。
5.2 推理超时导致的机器人失稳抖动
这是我在实机调试中最常遇到的问题。现象是：机器人走几步就出现剧烈抖动，像是肌肉痉挛一样，然后摔倒。看日志发现有些控制周期的推理耗时超过了 10 毫秒。
原因分析下来有两个：
- 主程序里有其他线程占用了大量 CPU，导致控制线程被抢占。解决办法就是前面提到的 CPU 亲和性绑定，以及把不重要的任务（比如日志写入、可视化）放到其他核心上。
- 日志写入频繁调用磁盘 I/O，同步阻塞了控制循环。解决办法是把日志写入改成异步队列，先攒着，控制循环之外再写。
建议你在实机调试时，给控制线程打一个时间戳，实时监测每个循环的实际耗时。一旦发现耗时有超过 5 毫秒的情况，就优先排查是不是其他任务干扰了控制线程。
5.3 IMU 数据异常导致的姿态估计偏差
Microduck 用到 IMU 的加速度计和陀螺仪数据来估计身体姿态，强化学习策略对姿态质量很敏感。我有一次把 IMU 线接在电机驱动线旁边，结果电机一启动，IMU 数据就全是噪声，机器人直接原地打转。
后来把 IMU 线单独走线，远离电机驱动线，并加了一颗小电容滤波，问题就解决了。如果 IMU 数据仍然抖动，可以在代码里做低通滤波，但要注意滤波延迟不能太大，否则会给控制器引入相位滞后。
5.4 泰山派识别到 RK3566 但出现 ADB 设备的处理方式
很多 RK3566 开发板（包括泰山派）出厂固件默认开启了 USB ADB 模式，插到电脑上会被识别成一个 ADB 设备，而不是我们预期的 USB 网卡或串口设备。这不影响板子本身的运行，但会干扰你通过 USB 连接调试。
处理方法有两种：
- 如果只需要 SSH 登录，直接看板子在局域网里的 IP，用
ssh root@板子IP登录就行，不需要管 ADB。 - 如果确实需要通过 USB 串口登录，需要进入系统后修改 USB 设备的模式配置，把 ADB 功能关掉，或者改成 RNDIS（USB 虚拟网卡）模式。
我推荐直接用 SSH 加网线或者 WiFi 的方式，简单稳定。ADB 模式留着急救用就行。
5.5 我的实机调试顺序建议
如果你准备从零开始部署一台强化学习机器人，建议按这个顺序来，能少走很多弯路：
- 先让电机转起来。用最简单的代码写一个正弦波测试，确认驱动板、串口通信和电机本身都是好的。
- 然后测试 IMU 数据。放在桌面上静止时，姿态角应该非常稳定，噪声幅度在几度以内。
- 接着做开环动作测试。给机器人一个固定的姿态目标，手动掰它的腿，确认每个关节的方向正确、限位合理。
- 最后才是加载强化学习策略。而且第一次加载时，最好用绳子把机器人吊起来，让腿悬空，确认推理输出的动作序列是合理的，再让它落地行走。
如果第四步直接落地跑，电机输出异常时很可能直接损坏结构件或舵机。我自己的 Microduck 就因为这个原因换过一次腿部的连接件。
最后再分享一个小技巧：部署强化学习策略到实机时，不要一上来就加载“在仿真里表现最好”的那个模型。我习惯在训练快结束前多存几个 checkpoint，然后实机逐个测试。有时候仿真里次优的模型，在实机上反而更稳，因为它的动作更保守、更平滑。多试两个模型，也许能帮你省下大量的调参时间。
