企业官网建设流程全解析

1. 为什么是 Microduck：从仿真到实机的 25 厘米载体

先说结论：Microduck 是我见过的在“教学/研究”和“真机部署”之间平衡得最好的小尺寸足式平台。25 厘米级别的机身意味着它可以在桌面上完成大部分实验，不用像 1 米级大狗那样担心安全问题；同时它保留了关节电机、IMU、编码器等完整的感知-执行闭环，不像很多微型玩具机械狗只有开关量遥控。对于要做强化学习 sim2real 的人，这个载体大小正合适。

整个项目链路是：英伟达 GPU 上跑 Isaac Lab / Isaac Gym 仿真训练 → 得到强化学习策略 → 导出 ONNX 或 pt 模型 → 部署到 RK3566 核心板 → 实机运行。这里的 RK3566 是瑞芯微的 SoC，四核 Cortex-A55，集成 0.8 TOPS NPU。说实话，这个算力在今天的边缘设备里不算强，但用来推理一个几十层的小型 MLP 策略网络绰绰有余。泰山派开发板（基于 RK3566）在这套流程里扮演的，就是“大脑”的角色。

我自己的使用场景其实很直白：在实验室用一台带 RTX 卡的机器把策略训好，然后希望在不接电脑、不插网线的状态下，让机器人自己跑起来。Microduck 配合 RK3566 正好满足这个诉求——它自带多个串口、USB 口、GPIO，跟电机的通信不需要额外转接板，一根线就能搞定。

这里要提醒一句：如果你只是想看机器人走路，那不需要学强化学习，传统 PID 就够了。Microduck 这类平台的有趣之处在于，它用 RL 训出来的步态更接近自然生物的步态，抗扰动能力也更强。而“从 GPU 到实机”这一整条链路，才是这个项目真正的学习价值所在——它几乎囊括了仿真环境搭建、奖励函数设计、策略导出、边缘端推理优化、实机联调这五个现代机器人开发的关键环节。

我最初接触这个项目时踩了不少坑，尤其是“RK3566 能识别到板子但显示是 ADB 设备”这个问题，浪费了我整整一个下午。这类问题在社区里问的人很多，但很少有文章系统讲清楚。所以这篇手记我会把重点放在**“从训练完成到实机稳定行走”之间的那些真实障碍**上，顺带把整个流程串一遍。

2. 算力规划：为什么一块消费级 GPU 就够，以及 RK3566 的角色定位

2.1 仿真训练侧的算力需求

如果你是第一次接触强化学习 + 机器人，可能有一个误区：会觉得训练机器人一定要很大规模的算力集群。实际上，以 Microduck 这种 12 自由度（每条腿 3 个关节）的小型机器人来说，单张英伟达 GPU（RTX 3060 及以上）已经可以完成一个可用策略的训练。

原因有两方面。第一，像 Isaac Lab 这类基于 GPU 并行的仿真环境，本身就设计成可以在一块卡上同时跑数千个并行环境。PPO（近端策略优化）这类强化学习算法依赖环境采样多样性，GPU 并行直接把采样效率拉高了几个数量级。第二，Microduck 的动作空间和质量属性相对简单，策略网络不需要很大——一般是一个 [state_dim, 256, 256, action_dim] 尺寸的 MLP 就够用了。我的习惯是：先用 2048 个并行环境，在 3060 上训练 20000 次迭代，大约 2~4 小时能出一个能稳定行走的 checkpoint。

这里有个经验值可以分享：如果你发现训练时间超过 6 小时还看不到像样的步态，大概率不是算力不够，而是奖励函数或者域随机化参数有问题。我见过不少人盲目调大网络尺寸，结果训练反而变慢、策略变差。小模型的优势在于：它更容易收敛，推理速度更快，部署到 RK3566 时延更低。

2.2 边缘部署侧的算力适配

RK3566 的 CPU 是 4 核 A55，主频最高 1.8GHz。跑一个量化后的 INT8 神经网络，大概能到 100~200 FPS 的推理速度。这个数字听起来不高，但机器人的控制频率通常在 50~100Hz（也就是每 10~20 毫秒要决策一次），推理耗时只要控制在 3 毫秒以内，整条控制链路就不会成为瓶颈。

真正需要注意的，不是神经网络本身的推理速度，而是整条感知-决策-执行管线的延迟。在实机上，IMU 数据读取、关节编码器读取、状态拼接、模型推理、动作下发，每一步都有开销。如果你在 PC 端用 PyTorch 推理很流畅，但到 RK3566 上发现控制频率只有 30Hz，那问题往往出在某个中间环节——不管是串口通信的延时，还是 Python 解释器本身的 GIL 限制，都可能是元凶。

我个人建议：RK3566 上不要用 Python 做实时控制循环，至少推理部分要写成 C++ 或者调用 NPU 的 C API。Python 适合做调试和原型验证，但不适合做最终部署。后面我会专门讲我是怎么解决这个问题的。

2.3 关于算力的一个反直觉结论

在实机上跑了一段时间之后，我有一个结论：Microduck 这个级别的平台，算力根本不是什么稀缺资源，真正的瓶颈在工程集成能力——如何把数据通路打通、如何把延迟压下来、如何处理实机与仿真的差异。RK3566 算力虽然比树莓派 4 强一些，但也谈不上惊人，可是它赢在接口丰富、工具链成熟、有 NPU 可用。这些特点对一个机器人项目来说，比单纯的 CPU 跑分重要得多。

所以如果你想复现这个项目，不用一上来就考虑上 Orin 或者 x86 工控机。先把 RK3566 吃透，它足以支撑你完成从“会走”到“走得好”的全部迭代。

3. 强化学习训练：从跑通 demo 到可控步态的关键细节

3.1 仿真环境搭建与常见坑

Microduck 的仿真训练，社区里目前主流的选择是 Isaac Lab（NVIDIA 官方维护的强化学习框架），也有一些项目用老的 Isaac Gym（目前已停止维护）。两者在前端 API 上差异不大，但 Isaac Lab 对最新版本 PyTorch 和 Isaac Sim 的支持更好。我建议直接上 Isaac Lab，别在 Isaac Gym 上花时间了。

安装过程中最常遇到的三个问题：

1. Isaac Sim 下载慢：这个没太多技巧，建议用官方提供的镜像渠道，或者挂代理（但请确保合法合规）。
2. 版本不匹配：Isaac Lab 的版本跟 Isaac Sim、PyTorch 的版本是绑定的。曾经有个版本要求 PyTorch 2.0.1，你装了 2.1 就报一堆 API 错误。解法就是严格按官方 requirements 来，不要图新鲜升级 PyTorch。
3. GPU 显存溢出：默认并行环境数（num_envs）在 4096 或 8192，如果你的卡只有 8GB 显存，直接降到 1024 或 2048 就好。并行数少了，训练时间会变长，但不会影响最终策略质量，只要迭代轮次够。

我的最终训练配置是这样的（RTX 3060 12GB）：

• 并行环境数：2048
• 最大迭代步数：30000
• 学习率：3e-4（线性衰减）
• GAE 参数 lambda：0.95
• PPO clip 范围：0.2
• 熵系数：0.01（这个很重要，太小容易过早收敛到局部最优）

3.2 奖励函数设计：踩过最多的坑

强化学习项目 80% 的精力和时间都在奖励函数上。Microduck 要实现稳定的双足/四足步态，奖励设计至少要包含几个方向：

运动方向奖励：让机器人沿着 y 轴前进。这类奖励通常用“当前前进速度与目标速度的差值”来构造，差值越小奖励越高。推荐用负二次误差的形式，让机器人有平滑加速的动机。

姿态保持奖励：IMU 返回的 roll 和 pitch 角度应该接近 0。角度偏得越大，惩罚越大。这个惩罚不能设置得过重，否则机器人会走向“僵硬地保持姿态但完全不前进”的极端。

能量惩罚：关节力矩或加速度过大时要惩罚，这能让步态更自然，避免高频抖动。我试过把能耗惩罚设太高，结果机器人变成走路极慢的“老人步态”，反而不实用。

动作平滑惩罚：相邻两步的动作差过大时要惩罚，否则策略容易学到高频抖动的小碎步。

上面这些都是常规操作，真正让我踩坑的是奖励权重的平衡。一开始我参考了其他项目的权重，把速度奖励设得很高，结果机器人学会了“往前跳”而不是“走”，虽然前进速度达标了，但姿态东倒西歪。后来我调了一下午，把速度奖励权重下调了 40%，姿态惩罚权重上调了 30%，步态才变得自然。

这里结合热搜词里提到的“强化学习遇到错误奖励”，我必须多写几句：奖励函数不是拍脑袋定的，每一步都要在 TensorBoard 里看曲线。如果你发现“总奖励在涨，但机器人的实际行为变奇怪了”，那一定是某个子奖励项失衡了。比较常见的失衡场景是：

• reward_forward_vel权重过高 → 机器人摔倒后也能靠“滑行”获得前进奖励
• reward_action_rate权重过高 → 机器人动作变化极慢，反应迟钝
• reward_orientation权重过高 → 机器人宁愿站着不动也不前进

我的建议是：先不加任何“花活”，只用最简单的三项（前进、姿态、能耗）跑出一个能走起来的基线，然后再逐步加复杂度。如果一开始就堆 10 个奖励项，出问题你根本不知道从哪排查。

3.3 域随机化：sim2real 的灵魂

从仿真到实机，最大的敌人是“仿真与现实的差距”。你仿真的物理参数（摩擦力、电机响应、质量分布）不可能和实机完全一致。域随机化就是在训练过程中随机改变这些参数，让策略学会适应各种“变形”的情况。

我在 Microduck 上的域随机化配置：

• 关节摩擦系数：在 0.3~1.0 之间随机
• 电机扭矩常数：±10% 随机
• 地面摩擦：0.5~1.5 随机
• 机身质量：±20% 随机
• 质心位置：±3cm 偏移（这个非常有效）
• 控制延迟：随机增加 0~20ms

特别是控制延迟随机化，很多人的 sim2real 失败都栽在这里。如果你在仿真里假设“给定动作，电机立刻响应”，到了实机你会发现每帧总有几毫秒的通信延迟和电机响应延迟，累积起来就是策略的“不稳定因子”。在仿真里显式加入延迟，策略就会学会在有滞后的情况下依然稳定输出动作。这比起在实机上慢慢调试 PID 前馈要高效太多了。

我当时的训练验证曲线很典型：加了域随机化之后，在仿真里看奖励曲线反而不如不加时平滑，但拉到实机上第一次跑就能走起来。所以记住一句话：仿真里太完美的策略，实机上一定崩。

3.4 IQL 等离线强化学习的补充视角

热词里好几次提到“IQL 离线强化学习”。离线 RL 的思路是不再依赖在线采样，而是从一个固定的数据集里学行为策略。在机器人领域，离线 RL 的吸引力在于：你可以先用传统控制器（比如 MPC、PID）运行实机收集大量状态-动作-奖励数据，然后用 IQL 这类算法离线训练出一个策略，省去仿真环境的建模成本。

但这个路线放在 Microduck 这种平台上，我个人不太推荐作为首选。原因很现实：

1. Microduck 没有现成的高质量经验数据集，你只能自己收集，数据量通常不够训练出鲁棒策略。
2. 离线 RL 对数据覆盖范围要求极高，你收集的轨迹里如果没有“跌倒后自恢复”的数据，策略在遇到扰动时就不会自愈。
3. IQL 训练时的超参数敏感性也偏高，新手上手难度比 PPO 大不少。

当然，如果你已经有一个在线 RL 训练好的策略，又想把“部署时的实机数据”反哺回来做进一步优化，IQL 是很好的工具。我后来试着用 IQL 在旧数据集上做了微调，确实能在某些场景下提升鲁棒性。但那是“锦上添花”，不是“雪中送炭”。建议你先掌握 PPO + 域随机化的完整链路，再考虑离线 RL 的进阶玩法。

4. 策略导出与模型转换：把 PyTorch 变成 RK3566 能跑的格式

4.1 导出前必须做的一次验证

从仿真训练得到的策略，通常是一个 PyTorch 的nn.Module。导出 ONNX 非常容易，三行代码的事。但导出前一定要做一次仿真里的闭环验证：把 actor 网络的权重锁死，单独用这个网络去跑仿真环境，确保它确实能完成任务。因为训练过程里 actor 和 critic 是同时更新的，你有可能导出的是某个中间状态的 actor，而不是最终版本的。

我一般会在保存 checkpoint 时，同时记录一个字段说明“这个 checkpoint 对应的平均 reward 是多少、是否通过了闭环评测”。否则训练了几百个 checkpoint，早忘了哪个是好的。这个习惯帮我省了很多时间。

4.2 ONNX 导出的关键参数选择

ONNX 导出时，有几个参数需要特别注意：

import torch # 假设 policy 是训练好的 actor 网络 # 输入维度根据自己的 state 定义，比如 48 维 dummy_input = torch.randn(1, 48) torch.onnx.export( policy, dummy_input, "microduck_policy.onnx", input_names=["obs"], output_names=["actions"], dynamic_axes=None, # 这里必须设 None，固定 batch size 为 1，对部署更友好 opset_version=12, )

两个要点：

1. dynamic_axes我建议直接设为 None。机器人推理时每次输入都是 1 个 state，不需要动态 batch。固定维度能让后续的量化工具更好地优化计算图。
2. opset_version选 12 是目前 RKNN 工具链兼容性比较好的版本，太高的 opset 反而可能不被支持。

导出后，最好用onnxruntime在 PC 上跑一遍，确认输入输出尺寸和数值范围没有问题。这一步只要能跑通，就已经排除掉了 70% 的可能坑。

4.3 RKNN 模型转换：RK3566 上的 NPU 推理

RK3566 的 NPU 只支持 RKNN 格式的模型，所以 ONNX 还需要通过瑞芯微官方的rknn-toolkit2转换。转换工具跑在 PC 上（x86 架构），转换完成后生成.rknn文件，拷贝到板子上用rknn-toolkit-lite的 C API 或 Python API 加载推理。

这个转换过程，有几个我觉得必须强调的点：

1. 必须做量化校准。RKNN 的 INT8 量化需要一组代表性的输入数据作为校准集。如果你直接转 INT8 而不带校准数据，精度会下降得很厉害。我一个项目的策略在仿真里成功率 95%，直接转 INT8 后降到 60%，加了 1000 帧校准数据后恢复到 90%。

2. 算子兼容性。PPO 的 MLP 基本只涉及全连接、ReLU、LayerNorm 这类算子，RKNN 工具链的支持比较成熟。但如果你在策略里用了 GELU 激活函数或者注意力机制，就要小心了，转换时很容易报“算子不支持”的错误。解法是：要么换回 ReLU 重新训练，要么在导出 ONNX 的时候把不支持算子用onnxsim做简化折叠。

3. CPU 回退。RKNN 工具链允许指定某些算子在 CPU 上执行，而不是 NPU。有时候一个算子不支持，直接回退 CPU，模型也能跑，但整体推理速度会受影响。我的建议是：MLP 这种结构简单的网络，能全量上 NPU 就全量上，不要偷懒回退。

转换命令大致是（我这里只说思路，不贴具体代码，因为工具链版本差异大）：

• 用rknn.config设置目标平台为 rk3566
• 加载 ONNX 模型
• 设置量化数据集（一组真实/仿真 state 的 npy 数组）
• build 生成 rknn 模型
• 导出最终文件

4.4 量化精度损失：从 95% 到 90% 再回到 93%

说到量化，很多做 RL 的人第一次听到“策略要 INT8 量化”都会紧张——毕竟 RL 策略是连续动作输出，精度损失可能直接决定动作对不对。我实测下来，Microduck 的策略对量化其实相当鲁棒，原因在于：

• 动作空间是平滑连续的，网络输出的微小误差反映到关节角度上，只有零点几度的偏差
• 机器人底盘的机械结构本身有柔顺性，电机响应也不是绝对精确

换句话说，一个 256 维的 MLP 策略，即使量化后误差 5%，对实际行为的影响远小于“控制频率下降 20%”的影响。所以如果你时间紧，先跳过量化，直接用 FP16 或 FP32 模型在 RK3566 的 CPU 上跑，验证整个链路通不通，然后再优化性能做量化。这样定位问题会更清晰。

5. 实机部署：RK3566 + 泰山派的硬核环境搭建

5.1 系统选型与基础配置

我用的泰山派开发板是 RK3566 方案里比较亲民的一款，核心板加底板可以装在 Microduck 机身上。系统方面，官方提供了 Buildroot 和 Debian 两种镜像。建议直接用 Debian，虽然体积大一点，但软件生态方便，调试时省心得多。

这里要特别回应一个热词：“泰山派识别到 RK3566 但是是 ADB 设备”。这是很多新手刚上手泰山派时懵掉的地方——板子插上电脑后，lsusb能看到 Rockchip 设备，但系统里出现的不是虚拟串口，而是一个 ADB 设备接口。这其实不是故障，而是板子在默认状态下跑的是 Android 或者带 ADB 的固件。解决思路很简单：

1. 确认你烧录的是 Debian（或 Linux）镜像，而不是 Android 镜像
2. 如果是 Debian 镜像，检查板子上是否开启了 ADB 服务（systemctl status adbd）
3. 如果确实需要串口控制台，你需要启用 UART 的 debug 串口功能

我最初的板子到手就是这样，插上电脑显示为1f3a:efe8（Rockchip ADB），当时我一度以为是驱动问题。后来刷了官方 Debian 镜像、进入系统后手动关掉 adbd 服务，才恢复正常串口通信。如果你遇到的也是这个现象，先别怀疑硬件，从固件上查。

5.2 与电机通信：串口还是 USB？

Microduck 原来的通信方案是用串口（UART）直接连接电机控制板。但有些版本的电机驱动板只提供 USB 口，这时候就需要在 RK3566 上做一个 USB 转串口处理。

我的实际经验：

• 如果你电机控制板支持串口（通常是 TTL 电平 3.3V），优先用硬件 UART。RK3566 自带多个 UART 引脚，延迟最小，不会因为 USB 转串口芯片的缓冲导致额外延迟。
• 如果只能用 USB，注意选质量好的转接芯片（CP2102 或 FT232），山寨 CH340 也能用，但偶发丢包会在控制频率上放大成抖动。

Microduck 的关节电机通常使用类似串口总线协议通信，一帧包含电机 ID、目标位置/速度/力矩、校验位等。我在部署时直接用了板子的 UART2，波特率设成 1M（Microduck 电机支持的最高波特率），实测控制频率能稳定到 100Hz 以上。

5.3 实时性优化：从 30Hz 到 100Hz 的调优过程

最初我 RK3566 上跑 Python 控制循环，频率只能到 30Hz 左右，机器人走起来一顿一顿的。后来我用 C++ 重写了推理和控制循环，频率提升到 100Hz 以上。整个优化过程，我总结了三个关键点：

1. 去掉 Python 解释器开销。如果你的策略推理是用 Python 的 rknn-toolkit-lite API，每帧光 Python 层调用就有几毫秒开销。C API 则可以直接在内存里复用输入输出 buffer，省掉重复分配。

2. 置 CPU 亲和性。RK3566 有 4 个 A55 核，把控制线程绑定到其中一个核上，避免操作系统调度导致的抖动。这对实时控制非常重要。

3. 用双缓冲共享内存做进程间通信。如果 IMU 读取和策略推理在同一个进程里，这个优化可以不做；但如果分成多个进程/线程，共享内存比 socket 或 pipe 高效太多。

其实对 RK3566 来说，达到 100Hz 控制频率并不难，难的是稳定达到——也就是每一拍的延迟抖动不超过 1~2ms。我用perf工具看了几次热点，发现大头在电机指令的序列化和串口写入。后来把串口 FIFO 打开、指令打包成 DMA 一次性发送，延迟就稳定下来了。

5.4 泰山派识别为 ADB 设备问题的彻底解法

这个问题太典型，值得单独占一节。现象是：把泰山派通过 USB 连到电脑，设备管理器里出现的是 ADB 接口，而不是串口（COM 口）。常见的困惑是“我明明烧的是 Linux 镜像啊”。

排查顺序：

1. 先确认固件确实是你烧的那个。回读 eMMC 里的系统，看看/etc/os-release是否是 Debian。
2. 确认内核是否使能了 USB gadget 的 adb 功能。Linux 镜像默认有可能把 USB 口配置成 ADB gadget，供调试用。执行ls /dev/看看有没有ttyGS0，如果有，说明内核已经加载了 USB gadget 串口驱动。
3. 切换 USB 口模式。泰山派的 USB 口有一个 OTG 检测脚，某些底板设计上，把 OTG 口插到电脑上就是 ADB，但把普通 USB HOST 口接上就是串口。

我的最终做法是：直接用开发板上的调试串口引脚（TTL 电平）连接 USB 转 TTL 模块，不进 ADB 模式。这样既不依赖 USB gadget 驱动，也不怕 OTG 识别问题，输出就在/dev/ttyS0或/dev/ttyS2上。如果你一定要用 USB 调试，那就需要改内核设备树或者关掉 adbd 服务，但说实话没有必要折腾。

6. 实机联调：第一次站起来之前的那些事

6.1 关节零位校准：最基础也最容易被忽略

实机联调的第一个坎，不是策略，而是电机零位。Microduck 的关节电机在断电后需要重新找零位——如果零位不对，即使策略网络输出的动作是正确的，机器人也会以一个扭曲的初始姿态开始执行动作，结果必然是摔倒。

我用的是“手动掰直 + 软件归零”的方法：把每条腿手动摆到 90 度标准关机角度，然后给电机发送归零指令，让编码器记录当下位置为 0。注意，每条腿的零位定义在 URDF 里是有规定的，不要凭手感，要对照 Microduck 的文档。否则 A 腿的 0 和 B 腿的 0 定义不一致，策略照样崩。

这里有一个常见 bug：多关节电机 ID 冲突。如果某两条腿的电机 ID 相同，上电后表现就是关节乱动或者完全不动。排查方法是逐个发送“读取电机 ID”的指令，确认 12 个电机依次对应正确的 ID。我经历过两次这个问题，原因都是接线端子接触不好导致 ID 配置没有写入成功。

6.2 遥控器测试：先验证机械和电机，再上策略

在加载强化学习策略之前，我强烈建议先用遥控器/手动模式测试机器人的基本动作。Microduck 的固件一般自带一个简单的遥控模式，能控制每条腿的基本动作。这一步的作用是：

1. 验证 12 个电机都能正常响应
2. 验证关节运动方向和正负号定义是否一致
3. 验证电池电压能满足长时间高负载运行

我遇到过的问题是：电机正反转方向定义在仿真和实机里不一致。仿真里action=1是关节正转，实机里可能因为接线原因变成了反转。如果不先做方向验证，直接加载策略，机器人会立刻“劈叉”摔倒，还会让你误以为是策略没训好。

6.3 状态估计的实机映射

Microduck 的策略输入（state）一般包括机器人基座的线速度、角速度、姿态（来自 IMU）、关节角度和关节角速度（来自编码器）。在仿真里，这些状态是理想化的。到实机上，IMU 数据有噪声，编码器数据偶尔有毛刺，如果不做处理，策略会整体产生偏移。

我做的处理：

• IMU 数据过一阶低通滤波，截止频率约 20Hz，滤掉高频振动干扰
• 关节角速度用编码器差分计算，但配合一个死区阈值，避免静止时微小抖动被放大
• 基座线速度不从编码器估计（轮式机器人常用轮速积分，但足式机器人地面滑移大，积分发散极快），直接用 IMU 的姿态和线加速度估计

这里有个工程细节：Microduck 的策略输入如果用的是“机体速度”，实机上建议用估计出的基座线速度或者直接用 IMU 积分得到的线速度，不要用电机转速换算，否则地面打滑时会差非常多。

6.4 第一次上策略：控制频率、滤波参数、保护机制

一切就绪后，第一次加载策略是非常紧张的时刻。我的建议是把以下参数提前准备好，避免手忙脚乱：

第一次跑的时候，我不建议直接放在地面上松手，而是用一根绳子系在机身后方，吊着一点力，让机器人的一部分重量被支撑住，观察它腿部的运动是否合理，然后再慢慢放下来。这样即使策略完全不行，也只会让机器人原地扑腾，不会跑飞。

我第一次跑 Microduck 时就是因为心急直接放地上了，结果策略的x轴速度指令和实际方向完全相反，机器人直接冲了出去，把前腿的一个连杆撞歪了。流血教训，大家引以为戒。

7. 常见问题排查：部署过程中最容易卡的七个点

把我在这个项目里遇到过的问题按出现频率排个序，做成一张速查表。每一个都对应一个具体的排查思路。

问题 1：RK3566 识别为 ADB 设备，没有串口

• 原因 1：固件是 Android 镜像或 ADB gadget 被启用
• 解决：重新烧录 Debian 镜像，或关闭 adbd 服务
• 原因 2：使用了 OTG 口而非原生 UART 引脚
• 解决：改用板载调试串口（TTL），或用 USB 转 TTL 模块

问题 2：ONNX 转 RKNN 报“算子不支持”

• 原因：策略网络里有自注意力、GELU 等 RKNN 未支持算子
• 解决：用onnxsim简化模型，或改回 ReLU 重新训练
• 提示：全连接 + ReLU 是最稳的组合，没有之一

问题 3：量化后策略完全失效

• 原因：校准集数据分布和实际部署时的 state 分布不一致
• 解决：用 500~2000 帧真实/仿真 rollout 数据做校准集，而不是随机数
• 提示：校准数据覆盖率比数量更重要

问题 4：实机走几步就摔倒，但在仿真里完美

• 原因 1：域随机化不充分，尤其缺控制延迟随机化
• 原因 2：状态估计噪声过大，策略被“幻觉”误导
• 原因 3：控制频率和训练时不一致
• 解决：分别排查，优先补控制延迟和状态滤波

问题 5：部署后控制频率只有 30Hz

• 原因：Python 控制循环 + 串口写入延迟
• 解决：C++ 重写控制循环，重用内存 buffer，DMA 发送电机指令
• 提示：目标可以定 100Hz，但先保证 50Hz 稳定，再逐步优化

问题 6：上策略后关节乱抖，像癫痫一样

• 原因 1：动作平滑惩罚权重太低，策略学到高频抖动
• 原因 2：编码器差分计算的角速度噪声太大
• 解决：对动作输出和角速度都做滤波，或者在奖励函数里加大action_rate惩罚

问题 7：电池掉电快，走不了几分钟

• 原因：电机脉动电流大，电池容量或电压支撑不住
• 解决：换 C 数高一点的航模电池（如 100C 以上），或者降低最大输出力矩限制

8. 后续还能怎么玩：从 PID 到分层强化学习

Microduck 这个项目做完“能走”之后，真正的乐趣才刚刚开始。我给几个值得深入的方向，都是我自己试过或正在尝试的：

基于强化学习的 PID 控制优化。热词里有“基于强化学习的 PID 控制”，这个思路很妙——用 RL 输出 PID 增益（kp、ki、kd），代替传统人工整定。具体实现上可以用策略网络输出每个关节的 PID 增益，然后结合传统 PID 控制器做底层控制。这种做法比直接用 RL 输出关节扭矩的鲁棒性更好，对电机模型误差不那么敏感。

分层强化学习。上层策略负责路径规划和足端轨迹选择（比如“迈左腿 vs 迈右腿”），底层策略负责关节力矩控制。分层的好处是，上层决策频率可以低一些（10~20Hz），底层控制频率保持 100Hz，算力压力小很多。

倒立摆 / 双足平衡。Microduck 的双足倒立摆模式是很多人的进阶实验。使用同样的 RL-to-RK3566 链路，只需要修改仿真环境的任务定义，让机器人在双足上保持平衡。这个任务对状态估计的精度要求更高，也需要更精细的奖励设计，但一旦跑通，你对“足式机器人动力学”的理解会深一个层次。

模仿学习。如果你想跳过大段奖励函数设计的痛苦，可以尝试从动捕数据或人类动作数据出发，用模仿学习让 Microduck 学会特定动作（比如作揖、挥爪）。这里 RK3566 的算力依然足够，核心难点不在于部署，而在于如何处理好动作数据的时间对齐和相位管理。

9. 最后再分享两个关于长期联调的体会

写到这里，我已经把这个项目的核心链路和能踩的坑都讲了。最后想分享两个“非技术但真的很影响成败”的体会。

第一个是调试要留足环境准备时间。做机器人实机联调，永远会出现“明明代码没问题，但今天机器人就是站不起来”的情况——电池电压低、地面摩擦系数变了、某个电机过热、螺丝松了……这些隐性变量对 RL 策略的影响，比对 PID 控制器的影响大得多。RL 策略在仿真里见过各种“畸形”环境，但现实变量的组合无穷无尽，机器人的每一个机械松动都会暴露在策略面前。

第二个是记录一切实验日志。我后来养成了一个习惯：每次实机跑之前，记录当前策略 checkpoint 编号、域随机化配置、控制频率、电池电压、室温，跑完后再记录行为表现评分。这样积累一段时间，你可以发现一些特别微妙的关系——比如“气温低于 15 度时，关节阻尼变大，同一个策略的表现会明显下降”。这种经验是文档里绝对没有的，但它才是你真正成为“机器人调参老手”的证据。

Microduck 这 25 厘米的小东西，训练和部署链路里藏着整个足式机器人落地的大部分核心问题。把它完整跑通一遍，比看十篇论文都有用。如果你也买了板子、正在调策略，希望这篇手记能帮你少走几步弯路。