老读者可能还记得，我之前一直在聊强化学习在仿真环境里怎么跑、训练曲线怎么调、奖励函数怎么改，但说实话，仿真跑得再漂亮，真机一上电、舵机一响，很多东西都会打回原形。这次的项目是把手头一套 Microduck 25 厘米四足机器人从“在英伟达 GPU 上训练策略”推进到“在 RK3566 开发板上实机运行”，整个过程踩了不少坑，也摸清了一条比较靠谱的落地路径，今天把这些经验整理出来，希望能给正在折腾强化学习机器人落地的朋友一点参考。
先交代一下这套东西是什么：Microduck 是一台大约 25 厘米长的小型四足机器人，结构上类似 MIT 的 mini cheetah 和 Stanford Pupper 那一系，但成本友好得多，用的是串行总线舵机加一块 RK3566 开发板做大脑。RK3566 是瑞芯微的一款四核 Cortex-A55 处理器，主频 1.8GHz 左右，带 0.8 TOPS 的 NPU，放在边缘设备里属于够用但不宽裕的水平。整个项目的核心目标是让机器人在真实地面上走出稳定的步态，而不是只在 MuJoCo 或者 Isaac Gym 里走两步就完事。本文适合手里已经有机器人和一点 PyTorch / Linux 基础、想把强化学习策略搬到真机上的朋友，接下来讲的内容基本是踩坑实录，不是教科书。
1. 方案选型与整体架构
1.1 为什么是 Microduck，为什么是 RK3566
刚开始我其实纠结过一段时间的平台选型。市面上四足机器人开发平台不算少，尤其是树莓派加舵机的方案很常见，资料也多。但 Microduck 这个尺寸级别有个很关键的优势：结构件和舵机都是为低成本教育场景设计的，整机重量轻，25 厘米这个尺寸刚好适合在桌面上做实验，即使摔倒也不至于把电机烧了。对比过 30 厘米以上的大型四足，那些东西一套下来成本翻好几倍，而且功率大、速度快，真在室内调策略时风险也大。
RK3566 之所以被选中，有三点考虑。第一，它跑 Linux 的生态比较成熟，Ubuntu、Debian 镜像都有，ROS2 也能顺利装上去；第二，接口丰富，USB 3.0、千兆以太网、PCIe 都有，后续扩展摄像头、激光雷达都比较方便；第三，NPU 虽然算力不高，但实际用下来跑普通 CNN 模型是没问题的，后面有需要可以做视觉感知。相比树莓派 4B 在缺货时期的价格，RK3566 的板卡性价比也更高，像泰山派这类开发板两三百块钱就能拿下。唯一需要注意的是，RK3566 的 CPU 单核性能并不强，跑一些复杂模型时延迟会比树莓派高一些，后面会详细说。
1.2 从仿真到实机的整体数据流
整个系统的数据流可以分成训练侧和部署侧两条线。训练侧核心就是英伟达 GPU 平台，用 PyTorch 写策略网络，在 MuJoCo 物理引擎里做强化学习训练。这里没有选 Isaac Gym 主要是因为当时手头环境对 Unity 资产支持不太好，MuJoCo 的 Python 接口更轻量，直接 pip install 就能跑，对自定义地形、模型加载也比较直观。
训练完的策略网络会导出成 ONNX 格式。这一步很关键，因为部署侧不可能直接跑 PyTorch 模型，RK3566 上跑 ONNX Runtime 才是合理选择。ONNX 是一个中间表示格式，相当于把 PyTorch 训练出来的网络结构固化成一个与框架无关的模型文件，这样部署端的推理引擎就能直接读了。
部署侧的数据流大概是这样的：RK3566 通过串口或者 USB 转串口连接底层的舵机控制板，控制板负责解析位置指令并驱动 Microduck 的 12 个关节。RK3566 上跑一个轻量的控制程序，循环内部先读传感器数据（主要是 IMU 的角速度和线加速度），把这些数据拼成输入张量，交给 ONNX Runtime 推理得到 12 个关节的目标位置，再通过串行总线发给舵机。
![数据流示意（文字版）]
GPU 训练端：MuJoCo 环境 + PyTorch -> 导出 ONNX -> RK3566 部署端：ONNX Runtime 推理 -> 关节控制指令 -> 舵机执行
这个架构的优势在于分工明确：训练侧不关心部署硬件，部署侧不依赖训练框架。需要强调的是，这里的策略网络输入不仅仅是关节角度，还包括 IMU 数据和时间步的历史信息，因为强化学习策略通常需要知道状态的时序变化才能做出稳定决策，这就引出了后面要聊的 LSTM 网络部署问题。
2. 训练阶段容易忽略的部署细节
2.1 在仿真里训练一个“能上真机”的策略
很多人跑强化学习训练时只盯着 reward 曲线，觉得仿真里 reward 上去了就等于任务完成了。但实际从仿真到真机的迁移过程中，最大的坑就是仿真环境和真实环境之间的差距，学术上叫 sim-to-real gap。如果训练时完全没有考虑真机环境的差异，策略在仿真里能跑得很好，到了真机上因为摩擦力、惯量、延迟等因素的微小变化，直接一个侧摔变成“路倒”。
我在训练阶段采用的策略是领域随机化（domain randomization）。简单说，就是在每一次训练 episode 开始的时候，随机改变仿真环境里的物理参数，比如地面摩擦力系数、舵机响应延迟、负载质量、IMU 噪声水平等。这样做的好处是让策略不再依赖某一个固定的物理参数，而是学会一套在各种不确定条件下都能保持平衡的控制策略。实际设置的随机范围我建议先小后大，比如地面摩擦系数在 0.4 到 1.2 之间随机，舵机延迟在 0 到 20 毫秒之间随机，逐步加大范围，直到真机表现趋于稳定。
另一个关键点是仿真步长和真机控制频率的匹配。MuJoCo 仿真步长我设的是 0.002 秒，也就是 500Hz 的物理更新率，但策略推理不可能在真机上跑这么高频。真机上强化学习策略的常用控制频率是 50Hz，也就是每 20 毫秒推理一次。这两个频率之间需要通过动作平滑策略来衔接，我的做法是把 500Hz 的物理仿真步长下、每隔 10 步取一次状态做推理，剩下的 9 步把目标位置做线性插值。这样做的好处是，策略看到的状态变化曲线跟真机上 50Hz 采样看到的基本一致，避免策略过于依赖高频信息。
2.2 导出 ONNX 时的算子与动态维度问题
训练好策略网络后，导出 ONNX 这一个环节真的能让人怀疑人生。我最初直接用 torch.onnx.export 导出一个包含 LSTM 层的策略网络，结果在 RK3566 的 ONNX Runtime 上加载直接报错，提示某些算子不支持。排查了半天，发现问题是 PyTorch 导出的 LSTM 默认用了一堆动态循环节点，ONNX Runtime 的 CPU 版本在 RK3566 上不支持这些动态图算子的高效执行。
解决办法有两个方向。第一个是改用 ONNX Runtime 支持较好的静态图结构，比如用固定循环次数的展开 LSTM 替代动态 LSTM；第二个更激进，直接把 LSTM 换成 GRU 或者甚至一维卷积层，GRU 跟 LSTM 的表达能力接近，但导出后的算子更简洁，部署兼容性更好。我最终在 Microduck 上选择了 GRU，因为四足步态控制需要记忆过去几个周期的状态，GRU 在这方面完全够用，而且推理速度比 LSTM 快不少。
动态维度问题也值得单独说。torch.onnx.export 默认导出的模型输入维度是固定的，比如 [1, 12]，但在真机运行的时候，IMU 数据的维度可能因为批次处理的原因变成 [1, 14] 或者 [2, 12]，如果模型写死了输入形状，推理就会报错。解决方案是在导出时把 dynamic_axes 参数配上，把时间步和批次维度标记成动态，但要注意动态维度在部分推理引擎里会降低算子融合效率，尽可能保持部署时的输入形状和导出时一致更好。
2.3 奖励函数设计的一些“后悔药”
关于奖励函数，网上文章已经很多了，我只提一个跟真机落地强相关的心得。最初我按通用 bipedal 任务设计奖励函数，比如前进速度奖励、身体朝向惩罚、能量消耗惩罚，结果真机跑起来发现步态虽然对但关节角度变化过于剧烈，舵机发热严重，跑个几分钟主板就开始电压不稳。
后来在奖励函数里加了关节角加速度的惩罚项，同时把关节速度的惩罚系数调高了两倍，效果立竿见影。这里背后逻辑是，仿真里舵机是理想模型，任意高加速度的运动都能执行，但真机舵机有物理极限，过高的加速度需求会被舵机直接裁掉，造成策略期望和实际执行的偏差。如果奖励函数显式惩罚高加速度，训练出的策略自然会更“平滑”，真机执行的成功率就上来了。
注意：训练阶段一定要记录策略输入输出张量的范围。真机推理时如果输入状态和训练时的分布差异过大，比如 IMU 噪声导致加速度数值飙到训练时没见过的高值，策略输出可能完全乱掉。我的做法是训练时把每个状态维度的 min/max 记录下来，部署后在推理前做裁剪。
3. RK3566 实机适配：性能、算子与通信
3.1 实测推理性能：50Hz 控制循环到底能不能撑住
这是很多刚从 GPU 转到边缘设备的人最担心的一个问题。GPU 上一个前向传播可能只要几毫秒，RK3566 上跑同样的网络可能直接慢一个数量级。但这里有个关键点：GPU 擅长的是大规模并行计算的卷积操作，而强化学习控制策略通常是小规模全连接网络加少量循环结构，这种模型在 CPU 上跑反而没有想象中那么慢。
我的策略网络结构大致是：14 维输入（12 个关节角 + 2 个 IMU 角速度）经过两层 128 维的全连接和 ReLU 激活，接一个 64 维的 GRU 层，再经过一层 128 维全连接，最终输出 12 个关节目标角速度。整个模型参数量在 7 万左右。在 RK3566 上用 ONNX Runtime 的 CPU 后端跑，单次推理耗时大约 8 到 12 毫秒，加上前后处理、串口通信，整个 50Hz 控制循环的耗时能稳定控制在 20 毫秒以内，也就是 CPU 占用率在 50% 左右。
如果模型再大一点，比如把 GRU 换成隐藏层 128 维的双层 LSTM，单次推理会飙到 25 毫秒以上，控制循环就要降到 30Hz 了。所以结论很明确：在 RK3566 上做强化学习控制，控制频率和模型大小是直接矛盾的，优先保证 50Hz 以上的控制频率更重要，模型精简后策略仍然可以通过训练阶段的调优来弥补表达能力的损失。
实测我最终在 Microduck 上跑的数据是：
- 模型推理： 9.4ms（平均）
- 状态读取与预处理： 2.1ms
- 串口发送控制指令： 1.8ms
- 总循环时间： 13.3ms，满足 50Hz 预算
3.2 RK3566 NPU 为什么没派上用场
RK3566 宣传的 0.8 TOPS NPU 看起来很诱人，但实际用在这一类强化学习控制策略上，性价比并不高。原因有三点：
第一，NPU 主要针对 CNN 类模型做了大量优化，对全连接层和循环神经网络的支持很弱。我尝试过把训练好的模型用 RKNN-Toolkit2 转成 RKNN 格式，结果 RKNN 对 GRU/LSTM 的支持非常有限，部分算子直接需要退回 CPU 执行，这样反而多了一层数据拷贝开销，整体速度甚至比纯 CPU 推理更慢。
第二，量化精度损失对控制策略影响很大。NPU 要跑得快通常需要 INT8 量化，但控制策略输出的关节角度精度要求很高，量化到 8 bit 后角度误差会被放大，真机上表现为每个控制周期都会出现小幅抖动，合在一起就是步态的明显不平滑。
第三，渲染和调度复杂。NPU 推理是异步的，需要自己管理输入输出缓冲区，控制循环这种对延迟一致性要求很高的场景，增加了不少调试成本。所以最终我选择在 CPU 上用 FP32 ONNX Runtime 推理，模型小、延迟稳、精度无损，这才是边缘控制的正道。
3.3 通信链路：RNDIS、串口和时序预算
Microduck 的 RK3566 开发板与上位机之间一般通过 USB RNDIS 协议组建虚拟以太网，也就是说插上 USB 线后，在宿主机和开发板上分别配置 IP，就能像局域网一样 SSH 登录和传输文件。这种方式比 HDMI 加键鼠方便太多，也是我日常调试的主要入口。不过在实机运行时要特别注意：RNDIS 的虚拟网卡走的是 USB 协议栈，偶尔会有小幅延迟抖动，所以我的做法是控制程序启动后，把所有无关服务停掉，保证 CPU 不被 USB 协议栈抢占太多。
另一个值得强调的通信链路是 RK3566 与底层舵机控制板的连接。Microduck 的舵机控制板一般通过串口接收指令，波特率通常设为 1Mbps 或者 500kbps。串口通信的时序非常敏感，我之前踩过一个坑是在同一路串口上既给舵机发位置指令，又去读舵机角度反馈，结果读取的时候产生了几毫秒阻塞，导致控制循环超过 20ms 预算。后来我改成发出指令后不等待反馈，只在需要校准或紧急停止时才主动读取舵机状态，时序就稳定了。
如果你也遇到控制循环周期波动大的情况，可以先在代码里打印每个环节的耗时分布，看堵塞到底出在推理、串口还是系统调用上。大多数情况通过调整线程优先级就能解决，实时的思路参考 RT Linux 的做法，把控制线程绑定到特定 CPU 核，并用 sched_setscheduler 设置 SCHED_FIFO 实时优先级。
3.4 电源噪声与舵机抖动
这个坑我一开始完全没有预料到。真机第一次站稳后走路总是发抖，一开始我以为是策略网络输出的速度指令波动太大，后来把推理输出直接打到日志里，发现输出序列非常平滑，问题其实是电源。
Microduck 如果直接用 USB 或者普通稳压模块给舵机和 RK3566 同时供电，舵机大电流瞬态变化会引起电源电压波动，这个噪声会通过 ADC 传导到 IMU 的读数上，最终导致控制策略收到错误的姿态信息。花了两天才定位到这个问题，当时的排查办法是看 IMU 原始数据里是不是有跟舵机动作相关的周期性噪声，发现确实是。
解决方案分两步：第一，舵机电源和控制板电源分开，舵机用电池高压直接供电，控制板经过稳压模块隔离供电；第二，在 IMU 数据进入策略网络前，用低通滤波器滤掉高频噪声。我这里用的是二阶 Butterworth 低通滤波器，截止频率 30Hz，对 50Hz 的控制循环来说足够了，不会引入明显延迟。
建议：给 RK3566 和舵机分别供电，至少也要在舵机电源上加大容量的电解电容。真机调试电源问题的优先级，应该放在模型调优之前。
4. 真机运行与调试：从站不起来到稳定步态
4.1 安全措施与开机逻辑
真机调试第一步不是调策略，而是写好安全逻辑。我在 Microduck 的控制程序里加了三层保护：第一层是状态检查，如果 IMU 检测到机身倾斜角度超过 45 度，立即停止发送控制指令；第二层是看门狗，控制循环每一轮都会更新一个计数器，如果主循环卡住超过 500ms，舵机控制板自动把所有关节回到初始位置；第三层是每次上电时所有舵机处于零力矩状态，只有确认遥控指令后才进入工作模式。
这个看起来简单的安全逻辑，救了我无数次。刚开始调试策略网络的时候，因为 IMU 数据方向没校准对，机器人一站起来就往一边倒，摔倒速度极快，如果没有第一层保护和外壳缓冲，舵机齿轮早摔断了。提醒所有做真机强化学习的朋友，安全逻辑一定是最先写的代码，没有协商余地。
4.2 零点校准与关节方向统一
Microduck 这类四足机器人采用的是串行总线舵机，可以实现角度反馈和位置闭环，但出厂时关节零点和方向并不统一。同一个关节，两只脚可能一个默认在 +20 度一个默认在 -20 度，如果不校准，就算策略网络输出完全正确的角度指令，机器人也会走成螺旋步态。
校准方法不复杂：用一个水平平台把机身架起来，让每条腿自然下垂，读取所有关节的当前角度并记录为“零点偏移”，部署时把策略输出减去这个偏移再下发。关节方向的处理更隐蔽，需要确认每个舵机的旋转方向和策略训练中使用的正方向一致，不一致的关节在部署代码里单独翻转角度符号。这个校准过程虽然无聊，但直接影响最终步态质量。
4.3 真机实测结果与 PPO 策略的调整方向
经过上面的适配后，我把训练好的 PPO 策略部署到 RK3566 上，第一次尝试是让机器人在原地站定 10 秒，再看姿态是否稳定。实测结果是：机身倾斜角度能控制在 5 度以内，但伴随大约 1.5Hz 的周期性低频晃动，步态虽然没倒但看起来像是时刻在“微调”。
这个问题的根源是策略网络在训练时没有见过真机的 IMU 高频噪声，导致它对速度信号过于敏感。解决办法有三条路：一是增大训练时 IMU 噪声的随机范围，让策略学会过滤噪声；二是在部署端滤波，正如前文所说；三是降低策略输出增益，让每个控制周期的关节角度变化幅度变小。我最终采用了第二种加第三种组合，实机表现明显改善，低频晃动基本消失了。
再说一个在参考关注里反复出现的关键词——“基于强化学习的 PID 控制”。很多人误以为强化学习替代了 PID，实际上在 Microduck 上更合理的做法是让强化学习策略输出目标速度和姿态，再由底层的 PD/PID 控制器去跟踪这些目标。也就是说，强化学习负责“指挥”，传统控制负责“执行”。这个分工让整个系统更容易调试：哪一层出问题就修哪一层，而不是把两个复杂的控制逻辑混在一个黑盒里。
4.4 常见问题与排查速查表
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 机器人在固频 1-2Hz 晃动 | IMU 噪声过大或输出增益过高 | 检查 IMU 原始数据；降低策略输出增益；加强低通滤波 |
| 电机发热严重 | 策略输出加速度过大 | 在奖励函数里加加速度惩罚；检查舵机是否超限位 |
| 控制循环超过 20ms | 模型推理过慢或串口阻塞 | 打印各环节耗时；换更小的网络；调整串口读逻辑 |
| 走起来往一侧偏 | 零点偏移未校准 / 关节方向不一致 | 重新校准零点；检查关节方向符号 |
| 机器人一上电就抖 | 电源噪声干扰 IMU | 分开供电；IMU 和舵机地线分离 |
| ONNX Runtime 加载失败 | 算子不支持 / 动态维度问题 | 换 GRU；检查 dynamic_axes 是否合理 |
| 舵机失去响应 | 看门狗触发或串口错误 | 查日志看是否触发安全逻辑；重启控制程序 |
5. 个人体会：仿真到真机之间到底隔了什么
整个项目从训练到实机跑通，前后花了我大概三周业余时间，真正花在训练和模型调优上的时间只占三分之一，剩下三分之二全部耗在系统集成和调试上。这大概是强化学习机器人落地最真实的规律：算法是引擎，但真机落地是底盘、电源、通信、实时性、安全机制这些“脏活”共同堆出来的。
如果让我重新做一遍，我会在项目一开始就把部署目标平台、控制频率、模型大小上限、通信时序预算这些约束写进设计文档里，然后带着这些约束去设计网络结构和训练超参，而不是训练完了才开始考虑“怎么搬到 RK3566 上”。否则等待你的就是改网络结构重新训练、重新适配边缘算子的循环。
另外要说的经验是：不要迷信 GPU 时代的训练工具链。PyTorch 里写网络很惬意，但 ONNX 导出、算子兼容、INT8 量化这些部署相关的能力，一定要提前熟悉。尤其像 RK3566 这种边缘设备，ONNX Runtime CPU 推理是最稳的路径，NPU 能不用就不用，至少在控制类任务上是这样。
最后分享一个对 Microduck 这类小型四足很实用的小技巧：真机部署前，先在仿真环境里把策略加上输出限幅和变化率限幅，再测试一遍在不同初始姿态下的表现。因为真机上舵机执行角度指令本身有延迟，如果策略输出变化速度过快，实际执行和仿真之间会出现滞后误差。加上变化率限幅之后，这个误差会被显著压小，步态也会平滑很多。这也是我这次工程里体会最深、回报最高的一个改动。
