企业官网建设流程全解析

Microduck 是那种第一眼看上去像玩具、实际玩法很深的 25cm 级强化学习机器人。我手头这台从英伟达 GPU 上的仿真训练开始，最终让它跑在 RK3566 实机上，中间横跨了强化学习算法调试、模型导出、边缘端部署、电机驱动和一堆本该避免但绕不开的坑。这篇文章就记录整个部署过程，适合正在折腾 Microduck 的玩家、准备把强化学习策略从 PC 搬到嵌入式平台的研究生或工程师，也适合只想知道 RK3566 这类开发板到底能不能跑强化学习策略的朋友。

1. 项目背景与整体方案选型

1.1 Microduck 是什么，25cm 尺寸带来的设计约束

Microduck 是一个开源的小型强化学习机器人项目，整体尺寸只有 25cm 级别，常见的说法也叫它“玩具尺寸四足”或者“桌面级足式机器人”。体积小带来的好处是场地要求低、危险系数低，可以在桌面上直接做实验；但代价也很明显：可用电池容量小，电机扭矩小，主控板尺寸小，散热条件差。这就直接决定了你在选主控芯片、电机驱动、通信总线的时候，不能照着大型机器人的思路来。

很多玩机器人的人一上来就想着用高性能工控机或者 Jetson Orin 这类平台做端侧推理，但 Microduck 这种尺寸根本塞不下这么大的板子，功耗也不现实。我最初试过用 Jetson Nano 做推理平台，结果电池掉电速度惊人，而且发热严重，最后只能放弃。真正适合这种体积的，是一块像 RK3566 这种小尺寸、低功耗、带一点点 NPU 算力的核心板。

25cm 尺寸还有一个隐含约束：结构件大多是 3D 打印的，重量控制不严格，转动惯量分布不均匀。这意味着你在 GPU 仿真环境里练出来的策略，如果不在仿真阶段做好域随机化，到了实机上大概率站都站不稳。所以这个尺寸的机器人项目，反而是对“仿真到实机迁移”要求最严苛的一类。

1.2 为什么选择英伟达 GPU + RK3566 这套组合

训练端选择英伟达 GPU，不需要太多解释。强化学习，尤其是 PPO 这类策略梯度算法，动辄需要跑几十万到几百万个 step，没有 GPU 加速的 Isaac Gym 或 MuJoCo，光靠 CPU 仿真，训练一个能走的四足策略可能要几天甚至一周，根本没法迭代。用 RTX 4090 这类消费级卡，配合 GPU 版仿真器，能把训练时间压缩到几小时，这就是选英伟达 GPU 的核心原因。

部署端选择 RK3566，则是从成本、功耗、算力三个维度权衡的结果。RK3566 是瑞芯微推出的一款四核 Cortex-A55 处理器，带 0.6TOPS 左右的 NPU，功耗通常能做到一两瓦左右，板子也够小，非常契合 Microduck 的限制条件。很多人会纠结它算力不如树莓派 5，但实际做部署时你会发现，强化学习策略网络往往是一个很小的 MLP（多层感知机），几百到一两千个参数，CPU 跑也只要几毫秒，NPU 反而不是重点。真正的问题是 RK3566 上的软件生态、系统镜像、外设接口是否稳定可靠，这才是我选择它之后花大量时间踩坑的地方。

所以整套链路用一句话总结：英伟达 GPU 负责把策略训出来，RK3566 负责把策略跑起来，中间通过模型导出和推理框架把两者连接起来。

1.3 完整部署链路概览

在动工之前，我先在纸上把整条链路画了一遍，避免做到一半才发现方案不闭环。我的最终链路是：

1. 在 PC 上用 GPU 仿真环境（MuJoCo 或 Isaac Gym）构建 Microduck 的四足动力学模型。
2. 用 PPO 或其变体算法训练控制策略，同时设计奖励函数，增加域随机化。
3. 训练完成后，把 PyTorch 权重导出为 ONNX 格式。
4. 对 ONNX 模型做精简，去掉不必要的算子，适配边缘端推理框架。
5. 在 RK3566 上部署推理代码，接好电机驱动，通过串口或者总线把动作指令下发到电机模块。
6. 实机调试，修正关节方向、控制频率、延时补偿等问题。

这条链路本身不算复杂，但每一步都有不少隐藏问题。尤其是从第 4 步到第 6 步，很多做算法的人不太熟悉硬件侧的操作，很容易卡住。后面我会按这个顺序把每个阶段的实操细节拆开来讲。

2. 强化学习训练阶段的关键环节

2.1 训练环境搭建：从 MuJoCo 到 Isaac Gym 的选择

我在训练阶段先用了 MuJoCo，因为它的物理引擎精度高，而且完全免费开源，社区里也有不少四足机器人模型可以直接导入。但真正开始大规模并行采样时，我发现 MuJoCo 的 GPU 加速能力在配置上有点繁琐，虽然它支持 GPU 批量仿真，但对一个刚开始接触这个项目的人来说，还是有点门槛。

后面我换了 Isaac Gym，这个环境最大的优势是可以直接在 GPU 上大规模并行多个机器人实例，一次性采样几千个环境，训练效率比单环境仿真高很多。Microduck 这种 25cm 小机器人，在 Isaac Gym 里可以同时跑几千个实例，配合 RTX 4090 的话，训练一个能稳定行走的 PPO 策略，大概只需要一两个小时到半天，具体取决于奖励函数设计得有多复杂。

当然 Isaac Gym 也有缺点。首先它的官方支持已经逐步转向新的 Isaac Lab 框架，旧版环境安装时和 CUDA、PyTorch 版本的兼容性问题比较多；其次，在 Isaac Gym 里要精确复现 Microduck 的物理尺寸、电机特性、关节阻尼，需要自己调整模型参数，并不是导入一个 URDF 就万事大吉。如果你和我一样用的是社区里现成的 Microduck 模型文件，一定要检查关节角度的正负方向，以及电机最大扭矩是否和实机一致。

我的建议是：如果你只想快速验证控制逻辑，用 MuJoCo 就够了；如果你要大量训练、频繁迭代策略，直接上 Isaac Gym 或 Isaac Lab，别犹豫。

2.2 状态空间、动作空间与奖励设计；错误奖励的处理

很多人第一次训练强化学习机器人时，失败的原因不在算法，而在状态空间和动作空间定义不合理。Microduck 这种四足机器人，我最开始用的状态向量是：

• 机身线速度（3 维）、角速度（3 维）
• 机身朝向的四元数（4 维）
• 四条腿的关节角度（假设每条腿 3 个电机，共 12 维）
• 关节角速度（12 维）
• 上一个动作（12 维）

这样加起来大概 46 维，对于 MLP 策略网络来说完全够用。动作空间是 12 维的关节目标位置，也就是每个电机期望转到哪个角度，具体的力矩由底层的 PID 控制器去实现。

这里有一个很关键的设计思路：强化学习策略不直接输出电流或力矩，而是输出目标位置，由电机驱动板自带的 PID 闭环去跟踪。这样做的好处是，策略在高层面做逻辑决策，底层的力控制和频率控制交给更可靠的嵌入式系统去处理，可以避免策略在完全没有约束的情况下，输出极端的力矩指令导致电机过载。热词里提到“基于强化学习的 PID 控制”，其实就是这个方向的一个变体，你可以让强化学习实时调节 PID 参数，也可以让强化学习输出目标轨迹，PID 去跟踪，两种方式都有人在用。

奖励设计是训练阶段最容易踩坑的地方，尤其是热词里提到的“强化学习遇到错误奖励”。我在 Microduck 项目里遇到过两次比较典型的错误奖励问题。第一次是奖励项数值量级失衡，我把前进速度奖励设成 1.0，而朝向一致性的惩罚只有 0.01，结果训练出来的策略疯狂乱跑，即使方向偏离很大也能获得高总奖励。第二次是稀疏奖励陷阱，能量惩罚设置得太重，策略干脆待着不动，因为任何动作都会增加能量消耗，不动反而能拿到更高的累计奖励。

处理错误奖励的核心思路是：每次只检查单一奖励项的贡献，而不是只看总奖励曲线。我会在训练时把各个奖励分量单独记录成日志，观察前进速度分量是否正常上升、电能惩罚是否失控、朝向误差是否有收敛趋势。如果某个分量始终抖动剧烈，多半就是该项的系数太高，或者目标函数和策略行为之间存在冲突。实践中比较好用的做法是先用简单奖励跑通，比如只给前进速度奖励和存活奖励，跑一个能走但姿势怪异的策略，再逐步加上姿态稳定性、能耗项、关节限位惩罚。

2.3 从仿真到实机的域随机化

Microduck 这类小机器人实机部署最大的敌人是仿真环境和真实物理环境的差异。我在仿真里跑得再漂亮，拿到实机上一开机，大多数情况是原地抽搐、翻车、甚至直接把电机堵转。原因无外乎摩擦系数不一样、重心位置有偏差、电机响应延迟高、关节阻尼不匹配。

域随机化是目前解决这个问题最实用、也最容易落地的手段。我的具体做法是：在每一次环境重置的时候，随机化机身质量、质心偏移、腿部摩擦系数、关节阻尼、电机扭矩上限、控制延时这几个参数，随机区间大概设置在机器人真实参数的百分之二十左右。比如 Microduck 的实际重量是 0.6kg，我就在 0.5kg 到 0.7kg 之间随机采样。

这里要特别提醒一点，控制延时是一个很容易被忽略但影响巨大的随机化参数。实机从读取传感器到真正驱动电机，整个链路通常有几十毫秒的延迟，如果你的训练环境里没有加延时模拟，策略就会对动作效果产生错误的时序关联推断。我的做法是在训练环境的每一步里随机插入 10 到 50 毫秒的延迟，让策略学会在不确定性下保持稳定，这样实机部署时，策略的鲁棒性会好很多。

2.4 GPU 训练中的算力配置与超参数

训练超参数这一块，我直接说我在 Microduck 项目里用到的、实测有效的配置。PPO 算法，actor 网络和 critic 网络都是两层 MLP，每层 256 个神经元，激活函数用 ReLU。学习率初始为 3e-4，训练过程中逐步衰减到 3e-5。batch size 设为 2048，minibatch 为 128，clip 参数 0.2，GAE 的 lambda 取 0.95，折扣因子 gamma 取 0.99。

在 Isaac Gym 里，我同时跑 4096 个环境实例，每个实例都是独立的 Microduck 机器人，用 RTX 4090 训练时，单次迭代差不多需要 2 到 3 秒。通常跑到 3000 到 5000 步迭代时，策略已经能走出比较像样的步态，总体训练时间大概在一到三个小时，取决于你是否同时做大量的域随机化。要注意的是，训练日志最好每 50 次迭代就记录一次到本地，避免中途崩溃丢了全部进度。

3. 模型导出与边缘端适配

3.1 从 PyTorch 模型到 ONNX / RKNN 的转换流程

训练完成后，你手里的是一组 PyTorch 的权重。这时候不能直接把权重丢给 RK3566，因为嵌入式端大概率不会装完整的 PyTorch，更常见的是用 ONNX Runtime 或者 RKNN 工具链做推理。我的第一步是把 actor 网络单独提取出来，保存成 ONNX 格式。

转换过程没那么玄乎，核心代码如下：

import torch import torch.nn as nn class Actor(nn.Module): def __init__(self, obs_dim, act_dim): super().__init__() self.net = nn.Sequential( nn.Linear(obs_dim, 256), nn.ReLU(), nn.Linear(256, 256), nn.ReLU(), nn.Linear(256, act_dim), nn.Tanh() ) def forward(self, obs): return self.net(obs) actor = Actor(obs_dim=46, act_dim=12) actor.load_state_dict(torch.load("microduck_actor.pth")) actor.eval() dummy_input = torch.randn(1, 46) torch.onnx.export( actor, dummy_input, "microduck_actor.onnx", input_names=["obs"], output_names=["action"], dynamic_axes={"obs": {0: "batch_size"}, "action": {0: "batch_size"}}, opset_version=12 )

这里我把输入输出动态 batch 打开了，方便在板端推理时每次只输入一个样本。opset_version 建议选 11 到 13 之间，太高的版本有些嵌入式推理框架支持不完整。导出后用onnx.checker.check_model验证一下整体结构，再打印一遍网络层，确认没有出现奇怪的算子。

如果执意要用 RK3566 的 NPU，那么接下来还需要用 RKNN-Toolkit2 把 ONNX 模型转成 RKNN 格式。这个过程我踩过一个明显的坑：rknn-toolkit2 的版本必须和开发板上运行的 RKNPU 驱动版本对齐，否则转换出来的模型在板上加载时会出现版本不匹配的报错。我最后用的是 rknn-toolkit2 1.6.0 配合板端 1.6 驱动，才稳定跑起来。

3.2 RK3566 硬件资源限制下的量化与算子裁剪

RK3566 的 NPU 理论算力有 0.6TOPS，听起来还能用，但实际上它支持的算子种类有限，尤其是一些动态形状、循环、稀疏操作，很可能会出现转换失败。好在一个 MLP 策略网络只有全连接层、ReLU、Tanh 这类基础算子，算是在 RKNN 支持的范围内，所以转换成功率还算高。

不过这里有一个非常现实的问题：量化。RK3566 的 NPU 对浮点模型直接支持有限，更常见的是转成 INT8 定点运算。我在量化后先小范围测试了一下，理论上 INT8 量化对 MLP 这种小网络的影响应该很小，但实测下来，量化后的策略在实机上偶尔会出现关节方向微小抖动，后续排查是 tanh 输出层的数值精度有损失，导致策略输出和原始浮点版本有轻微偏差。解决办法是尽量保留输出层为浮点层，或者让 actor 网络输出之前接一个线性层，不强制走 INT8 量化。

如果你和我一样，最终决定用 CPU 跑 ONNX Runtime，那可以完全避开量化的问题。对于 Microduck 的运动控制频率，常用的控制循环是 50Hz 到 100Hz，也就是说每 10 到 20 毫秒要跑一次推理。这个 MLP 网络在 RK3566 的四个 A55 内核上单次推理只需要 2 到 5 毫秒，CPU 完全跑得动，NPU 反而不一定更稳。

由此可见，“必须用 NPU”是很多人对嵌入式 AI 的误解。在 RK3566 上部署强化学习策略，最重要的评估指标是端到端延迟是否满足控制频率，而不是硬件上有没有 NPU。如果 CPU 能满足实时性，优先用 CPU 推理，能省去大量算子兼容性调试时间。

3.3 推理框架选型：ONNX Runtime CPU 还是 RKNN

我在 RK3566 上对比过两张方案：ONNX Runtime（CPU）和 RKNN（NPU）。ONNX Runtime 的优势是部署简单，直接安装 prebuilt wheel 就能跑，不依赖 NPU 驱动，而且对 PyTorch 导出的 ONNX 模型兼容性好。缺点是占用的内存稍微多一点，但 Microduck 控制程序本身很小，完全没问题。

如果走 RKNN 通道，最大的优势是 NPU 可以腾出 CPU 资源给其他任务，比如运动学解算、传感器处理等。但对于我这种小规模 MLP 网络，NPU 的加速效果并不明显，反而因为模型转换、量化精度、驱动版本匹配这些事，增加了大量时间成本。如果你只是复制我的做法，我建议直接走 ONNX Runtime CPU，先把整个控制系统跑通，后面有余力再考虑优化 NPU 推理。

在板端运行 ONNX Runtime 的代码思路也很清晰：

import onnxruntime as ort import numpy as np sess = ort.InferenceSession("microduck_actor.onnx", providers=["CPUExecutionProvider"]) # 每一控制周期构造 obs，shape 为 (1, 46) obs = np.random.randn(46).astype(np.float32).reshape(1, 46) input_name = sess.get_inputs()[0].name action = sess.run(None, {input_name: obs})[0].reshape(-1) print(action)

这里有个细节要注意：输入数据必须用np.float32，不能是 float64，否则 ONNX Runtime 会报类型不匹配。我在第一次跑的时候吃了这个亏，整个程序报错后我查了半天，最后才发现是输入数据格式问题。

4. RK3566 实机部署与调试实录

4.1 系统镜像与设备识别问题：泰山派识别到 RK3566 但是是 ADB 设备

硬件调试的第一步是让 RK3566 开发板正常启动并可以被电脑访问。我用的是泰山派（TaisanPi）的 RK3566 核心板，板卡本身支持 USB、串口、以太网，但第一次上电时就被电脑识别成了一个 ADB 设备，而不是常规的串口或者网络设备，这让我折腾了一晚上。

所谓“泰山派识别到 RK3566 但是是 ADB 设备”，意思是开发板通过 USB 连接到电脑后，lsusb识别到的设备 ID 指向 Android Debug Bridge，而不是一个普通的 USB 以太网卡或者串口设备。出现这个问题的根本原因是板卡上电后进入了烧录模式或者出厂固件自带的 ADB 服务在跑，这时候你是没法正常进入系统的。很多刚入手 RK3566 的朋友都会卡在这一步。

我的解决方法是这样的：首先用瑞芯微官方的 RKDevTool 烧录工具，进入 MaskROM 模式重新烧写一个干净的系统镜像。具体操作是，先按住板子上的恢复键，再上电，让板子进入烧录模式，随后在 RKDevTool 里烧入一个 Debian 或者 Ubuntu 的镜像，不要用出厂自带的 Android 镜像。烧写成功后，重新上电，连接 USB 转串口模块，登录系统，把 USB 设备模式改回普通 USB Device 或者直接禁用 ADB，问题就解决了。

如果你只是想在 Linux 系统里用 USB 通信，记得检查一下内核是否加载了对应的 USB gadget 驱动，必要时写一个 systemd 服务来启动设备模式配置脚本。

4.2 串口 / 外设对接与电机控制

RK3566 实机跑起来之后，下一步就是把控制信号发到电机。Microduck 的电机一般是 12V 的串行总线舵机，比如常见的 LX-16A、ST3215 这类，走半双工 UART 通信。我在系统中用/dev/ttyS4串口和电机的转换板通信，波特率出厂默认是 115200，注意每条指令帧的 ID 和校验位不能写错，通过 UART 调用电机的角度位置控制指令。

控制频率的选择上，我一开始跑 200Hz，也就是 5ms 一发指令，结果电机驱动板响应不过来，串口数据大量积压，关节明显抖动。后来调低到 100Hz，单次指令间隔 10ms，推理、控制、通信都能在时间片里完成，机器人走起来才稳定。这里想提醒各位，千万不要盲目追求高控制频率，总线舵机的内部 PWM 刷新频率通常是 50 到 250Hz，一串指令发得再快，电机跟不上也是白搭。

电机控制之外还要处理机身惯性测量单元（IMU）。我用的是一款常见的九轴 IMU，通过 I2C 接口读取加速度和角速度数据，再把姿态四元数作为状态输入的一部分。IMU 数据的实时性会影响强化学习策略的输入质量，我把 IMU 读取放在一个独立线程里，让它以 500Hz 的频率刷数据，然后控制主线程每 10ms 取一次最新的传感器数据。

4.3 部署后效果验证与性能调优

实机部署成功不代表着能走好。我第一次把策略部署上去后，Microduck 能站起来，但迈步时明显一瘸一拐，而且频繁往一侧偏。排查下来主要有三个问题：一个是左右腿的关节方向在仿真和实机上不一致，等于策略在给反方向指令；另一个是 IMU 数据有噪声，策略输入不稳定；第三个是控制线程和推理线程没有做好同步，导致推理输出动作时使用的传感器数据已经是旧数据。

针对这三点，我做的修正分别是：在实机上逐个关节校验电机方向，写一个简单的脚本让每个关节转到目标角度，确认转向与仿真模型一致；对 IMU 数据加一个轻量级的低通滤波，比如一阶 RC 滤波，减少高频噪声；把控制循环改成“先读取当前传感器数据，再推理，再下发指令”的严格顺序执行，避免多线程竞态。

实测下来，经过这些修正后 Microduck 的行走稳定性提升明显，单次连续行走距离能稳定保持在十米以上。当然这只是一个基本目标，后续还有转向、越障、摔倒恢复等更复杂的控制目标，都需要进一步训练和部署调试。

5. 实践中的典型问题与排查方法

5.1 设备识别失败：快速排查清单

RK3566 板卡设备识别问题在实际项目中出现的概率极高，尤其当你第一次刷机或者更换系统镜像的时候。我根据自己的经历整理了一张快速排查表，遇到问题可以直接照着查。

设备识别问题大多数可以通过重新烧录和检查 USB 线缆解决，真正卡住人的往往是不断尝试各种粗糙方案，却忽略了系统镜像本身就是错的。

5.2 模型转换失败 / 精度下降

我在从 PyTorch 导出 ONNX、再从 ONNX 转 RKNN 的过程中，遇到过的错误类型基本是三类：算子不支持、版本不匹配、动态 shape 引起的问题。

算子不支持时，你需要在导出端修改网络结构，把不支持的层用等价的基础算子替换，或者干脆重置为 CPU 推理。版本不匹配则是我在前面提过的，rknn-toolkit2 和板端 RKNPU 驱动版本必须一致。动态 shape 的问题更隐蔽，很多 RKNN 模型要求 batch size 固定为 1，如果你在导出时保留了动态 batch，转换后可能无法加载。解决办法是重新导出，固定 batch 为 1。

精度下降方面，前面提过 INT8 量化后输出层 tanh 受到一些影响。我验证精度的方法是先在 PC 上随机生成几百组输入，比较 PyTorch 原模型和板端推理模型的输出差异，计算最大绝对误差和均方根误差。对于 MLP 策略网络，合理的误差范围在 0.01 到 0.05 左右，如果误差超过 0.1，策略在实机上的表现很可能出现明显退化。

5.3 实机抖动、策略失效、奖励信号异常

实机抖动和策略失效是强化学习机器人部署中最让人头痛的问题。抖动的原因通常有几个：传感器噪声过大、控制频率和电机响应不匹配、控制输出的动作指令变化太剧烈、关节连杆存在间隙。我的处理思路是，先把控制频率固定到 100Hz，然后在动作指令上增加一个低通滤波，比如每次只更新目标角度的百分之三十，让关节运动更平滑。虽然这会稍微牺牲响应速度，但稳定性提升立竿见影。

策略失效则要区分是实机输入不对还是模型本身泛化能力不足。实机输入不对通常体现在观测向量的维度、顺序、单位与训练时不一致，比如仿真里用的是弧度，实机上读出来的是角度制数，那就需要做转换。如果策略本身泛化能力不足，则只能回头补训练，增加更多域随机化参数，或者在实机上收集数据后做离线强化学习微调，比如用 IQL（离线强化学习）来校正当前策略。

奖励信号异常多数是训练阶段的问题。如果你在训练过程中发现 total reward 在上升，但在某一次迭代后骤降，然后恢复得很慢，很可能是某个随机异常的仿真步进导致策略崩溃。解决方法是加载之前的备份权重，减小学习率，同时检查是否有环境重置时出现非法状态。奖励曲线出现“先升后降”的走势时，不要急着加大奖励系数，先看各项子奖励的贡献变化，往往能发现某些项在反复震荡。

6. 写在最后：Microduck 的扩展方向与个人经验

Microduck 这个项目真正跑通之后，我在 PC 端训练的效率并没有提升多少，反而是 RK3566 这个嵌入式平台的部署经验，让我对“强化学习机器人落地”这件事有了完全不同的理解。很多人总以为难点在算法，但实际调试中，传感器对齐、关节方向、控制频率、模型数值精度这些“琐事”才是最耗费时间的部分。

如果后续要继续扩展，我个人比较想尝试的方向是离线强化学习，比如先搜集 Microduck 在实机上自主跑动的大量数据，再用 IQL 这类算法离线训练策略，这样可以进一步缩小仿真和实机的差距。另外也可以在平台上做更复杂的任务，比如目标跟随、避障、小斜坡越障，这些都需要重新设计奖励函数和训练设置。

最后分享一个小技巧：不管是用 ONNX Runtime 还是 RKNN，部署前一定要在 PC 上先做输出一致性校验，不要直接烧到板子上再改。我一开始就是图快，模型转完直接丢 RK3566，结果各种莫名抖动，后来回到 PC 上做差分测试，才发现是量化精度的问题。多花十分钟做校验，实机上能省出好几个晚上的调试时间。