从GPU到RK3566：四足机器人Microduck的强化学习部署实战

干了几年机器人强化学习，我越来越觉得最有意思的不是在仿真里把 reward 刷到多少，而是看着一个在 GPU 上训练出来的策略，真的能在一个手掌大的板子上跑起来，让 25 厘米的四足小家伙在桌面上站稳、迈步、翻正。这篇就完整复盘一下 Microduck 从英伟达 GPU 上的强化学习训练，到 RK3566 实机部署的整个过程，重点讲训练完之后怎么把模型搬到嵌入式平台上，以及那些文档里基本不会写的坑。

先交代一下背景，Microduck 是一只 25 厘米级别的开源四足机器人，主控我用的是 RK3566 的开发板，关节执行器是串行总线舵机。训练阶段在 NVIDIA GPU 上用强化学习（PPO）跑仿真，训练完成后把策略导出成 ONNX，再转换到 RK3566 上做实时推理。这套流程对做机器人强化学习、嵌入式部署、边缘计算的同学都有参考价值。如果你想做 sim-to-real，又不想一上来就搞宇树那种大机器，Microduck 这个尺寸和算力平台其实很合适，因为你真刀真枪会遇到所有嵌入式部署该有的问题——延迟、量化、实时性、供电、通信，一样都躲不掉。

1. Microduck 项目拆解：这个机器人到底在做什么

1.1 25 厘米的小家伙，硬件上是怎么搭的

Microduck 的名字带着点彩蛋，“duck”不是比喻它是鸭子，而是这个项目的定位就是小巧、好玩、开源，像养一只宠物一样可以天天折腾。整机大概 25 厘米长，重量在 1 公斤上下，四肢各有 3 个自由度，一共 12 个关节。每个关节由一个串行总线舵机驱动，主控板是一块 RK3566 开发板，运行 Linux 系统，通过 UART 串口和舵机控制模块通信。

这种硬件配置在机器人强化学习项目里属于“小而全”的类型。算力不像普通树莓派只能做轻量逻辑控制，也不像 x86 工控机那样可以随便跑大模型，RK3566 是一颗四核 Cortex-A55 的 SoC，主频 1.8GHz，另外带一个 1 TOPS 级别的 NPU。对于我们这种策略网络只有几万到几十万个参数的小模型来说，CPU 推理完全够用，NPU 反而会因为量化和转换流程带来一堆额外问题。

再说舵机。Microduck 这类小机器人大量使用的是串行总线舵机，常见的有 LX-16A 这种，也有用步进加编码器方案的。我手上这套用的是支持位置反馈的串行舵机，内部自带位置闭环，我们主机端只需要以固定频率把目标角度通过串口发过去就行。好处是控制简单，坏处是内部闭环响应速度有限，而且位置反馈的频率和精度都一般，这个后面实机部署部分会详细展开。

1.2 为什么说“训练容易部署难”

很多人一听到强化学习机器人，第一反应是训练门槛高，需要 GPU、需要搭仿真环境、需要调 reward。实际上当你把框架跑通之后，训练本身是很流水线的事情，真正让人掉头发的是部署阶段。

原因也很直接：训练的时候你面对的是一个理想化的仿真环境。物理引擎帮你算接触力，执行器的响应是参数化模型，传感器数据干干净净没有噪声，一切都跑在一张 A100 或者 4090 上，算力是无限量供应的。但到了 RK3566 实机上，情况完全变了。串口通信有延迟和丢包，舵机响应有滞后，IMU 数据带着噪声，CPU 还要同时跑系统服务、通信协议和推理任务，任何一个环节出现抖动，整个控制循环就乱了。

另一个容易被忽略的点是仿真到实物的“分布偏移”。训练时策略学到的行为，是基于仿真里那一套摩擦系数、质量分布、执行器延迟的。哪怕仿真建得再精细，和物理世界也不可能完全一致，这就会导致同一个策略，在仿真里走得稳稳当当，一放到真机上就开始劈叉、发抖、原地摔。所以部署本质上要解决两件事：一是把模型高效地跑在嵌入式平台上，二是把仿真和现实的差距尽量抹平。

1.3 部署链路的整体设计

在动手之前，先把我这边的部署链路梳理一遍，这样后面每一节你都能知道当前在整条流水线的哪个位置。整个流程分五步：

• GPU 仿真训练：在 NVIDIA GPU 上用 Isaac Gym 并行跑几千个环境，训练 PPO 策略。

• 模型导出：把训练好的 PyTorch 策略网络导出成 ONNX 格式，固定输入输出维度。

• 推理方案选型：评估 RK3566 上是走 CPU 的 ONNX Runtime，还是走 NPU 的 RKNN，或者直接手写。

• 实机系统集成：在 RK3566 上跑 Linux 控制程序，串口驱动舵机，IMU 读姿态，控制循环里调用推理。

• 参数整定与避坑：处理执行器延迟、传感器噪声、供电抖动、sim-to-real gap 等一系列问题。

这个链路看起来不复杂，但每一步都有很多细节。下面我按顺序把每一步的实际操作和踩坑记录都写出来。

2. 训练阶段：GPU 上的强化学习流水线

2.1 仿真环境怎么选：Isaac Gym 还是 MuJoCo

Microduck 这类足式机器人做强化学习，目前主流的选择是 NVIDIA Isaac Gym，也有用 MuJoCo 的。两个平台我都在自己的项目里试过。Isaac Gym 最大的优势是 GPU 并行，单张卡一次可以跑几千到上万个环境，训练吞吐量极高。MuJoCo 的物理精度和生态成熟度也很高，但 CPU 版本的并行效率不够，用 GPU 版本（MJX）又会引入新的 API 学习成本。

我最后选择了 Isaac Gym。原因是 Microduck 需要大量并行地进行足式运动策略搜索，PPO 这种 on-policy 算法对采样效率要求很高。如果用 CPU 物理引擎，一个上千步 episode 的策略动辄需要几分钟才能收集一轮数据，而在 Isaac Gym 里几千个环境并行，一轮采样几秒钟就完成了，训练一个能走的策略可能只需要几十分钟到几个小时，这个差距对迭代速度是决定性的。

硬件上我用了一张 NVIDIA RTX 4090。4090 的 24GB 显存跑 Microduck 这种 12 自由度的四足机器人，开 4096 个并行环境毫无压力，计算资源还有富余。如果你手上的是 3080 或者 A5000 这种级别的卡，减到 2048 个环境也一样能跑，无非是训练时间稍微长一点。

2.2 状态空间、动作空间与奖励函数设计

训练机器人运动，第一步是定义清楚 MDP（马尔可夫决策过程），也就是强化学习中智能体感知什么、能做什么、目标是什么。Microduck 的策略网络输入是一堆传感器数据的拼接，输出是 12 个关节的目标位置。我这里给出一个典型的配置供参考。

状态空间（观察），维度大概是 42 维，包括：

• 12 个关节当前角度
• 12 个关节当前角速度（可以从编码器差分得到）
• 3 维机身角速度（IMU 陀螺仪）
• 3 维机身倾角（IMU 加速度计解算或姿态融合）
• 12 个上一时刻的动作值（历史动作，增加马尔可夫性）

动作空间就是 12 维，直接输出每条腿 3 个关节的目标角度。脚部不直接输出力或力矩，而是让底层 PD 控制器去跟踪目标角度。为什么要这样做？因为真实舵机内部是位置闭环的，你直接给角度指令最合理。仿真里如果动作定义为关节力矩，虽然控制粒度更细，但到了真机上舵机根本不接受力矩指令，sim-to-real 的鸿沟会大得多。

奖励函数我拆成三块的加权和。第一块是任务奖励，前进速度跟踪，让机器人朝着目标方向移动；第二块是生存奖励，只要不摔倒就持续给一个小的正向奖励，目的是让策略学会保持稳定；第三块是惩罚项，包括关节加速度过大、机身姿态倾斜过大、动作变化过快等。整体权重分配用脚本网格搜索了一轮，最后确定的组合大致是：速度奖励权重 1.0，姿态稳定权重 0.5，能量惩罚权重 0.05。惩罚项的作用不是让机器人不动，而是让它用更平滑、更自然的方式运动，毕竟奖励稀疏的话策略很容易学出那种抽搐式的死走。

2.3 PPO 训练参数与收敛经验

算法层面用的是 PPO，这是机器人强化学习运动控制事实上的标准选择。PPO 的优点是训练稳定、超参不那么敏感，而且对 on-policy 采样效率的利用比较好。核心超参数如下：

我在训练过程中有个习惯，每个固定的步数保存一个 checkpoint，然后立刻在仿真里做一次快速评估，统计步态、速度、稳定性。不要只盯 reward 曲线，reward 高不代表走路姿势好看，有些策略 reward 很高但走起来姿态扭曲、关节极限频繁触发，这种 checkpoint 拿到实机上基本是废的。

实际训练中，Microduck 的策略网络是很小的一个 MLP，两层隐藏层，每层 256 个神经元，激活函数是 ELU，参数量大概十几万。这个体量的网络在仿真里训练非常快，单个 PPO 迭代用不了几秒钟，通常几百个迭代之后就能看到机器人学会基本的对角小跑步态。

2.4 域随机化：从仿真到实机的关键一步

如果你直接拿训练好的策略上真机，大概率会得到一个当场摔跤的机器人。核心原因是仿真的物理参数和真实世界总有偏差。域随机化就是解决这个问题的常用方法，在训练时每重置一次环境，就随机扰动一批物理参数，让策略在“各种可能的世界”里都学得会走路，这样到了真实世界，策略就有足够的鲁棒性。

我这边对 Microduck 做了这些随机化：

• 地面摩擦系数：在 0.3 到 1.5 之间随机
• 机器人本体质量：在 80% 到 120% 之间随机
• 关节执行器响应延迟：在 0 到 40ms 之间随机
• PD 增益：在 90% 到 110% 之间随机
• 重力向量：小幅扰动，模拟安装误差

尤其要注意执行器延迟随机化。真实舵机的内部闭环加上串口通信，延迟一般在 20ms 到 50ms 之间，如果仿真里不把这个延迟建进去，策略会倾向于用高频的小动作去控制关节，这在仿真里没问题，但在真机上因为延迟可能直接发散。我甚至见过一个策略在仿真里动作频率极高、姿态稳定，一到实机就浑身发抖，抖到站不住，最后查出来就是执行器延迟没有建模。

另一个细节：仿真里的 PD 控制器频率远高于真实舵机的内部控制频率，所以真实舵机位置跟踪的滞后比仿真大得多。这个在训练时也要考虑进去，做法是给动作输出加一阶低通滤波来模拟执行器的带宽限制，实测对 sim-to-real 提升非常明显。

3. 模型交接：从 PyTorch 到 RK3566 的导出与推理

3.1 模型导出 ONNX 的细节

训练完的 PyTorch 模型要部署到 RK3566，第一个步骤是导出成 ONNX 格式。这一步看起来简单，但也有几个容易踩的地方。首先，导出的模型必须固定输入输出维度，不能用动态维度，否则后面转换的时候一堆兼容性问题。其次，如果有 batch 维，建议导出成 batch=1 的版本，因为推理的时候每次只需要一张观测，处理单个样本，不必要的 batch 维度反而会影响性能。

导出代码大致是这样：

import torch model = torch.load("policy.pt") model.eval() dummy_input = torch.randn(1, obs_dim) torch.onnx.export( model, dummy_input, "microduck_policy.onnx", input_names=["obs"], output_names=["action"], dynamic_axes=None, opset_version=11 )

导出之后，先用 onnxruntime 在 PC 上做一次推理，对比 PyTorch 的输出，确认数值一致。我这里实测过两种框架在 FP32 下的输出差异，浮点误差在 1e-6 级别，完全不影响控制，但你要是做了量化，就得特别小心精度变化。

另外，别忘记把仿真里用的 obs 归一化参数一起存下来。训练时通常会把状态标准化到零均值单位方差，部署时也要用完全一样的均值和方差去归一化真实观测。这个参数忘了带的话，实机上的输入分布直接偏移，策略表现会一塌糊涂。我专门写了一个 JSON 文件保存 obs_mean、obs_std、action_mean、action_std 这些参数，和模型文件放一起，部署程序启动时加载。

3.2 RK3566 推理方案选型：ONNX Runtime 还是 RKNN

RK3566 上的模型推理有几种方案，我实际对比过三种：ONNX Runtime 的 CPU EP、RKNN-Toolkit 转 NPU 模型、以及手写前向计算。三种方案各有取舍。

我们的控制频率是 50Hz，也就是每周期 20ms，CPU 推理 2ms 完全在预算之内。所以最后我选择了最简单的 ONNX Runtime CPU 方案，没有用 NPU。这里我想多说一句：很多新手一看到板子有 NPU 就觉得必须用，但实际上 NPU 的收益在算力紧张时才明显，而代价是量化、算子兼容、内存拷贝这一系列复杂度。Microduck 这种小网络，CPU 的 2ms 已经非常充裕，多出来的时间留给通信和滤波更有价值。

如果你真的想用 RKNN，流程大致是：在 PC 上安装 rknn-toolkit2，把 ONNX 转成 RKNN 格式，然后拷贝到板子上用 librknnrt 的 C API 或 Python API 推理。这个流程我自己跑通过，但算子支持是个大坑，MLP 里的 LayerNorm、GELU 这类常见算子经常要改模型结构或者手动替换，很折腾。对于强化学习策略这种推理速度本来就足够的负载，我诚心建议先用 CPU 跑起来，后面需要再优化。

3.3 量化与精度损失带来的问题

如果你还是想要 NPU 的极致延迟，量化是绕不开的步骤。RKNN 默认支持 INT8 量化，但强化学习策略的量化比图像分类要敏感得多。原因是策略输出的微小变化会被底层控制放大，比如目标角度偏差 0.01 弧度，在关节上可能就是明显的抖动。我用 RKNN 工具量化过一版微策略，精度损失导致实机上机器人走路时带着高频抖动，虽然不至于摔，但姿态明显不如 FP32 版本干净。

如果要量化，有几个建议。第一，量化校准数据集不能随便选几十张图那套做法，要强化学习里收集一批全覆盖的 (obs, action) 数据，覆盖各个运动相位。第二，优先保留第一层和最后一层为 FP16 或 FP32，只量化中间层。第三，量化和不量化各出一版，实机对比测试后再定，别在量化上一条路走到黑。

3.4 把策略封装成低延迟推理模块

选定了 ONNX Runtime，下面要解决的是如何在 RK3566 上高效跑起来。我是在 C++ 程序里用 onnxruntime 的 C API 做的，注意不要每次推理都重新加载模型或者重新创建 session，这个开销非常大。正确做法是程序启动时创建一次 session，然后进入控制循环反复调用。加载模型时有一步“预热”，用全零输入先跑几遍推理，让内存池和线程池热起来，避免第一次推理延迟特别高。

Ort::Session session(env, model_path.c_str(), session_options); std::vector<float> input(obs_dim, 0.0f); // 预热 10 次 for (int i = 0; i < 10; i++) { inference(session, input.data()); }

在控制循环里，每次拿到传感器观测后，先做归一化，再拼接成状态向量，调用一次推理，得到 12 个关节目标角度。整个流程在 RK3566 上实测下来，CPU 推理稳定在 1.5-2ms，占控制周期 20ms 的不到 10%，余量很充足。

4. RK3566 实机部署：硬件、线程与执行器控制

4.1 实机供电与接线问题

在讲代码之前，必须先讲供电，因为这是 Microduck 这类小型机器人最容易翻车的地方。12 个舵机同时高频运动时，瞬时电流可以到好几安培，如果电源跟不上，电压跌落会导致主控复位，表现就是跑着跑着突然“当机”然后重启，所有的运动学状态一下子清零。

我的供电方案是：2S 锂电池（7.4V 标称）直接给舵机供电，另外用一个 DC-DC 降压模块降到 5V 给 RK3566 开发板供电。这里有几个关键点：第一，舵机电源和主控电源要共地，否则串口通信会出现乱码、丢包；第二，在舵机电源输入端并联一个大容量电解电容（我用了 470uF 左右的），吸收瞬间电流波动；第三，信号线尽量远离舵机电源线，避免 PWM 或串口信号被电机干扰。我第一版布局就是把串口线和电源线走得太近，结果舵机一动作串口就丢包，排查了很久才发现是干扰问题。

还有一点是关于舵机供电电压的。串行总线舵机有的支持宽电压，有的必须在标称电压附近，比如标称 6V 的舵机，你给到 7.4V，轻则发热，重则直接烧毁。Microduck 这类小型机器人如果用的舵机标称 6V，建议加一个 6V 稳压模块专门给舵机供电，不要直接把电池电压怼上去。

4.2 控制循环与实时性设计

嵌入式控制程序和仿真里最大的区别就是实时性。仿真里的控制循环是理想化的“每一步立刻算完”，而 RK3566 上跑的是 Linux，系统调度、后台进程、CPU 频率动态调整都会带来不确定的抖动。为了保证控制稳定，我把控制循环做成了独立的高优先级实时线程，线程里用 monotonic clock 做时间基准，按 50Hz（20ms 周期）循环执行。

线程绑定的做法是这样的：先用 CPU affinity 把控制线程绑到一个固定的 CPU 核上，比如 CPU3，然后用sched_setscheduler设置成 SCHED_FIFO 实时优先级。这样这个核基本不会被普通进程抢占，控制循环的抖动能从十几毫秒降低到几毫秒以内。同时，把串口通信、IMU 读取、推理这几个耗时操作都放在这个实时线程里，按顺序执行，不搞多线程拼凑。

延迟预算我大概是这样分配的：串口读取并解析舵机状态 5ms，IMU 读取 1ms，归一化加推理 2ms，动作平滑加串口发送 3ms，剩余 9ms 做余量。一开始我的控制循环是“读到啥算啥”，没有固定节奏，结果舵机指令到达时间忽早忽晚，机器人跑起来明显不稳定，后来改成固定 20ms 周期并且用 busy-wait 来对齐时序才稳定下来。

这里特别提醒一点：不要用sleep(20)这种墙钟睡眠来控制循环节奏，它受系统定时器精度影响很大。要用clock_nanosleep或者忙等待加clock_gettime（MONOTONIC）的组合。

4.3 执行器控制与动作平滑

RL 策略输出的 12 维目标角度不能直接发给舵机，中间必须经过一层平滑处理。原因有二：一是策略在仿真里学出来的动作本来就带有一定的高频成分，直接执行会加剧舵机磨损；二是真实舵机内部闭环有延迟，突然跳变的目标角度会引起超调，表现为机器人步伐生硬、抖动。

我用的平滑方案是低通滤波加速率限制。对每个关节的输出做如下处理：

filtered = prev_filtered + alpha * (target - prev_filtered) alpha = 0.3 左右

alpha 的选择要权衡：太大容易抖动，太小会让动作显得迟钝。我用 0.3 作为起始值，然后根据实机效果调。同时，限制每个控制周期内关节角度的最大变化量，例如每个周期不超过 0.05 弧度，避免舵机收到跳变指令。

舵机控制协议上，Microduck 用的是串行总线舵机，我这边波特率设的 115200，指令帧包含舵机 ID、目标角度、执行时间，舵机收到后会闭环跟踪。实测下来，115200 波特率在一个周期内更新 12 路舵机完全没问题。要注意的是，不同舵机协议差异很大，有的需要在发送前计算 CRC，有的不需要，翻手册的时候多看几遍。

还有一个非常容易被忽略的点：舵机一旦启动，会持续按当前位置和目标位置做闭环，如果你程序崩溃了，它不会自动停下来，机器人会僵在原地或者继续走，很危险。所以我在程序启动和异常退出时都会发送“失能”指令，让所有舵机立刻释放力矩，让机器人趴下。

4.4 状态反馈与传感器滤波

策略推理需要关节角度、角速度和 IMU 数据。关节角度可以从舵机读取，但有两个问题需要处理。第一，舵机位置反馈的精度和更新率都有限，直接差分出来的角速度噪声很大。第二，串口通信本身有延迟，读回来的位置是几十毫秒前的，如果直接用这个值去和 IMU 数据拼接观测，会导致策略输入的各个维度时间戳不一致。

角速度我用了低通滤波加中心差分组合，公式是：

angular_velocity = (position[t] - position[t-1]) / dt filtered_velocity = 0.7 * filtered_velocity + 0.3 * angular_velocity

IMU 数据我用的是 MPU6050 这类六轴传感器，读取频率 100Hz 或 200Hz。重要的是做姿态融合，从加速度计和陀螺仪解算出机身的 roll、pitch、yaw。这里我用了一个轻量的互补滤波，没有上卡尔曼，因为控制频率不高，互补滤波的计算开销小、响应足够。互补滤波的关键是融合系数，我调到 0.96（陀螺仪权重）和 0.04（加速度计权重）左右，过滤掉了加速度计的高频噪声，同时保住了陀螺仪的方向稳定性。

另外，策略观测里的 12 个上一时刻动作值，理论上应该用“上一次实际执行到舵机上的动作”，而不是“上一次策略网络输出后还没有经过平滑的目标”。这个小细节如果不注意，实机效果和仿真差距会很大。我是把平滑滤波器输出的最终值当作“已执行动作”反馈到下一帧的观测里，这样闭环更干净。

5. 常见问题与排查技巧实录

5.1 sim-to-real gap：策略在实机上完全乱套

这是每个做机器人强化学习的人都会遇到的头号难题。表现分两种：一种是策略一上真机就原地打转、劈叉、站不起来；另一种是能站住，但动作非常僵硬，小碎步挪动，完全没有仿真里的灵活步态。

如果是第一种，优先排查训练时的域随机化是不是不够。摩擦系数范围收窄一点、执行器延迟没有建模、PD 增益和真机偏差太大，这些都是常见原因。我这边第一版训练完全没做执行器延迟建模，上真机后机器人站住都难，后来把延迟随机化加上，明显好很多。

如果是第二种，多半是执行器带宽不够。仿真里的 PD 控制器可以做到毫秒级响应，但真实舵机内部是一个带宽很低的闭环系统，目标角度变化太快它根本追不上，实际关节轨迹就被钝化了。对策是训练时给动作输出加低通滤波或者约束的随机化，让策略学会在“慢执行器”下也能运动。

还有一种隐蔽的原因是观测噪声。仿真里的观测是完美数据，但真机上 IMU 有随机游走，关节角速度差分噪声很大。建议训练时在观测里加高斯噪声，噪声幅度稍微大一点，让策略学会对噪声鲁棒。

5.2 RK3566 推理延迟抖动

CPU 推理本身只要 2ms 左右，但如果你发现控制循环偶发出现巨大的时间毛刺，比如某一次循环跑了 30ms，那一定是系统层面的问题。排查步骤我建议按下面走：

• 检查是否绑核：控制线程有没有固定到独立 CPU 核上，没有的话先绑核。
• 检查系统负载：后台有没有跑别的服务，比如 ssh、日志、wpa_supplicant，尽量关掉。
• 检查 CPU 频率策略：RK3566 的 CPU 默认可能有节能模式，动态调频会让推理时间不稳定，建议把 cpufreq governor 设成 performance，强制最高频率。
• 检查内存和 swap：如果系统 swap 开了且内存不够，推理时可能发生内存换页，导致延迟巨大。关掉 swap，尽量让程序常驻内存。

实测下来，绑定核加 performance 模式之后，推理延迟抖动从 ±8ms 降到了 ±1ms 以内，控制循环的稳定性提升非常明显。

5.3 舵机响应慢、发热和丢包

舵机响应慢分硬件和软件两种原因。软件上的坑最常见的是波特率太低或者指令周期太长。如果你用的是 9600 波特率，12 个舵机一轮指令就要传很久，控制频率根本提不上去。我现在用的 115200，一轮指令不到 5ms，基本不影响 50Hz 的控制。硬件上，舵机扭矩不够也会导致响应变慢，表现为小角度指令能跟踪，大角度摆动就滞后，换更高扭矩的舵机或者降低单步动作幅度可以缓解。

舵机发热也要关注。RL 策略跑出来的动作频率通常比手工调的姿态控制器高，舵机持续高频运动，发热很快。我一开始跑策略时舵机温度直线上升，后来加了一层动作平滑把高频分量滤掉，温度立竿见影地降下来了。如果你的舵机没有温度保护，建议在程序里加一个运行时长限制或者温度读数检查，防止烧毁。

串口丢包的排查比较磨人。我这里遇到过三种情况：电源共地问题、信号干扰、以及串口缓冲区溢出。其中缓冲区溢出最常见，当控制循环偶尔卡顿，串口接收缓冲区里的数据没有被及时读取，后续的帧就会被覆盖。我的解决方法是提高读取频率，在控制循环之外用独立线程持续读串口并放入环形缓冲区，控制循环从环形缓冲区里取最新的一帧状态，这样即使某一帧处理慢了，也不会积累脏数据。

5.4 常见问题速查表

我把这个表贴在项目文档开头，每次调试之前先过一遍，能省下很多重复排查的时间。

5.5 部署前最好先想清楚的几个问题

踩过这一轮坑之后，我最大的感受是：部署不是训练的“最后一公里”，而是从训练一开始就要考虑的问题。有几个问题建议在你开始写训练代码之前就想清楚：

第一，你的执行器到底是什么控制接口？是位置指令还是力矩指令？这直接决定了动作空间的定义方式，我见过不少人仿真里用力矩控制训练了几个月，最后发现手上的舵机只有位置模式，整个项目推倒重来。

第二，你的控制频率是多少？仿真里的控制频率可以随便设，但真机上的控制在很大程度上被传感器更新率、串口通信速率和舵机内部闭环带宽限制住了，训练前先定好一个合理的控制频率，仿真和部署保持一致。

第三，你的推理平台能承受多大的模型？Microduck 这种小网络很简单，但如果你后面想加视觉输入、加更大的历史状态序列，RK3566 的 CPU 就不一定够用了，这时候是换平台、用 NPU 还是精简模型，需要提前想清楚方案。

项目跑通之后，我又花了不少时间做策略的鲁棒性测试，比如在不同地面材质上走、从不同姿势初始化、人为推搡看响应。这些测试暴露出来的问题，往往比仿真评估更能说明策略的真实水平。如果你也想复现 Microduck 这套流程，我建议参考版本库里的默认配置先完整跑通，再逐步改奖励函数和域随机化参数，你会发现这套工作流带来的迭代速度，是传统手写步态控制器完全比不上的。真正花时间的从来不是那张 GPU 上的训练，而是把走线理清、把电源做好、把延迟压下去这些在别人看来“不高级”的活，但这些才是机器人强化学习落地最扎实的地基。