去年年底我手头接到一个挺折腾的任务把一套在英伟达 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 还是 IQLMicroduck 的控制策略我最初用的是 PPOProximal Policy Optimization这也是足式机器人领域最主流的在线强化学习算法。PPO 在仿真环境里收敛稳定超参鲁棒性高适合我们这种没有专业强化学习团队的小项目。但后来我发现 PPO 有个致命短板样本效率低而且对仿真环境的质量要求极高。如果你没有把电机延迟、摩擦力、驱动饱和这些细节在仿真里建模到位PPO 训出来的策略在实机上基本必翻车。于是第二版我尝试了 IQLImplicit Q-Learning离线强化学习直接从一组混有噪声的采集数据中学习策略不依赖实时与环境的交互。两个算法在 GPU 上的训练表现差异很大。PPO 训练一千万步大概需要 4-6 小时单张 3090IQL 离线训练因为数据集固定一个 epoch 只要半小时左右。但 IQL 对数据质量要求更高数据里如果没有覆盖到关键状态比如侧倾超过 30 度策略遇到没见过的情况就会抓瞎。2.2 reward 设计经验被忽视的“零速惩罚”训练前期我的模型总是学会“原地转圈”而不是“向前走”。后来逐项复盘 reward 项才发现问题出在速度项的奖励函数设计不合理。我只奖励了前进速度没有惩罚横向速度和偏航角速度策略就“作弊”了——通过侧向滑动和摇头晃脑来刷奖励。正确的做法是加三项前进速度与目标速度的差用高斯函数映射到 (0,1]保证正奖励。横向速度和偏航角速度的 L2 惩罚系数可以设为 0.5 和 0.2。关节加速度变化率惩罚action rate penalty防止动作抖动。第三项尤其关键。如果这个惩罚系数设得太小动作会高频抖动到了实机上舵机发热严重甚至直接过热保护系数设得太大动作会变得迟钝走起来像木偶。我的最终取值是 0.01已经过了五轮调参。2.3 模型规模与训练收益的权衡强化学习策略网络的规模不需要大我的基础版本是一个三层 MLP输入维度是 34IMU 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 RuntimeCPURKNNNPU以及纯 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显示它是一个 ADBAndroid Debug Bridge设备而不是 USB 串口设备。插上 USB 线后/dev/ttyUSB0设备节点完全没有生成。排查思路先确认 USB 线是数据线而非充电线排除硬件问题。检查内核模块lsmod | grep usb看是否加载了usb_serial驱动结果是没加载。手动加载usb_serial和cdc_acm模块设备节点出现但一访问就报 I/O 错误。进一步查询/sys/kernel/debug/usb/devices发现设备枚举的接口类是 0xFFvendor specific被系统识别为 ADB 接口。根因是板卡厂商的固件默认烧写了 Android 系统的 bootloaderUSB 口默认进入 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, param); 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 的默认值继承来的实机上完全不对。我根据实机响应曲线反复调了五轮最终确定位置环 P35.0D2.2角速度环 P8.0I0.5D0.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 就能看到。