从Isaac Gym到RK3566：双足机器人强化学习策略的完整部署实践

先交代一下背景：Microduck是一台25厘米左右的小型双足机器人，最初是在英伟达GPU上用强化学习在仿真里练出来的，整套训练流程跑在Isaac Gym这类环境里。这篇文章记录的是我把它从“GPU上的数字模型”搬上RK3566实机（泰山派）的完整过程，包括训练侧的东西、导出侧要注意的算子、实机上电后的调试，以及我在这个过程中踩过的坑。 如果你手里也有一台类似的小型双足/四足机器人，训练环境用的是NVIDIA GPU，部署目标却是一块几瓦功耗的ARM板卡，那这篇文章应该能帮你少走不少弯路。尤其是从“仿真能走”到“实物能站稳”中间的那段空白，我会尽量把每个关键步骤都讲透。

1. 项目全貌与部署路线设计

1.1 Microduck是什么，我为什么要做这块板子

Microduck是那种看着小巧、实际牵涉面却很广的项目。整体身高25厘米级别，双足构型，每条腿通常有3个自由度，全身加起来6个左右的关节电机。这类小机器人和工业机械臂有个明显区别：它本身是不稳定系统，站直了就得实时控制，重心稍微偏一点就会倒。传统的做法是写PID/PD控制器，把姿态稳住；但Microduck这类项目从一开始就选择了强化学习路线，让策略网络自己学习“怎么站、怎么走、怎么在被推一下之后恢复平衡”。

我最初拿到这块板子时，以为工作重点会是强化学习算法本身。做了几天才发现，真正磨人的不是PPO算法的收敛问题，而是整个部署链路没有任何一环是省心的。训练时我在英伟达GPU上用PyTorch训练，功耗随便三四百瓦；部署目标却是RK3566，典型功耗5瓦以内，CPU主频不高，片上带NPU但跑双足控制这类策略网络根本用不上——因为RL策略推理本身是个很小的MLP，NPU在这种场景反而没什么优势。

这套“大算力训练、小算力部署”的路子，几乎是所有具身智能项目都会遇到的共同命题。你把机器人做大了，可以用工控机甚至机架式服务器当“大脑”；但Microduck这个尺寸注定是边缘部署，必须在板端解决。25厘米高的机器人，注定不可能背一台GPU服务器到处跑，所以RK3566这种板子就是一个很合适的选择。它的算力不算强，但足够跑一个小的MLP控制策略，同时还能跑Linux系统、接摄像头、走通信，刚好卡在“啥都能干但啥都要抠一抠”的定位上。

1.2 从英伟达GPU到RK3566：一条完整的部署链路

如果只把问题理解为“把模型从GPU拷到ARM板卡上跑”，那实现起来其实很快——因为强化学习部署到实机时，用的往往不是原版PyTorch模型，而是转换后的ONNX或者RKNN格式。但这件事真正的链路拆开看，大概有六段：

1. GPU端做仿真训练，输出的是PyTorch权重文件；
2. 从训练工程里抽出actor策略网络，丢掉critic、丢掉训练用的均值方差，只留纯推理图；
3. 把PyTorch模型转成ONNX格式，再根据RK3566的NPU情况决定是否转RKNN；
4. 在RK3566上准备运行时环境，包括系统镜像、Python/C++推理库、传感器驱动、通信接口；
5. 把控制策略和IMU/关节编码器数据打通，让策略网络在板端实时跑起来；
6. 实机联调，调频率、调相位、调奖励函数与真实世界不一致带来的差异。

这几段每一段都有独立的坑。比如PyTorch里很常见的Flatten、transpose算子，在导出ONNX时可能正常，但走到RKNN工具链时就会提示算子不支持；又比如训练时IMU数据是理想仿真的，但实机上IMU零漂、振动噪声、延迟都会让策略表现断崖式下降。所以在训练侧就要加入噪声、延迟、力扰动这些domain randomization，否则模型还没上实机就已经“死”在仿真里了。

1.3 为什么选RK3566而不是再租一台GPU服务器

有人问我，Microduck这种25厘米的机器人，为什么不用树莓派，也不用Jetson Orin Nano，偏偏选了RK3566。这里面有成本、功耗和扩展性的多重考虑。RK3566板卡（比如泰山派）核心板加底板可能就一两百元，功耗比Jetson低一个量级，接口方面有PCIe、USB3.0、千兆网、MIPI-CSI，GPIO/I2C/SPI/UART也齐全，作为机器人的“小脑”完全够用。虽然它的CPU是四核Cortex-A55，频率也就1.8GHz左右，但在做纯CPU推理时跑一个十几层的小MLP，单次推理实测在几十微秒到一百多微秒之间，这个量级对控制频率来说是绰绰有余的。

反过来，如果你用Jetson Orin Nano或者更贵的板子，算力确实更强，但同样的机器人整机功耗、体积、成本都会往上走。用RK3566是非常典型的“低成本实现闭环”思路。它不是不能跑视觉大模型，而是你不需要用牛刀杀鸡。Microduck的控制策略网络参数量通常不到几十万，整个actor的FLOPs可能只是ResNet的一个零头，把它硬塞到几百TOPS的算力平台上没有意义。

我实际把整套策略部署上之后测过：RK3566上纯C++实现策略网络推理，不做NPU加速，一帧耗时大约40到80微秒；哪怕是Python推理加numpy手写前向，也就1毫秒上下。而双足机器人的控制频率一般在200到1000Hz，也就是每帧周期1到5毫秒，所以算力瓶颈根本没有，真正的瓶颈在传感器读取、串口通信和控制线程的实时性上。

2. GPU端训练环境与策略细节

2.1 仿真环境与强化学习框架选型

训练环境这块，我看了当前机器人强化学习圈子的主流方案后选了Isaac Gym。这类环境的好处是能直接在GPU上做几千上万个并行环境的仿真，批量采样速度非常快，PPO这种on-policy算法最依赖的就是采样吞吐量，没有GPU并行仿真，训练一个双足行走策略可能要几天，而用Isaac Gym之后基本几个小时能见到初步效果。

具体硬件上，我用的是一块NVIDIA RTX显卡，显存至少12GB。如果你想训Microduck这种小型机器人，显存要求不会特别夸张，但并行环境数量如果上到4096甚至8192，显存占用还是会涨得比较快。我在实际训练时把并行环境数设在2048到4096之间，单卡显存占用大约6到10GB，如果显存不够就降到1024个环境，等待时间会明显变长。

训练框架我建议直接用Legged Gym或者RLGym这类开源项目魔改。它们的核心逻辑都差不多：定义机器人的URDF/MJCF模型，在仿真环境里创建地形、设置初始姿态、定义奖励函数和终止条件，然后并行采样，交给PPO更新。网络上Microduck相关仓库也有现成训练代码，你可以下载后把机器人的URDF和关节配置替换成自己的，再根据实际硬件调一下关节阻尼、摩擦力、电机时间常数这些参数。

2.2 训练参数、观测空间与奖励设计

我第一次跑Microduck仿真时，发现“站不稳”其实不是策略问题，而是观测空间和奖励函数设计不合理。这个小双足机器人能观测的数据包括：机身IMU的角速度、姿态（用四元数或欧拉角），关节角度、关节角速度，再加上前一时刻的动作。把这些拼起来，观测维度通常在30到50之间。动作空间就是6个关节的目标位置或目标速度增量，维度很小。

奖励函数这块，踩过不少坑。初期阶段我模仿其他项目写“站立越高越好、机身姿态越水平越好、动作变化越小越好”，结果策略学出了一个很猥琐的动作：让机器人原地蹲下去，因为蹲下时重心低、姿态误差也小，奖励反而高。后来加了一条“目标高度惩罚”，规定机身高度低于某个阈值时额外给大惩罚，策略才老老实实学站立。另一个常见情况是“走起来很别扭”，因为动作平滑惩罚的系数设置太大，导致策略不敢动，输出全是零；调小之后又容易震荡，所以这个系数需要反复试。

实用经验是：奖励不要急着叠加太多项，先让机器人学会站，再加行走目标，最后加抗扰动。训练时要盯两个核心指标——平均奖励曲线是否还在上升、以及仿真里机器人能不能扛过整个episode时长。此外特别建议加入域随机化：把摩擦力、电机强度、IMU噪声、控制延迟都加一点随机扰动。没有域随机化的策略，上实机大概率会像喝醉了一样，因为真实世界和仿真理想环境差距太大。

2.3 一次完整训练的实验记录与导出前检查

我跑的比较完整的一次训练记录大致是这样：并行环境4096个，PPO的clip范围0.2，actor和critic都是三层MLP，隐藏层256，学习率1e-3，训练步数2000万左右。刚开始几百步时，机器人基本秒倒，平均episode长度不到0.5秒；随着训练推进，大概到了200万步时，机器人能站住一小会儿；600万步之后开始能迈步；800万到1500万步之间行走能力明显提升。最终策略在仿真里的成绩是：平地直走基本不倒，能从侧面承受一定大小的推力扰动。

这个结果看着还算不错，但每次训练结束我都会做一件很多人忽略的事：用训练好的权重去跑若干次确定性推理，同时把每一帧的观测均值、方差、奖励分量记录下来。为什么？因为部署到实机时，如果机器人走着走着突然朝一个方向猛冲或者疯狂抖动，往往不是因为策略本身学得不好，而是你得确认导出的模型和训练时用的模型在数学上完全一致，且没有丢掉归一化层。

强化学习策略网络在训练时一般会做observation normalization，也就是把状态输入减去均值再除以标准差。均值方差是在训练过程中在线统计的，部署时这些统计量必须原封不动地带过去。如果只在PyTorch里跑没问题，导出成ONNX时却忘了把归一化层也固化进去，实机上就会看到奖励函数明明是正常的，但机器人的表现完全对不上——这就是所谓“遇到错误奖励但排查不到奖励问题”的一个常见来源。

2.4 关于IQL离线强化学习的延展

最近圈子很多人讨论IQL（Implicit Q-Learning）这类离线强化学习算法，我其实也在关注。在线PPO训练虽然效果好，但要求你有一块不错的NVIDIA GPU一直跑仿真；而IQL这类离线算法的思路是：不需要在线仿真，直接用一批已经收集好的经验数据集训练策略。这样训练功耗低、训练时间也更快，对没有多卡GPU的个人开发者来说是个友好方向。

IQL的核心思想是不对超出数据集分布的动作做过高估计，通过隐式Q函数让策略学习“只做数据里出现过的靠谱动作”。放在Microduck这种小机器人上，一种很自然的应用方式是：先用在线PPO或者人工遥控采集一批数据，再用IQL做后训练或策略精修。部署导出流程其实和在线训练基本一样——保存的仍然是actor网络，导出后照样走ONNX/RKNN路线。要注意的是，IQL对数据集质量很敏感，如果你采集的数据里大部分都是“机器人摔倒”“机器人站在原地不动”，那学出来的策略也不会好用。

本小节的建议是：如果你预算不足、没有可长期占用的GPU，研究一下离线强化学习是值得的；但如果你只是想把Microduck快速跑起来，老老实实在线PPO仍然是当前性价比最高的路径。

3. 模型导出与边缘端适配

3.1 部署时只需要的是策略网络，不是整个训练模型

强化学习训练出来的模型里通常包含actor和critic两个部分。actor负责根据观测输出动作，critic负责评估状态价值，只在训练阶段用。但很多人在导出时会搞混，直接把整个checkpoint加载然后torch.onnx.export，结果导出的模型里带了critic分支，导致模型体积变大、算子变复杂，甚至有些critic里用到的算子RKNN工具链根本不愿意支持。

正确做法是先加载训练好的权重，然后只取出actor网络。在Microduck这种场景里，动作一般选确定性输出，即actor网络的mean，而不是再采样一个高斯分布。如果你训练时使用了log_std，部署时必须丢掉采样环节，否则实机上每次动作都会带随机噪声，机器人轻则抖动，重则直接摔倒。换句话说：实机部署的策略应当是一个确定性的从观测到动作的映射。

另外，critic网络的输入输出维度和actor不同，部署前建议把模型结构打印出来确认一下。我就是因为一开始没注意，导出的ONNX里混了一个值为0的输入节点，导致后面在板端推理时输入维度不匹配，排查了很久才发现导出逻辑写错了。

3.2 从PyTorch权重到RK3566能跑的格式

PyTorch权重不能直接在RK3566上跑，除非你在板卡上装PyTorch。理论上可以装，但对RK3566来说太浪费了：PyTorch的ARM版体积大、内存占用高，而且很多算子并没有针对ARM做专门优化。更合理的路线是：PyTorch -> ONNX -> RKNN。如果只跑CPU，ONNX Runtime也是不错的方案；如果你想把某些层放到NPU，则必须转成RKNN。

导出ONNX的代码看起来很简单：

import torch import torch.nn as nn def export_actor_to_onnx(actor, obs_dim=42, file="microduck_actor.onnx"): actor.eval() dummy_input = torch.randn(1, obs_dim) torch.onnx.export( actor, dummy_input, file, input_names=["obs"], output_names=["action"], dynamic_axes={"obs": {0: "batch"}, "action": {0: "batch"}}, opset_version=11, )

但中间有几个容易被忽略的点：第一，actor网络里如果用了BatchNorm，导出时会问你要不要将其固定下来，必须选择固定，也就是使用训练阶段累计的running_mean和running_var，否则没有训练时的数据分布，跑出来的结果就不对。第二，opset_version不要追求太高，RKNN工具链往往对新opset支持不够及时，我这边稳定使用的是opset 11或12。第三，导出之后一定要先用onnxruntime跑一遍和PyTorch相同的输入，对比输出差异，误差在1e-4级别才算正常。

之后再把ONNX转成RKNN。这个转换在PC端用瑞芯微提供的rknn-toolkit2就可以做，大概流程是：加载ONNX模型，配置量化方式，设置目标平台为rk3566，然后导出rknn文件。我个人在实际部署时并没有把所有层都塞进NPU，因为RL策略网络层数不多，CPU跑已经够快，反而省去了量化精度损失的烦恼。

3.3 量化和算子适配的取舍

RK3566的NPU推理通常需要INT8量化才能发挥最大性能，但这对RL策略来说可能是个陷阱。量化会带来精度损失，而控制策略对动作输出的精度其实比较敏感。一个简单实验就能说明问题：用原FP32 ONNX在实机上跑，机器人站得还行；用RKNN INT8量化后再跑，机器人开始高频抖动，或者动作幅度明显减弱。原因就是量化后的推理误差被机器人本体放大成了不稳定的反馈信号。

怎么取舍？我的建议是分场景看。如果策略模型比较大、对延迟要求很高，迫不得已走NPU，那要考虑量化校准数据集怎么选。校准数据应该尽量贴合真实部署时的观测分布，不能拿一堆随机噪声去校准，否则权重量化后的有效位数会浪费在无关分布上。如果模型很小、单次推理在CPU上只要几十微秒，我建议直接保留FP32或FP16，用CPU推理就好。Microduck的策略网络是典型的小模型，CPU推理完全没有性能压力，不必非走NPU不可。

最后一步，如果确实有某些层无法被RKNN工具链转换，常见处理方式是先用onnxsimplifier对ONNX图做简化，很多冗余算子（比如Identity、多余的Cast）可以在图优化阶段被消掉；对于实在不支持的算子，再考虑重写网络中用到的对应模块，比如把注意力或者自定义激活函数替换成标准算子。

3.4 状态归一化参数不能丢

前面提到过observation normalization，但这层太重要了，必须单独再拎出来说一遍。许多双足强化学习项目里，归一化的均值方差不是和actor网络一起保存的，而是放在单独的buffer里。在PyTorch里推理时，你通常是先对观测做归一化，再输入actor；但部署时如果只导出actor，就必须在外部把归一化层的参数固化下来，要么把它们作为actor的前置层一起导出，要么在板端代码里先做一次(x - mean) / std再喂给模型。

我建议直接把这个归一化操作写进actor的forward函数里再导出，或者在ONNX前面拼接一个“归一化子图”，这样到板端就少一个需要维护的步骤。我在实际部署时吃过这个亏：训练时奖励正常、仿真里走得好好的，导出后忘了带mean/std，实机上机器人反应迟钝，仿佛“梦游”。检查了很久才发现输入观测的尺度完全不对，有些特征的量级被放大了几十倍。

还有一个容易被忽视的点：IMU数据的坐标系和仿真中的定义是否一致。如果你在仿真里用的重力方向是z轴向下，但实机IMU装反了或者驱动输出的符号定义相反，那么即使归一化参数对，策略也会错乱。导出模型前一定要确认数据流每个环节的坐标系一致。

4. RK3566实机运行环境搭建与踩坑

4.1 系统镜像、root权限与开发板识别问题

RK3566的开发板很多，我这里用的是泰山派。买来第一件事是刷一个干净的系统镜像，通常是Ubuntu或者Debian的ARM版本。刷机本身并不复杂，但有一个很多新手都会卡住的问题：板子插上USB后，电脑提示识别到了rk3566设备，但它是作为“ADB设备”出现的，而不是烧录工具期望的“Rockusb设备”（Loader模式）。

出现这种状况，原因基本是设备没有进入烧录模式。正常流程是先按住板子上的maskrom按键或loader按键，再给板上电，让USB控制器进入下载模式。如果你只是直接用USB线连接，板子系统正常启动后，它自然会被识别成ADB设备——因为系统里的adbd服务起来了，这不能用来烧录。解决办法很简单：拔掉电源，按住loader/maskrom键不松手，插上USB线，等待几秒后再松开，这时候设备管理器里应该会刷新为Rockusb设备，烧录工具就能识别了。

root权限也是个绕不开的话题。RK3566默认镜像一般直接就是root用户或者可以方便地切换root。如果普通用户遇到权限问题，常见的做法是adb root或者直接使用root账号登录。这个没什么好避讳的，嵌入式Linux开发本来就需要拿到完整系统权限。拿到root之后，建议立刻做两件事：关掉不需要的开机自启服务，释放CPU占用；调高CPUfreq的governor为performance模式，避免频率波动影响控制节拍。

提示：凡是涉及系统镜像烧录的操作，请先确认你拿到的固件和板卡型号匹配，尤其是DDR型号和存储介质（EMMC还是SD卡）不能选错，否则有可能无法启动。

4.2 控制线程的实时性与单核绑定

RK3566虽然能跑Linux，但它的实时性默认并不理想。Linux内核本身是分时调度系统，控制线程可能被其它进程抢占，造成偶发延迟。对双足机器人来说，偶发延迟意味着什么？意味着某个控制周期没有及时输出动作，机器人就可能在那个瞬间失去平衡。我在实机调试时，早期用普通线程跑200Hz控制循环，肉眼可见机器人会“抖动一下”，日志里也记录到个别控制周期延迟到了20毫秒以上。

解决思路有三个层面。第一，给控制线程设置高优先级，用SCHED_FIFO这类实时调度策略；第二，将控制线程绑核到某个专用CPU核心，避免内核把它在各个核心之间来回迁移；第三，减少同核上的其它负载，比如把Wi-Fi、蓝牙、桌面环境等全部关掉。为了更彻底，还可以在内核启动参数里加上isolcpus或者使用cpuset，把某个核心完全隔离出来给控制线程用。

如果你准备在RK3566上用Python写控制主循环，需要特别小心Python的GC暂停和解释器GIL带来的不可控延迟。我实测Python的循环控制在低频（50到100Hz）还能用，但如果目标是500Hz以上，建议控制主循环用C++写，Python只负责配置加载和日志记录。很多Microduck开源方案的部署代码都会提供C++版本，就是为了规避这个问题。

4.3 与下位机的通信：串口、PWM与关节指令

在部署链路中，模型推理只占一小部分时间，真正占时间的是“读传感器”和“发关节指令”的过程。Microduck的关节电机常见有两种驱动方式：一种是普通PWM舵机，由板卡输出PWM信号控制目标位置；另一种是串行总线舵机或者带驱动的直流电机，通过串口/CAN发送位置、速度指令并读取反馈。

PWM舵机的优点是简单，缺点是你很难读到关节角度，只能“开环”地认为舵机转到了目标位置。这种情况下，算法的状态输入里其实没有准确的关节角度，只有目标位置，控制效果会差很多。串行总线舵机要好一些，能直接读到当前位置、电压、温度，让控制闭环真正闭合。我调试时用的方案是串口与下位机通信，先写一个简单的通信协议：帧头、设备ID、指令类型、数据、校验。控制线程每周期做四件事：读IMU、读关节角度、推理策略、通过串口发送关节目标位置。

串口通信在Linux上也有“坑”。默认的串口驱动可能会有缓冲延迟，你write之后数据不一定立刻发出。解决手段是设置串口的low_latency标志，并关闭tty的流控。CAN接口同理，需要配置好波特率并注意CAN帧的DLC对齐。实机跑起来之后，我用示波器量了串口的发送间隔，基本能稳定在5毫秒一次，200Hz的控制频率对Microduck这种25厘米级别的机器人是够用的。

5. 实机联调：从GPU上的“数字翻跟头”到脚下真正站稳

5.1 先做PD，再做RL，再谈鲁棒性

我见过不少人把训练好的RL策略下载到实机就直接开跑，结果机器人“啪”一下倒地，然后他们开始怀疑策略不行。但在我看来，实机联调的第一步不是RL，而是一个简单的PD控制器。先用PD验证驱动、传感器、通信链路是否正常工作：让每条腿的关节能转到指定角度、IMU数据能稳定读取、控制周期没有明显抖动。等到这些全部正常，再切换RL策略。

为什么一定要这样？因为RL策略是端到端学习出来的控制律，它的输入输出关系不像PD那样直观可控。如果底层驱动正负方向反了、关节零位偏了、IMU安装角度歪了，PD控制器还能靠调试识别出来，但RL策略会把这些错误当作“正常状态”的一部分去响应，表现可能极其诡异，你很难定位是模型问题还是硬件问题。所以哪怕你觉得PD很“传统”，它依然是排查硬件最趁手的工具。

在PD阶段，我最先做的事情是给所有关节发一组正弦扫频指令，观察关节响应是否平滑，有没有卡顿、啸叫、抖动。然后让机器人保持一个矮蹲姿势，测试重心和支撑脚的关系。最后，接上遥控急停，确保任何异常状态下都能立刻断电，避免策略失控时烧坏舵机或撞坏结构件。

5.2 训练奖励正常但实机抖动：排查实录

Microduck第一次切换RL策略跑起来时，出现了一个很典型的症状：仿真里跑步正常，实机上却能站稳，但站一会儿就会开始高频抖动，随后朝一边摔倒。第一反应是PID增益问题？但这个策略根本没有PID。然后怀疑控制频率不够，但从日志看频率稳定在200Hz，不像是这个问题。

后来逐项排查，发现问题出在IMU数据滤波上。仿真里的IMU数据是理想值，没有加速度计噪声和陀螺仪零漂；实机IMU却在每个控制周期都有细微的高频噪声。策略对机身角速度这个观测维度非常敏感，IMU噪声直接变成了动作抖动。我在PD阶段没暴露这个问题，是因为PD控制器的带宽低，天然滤掉了一部分高频分量；RL策略是纯比例式的状态映射，对噪声几乎没有过滤能力。

解决办法有两个方向：一是在硬件层面选更好的IMU，或者做振动隔离安装；二是在软件层面加低通滤波或滑动平均。我用了一阶低通滤波，截止频率设在30Hz左右，同时把陀螺仪零漂在静止时校准掉。另一个“隐藏问题”是电机响应延迟：仿真里我设的电机时间常数很小，实机舵机却存在几十毫秒的响应延迟，导致策略以为关节已经转到目标位置，但实际还在路上。加上这个延迟补偿后，机器人终于从“能站几秒”进步到“能持续站住并缓慢行走”。

5.3 常见问题速查表

5.4 我真正想强调的一支配平问题

最后聊一点“偏经验”的东西。强化学习机器人部署和普通深度学习模型部署有一个特别不一样的地方：它是一个闭环系统。模型推理的微小误差并不会在一次推理后就消失，而是会进入下一帧的观测，被系统自身放大或衰减。很多在单帧测试里看起来完全没问题的部署误差，比如0.01弧度的角度差、1%的延时抖动，在闭环里可能被放大成灾难性的摔倒。

这提示我们，不要只盯着单帧推理精度，而要用整个“控制周期”的视角去评估部署质量。怎么评估？让机器人带着遥测数据跑一段，把实机观测序列记录下来，然后在GPU仿真里用同样的观测序列做“开环回放”，对比策略输出的动作是否一致；也可以做“闭环回放”，把仿真环境的初始状态设成和实机一样，注入同样的扰动，看仿真里的表现是否能复现实机。如果仿真里稳定、实机不稳，那问题大概率出在观测质量或执行延迟上，而不是策略本身。

部署RL机器人给我最大的体会是：强化学习本身在GPU上训练时显得“高大上”，但真正让它落地，靠的反而全是那些最朴素的工程手段——滤波、标定、线程优先级、通信协议、归一化参数导出。把这些做扎实了，策略网络自然就站住了。经验就一句话：“仿真里解决不了的，实机上也解决不了；实机上的问题，大多不是强化学习的问题，而是系统集成的问题。”

如果有机会再做一次，我会在一开始就准备一个完整的遥测系统，把每一帧的观测、动作、控制周期、IMU原始数据全部记录下来，而不是等出问题了才去补日志。这不只是为排查用的，它还能给你下一轮训练提供真实数据，往IQL这类离线强化学习的方向走，用实机数据做策略精修，才是让Microduck越跑越稳的最短路径。