强化学习四足机器人Microduck实战：从GPU训练到RK3566实机部署

这段时间一直在折腾 Microduck 的实机部署，从最初的英伟达 GPU 训练环境，到最后落到一块 RK3566 主控的小机器人上，整个过程踩了不少坑，也理清楚了一条可以复用的链路。如果你手里正好有类似的强化学习机器人，比如低成本四足、双足或者机械臂，想把它从仿真里搬到实体硬件上跑，这篇文章应该对你有帮助。Microduck 是一台 25 厘米级别的四足机器人，运动控制策略完全靠强化学习训练得到，而部署目标选的是 RK3566 这种千元以内的 ARM 开发板——这种"高端训练、低端推理"的组合，其实是目前个人开发者做 sim-to-real 落地最常见的配置。

我会从方案选型、GPU 训练侧的关键环节、RK3566 实机部署的完整流程、仿真到实机的调参差异，以及问题排查几个部分展开。文章里所有步骤都是我在实际项目中验证过的，有些是通用流程，有些是特定场景下的处理方式，你直接照着做大概率能跑通。

1. 方案选型：为什么是 RK3566，Microduck 的整体链路

1.1 25 厘米级四足机器人为什么需要一套完整的训练部署链路

Microduck 这个级别的机器人，整机尺寸只有 25 厘米左右，重量一般在 1 到 2 公斤之间，关节用的是小型总线舵机或者带编码器的减速电机。它跟那种动辄几千上万的科研级四足（比如 Unitree Go2、ANYmal 这类）最大的区别是成本敏感，主控不可能上工控机或者高性能 Jetson，一块 RK3566 开发板加上外围电路，成本能压到非常低。

但这个尺寸的机器人有一个很尴尬的问题：动力学模型难建。25 厘米的小 robot，连杆短、惯量小、舵机响应非线性明显，如果你用传统 MPC、ZMP 那套基于模型的运动控制方法，光辨识动力学参数就能把你搞崩溃。强化学习恰恰绕开了这一步——它直接在仿真环境里通过大量试错学出一个从观测到关节指令的映射，不需要你手动建模，只需要你把仿真里的物理属性调到和真实硬件足够接近就行。

而"仿真训练 + 实机部署"这条链路，天然就分成了两个算力需求完全不同的阶段：

• 训练阶段：需要大规模并行仿真，成千上万个环境同时跑，只有英伟达 GPU 能干这件事。业内常用的 legged_gym、Isaac Lab、rsl_rl 都是基于 Isaac Gym 或者 Isaac Sim 写的，一个 RTX 3090 就能同时跑几千个环境。
• 部署阶段：只需要跑一个训练好的神经网络前向推理。策略网络通常很小，全连接层两三百万参数，单次推理的浮点运算量在几百万到几千万 FLOPs 这个量级，CPU 完全扛得住。RK3566 的四核 A55 跑 ONNX 推理，单次前向 1 到 3 毫秒，绰绰有余。

所以整个项目的核心思路就是用 GPU 的算力去换机器人本体的算力需求，用仿真的大量试错去换实机的调试时间。这个思路不止适用于 Microduck，你可以把任意一个基于强化学习的运动控制任务代入进来。

1.2 训练到部署的四段式链路拆解

我最终跑通的技术链路可以概括为四段：

仿真训练（英伟达 GPU + legged_gym/rsl_rl） → 策略导出（ONNX） → 板端推理（RK3566 + onnxruntime/rknn） → 实机控制（主循环 + 舵机/传感器）

第一段是训练，跑 PPO 或者类似算法的策略梯度更新，得到的是一个 PyTorch 模型权重文件。第二段是把 PyTorch 模型转成 ONNX，这一步很关键但经常被忽略：ONNX 是框架无关的中间表示，转换之后你才能在 RK3566 上用 onnxruntime 做 CPU 推理，或者用 rknn-toolkit2 转到 NPU 上。

第三段是板端推理。RK3566 的方案有两种：最简单的直接用 onnxruntime 的 arm64 版本跑 CPU 推理，这种方式不折腾 NPU，部署最快；另一种是用瑞芯微的 rknn-toolkit2 把 ONNX 转成 RKNN 格式，跑 NPU 加速，能效比更高，但转换过程容易被算子卡住，需要来回调整网络结构。

第四段是实机控制环。RK3566 上要写一个固定频率的控制主循环，一般是 50Hz 或者 100Hz，每个周期读 IMU 和关节编码器，组装观测向量，喂给策略网络，拿到动作输出，再映射成舵机目标角度，通过串口或者总线发给执行器。

这四个阶段说起来简单，但每一步都有大量细节决定你最后能不能让机器人真的站起来走两步。下面我从训练侧开始逐个拆。

2. GPU 训练侧：让策略先在仿真里跑稳

2.1 训练框架与强化学习算法选型

Microduck 这类四足机器人强化学习训练，目前主流选择是 legged_gym 或者以它为模板魔改的仓库，底层依赖 Isaac Gym 做仿真环境，用 rsl_rl 里的 PPO 做策略学习。legged_gym的代码结构很清楚，它把机器人建模、奖励函数、域随机化、训练循环都拆开了，你不用从零写 PPO，只需要改配置文件和奖励函数。

算法层面我建议直接上 PPO，不要一上来就试 SAC、TD3 这些 off-policy 算法。原因很简单：PPO 是 on-policy 算法，天然适合并行环境下的仿真训练，而且对超参数不那么敏感，收敛曲线稳定。legged_gym 自带的 PPO 实现已经调得不错了，你换一个算法反而要重新调一大堆东西。

训练的时候我用的是一块 RTX 4070 Ti，4096 个并行环境。跑一个完整的四足行走策略，大概 1 到 2 万步就能看到明显的运动效果，当然这个要看你的奖励函数设计。这个问题在网络热词里出现频率很高：microduck 怎么训练。其实流程不复杂，复杂的是你训练出来的策略能不能迁移到实机。

一个值得注意的点：ugly 的奖励函数会让网络学到一些"作弊"行为。比如你希望它往前走，如果你只给速度奖励，它会学到一种高频抖动身体、靠惯性滑行的姿势，速度确实上去了，但姿态极其诡异。这种策略在仿真里能用，到实机上根本走不了几步就翻车。所以奖励设计必须包含姿态稳定、关节极限约束、能量惩罚这几个维度。

2.2 观测空间、动作空间与域随机化

Microduck 的策略输入（观测空间）我要多说几句，因为它直接决定了实机部署时你要接哪些传感器。常见配置是：

• 机身姿态：roll、pitch，来自 IMU（yaw 一般不直接用，因为漂移严重）
• 机身角速度：roll rate、pitch rate、yaw rate，同样来自 IMU 陀螺仪
• 关节角度：每条腿 2 到 3 个自由度，整机 8 到 12 个关节，数值来自关节编码器
• 关节角速度：可以从编码器差分得到，或者用舵机反馈的速度
• 历史动作：把前两步的动作也放进观测里，相当于给策略一点"记忆"，能显著提升运动平滑度
• 速度指令：期望的前向速度、横向速度、转向角速度，这个是你遥控时实时改变的

动作空间则是每个关节的目标角度偏移量。策略输出的是一个 8 到 12 维的向量，表示每个关节相对默认姿态的偏移，然后通过位置控制模式发给舵机。

域随机化是 sim-to-real 能成功的核心。我会在仿真里随机化以下参数：

• 地面摩擦系数（0.4 到 1.2）
• 关节电机力矩系数（±20%）
• 机身质量（±20%）
• 关节阻尼默认值
• IMU 噪声水平（根据实测噪声标定）
• 控制延迟（1 到 3 个控制周期）

这样训练出来的策略就像摔打过的运动员，不挑场地。我特别建议控制延迟的随机化范围稍微放宽一点，因为 RK3566 上的控制周期抖动比你在 GPU 仿真里大得多，后面我会讲实测数据。

2.3 导出 ONNX 与精度校验

训练完成后得到一个.pt权重文件，接下来要转 ONNX。这里有几个关键注意点，我踩过坑：

第一，导出时固定 batch size 为 1。ONNX 默认会把动态维度暴露出来，但板端推理时你永远只喂一个观测向量，固定 batch size 可以减少不必要的运行时开销。如果需要在推理时处理多 batch，你再改成动态维度也不迟。

第二，检查输入输出的张量顺序。在 PyTorch 里你的观测向量可能是[1, obs_dim]，导出 ONNX 后要保持一致，板端组装观测向量时不能把顺序搞反。我建议在导出前写一个 Python 脚本，从训练好的模型中取一次真实推理结果，然后加载 ONNX 再推理一次，对比两者输出差异。差异在 1e-5 级别以内是正常的，如果差得大，多半是导出时模型状态不对（比如没有model.eval()）。

第三，如果后续要走 RKNN NPU 转换，ONNX 里尽量不要有动态 shape 的操作、循环、where这类容易不受支持的算子。策略网络一般是全连接层 + tanh 激活，这种结构 RKNN 支持得很完整，基本不会卡算子。

我导出的这个模型结构非常简单：输入 40 维左右，经过三层 256 或 512 的全连接层，输出 10 维动作向量。ONNX 文件大小不到 2MB，部署毫无压力。

3. RK3566 实机部署：从 ONNX 文件到电机转动

3.1 RK3566 软硬件环境准备

RK3566 的定位是瑞芯微的入门级 AIoT 芯片，四核 Cortex-A55 1.8GHz，带 0.8 TOPS 的 NPU。跑 Microduck 这种轻量策略完全够用，你需要准备的东西如下：

• RK3566 开发板一块，常见的有泰山派、香橙派 5 的降级版或者其他 RK3566 核心板
• 一个 MicroSD 卡或者 eMMC 模块，烧录 Debian 或者 Ubuntu 系统镜像
• IMU 模块（常见是 MPU6050 或者 ICM42688，I2C 接口）
• 总线舵机或者带串口反馈的舵机驱动板
• 电池，3S 锂电池或者 2S，看你舵机选型

这里穿插一个网络上很典型的问题：rk3566 识别到但是是 adb 设备。这个我遇到过，原因通常是你把开发板通过 USB 连到了 PC，而 RK3566 出厂镜像默认开着 adb 服务，于是 PC 上显示的是 adb 设备而不是串口设备或者网络设备。解决方法是直接进系统把 adb 服务关掉：

adb kill-server

如果压根不需要 adb，可以在板子上执行：

sudo systemctl disable adbd sudo reboot

或者干脆用 SSH 连接，别用 USB 线连 PC，省得 USB gadget 模式和 adb 抢占设备节点。

系统装好之后，安装板端推理需要的 Python 库：

pip install onnxruntime numpy pyserial

如果要从源码自己编译 onnxruntime，建议别折腾。官方发布的onnxruntime-arm64预编译包可以直接装。实测 RK3566 上单线程跑 40 维输入、3 层 256 全连接的 ONNX 模型，单次推理约 1.5 到 3 毫秒，完全能满足 50Hz 控制频率（周期 20 毫秒）的需求。

3.2 板端推理：直接跑 ONNX 还是转 RKNN

在 RK3566 上有两条路：用onnxruntime直接跑，或者用rknn-toolkit2转 RKNN 格式跑 NPU。

我最初的方案是先直接跑 ONNX，让整条控制链路先通起来，再考虑 NPU 优化。这是非常推荐的做法，因为 NPU 转换会引入很多变量，如果一开始就混在一起，出了问题你根本分不清是模型转换的问题还是控制逻辑的问题。

RKNN 转换的大致路径是在 PC 上安装 rknn-toolkit2，然后写一个转换脚本：

from rknn.api import RKNN rknn = RKNN() rknn.config(mean_values=[[0]], std_values=[[1]], target_platform='rk3566') rknn.load_onnx(model='microduck_policy.onnx') rknn.build(do_quantization=False) rknn.export_rknn('microduck_policy.rknn')

这里我建议一开始先不开量化（do_quantization=False），浮点推理精度最稳，跑通了再试 INT8 量化。量化之后模型更小、推理更快，但精度会受影响，实机上可能需要重新调一些鲁棒性参数。

不过说实话，对于这么小的全连接网络，NPU 加速带来的收益没有想象中明显。CPU 跑 1.5 到 3 毫秒已经够用，NPU 加速后可能降到 1 毫秒以内，但控制周期并不会因此变得更短——因为舵机响应速度才是瓶颈。所以如果你时间有限，直接用 onnxruntime 跑 CPU 是性价比最高的选择。

3.3 机器人端控制循环的实现

实机控制主循环是部署中最容易出问题的环节。我最终的结构大致如下：

import onnxruntime as ort import numpy as np import time import serial sess = ort.InferenceSession("microduck_policy.onnx") input_name = sess.get_inputs()[0].name rate = 50 dt = 1.0 / rate control_period = 0.0 while True: loop_start = time.perf_counter() obs = collect_observation() # 读 IMU + 关节编码器，组装观测向量 obs_array = np.array(obs, dtype=np.float32).reshape(1, -1) action = sess.run(None, {input_name: obs_array})[0][0] # 推理 target_angles = default_pose + action * action_scale # 动作映射 send_to_servos(target_angles) # 通过串口发送目标角度 loop_time = time.perf_counter() - loop_start sleep_time = dt - loop_time if sleep_time > 0: time.sleep(sleep_time)

有几个容易踩坑的细节：

• 观测向量的顺序和归一化参数必须和训练时完全一致。比如训练时关节角度是归一化到 [-1, 1] 的，实机上也要用同样的缩放系数，否则策略输入分布变了，直接崩。
• 控制周期抖动要记录。我用time.perf_counter()实测，RK3566 上 Python 写的控制循环，由于系统调度和 Python 的 GIL，周期抖动能到 ±5 毫秒。方案有两个：一是给 Python 进程绑核并设置实时调度优先级（chrt），二是直接把控制环用 C++ 重写。我试过绑核之后抖动能降到 ±2 毫秒左右，勉强够用；如果你要更高的稳定性，C++ 是更好的选择。
• 舵机发送协议要考虑回包时间。如果你用的是总线舵机，发送一条指令后通常会有一帧反馈（位置、温度等信息），如果你的代码是阻塞式串口读写，每一帧回包都会占用控制周期时间。我的做法是只发不收，反馈信息单独用一个较低频率（比如 5Hz）去读，避免阻塞主循环。

关于状态估计，Microduck 这种小四足初期不需要做复杂的卡尔曼滤波，直接用 IMU 的重力向量算 roll 和 pitch，角速度用陀螺仪原始值，腿部姿态用编码器累计即可。等你想跑更复杂的技巧（比如跳跃、越障）再考虑加 leg odometry 或者状态估计器。

3.4 第一次让 Microduck 站起来的检查清单

这一步我建议养成惯性思维：每次上电之前过一遍检查清单。以下是我自己用来排除低级错误的清单。

• 电池电压是否在舵机工作范围内？低压会导致舵机力矩不足，机器人站起来就抖。
• 舵机初始位置是否处于机械零点附近？如果策略输出期望的默认姿态和实际舵机零点偏差太大，上电瞬间舵机会猛冲，轻则抖动，重则扫齿或者烧舵机板。
• IMU 数据方向是否和训练环境一致？我犯过的一个低级错误是 IMU 安装方向反了，导致仿真里机器人能走，实机上站起来就转圈。
• 控制频率是否稳定？启动前先打印 50 个周期的耗时，确认没有异常大的延迟。
• 急停开关是否有效？第一次实验必须留一个物理急停或者一键进入阻尼模式的按键。

第一次上电实测，先把策略输出的动作幅度设成训练时的 50% 甚至 30%，确认机器人的姿态趋势正常后再慢慢扩大。别指望策略第一次就能走得像仿真里一样流畅，sim-to-real 差距处理得再好，也会有各种现实世界的意外。

4. 从仿真到实机：sim-to-real 差异与调参经验

4.1 为什么仿真里走得好好的，实机一跑就摔

这是 sim-to-real 最经典的难题，Microduck 这类低成本小机器人尤其明显。主要原因有三个：

第一个是控制延迟不一致。GPU 仿真里，策略推理几乎零延迟，观测到位动作立刻执行。实机上从 IMU 采样、串口读编码器、策略推理、串口发送，到舵机真正转到位，整个链路延迟轻松超过 30 毫秒，相当于 1 到 2 个控制周期。这就是为什么我在训练阶段坚持做控制延迟随机化，把延迟范围拉大到 1 到 3 个控制周期。

第二个是电机响应差异。仿真里电机被建模成理想力矩源加一个简单阻尼，而真实舵机有死区、有回差、有最大转速限制。尤其便宜的小舵机，你给它发一个很小的角度增量，它可能根本不动作，等增量累积到一定程度又猛冲一下。这种非线性是仿真很难精确建模的。

第三个是噪声分布不同。仿真里的 IMU 噪声是人为加的高斯噪声，而真实 MPU6050 除了高斯噪声还有温漂、零偏和震动耦合的高频噪声。关节编码器如果用舵机反馈，量化噪声也很大。

4.2 我在 RK3566 上踩过的五个具体坑

第一个坑是 onnxruntime 线程数问题。onnxruntime 默认会调度多线程，但在 RK3566 这种四核小 ARM 上，多线程反而会引入调度抖动。我通过在推理前设置sess.set_providers(['CPUExecutionProvider'])，并把线程数限制为 1，延迟稳定了很多。

第二个坑是 IMU 数据没有上低通滤波。直接用原始陀螺仪数据喂给策略，高频噪声会让动作输出抖动特别明显。我在 IMU 数据上做了滑动平均滤波，窗口大小取 5 个采样点，抖动大幅改善。注意滤波也会引入延迟，窗口不能太大。

第三个坑是舵机零点漂移。Microduck 用的舵机在长时间工作后会有温度上升导致的零点漂移，表现为机器人会往一个方向慢慢歪斜。这个在仿真里完全没有，因为仿真不存在发热。我的处理方式是在控制循环里加一个缓慢的积分项，随时修正默认姿态的零点。

第四个坑是电池电压跌落。满电时舵机响应迅速，飞一会儿电压从 12V 跌到 10V 以下，表面上看电机还能动，但实际力矩和响应速度已经大幅下降，机器人的步态会突然变软。这个我后来在训练时对电机力矩系数做了更宽的随机化，同时尽量用大容量电池，让电压平台更稳定。

第五个坑是强化学习遇到错误奖励这类问题——怎么知道策略有没有作弊。我训练时录了不少"奖励曲线很好但行为很怪"的案例。典型的比如为了拿前进奖励，策略选择倒立走或者横向弹跳。解决方案是在奖励函数里加正向的姿态惩罚项，并且开启域随机化之后，再检查一下策略在随机条件下是否还能保持合理运动。

4.3 实测数据与调参记录

给一组我在 RK3566 上实测出来的数据，供你参考：

调参方面最重要的三个杠杆是：动作幅度缩放系数、控制频率、观测长度（历史动作步数）。我的经验是动作缩放系数先设 0.5，稳定后逐步加到 1.0；控制频率固定 50Hz 别轻易改高，否则舵机追不上；观测里的历史动作步数从 2 步开始，不够再加。

另外一个细节：策略在 GPU 训练时用的是 float32，RK3566 上面的 onnxruntime 也用的是 float32。如果转 RKNN 并开启量化到 int8，同样的权重可能会让机器人的运动风格产生肉眼可见的变化。量化后一定要重新在实机上评估一遍，不能想当然认为精度差一点没关系。

5. 常见问题速查表与排查技巧

在部署 Microduck 的过程中，我整理了这些高频问题，一张表直接对照查：

排查方面的独家经验有两条。第一条，先在 PC 上模拟板端环境跑一遍再上实机。我写了一个小脚本，在 PC 上加载同一份 ONNX 文件，把实机录的 IMU 和编码器数据喂进去，对比策略输出和训练时的输出。这样可以隔离出是模型转换的问题还是硬件端的问题，避免拿实机做调试的时间成本。第二条，所有传感器数据先落盘再分析。第一次实机调试时，我把每个控制周期的观测、动作、舵机反馈全部记录成 CSV 文件，跑完一遍后离线分析，看看哪个环节延迟最大、哪个观测值异常，比现场盯 TTY 输出高效太多了。

另外还有一个容易忽略的点：控制程序的日志级别。RK3566 上如果print太频繁，串口输出本身就会占用 CPU 时间并干扰控制周期。实机运行时我建议只在启动和异常时打印，正常控制循环里不要有任何输出。

6. 保持稳定的实机部署结构与其他优化方向

这里补一个我在 RK3566 上最终采用的部署目录结构，适合你直接抄作业：

/opt/microduck/ ├── models/ │ ├── microduck_policy.onnx │ └── microduck_policy.rknn # 可选 ├── src/ │ ├── main_control.py # 主控制循环 │ ├── imu_reader.py # IMU 读取与滤波 │ ├── servo_driver.py # 舵机串口协议 │ ├── state_estimator.py # 姿态/关节状态处理 │ └── config.py # 归一化参数、动作缩放、控制频率 ├── logs/ # 控制日志与传感器数据落盘 └── scripts/ ├── export_onnx.py # 训练后导出 ONNX ├── run_pc_sim.py # PC 端模拟板端推理验证 └── calibrate_imu.py # IMU 安装方向与零偏标定

这套结构的好处是：模型文件、源码、日志互不干扰；config.py里集中管理所有实机相关的可调参数，调参不需要翻代码；scripts里的工具链在 PC 和板端都能执行。

关于后续优化方向，如果你想让 Microduck 跑得更激进、更接近仿真效果，有两个方向我很推荐尝试。第一是给 RK3566 加 NPU 加速，把 ONNX 转 RKNN 并做 INT8 量化，把推理耗时压到 1 毫秒以内，同时把控制循环改成 C++ 实现，这样控制频率可以提升到 100Hz 甚至更高，舵机的跟随性能会明显改善。第二是加入更完整的 leg odometry，把腿部编码器信息和 IMU 融合，让机器人对自身位置有估计，这样你才能从"原地行走"升级到"定点导航"或者"越障"，真正把强化学习控制策略做成一个完整的机器人应用。

我个人在实际操作中的体会是：Microduck 这个项目最难的其实不是训练，而是那种"一切都对但就是走不了"的状态。仿真里跑一万步、奖励曲线收敛得漂亮，都不如实机上它稳稳站住那一刻带来的成就感。如果你也在这个阶段卡着，别急，按顺序检查延迟、噪声、舵机响应、观测归一化这几个环节，九成的问题都在这里。