企业官网建设流程全解析

说真的，第一次把Microduck从英伟达GPU上的仿真环境搬到RK3566这块小板子上时，我心里是没底的。训练时用的显卡动辄几百瓦功耗，而RK3566整板功耗可能还不到5瓦，中间隔着好几个数量级的算力差距。但正是这种"高射炮打蚊子"再"换弹弓打鸟"的过程，让我把整个强化学习机器人落地的链路彻底摸了一遍。

这篇文章我会把Microduck这只25厘米四足机器人的完整部署过程拆开讲：为什么训练端要GPU、部署端选RK3566、中间模型怎么从PyTorch一路变成RKNN格式、实机上电后遇到的那些奇奇怪怪的问题，以及最终跑起来的性能表现。适合手里有Microduck整机或者类似小型足式机器人、想自己从零训一套强化学习策略并且部署到低成本嵌入式平台的玩家参考。

1. 训练端与部署端：为什么是GPU加RK3566的组合

1.1 Microduck到底是个什么项目

Microduck是一个开源的小型四足机器人项目，体长大概25厘米，整机重量控制在几百克级别。它最吸引人的地方不是硬件本身，而是官方仓库直接给出了一套从仿真训练到真机部署的完整方案，用的是IQL离线强化学习路线，也就是Implicit Q-Learning。这一点非常关键，因为早期做足式机器人强化学习，大家习惯用PPO这类在线算法，机器人本体需要在仿真里不断试错采样，训练完再想办法迁移到真机。而Microduck直接走离线强化学习，先收集好数据集，再训练策略，整个流程更接近传统深度学习的工作方式。

从硬件配置看，Microduck有12个自由度，每条腿是髋关节、大腿关节、小腿关节的经典三关节布局。控制板用的就是RK3566这颗SoC，集成4核Cortex-A55 CPU，还带了一个算力在1 TOPS左右的NPU。这个规格在嵌入式平台里不算高，但跑一个轻量级MLP策略网络绰绰有余。

1.2 算力鸿沟决定了部署方式

训练强化学习策略和部署策略，对算力的需求完全是两回事。训练阶段，算法要不断和环境交互采样，一个批次的数据要经过前向传播、计算损失、反向传播、更新网络参数这一整套流程。跑几百万步训练，哪怕用RTX 4090这种级别的显卡，也要几个小时甚至一晚上。真让机器人本体背着个GPU满屋跑，既不现实也没必要。

RK3566能做的是推理——策略网络已经训练好，权重固定，输入观测向量，前向算一遍输出动作。这种固定形状的小型MLP，在NPU上做INT8量化推理，单次时延可以压到几毫秒级别，完全能满足足式机器人50Hz甚至更高频率的控制需求。所以整个技术路线的本质是：用高算力把策略练好，再用模型压缩和格式转换，把策略塞进低功耗设备里实时运行。

1.3 IQL离线强化学习的存在意义

Microduck选IQL而不是PPO，我个人理解有几层考虑。首先是数据效率，IQL是从固定数据集里学习，不需要在线和环境交互，这让整个训练流程变得稳定可控。其次是安全性，真机上的在线强化学习一旦策略崩溃，轻则摔机重则损坏硬件，而离线学习在部署前就可以通过仿真充分验证。第三是复现门槛，离线数据集的采集和训练是解耦的，意味着别人用了什么样的数据、什么样的训练配置，社区都能直接复现。

IQL的核心思路是学一个Q函数，但通过expectile回归来避免对分布外动作的过高估计。通俗点说，数据集中有的状态动作对，我们认真学习；数据集中没有见过的组合，不去瞎猜它的价值。这让它特别适合机器人这种高维连续控制任务。

2. 仿真训练：把策略在MuJoCo里先跑通

2.1 训练环境搭建

Microduck的训练环境主要基于MuJoCo物理引擎，这是目前机器人强化学习社区最常用的仿真器之一。我的建议是直接用官方仓库的依赖清单来装环境，不要自己混装版本。MuJoCo对Python版本和NumPy版本有要求，我一开始图省事用了系统自带的Python 3.10，结果编译扩展时报了一堆错，最后老老实实按README建了虚拟环境。

GPU这边，我用的是一张12GB显存的NVIDIA显卡，训练Microduck这个体量的任务绰绰有余。如果显存低于8GB，可以把batch size调小一些，但训练时间会相应变长。值得说明的是，IQL的训练过程中不需要在GPU上跑仿真，仿真一般用多核CPU并行，GPU主要负责网络前向和反向计算，所以训练机的CPU核心数量也很重要。

2.2 数据集从哪里来

离线强化学习的数据集质量，直接决定最终策略的天花板。Microduck的策略训练数据来自仿真环境，在仿真里用一些前置控制器或者随机策略去探索环境，记录下状态、动作、奖励、下一状态这些转移数据。这里有个很容易踩的坑：如果数据集里全是成功轨迹，策略学出来会很脆，一旦实机状态略微偏离训练分布，表现就会断崖式下跌。

所以我采集数据时会刻意加入大量随机扰动：在仿真里随机改变地面摩擦系数、随机推机器人一把、随机初始化关节角度。目的就是让数据集覆盖尽可能广的状态空间。这个思路叫domain randomization，本质上是为策略创造更多"意想不到"的情况，逼着它学会适应。

2.3 训练参数与过程记录

我用的是官方默认配置基础上微调过的一组参数：

训练过程中我会重点盯两个指标：一个是Q值的均值曲线，稳定上升说明价值函数在收敛；另一个是策略在仿真环境里的平均回报，这个直接反映控制效果。如果发现回报曲线震荡剧烈，优先考虑降低学习率，而不是盲目加训练步数。

3. 从PyTorch到RKNN：模型转换全流程

3.1 导出ONNX时的关键细节

训练完的策略网络一般保存为PyTorch的state_dict格式，但RK3566的NPU不认识PyTorch，需要一个中间格式来过渡，ONNX就是这个桥梁。导出ONNX时，有几个细节直接影响后续转换的成败。

首先是必须把网络切到eval模式，同时关掉梯度计算。我的策略网络带了一个动作采样的随机头，训练时会从高斯分布里采样动作，但部署时只需要均值输出。这里一定要把采样分支剥掉，单独导出均值输出的子网络，否则导出后的模型带随机性，实机上表现会飘。

其次是输入输出的维度要固定。RNNK转换工具对动态shape支持有限，我在导出时显式指定了输入为一个batch、固定维度的向量。Microduck用的观测大约40维，输出12维关节目标角度。导出命令类似下面这段：

import torch policy.eval() dummy_obs = torch.randn(1, obs_dim) torch.onnx.export( policy.actor_mean, dummy_obs, "microduck_policy.onnx", input_names=["obs"], output_names=["action"], dynamic_axes=None, opset_version=12 )

导出完成后，一定要用onnxruntime在PC上先加载推理一次，确认输出形状和数值范围正常。这一步能过滤掉大部分低级错误。

3.2 RKNN量化转换的完整步骤

模型要跑在RK3566的NPU上，还得用瑞芯微官方提供的RKNN-Toolkit2工具链做转换。这个工具跑在x86的PC上，安装时要注意Python版本，我用的是Python 3.8配合虚拟环境才顺利装上。

转换脚本的核心逻辑是加载ONNX、配置量化参数、生成RKNN文件。量化这一步非常关键，它会把网络权重从FP32压到INT8，模型体积缩小4倍，推理速度大幅提升，但精度会有损失。我的转换配置参考如下：

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

dataset.txt里面放的是一批有代表性的输入数据，工具会统计这些数据的数值分布来确定量化参数。我建议从训练数据集里随机抽几百条真实观测样本，而不是随便生成一些随机向量，这样量化误差会小很多。

3.3 NPU推理精度对比

模型转换完，不能直接扔到板子上，先在PC上用RKNN模拟器做一次推理，和原始PyTorch模型的输出做对比。我跑了几百条样本，计算余弦相似度和最大绝对误差。正常情况下余弦相似度应该在0.99以上，最大绝对误差控制在0.1以内。

我第一次转换时发现动作输出比原始模型偏大，排查之后定位到是量化校准数据分布不匹配的问题。换成从真实仿真轨迹里采样的数据后，误差立刻降下来了。所以这个环节一定不能省，否则到了实机才发现动作异常，排查成本会翻倍。

4. RK3566上的系统部署与运行时接入

4.1 系统镜像与实时性配置

RK3566开发板烧录Ubuntu系统后，第一件事不是装环境，而是调整系统实时性。机器人控制对时延敏感，如果CPU忙于其他任务，控制周期抖动会导致策略输出不稳定。

我用的是这个思路：先把CPU调频策略固定到performance模式，避免频率波动影响推理延迟，再通过taskset命令把控制进程绑定到特定CPU核心上。如果后续想进一步压低抖动，可以考虑换preempt-rt内核，不过我实测下来，在标准内核上把进程优先级调高，配合核心隔离，已经能满足要求。

另外要关闭系统中不必要的服务——蓝牙、桌面环境、自动更新这些，在嵌入式部署时都是干扰源。

4.2 推理接口的接入方式

RK3566运行时接入有两种途径：Python版的rknn-toolkit-lite2接口，以及C/C++的librknnrt接口。Python方便快速验证，C接口适合正式部署。我第一版用的Python接口，跑了几天确认逻辑没问题后，才移植到C接口上，这样延迟更低，内存占用也更小。

C接口的调用流程大致是：初始化上下文、加载RKNN模型、查询输入输出信息、每次推理时把观测值填入输入张量、调用rknn_run执行推理、从输出张量里取出12维动作。这里有一个细节：观测数据要从float32转成int8量化后的格式，不过RKNN接口封装了这部分，只需要设置好输入张量的类型，工具会自动完成定标。

4.3 和控制回路的时钟同步

Microduck的控制循环是典型的两级结构：策略推理和底层PD控制。我实现的频率是策略50Hz、PD控制在500Hz。PD控制负责跟踪策略输出的目标关节角度，以更高的频率计算力矩指令发给电机驱动。

这里给人最深的教训是：策略推理频率不能一味追求高。RK3566的NPU跑一个INT8量化的MLP，单次推理时间大约2到4毫秒，理论上能跑到200Hz以上。但足式机器人控制并不需要那么高的策略频率，反而更看重延迟稳定。把策略频率定在50Hz，每个周期内留足裕量，哪怕偶尔一次推理超时，也不会导致控制崩溃。

5. 实机调试手记：那些仿真里永远不会告诉你的事

5.1 上电后站不稳的排查思路

实机调试的第一天，我满怀期待地给机器人上电，结果它就像喝醉了酒一样东倒西歪。这个情况太典型了，我把自己踩过的几个坑梳理了一下。

第一个排查点在观测归一化。训练时数据都做过标准化处理，实机上部署时如果忘了用同样的均值和方差做归一化，网络输入分布完全变了，输出自然乱套。第二个坑是初始姿态不一致。仿真里每次训练episode都从默认站立姿态开始，但实机上电时关节位置可能停在任意位置，策略一启动就面对一个没见过的状态，表现当然不可控。解决方法是每次启动前先把所有关节缓慢归位到默认姿态，再激活策略。第三个是电机响应差异。仿真里的PD参数和真机电机驱动器的PID参数不是一回事，需要根据实机表现重新整定。

5.2 走着走着就歪掉的玄学问题

当机器人终于能站稳之后，下一个问题接踵而至：它走路会逐渐偏向一侧，跑个几米就斜着出去了。

排查了一圈，发现根源在IMU零偏。训练时仿真里的IMU数据是理想值，而实机的IMU存在大约正负2度每秒的零偏，微小误差在积分和策略网络中被逐渐放大，导致步态不对称。解决方法是上电后静止采集几百帧IMU数据求平均，再在运行时减去这个零偏。另外，关节编码器的零点偏移也会导致类似问题，每次装机后都需要做一次标定，把机械中位和编码器读数对齐。

5.3 实机调参技巧速查

调试稳定后，我总结了一套对新手比较友好的实机调参顺序：

• 先在外部支架辅助下上电，让机器人双腿悬空或半承重，验证动作方向是否正确，避免一开始就摔坏硬件。
• 从低速度指令开始测试，确认行走步态稳定后，再逐步提高目标速度。
• 在代码里启用动作平滑，最简单的方式是一阶低通滤波，平滑系数从0.5开始调，太小动作迟缓，太大会震荡。
• 每次测试都记录日志，包括观测输入、策略输出、PD力矩、IMU数据。日志是排查这类部署问题最有效的手段。

6. 性能复盘与实用建议

6.1 部署后的实测数据

这套方案全部跑通后，我在两种推理模式下做了对比测试：

NPU相比CPU推理，速度提升接近一个数量级，功耗还更低。实测下来策略在50Hz频率下运行，CPU占用率很低，剩余算力足够跑状态估计和通信等外围任务。整个系统稳定工作一个小时后，开发板温度属于温热状态，不需要额外加散热风扇。

6.2 针对Microduck部署路径的个人体会

回头复盘整个流程，最核心的体会是：仿真到部署的惊险跳跃，每一步都有坑，但每一步也都有方法可循。

建议新入坑的朋友先不要追求自己训练数据、自己改算法，而是把官方给出的模型转换链路完整跑通一遍，实机稳定行走之后再考虑做自己的策略优化。毕竟强化学习机器人落地，最难的不是算法原理，而是打通整个工程链路的过程。希望这份手记能帮你少走一些弯路。