去年年底我手头接到一个挺折腾的任务：把一套在英伟达 GPU 上训练的强化学习运动控制策略，部署到一台 25 厘米级别、主控是 RK3566 的 Microduck 足式机器人上。训练时一切完美，仿真里走得像模像样，结果一上实机就变“机器人帕金森”，各种抖动、侧翻、原地抽搐。折腾了两周之后，我才真正把从 GPU 到 ARM 实机的整条链路跑通。
这篇手记不是教程式的复读，而是把这套部署过程中遇到的实际问题、选型理由、踩坑链路和最终调优结果完整记录下来。项目基于开源 25 厘米足式平台 Microduck，训练端是英伟达 GPU（我用的单张 RTX 3090），部署端是 RK3566 开发板，算法侧以 PPO 这类在线强化学习为主，也顺带试了 IQL 离线强化学习的路子。如果你正准备把强化学习模型搬上低成本边缘设备，或者被仿真到实机的 gap 折磨过，这篇文章应该对你有用。
1. 项目缘起：Microduck 这台 25 厘米机器人到底想验证什么
1.1 硬件形态与核心部件选型
Microduck 是一台 25 厘米级的小型腿足机器人，整体重量控制在 1 公斤上下，外壳用了碳纤维板加 3D 打印件混合结构，既能保证刚性又能快速改型。腿部结构采用经典的四连杆加单腿三自由度布局，每条腿三个舵机，一共十二个电机。电机选用的是串行总线舵机，支持位置、速度和力矩三种控制模式，实测响应速度在 2ms 左右，基本够用。
主控板就是这次部署的核心难点之一：RK3566。这颗芯片是瑞芯微推出的四核 Cortex-A55 处理器，最高主频 1.8GHz，集成了 0.8 TOPS 算力的 NPU，内存我配了 4GB LPDDR4。和常见的树莓派 4B 相比，RK3566 的 CPU 单核性能略弱，但胜在接口丰富、成本低、工业级供货稳定，而且自带 NPU 可以做边缘推理加速。
传感器方面，基座上有一颗六轴 IMU，用于姿态解算；每条腿的舵机内置编码器，可以回传角度和角速度。整机通过 2S 锂电池供电，续航大概 20 分钟。为了调试方便，我还加了一个 5.8G 图传模块，但真正跑强化学习策略时，所有计算都在板载完成，不需要上位机实时参与。
1.2 为什么选择 RK3566 而非树莓派或 Jetson
很多朋友第一反应是，既然要跑神经网络推理，为什么不直接用 Jetson Nano 或者树莓派 5？我当时也犹豫了很久，最终选 RK3566 有几个现实原因：
第一是成本。Jetson 系列的开发板价格虚高，而且 4GB 版本经常缺货。RK3566 的板子三百块以内就能买到，性能虽然比不上 Jetson，但对于 Microduck 这种实时控制场景，A55 四核 CPU 的算力已经足够——因为强化学习策略本身并不大。
第二是功耗。足式机器人是电池供电，Jetson 满载功耗能到 10W 以上，对电池和散热都是巨大压力。RK3566 的整板功耗非常友好，实测跑满也就 3W 左右，CPU 负载 60% 以下是常态，省下来的功耗全给舵机了。
第三是生态。RK3566 不是冷门芯片，Ubuntu、Buildroot、Debian 都有适配镜像，而且官方维护了 RKNN 工具链，支持 PyTorch、ONNX 转模型。虽然我在实际部署中绕过了 RKNN（后面细说），但至少有官方工具可以兜底。
1.3 强化学习在这台机器人上的作用边界
部署之前必须想清楚一个问题：强化学习策略到底接管了什么？很多人误以为强化学习模型是端到端输入图像输出关节角度，这在小机器人上不现实。Microduck 的强化学习策略做的是“高层运动控制”——输入是 IMU 姿态、关节角度、关节角速度、上一时刻的动作，输出的是十二个关节的目标角度或力矩偏置。
也就是说，底层 PID 闭环（我用的是串级 PID，外环角度、内环角速度）仍然保留，强化学习策略相当于动态调整 PID 目标值，或者在某些关节上加一个前馈补偿。这样做的优势很明显：策略网络不需要学习精确的电机死区补偿，而舵机自带的闭环能力会兜住底层控制。
2. 英伟达 GPU 上的训练：策略从哪里来
2.1 训练框架选择：PPO 还是 IQL
Microduck 的控制策略我最初用的是 PPO（Proximal Policy Optimization），这也是足式机器人领域最主流的在线强化学习算法。PPO 在仿真环境里收敛稳定，超参鲁棒性高，适合我们这种没有专业强化学习团队的小项目。
但后来我发现 PPO 有个致命短板：样本效率低，而且对仿真环境的质量要求极高。如果你没有把电机延迟、摩擦力、驱动饱和这些细节在仿真里建模到位，PPO 训出来的策略在实机上基本必翻车。于是第二版我尝试了 IQL（Implicit Q-Learning，离线强化学习），直接从一组混有噪声的采集数据中学习策略，不依赖实时与环境的交互。
两个算法在 GPU 上的训练表现差异很大。PPO 训练一千万步大概需要 4-6 小时（单张 3090），IQL 离线训练因为数据集固定，一个 epoch 只要半小时左右。但 IQL 对数据质量要求更高，数据里如果没有覆盖到关键状态（比如侧倾超过 30 度），策略遇到没见过的情况就会抓瞎。
2.2 reward 设计经验：被忽视的“零速惩罚”
训练前期我的模型总是学会“原地转圈”而不是“向前走”。后来逐项复盘 reward 项才发现，问题出在速度项的奖励函数设计不合理。我只奖励了前进速度，没有惩罚横向速度和偏航角速度，策略就“作弊”了——通过侧向滑动和摇头晃脑来刷奖励。
正确的做法是加三项：
- 前进速度与目标速度的差，用高斯函数映射到 (0,1]，保证正奖励。
- 横向速度和偏航角速度的 L2 惩罚，系数可以设为 0.5 和 0.2。
- 关节加速度变化率惩罚（action rate penalty），防止动作抖动。
第三项尤其关键。如果这个惩罚系数设得太小，动作会高频抖动，到了实机上舵机发热严重甚至直接过热保护；系数设得太大，动作会变得迟钝，走起来像木偶。我的最终取值是 0.01，已经过了五轮调参。
2.3 模型规模与训练收益的权衡
强化学习策略网络的规模不需要大，我的基础版本是一个三层 MLP：输入维度是 34（IMU 6 维 + 关节角度 12 维 + 关节角速度 12 维 + 上一帧动作 12 维，减去冗余后实际用 34），隐藏层分别是 256、128，输出维度是 12。参数量大约 9 万，模型文件导出 ONNX 后只有 360KB 左右。
有人可能觉得参数量太小，会不会学不到复杂行为？实际上对于 25 厘米级别的四足机器人，动作空间相对受限，过于复杂的网络反而容易过拟合仿真环境的动态特性，造成仿真到实机（Sim-to-Real）迁移困难。我的经验是先小后大，如果 256x128 学不会，再试 512x256，但训练时间会翻倍。
3. 从 PyTorch 到 RK3566：模型压缩与格式转换
3.1 ONNX 导出的坑：动态轴与 opset 版本
训练好模型只是第一步，真正的麻烦从导出 ONNX 开始。PyTorch 模型转 ONNX 看似简单，一个torch.onnx.export就搞定了，但实际踩了一堆坑。
首当其冲的是动态轴（dynamic axis）问题。我的模型输入里包含batch维度和sequence维度（如果你用了 LSTM 或 GRU），导出时必须显式指定哪些轴是动态的，否则 RK3566 上的推理引擎无法处理不定长输入。我的模型没有时序结构，所以直接把batch固定为 1，导出时动态轴全部禁用，反而省了很多后续兼容性的麻烦。
其次是 opset 版本。RK3566 的推理引擎对 ONNX 算子支持有限，实测 ONNX Runtime 的 CPU 后端可以支持 opset 11 到 17，但如果用 RKNN 工具链转换，opset 建议固定在 11 或 12，太高了会碰到不支持的算子。我的模型里全是全连接层和 tanh 激活函数，opset 12 就能全覆盖，但如果你用了LayerNorm、GELU这类较新的算子，需要降级或者算子替换。
3.2 量化：先用 FP16 还是直接 INT8
模型要部署到边缘设备，量化是绕不开的话题。RK3566 的 CPU 支持 FP32、FP16 标量运算，NPU 则能加速 INT8 量化模型。我一开始想走 RKNN 的 INT8 路线，毕竟 NPU 听起来比 CPU 高级，结果踩了一个大坑——量化后精度损失严重。
原因不复杂：我的策略网络输出的是关节目标角度，对精度要求极高（角度误差 1 度都会导致舵机闭环震荡），而 INT8 量化对激活值的分布太敏感。ReLU 还好，tanh 被量化到 INT8 后，接近饱和区的输出值误差直接从 0.001 变成 0.1，这在控制回路里是不可接受的。
最终我放弃了 INT8，改用 FP32 模型直接在 CPU 上跑推理。后面实测证明我的选择是对的——RK3566 的 A55 CPU 跑 256x128 的 MLP，单次推理只需 2-3ms，压根不需要 NPU 加速。这也是很多人对“边缘 AI”的误解：不是所有模型都需要走 NPU，小模型 CPU 推理反而更稳定。
3.3 模型部署形态：ONNX Runtime 还是自写 C++ 推理
部署推理后端我对比过三个方案：ONNX Runtime（CPU），RKNN（NPU），以及纯 C++ 手写全连接层正向计算。
第一个方案最简单，RK3566 上有预编译的 ONNX Runtime 的 aarch64 版本，直接调用 API 即可，支持 FP32 和 FP16。缺点是库体积大（约 10MB），依赖库多，对于单模型推理有点“杀鸡用牛刀”。
第二个方案（RKNN）在精度上踩坑后直接淘汰，还有一个原因是 NPU 驱动会占用实时性，推理时间受其他进程干扰明显，这对控制回路非常不利。
我最终选了第三个方案：用纯 C++ 实现全连接层和 tanh 激活函数，权重从 ONNX 里解析出来存成二进制文件。全连接层本身就是一个矩阵乘加操作，代码量不大，单次推理 2ms，可控性极强。
4. RK3566 实机部署环境搭建
4.1 系统镜像与内核参数调整
RK3566 的板卡系统我选的是 Ubuntu 22.04 Server 版，自带 6.1 内核。Server 版没有桌面环境，能省下将近 500MB 内存，对实时性也有帮助。
系统装好后第一件事是调整内核参数，关闭 CPU 调频和自动降频。默认的cpufreq策略会在负载降低时自动降低主频，导致推理时快时慢，控制周期不稳定。通过cpufreq-set把四核全部固定在最高频率：
cpufreq-set -c 0 -g performance -u 1.8GHz cpufreq-set -c 1 -g performance -u 1.8GHz cpufreq-set -c 2 -g performance -u 1.8GHz cpufreq-set -c 3 -g performance -u 1.8GHz如果芯片支持 DVFS，还需要在设备树里禁用cpu-supply的调压节点，保证跑高负载时不会触发欠压重启。
4.2 部署目录结构与依赖库管理
实机上的程序我分了四大块：
controller/：底层 PID 控制，负责解析 IMU 数据，输出 PWM 或串行舵机指令。policy/：强化学习策略推理模块，C++ 实现，加载权重文件，输入状态，输出动作。comm/：与上位机的通信模块，通过 USB-TTL 串口上报状态。storage/：记录日志，保存推理输入输出，用于后续离线强化学习数据采集。
依赖库尽量精简，大部分用系统自带的 libc、libm、libstdc++，只有串口通信用了libserialport。理由是嵌入式环境依赖越少越好，交叉编译时少一个动态库，运行时就少一个“找不到 so 文件”的坑。
4.3 交叉编译还是板端编译
我一开始图省事直接在 RK3566 板子上编译，结果一个 5000 行的 C++ 工程在 A55 上编译了将近十分钟，每次调代码浪费大量时间。后来切换到 PC 上交叉编译，用aarch64-linux-gnu-gcc配合 CMake 工具链，编译速度快了十倍。
交叉编译最大的坑是链接触发器。我用的编译器版本是 13.2.0，板端系统的 libstdc++ 版本是 12，编译出来的程序依赖更高的 GLIBCXX，放到板上一运行就报GLIBCXX_3.4.31 not found。解决方法是加一个静态链接选项，把 C++ 标准库静态编进去：
set(CMAKE_EXE_LINKER_FLAGS "-static-libstdc++ -static-libgcc")这样编译出来的二进制文件可以在绝大多数 aarch64 Linux 上运行，代价是体积大了 3MB，对于控制程序来说完全可接受。
5. 部署过程中踩过的三个深坑
5.1 RK3566 被识别成 ADB 设备：不是通信失败，是权限与 USB 模式冲突
调试过程中我遇到一个特别诡异的现象：用 USB 连接板子后，上位机识别到rk3566设备，但lsusb显示它是一个 ADB（Android Debug Bridge）设备，而不是 USB 串口设备。插上 USB 线后，/dev/ttyUSB0设备节点完全没有生成。
排查思路：
- 先确认 USB 线是数据线而非充电线，排除硬件问题。
- 检查内核模块，
lsmod | grep usb看是否加载了usb_serial驱动，结果是没加载。 - 手动加载
usb_serial和cdc_acm模块，设备节点出现，但一访问就报 I/O 错误。 - 进一步查询
/sys/kernel/debug/usb/devices，发现设备枚举的接口类是 0xFF（vendor specific），被系统识别为 ADB 接口。
根因是板卡厂商的固件默认烧写了 Android 系统的 bootloader，USB 口默认进入 ADB 模式。解决方法是重新烧写 Linux 版的 U-Boot，或者在 U-Boot 环境变量里关闭 ADB 功能。这个坑花了我们整整半天才挖出来，建议所有用 RK3566 做 Linux 开发的朋友，拿到板子第一件事先确认 USB 模式。
5.2 NPU 推理比 CPU 更慢的真相
前面提到我量化后想用 NPU 加速，结果实测 NPU 推理一次要 15ms，而 CPU 只要 2ms。这个反直觉的结果一开始让我怀疑是不是驱动没配置好，反复查了 RKNN 工具的版本和 NPU 负载情况，发现两个原因：
第一，模型太小。NPU 的推理延迟主要由启动和调度开销主导，真正计算矩阵乘的时间占比很低。对于 9 万参数的小模型，NPU 的调度开销已经超过了实际计算时间。
第二，NPU 驱动有额外的内存拷贝。输入数据要先 DMA 到 NPU 专用内存，推理完再拷贝回来，这两次拷贝的开销至少 5ms。
所以结论很明确：ONNX Runtime CPU 推理是首选，NPU 更适合大模型或 CV 预处理。
5.3 控制环时序抖动：从 20ms 降到 3ms 的关键
实机跑起来后，机器人频繁抽搐，但推理延迟只有 2ms 啊，按理说 500Hz 控制频率绰绰有余。后来我用perf和ftrace查了中断和调度延迟，发现控制周期抖动非常严重，最大值竟然超过 20ms，远超稳定阈值。
根因有两个：
第一个是 CPU 调度器的 CFS 策略不够实时，其他进程（比如日志模块）会抢占控制线程的 CPU 时间。解决方法是给控制线程设置为SCHED_FIFO实时优先级，并且把 CPU 亲和性绑定到单独一个核上。
struct sched_param param; param.sched_priority = 80; pthread_setschedparam(thread_id, SCHED_FIFO, ¶m); cpu_set_t set; CPU_ZERO(&set); CPU_SET(2, &set); pthread_setaffinity_np(thread_id, sizeof(set), &set);第二个是 IMU 数据读取使用的 I2C 总线有时序问题。I2C 读 IMU 时，如果总线被其他设备占用，阻塞时间会到几个毫秒。我在 IMU 驱动里加了 I2C 总线锁保护，并把控制循环改成双缓冲：上一帧数据在 CPU 计算完之前，新一帧数据已经在另一个 buffer 里等着了，相当于硬件 ping-pong 缓冲。
改完之后，控制周期的抖动降到 0.1ms 级别，机器人立刻稳定了。
6. 实机联调与效果调优
6.1 Sim-to-Real 差距：从仿真到实机最大的坎
训练时仿真环境里走得极好，一上实机就东倒西歪，这个问题几乎每个做强化学习足式机器人的团队都会遇到。Microduck 也没逃过，我第一版策略实机测试时，机器人根本站不住，只能在地上躺平。
Sim-to-Real 差距的来源主要有三个：
第一个是动力学参数不准。仿真里的电机力矩曲线、摩擦系数、阻尼参数和实机差异很大，尤其是舵机的死区效应，仿真里完全没建模。
第二个是传感器噪声。仿真里 IMU 数据是干净的，实机的振动噪声非常离谱，尤其是舵机动作时产生的结构性振动。
第三个是执行延迟。仿真里策略输出立即生效，实机则有舵机响应延迟和总线通信延迟。
解决手段是域随机化（Domain Randomization）。我在仿真里把电机扭矩系数随机化 20%，IMU 噪声标准差随机化到 0.5 度，舵机响应延迟随机化为 1-3ms。这样训练出来的策略对实机环境的鲁棒性大幅提升，实机上的“帕金森抖动”基本消失。
6.2 实机测试中的控制参数调整
策略部署到实机后，还必须微调底层 PID 参数。仿真里 PID 阻抗参数是从 MuJoCo 的默认值继承来的，实机上完全不对。我根据实机响应曲线反复调了五轮，最终确定：
- 位置环 P：35.0，D：2.2
- 角速度环 P：8.0，I：0.5，D：0.6
帕秋·道，“陀螺仪实测偏航角速度噪声太大，所以偏航环不加积分项。”实机测试时，策略输出的动作指令先经过一个低通滤波器（截止频率 20Hz），防止动作高频抖动传递到舵机。
6.3 安全性措施：限位、急停、力矩保护
强化学习策略在实机上跑有一定风险，尤其刚刚训练完还没调好参数时，机器人做出危险动作很常见。我的保护机制做了三层：
- 硬件急停：一个实体按钮，按下就切断舵机电源。
- 软件限位：关节角度超过 ±60 度直接清零策略输出，回中位，防止关节过限损坏。
- 力矩保护：舵机电流超过阈值（2.5A）持续 500ms，自动切换为安全模式，停止执行策略。
这三层缺一不可。我实测过程中至少闪断了三次舵机连接线，都是因为关节角度超限后被外力掰断，硬件限位救了整台机器人。
7. 后续还能怎么扩展
这次部署虽然跑通了，但说实话还有很多可以优化的地方。我给 Microduck 留了三个升级方向，后面会继续深入。
第一个是离线强化学习升级。我目前用 PPO 在线训练 + Sim-to-Real 迁移，但实机数据一直在产生，完全可以采集一批带噪声的实机交互数据，用 IQL 做离线微调，让策略适配这台特定机器人的个体差异。这是从“通用策略”走向“个体定制”的重要一步。
第二个是模型更小更快。目前的 MLP 是 256x128，单次 2ms。下一步我打算用知识蒸馏把一个 512x256 的教师网络压成 128x64 的学生网络，目标是推理 1ms 以内，把控制频率从 500Hz 提到 1000Hz，进一步提高动态稳定性。
第三个是感知闭环。目前机器人是盲走，没有视觉或触觉反馈。RK3566 有 0.8 TOPS 的 NPU，理论上可以跑一些轻量级视觉模型做地形识别，把视觉特征拼接到策略输入里。这个改动很大，需要重新训练策略，但上限也明显更高。
这套“GPU 训练 + RK3566 实机”的部署链路，其实适用于所有 25 厘米级别的足式机器人、机械臂或移动底盘。模型小、算力紧、实时性要求高，这三点和很多边缘 AI 场景是一样的。希望这篇记录能帮你少踩几个坑，项目源码和训练脚本我已经整理好放在 GitHub 仓库里，需要的朋友可以去找，搜索 Microduck 就能看到。
