从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 还是 MuJoCoMicroduck 这类足式机器人做强化学习目前主流的选择是 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 采样效率的利用比较好。核心超参数如下参数数值说明学习率1e-4用 Adam 优化器初期可调到 3e-4后段调低batch size8192每次更新用的样本量随环境数上调minibatch size2048每个 minibatch 的样本量影响更新频率clip range0.2PPO clip 的ε大了容易更新过度小了收敛慢entropy coefficient0.005鼓励探索的系数太大策略会乱逛GAE lambda0.95优势估计的衰减系数训练步数8000-20000视 reward 收敛情况而定我在训练过程中有个习惯每个固定的步数保存一个 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 维建议导出成 batch1 的版本因为推理的时候每次只需要一张观测处理单个样本不必要的 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_axesNone, opset_version11 )导出之后先用 onnxruntime 在 PC 上做一次推理对比 PyTorch 的输出确认数值一致。我这里实测过两种框架在 FP32 下的输出差异浮点误差在 1e-6 级别完全不影响控制但你要是做了量化就得特别小心精度变化。另外别忘记把仿真里用的 obs 归一化参数一起存下来。训练时通常会把状态标准化到零均值单位方差部署时也要用完全一样的均值和方差去归一化真实观测。这个参数忘了带的话实机上的输入分布直接偏移策略表现会一塌糊涂。我专门写了一个 JSON 文件保存 obs_mean、obs_std、action_mean、action_std 这些参数和模型文件放一起部署程序启动时加载。3.2 RK3566 推理方案选型ONNX Runtime 还是 RKNNRK3566 上的模型推理有几种方案我实际对比过三种ONNX Runtime 的 CPU EP、RKNN-Toolkit 转 NPU 模型、以及手写前向计算。三种方案各有取舍。方案帧率实测精度开发成本稳定性ONNX Runtime CPU约 2ms/次FP32无损失低pip 装一下就行高RKNN NPUINT8约 1ms/次有量化损失高需要转换和调优中手写 MLP 前向约 0.3ms/次FP32无损失中代码简单但需自己部署高我们的控制频率是 50Hz也就是每周期 20msCPU 推理 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::vectorfloat 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 做时间基准按 50Hz20ms 周期循环执行。线程绑定的做法是这样的先用 CPU affinity 把控制线程绑到一个固定的 CPU 核上比如 CPU3然后用sched_setscheduler设置成 SCHED_FIFO 实时优先级。这样这个核基本不会被普通进程抢占控制循环的抖动能从十几毫秒降低到几毫秒以内。同时把串口通信、IMU 读取、推理这几个耗时操作都放在这个实时线程里按顺序执行不搞多线程拼凑。延迟预算我大概是这样分配的串口读取并解析舵机状态 5msIMU 读取 1ms归一化加推理 2ms动作平滑加串口发送 3ms剩余 9ms 做余量。一开始我的控制循环是“读到啥算啥”没有固定节奏结果舵机指令到达时间忽早忽晚机器人跑起来明显不稳定后来改成固定 20ms 周期并且用 busy-wait 来对齐时序才稳定下来。这里特别提醒一点不要用sleep(20)这种墙钟睡眠来控制循环节奏它受系统定时器精度影响很大。要用clock_nanosleep或者忙等待加clock_gettimeMONOTONIC的组合。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_velocityIMU 数据我用的是 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 常见问题速查表现象可能原因排查与处理机器人上电后站不住劈叉策略 sim-to-real gap加大域随机化检查执行器延迟建模能站立但高频抖动推理延迟过大或动作未平滑检查绑核、cpufreq、动作低通跑几步突然重启供电电压跌落加电容、检查电池电压、分开供电串口乱码、丢包电源不共地或信号干扰共地、信号线远离电源线舵机异常发热动作频率过高动作平滑、降低控制频率策略输出看似正常但走路方向偏IMU 姿态估计不准或安装偏差标定 IMU 安装偏移、检查机体坐标系对齐上电后舵机不动串口未失能或协议错误检查 CRC、波特率、舵机 ID我把这个表贴在项目文档开头每次调试之前先过一遍能省下很多重复排查的时间。5.5 部署前最好先想清楚的几个问题踩过这一轮坑之后我最大的感受是部署不是训练的“最后一公里”而是从训练一开始就要考虑的问题。有几个问题建议在你开始写训练代码之前就想清楚第一你的执行器到底是什么控制接口是位置指令还是力矩指令这直接决定了动作空间的定义方式我见过不少人仿真里用力矩控制训练了几个月最后发现手上的舵机只有位置模式整个项目推倒重来。第二你的控制频率是多少仿真里的控制频率可以随便设但真机上的控制在很大程度上被传感器更新率、串口通信速率和舵机内部闭环带宽限制住了训练前先定好一个合理的控制频率仿真和部署保持一致。第三你的推理平台能承受多大的模型Microduck 这种小网络很简单但如果你后面想加视觉输入、加更大的历史状态序列RK3566 的 CPU 就不一定够用了这时候是换平台、用 NPU 还是精简模型需要提前想清楚方案。项目跑通之后我又花了不少时间做策略的鲁棒性测试比如在不同地面材质上走、从不同姿势初始化、人为推搡看响应。这些测试暴露出来的问题往往比仿真评估更能说明策略的真实水平。如果你也想复现 Microduck 这套流程我建议参考版本库里的默认配置先完整跑通再逐步改奖励函数和域随机化参数你会发现这套工作流带来的迭代速度是传统手写步态控制器完全比不上的。真正花时间的从来不是那张 GPU 上的训练而是把走线理清、把电源做好、把延迟压下去这些在别人看来“不高级”的活但这些才是机器人强化学习落地最扎实的地基。