企业官网建设流程全解析

1. 为什么把强化学习机器人部署到 RK3566，而不是继续跑在英伟达 GPU 上

先交代一下这个项目的背景。Microduck 是一台 25 厘米级别的四足机器人，结构很小，整机重量不到 1.5 公斤，核心控制板用的是瑞芯微 RK3566 SoC。这个芯片定位是低功耗边缘计算，四核 Cortex-A55，带一颗 0.8 TOPS 算力的 NPU，跑 Linux，整体功耗控制在 5 瓦以内。我们的目标是在这台小机器上跑强化学习运动控制策略，让它在真实环境里走出稳定的步态，而不是只在仿真里“看起来会走路”。

你可能第一反应是：既然已经有一套基于英伟达 GPU 的训练流程，为什么不直接在机器人上挂一块 Jetson Orin Nano？英伟达的生态确实完整，PyTorch 直接跑，CUDA 加速各种算子都有现成实现，但 Microduck 这种 25 厘米级别的小型机器人有它自己的约束。整机供电靠一块 2S 锂电池，Jetson 虽然性能强，但功耗和体积摆在那里，加上载板之后很难塞进这么小的机身。RK3566 的优势是成本低、功耗低、集成度高，核心板加底板整套下来不到 300 元，而且片上集成 NPU，理论上可以承担神经网络推理任务，所以这个选型本身就是冲着“低成本边缘部署”去的。

但这里有一个关键问题：强化学习策略是典型的神经网络推理负载，它跟常见的图像分类、目标检测不太一样。策略网络输入是一堆状态向量（关节角度、角速度、机身姿态、指令速度等），输出是 12 个关节的目标角度或扭矩，网络结构本身不大，通常只有几十万个参数，但推理频率要求很高——控制周期一般 500Hz 甚至 1kHz，也就是说每 1 到 2 毫秒就要完成一次前向推理。这个实时性要求对边缘设备来说比算力更棘手。

所以这个项目的本质问题不是“训练一个会走路的策略”——英伟达 GPU 上 4090 或 A100 训练这类小网络最多两三小时就能收敛；真正的难点是：如何把在 GPU 上训练好的 PyTorch 模型，搬到 RK3566 上以 500Hz 以上的频率稳定运行，同时还要保证策略在真机上不“水土不服”。

我带着这个目标完整走了一遍从训练、导出、量化到实机部署的流程，中间踩了不少坑。这篇文章把整个链路和每个环节的取舍记录下来，给后面想在低成本边缘设备上部署强化学习策略的朋友做个参考。

2. 硬件选型和软件栈：为什么 RK3566 的 NPU 既能用又不好用

2.1 RK3566 的硬件底子和它的边界

RK3566 这颗芯片在消费级产品里很常见，很多开源掌机、智能音箱、NAS 盒子用的都是它。对机器人开发者来说，它的吸引力在于接口全、成本低、资料相对开放。四核 Cortex-A55 主频最高 1.8GHz，日常跑 Linux 系统、做运动学解算、处理传感器数据完全够用，但这颗 0.8 TOPS 的 NPU 才是关键。

NPU 的算力数字听起来不高，但要注意它的计算方式。0.8 TOPS 指的是 INT8 精度下的理论峰值，FP16 大概只有它的一半甚至更低。而我们的强化学习策略网络如果直接用 FP32 在 CPU 上跑，A55 单核大概每毫秒只能跑一次几十万参数的网络前向，性能非常吃紧。所以要用好这个平台，就必须把模型量化到 INT8 并放到 NPU 上执行。

这里要提醒一个容易犯的错误：不是所有网络结构都能顺利量化到 NPU。NPU 对算子支持是有限的，尤其是涉及动态控制流（比如 while 循环、条件分支）、某些自定义激活函数、或者非 4 的倍数维度时，算子映射会非常痛苦。我们在 Microduck 上用的策略网络是基于 MLP（多层感知机）结构的，激活函数是 ReLU 或 tanh，这算是 NPU 最友好的结构——全连接层、ReLU、tanh 都是标准算子，量化误差相对可控。

2.2 软件栈的完整链路选型

训练侧我们用 NVIDIA GPU，Ubuntu 主机上装 PyTorch 和 Isaac Gym / MuJoCo 仿真环境完成策略训练。导出路径是：PyTorch → ONNX → RKNN。RKNN 是瑞芯微的模型转换工具链，负责把 ONNX 格式的模型转换成 NPU 能跑的 RKNN 格式。

这个链路里最容易出问题的是 RKNN 工具链和板端运行库的版本匹配。瑞芯微的工具链版本迭代很快，我们用的 RKNN-Toolkit2 1.6.0 版本配板端的 librknnrt 1.6.0，这个必须严格对齐，否则转换出来的模型在板端根本无法加载。很多人部署失败都是因为版本不一致，报错信息又不够直观，排查半天才发现是版本问题。

还有一个更隐蔽的问题：训练和部署的数据类型一致性问题。PyTorch 训练时我们用 FP32，导出 ONNX 时也保持 FP32，RKNN 工具链在量化阶段才转 INT8，这个过程会引入一定精度损失。后面我会展开说量化校准的细节，这里先记住一个结论：重建量化数据集比选量化算法更重要。

板端的运行环境我们用的是 Buildroot 裁剪的 Linux 系统，配合一个 C++ 写的控制程序，叫 duck_control。它负责读传感器、跑策略推理、输出 PWM 信号控制舵机（Microduck 用的是总线舵机，通过串口发送位置指令）。NPU 推理用 RKNN 的 C API，通过共享内存或直接返回的方式把推理结果传给控制线程，避免不必要的拷贝。

整体软件架构可以概括为三层：底层是 Buildroot 系统加串口驱动；中间是控制主循环（500Hz 定时中断触发）；上层是 NPU 推理模块和状态估计模块。这个分层的好处是方便单独调试——我们可以先用 CPU 推理跑通整个控制流程，再切到 NPU 推理对比效果，问题定位起来非常清晰。

3. 训练管线搭建：从“仿真里会走”到“转换后还能用”的关键参数

3.1 仿真环境和策略结构设计

我用的仿真环境是 MuJoCo，配合自写的 Gym 风格环境。机器人模型从 Microduck 的 URDF 文件导入，包含 12 个关节（每条腿 3 个：髋关节外摆、髋关节前后、膝关节）和对应的电机参数。仿真里加入噪声和延迟，是让策略能够迁移到真机的前提条件，这个后面单独说。

网络结构相对简单：输入维度 48 维（机身姿态四元数 4 维、角速度 3 维、重力向量 3 维、12 个关节角度、12 个关节角速度、12 个上一时刻的动作、电机指令延迟 1 维、节奏相位 2 维，具体设计参考了相关开源实现），中间是三层 MLP，每层 256 个神经元，激活函数用 ReLU，输出 12 维——每个关节的目标位置增量。这个结构用 GPU 训练非常快，单卡 4090 上 2000 个并行环境跑 6000 步迭代，大约 40 分钟能出基本会走的策略。

训练算法用的 PPO（Proximal Policy Optimization），这是强化学习运动控制领域最常用的算法。PPO 的优势是稳定、超参容易调，对新手友好。我们特别关注的是熵系数和 GAE（广义优势估计）的 lambda 参数，这两个值直接影响策略的探索程度和行为平滑度。熵系数太小，策略容易固化到某个次优步态；太大，动作抖动明显，量化后更容易出问题。我把熵系数的衰减从 0.005 调到 0.002，最终实机步态明显更平滑了。

3.2 训练中就要为部署做的准备：算子约束和维度对齐

这是整篇文章里我觉得最有价值的一条经验：在训练阶段就要有意识地限制网络结构和算子，不要等训练完了再去处理转换问题。

具体来说，有几条硬性约束：

第一，激活函数尽量用 ReLU。RK3566 NPU 对 ReLU 支持有硬件加速单元，而 SiLU（swish）虽然对强化学习策略的收敛有帮助，但很多 NPU 工具链对它的映射不太友好，要么转换成多个基础算子导致推理变慢，要么量化精度下降。如果你发现策略用 ReLU 收敛困难，可以先用 SiLU 训练出一个好的策略，再用 ReLU 微调几步，效果通常能接近。

第二，所有张量维度尽量对齐到 4 的倍数。对 NPU 来说，内部计算是按矩阵分块执行的，维度不是 4 的倍数时会有 padding，带来额外的计算浪费和潜在行为不一致。比如你的状态向量如果是 47 维，建议直接在输入端补一个 0 到 48 维，几乎不影响策略效果，但转换和推理的友好度会提升一个档次。

第三，不要在策略网络里用 GRU、LSTM，除非你跑的是一种需要历史信息的部分可观测任务。RNN 结构在 NPU 上要么不支持，要么推理耗时爆炸。Microduck 的步态策略我们用的是无记忆的 MLP，通过给网络输入“上一时刻动作”和“节奏相位”来隐式地引入时序信息，效果上已经够用。

第四，输出层的缩放参数要烘焙进网络里。很多策略网络的输出是用 tanh 后再乘一个系数（比如关节角度范围 ±0.5 弧度），这个乘法在训练代码里是后处理，但如果能把它集成到网络最后一层权重里，转换后推理的输出就是最终的关节增量，省去板端后处理的开销和出错的概率。

3.3 仿真和真机的 gap：域随机化怎么做

把策略从仿真搬到真机，最大的敌人是模型误差和传感器噪声。域随机化是应对这个问题的经典方案——在仿真里随机化各种物理参数，逼着策略学到鲁棒的行为。

我在 Microduck 上做了这几类随机化：

• 机身质量 ±20% 随机变化，模拟电池电量变化导致的重量分布差异
• 关节摩擦力和阻尼 ±30% 随机变化
• 电机力矩常数 ±10%
• 关节角度的观测噪声 ≤ 0.05 弧度
• 角速度观测噪声 ≤ 1.0 rad/s
• 控制延迟 1 到 3 个控制周期随机变化
• 地面摩擦系数 0.4 到 1.2 范围内变化

这个设置不是拍脑袋定的，参考了业界四足机器人 Sim-to-Real 的主流做法。关键是噪声的量级要跟真机实测对得上，太大策略会过度保守，走起来畏畏缩缩；太小则起不到提升鲁棒性的作用。我是先用真机记录了一段关节角度和 IMU 数据，然后统计出噪声方差，再回来标定仿真参数，这个闭环很重要。

4. 模型导出和 RKNN 量化：最容易踩坑的三个环节

4.1 PyTorch → ONNX 导出时的隐藏坑

PyTorch 模型导出成 ONNX 看起来是常规操作，tracing 一下就行，但实际操作时遇到一个问题：模型里有原地（in-place）操作会导致 ONNX 图结构异常，推理结果对不上。

具体场景是，我在网络里用了torch.relu_()的原地版本，训练时没问题，但导出后 RKNN 工具链加载 ONNX 时报告了无效节点。排查了半天，最后把原地操作改成torch.relu()才解决。这个是老坑了，但每次遇到还是容易忽视。

另外一个问题是输入输出的名字和形状要固定。RKNN 转换时是严格按 ONNX 图的输入输出张量名称来匹配的，如果你在导出时用了动态轴（比如dynamic_axes={'obs': {0: 'batch'}}），RKNN 工具链可能不支持，最好固定 batch 为 1，输入形状写成[1, 48]。

导出命令很简单：

import torch policy.eval() traced_model = torch.jit.trace(policy, torch.randn(1, 48)) torch.onnx.export( traced_model, torch.randn(1, 48), "microduck_policy.onnx", input_names=["obs"], output_names=["action"], opset_version=12, do_constant_folding=True )

opset_version 我用的是 12，更高版本的某些算子（比如aten::slice的新变体）RKNN 兼容性不太好。如果你转换时报算子不支持，可以试着往下调 opset 版本，这个技巧解决了我好几次转换问题。

4.2 RKNN 量化的正确姿势：数据校准集决定成败

RKNN 工具链会把 FP32 模型量化为 INT8，这个过程中最关键的不是选什么量化算法，而是你用什么数据来做量化校准。

我一开始直接用了仿真环境里随机采样的一批状态向量做校准集，结果转换后策略在真机上完全“乱走”——输出动作分布错得离谱。后来分析原因：校准数据要尽可能贴近实际部署时会遇到的输入分布。强化学习策略在运行时，状态输入是沿着某种轨迹分布的，而不是均匀随机的，你拿随机采样的数据做校准，量化时每个激活层的数值范围估算就不准，尤其是在中间层特征值的 min-max 范围偏差较大时。

正确的做法是：用训练好的策略在仿真环境里跑几段完整的步态轨迹，把过程中的观测状态全部保存下来，作为校准集。比如跑 20 次随机方向的前进、后退、转弯，每次记录 5000 帧状态，总共 10 万帧数据，然后随机抽 1 万帧做量化校准。

在 RKNN-Toolkit2 里，量化配置大概长这样：

from rknn.api import RKNN rknn = RKNN() rknn.config( mean_values=[[0, 0, 0]], std_values=[[1, 1, 1]], target_platform="rk3566", quantized_dtype="w8a8", quantized_algorithm="normal", quantized_method="layer", ) rknn.load_onnx(model="microduck_policy.onnx") rknn.build(do_quantization=True, dataset="calibration_dataset.txt") rknn.export_rknn("microduck_policy.rknn")

注意quantized_method="layer"——逐层量化模式对这个模型效果好于全局量化，因为每一层的数值范围差异较大。quantized_dtype="w8a8"表示权重和激活都量化为 8 位，这是 RK3566 NPU 的标准配置。

量化之后一定要做精度评估。RKNN 工具链提供了accuracy_analysis功能，可以逐层对比原始 FP32 模型和量化模型输出的差异。我评估下来，全网络输出均值误差在 0.02 弧度左右，这个量级对关节控制来说可以接受。

4.3 一次棘手的量化失败排查

这里记录一次花了整整两天的排查过程，给后来人省点时间。

现象：量化后的 RKNN 模型在板端加载成功，但推理输出全部是 0 或固定值，CPU 上跑 FP32 模型输出正常。

排查链路：

1. 先在 PC 上用 RKNN-Toolkit2 的模拟器跑了一遍 RKNN 模型的推理，输出正常——说明模型转换本身没问题。
2. 那就怀疑板端运行环境。打印了 librknnrt 版本号，确认跟工具链版本一致。
3. 继续查：发现板端首次推理正常，第二次推理开始输出固定值。把推理调用改成每次重新rknn_init，恢复正常，但控制频率达不到要求（初始化要几十毫秒）。
4. 怀疑是不是内存问题导致上一次推理结果被覆盖。查代码，发现官方的 C 示例里用的是rknn_outputs_get获取输出，然后手动把数据拷贝出来，拷贝时机不对就会遇到这种问题。
5. 最终定位：我们没有在rknn_outputs_get之后立即调用rknn_outputs_release，而是在下一次推理前才释放，导致 NPU 内部输出缓冲区被覆盖，拿到的是脏数据。改成推理完成后立刻拷贝并释放，问题彻底消失。

这个坑的根源是 NPU 的输出缓冲区复用机制，任何用 RKNN C API 的人大概率都会遇到，只是表现形式不同。我的建议是：严格按官方示例的时序操作输出缓冲区，不要为了省一次内存拷贝而改变释放时机。

5. 板端部署实战：实时性优化和传感器同步

5.1 控制主循环的时序设计

Microduck 的控制频率设定为 500Hz，即 2ms 一个控制周期。这个频率对 RK3566 来说压力不小——不仅要跑 NPU 推理，还要读 IMU、解算关节角度、发送舵机指令。

控制主循环用一个高精度定时器驱动，Linux 下用timerfd配合epoll_wait实现微妙级别的定时精度，比usleep靠谱得多。伪代码如下：

int timer_fd = timerfd_create(CLOCK_MONOTONIC, 0); struct itimerspec ts = {0}; ts.it_interval.tv_nsec = 2000000; // 2ms ts.it_value.tv_nsec = 2000000; timerfd_settime(timer_fd, 0, &ts, NULL); int epoll_fd = epoll_create1(0); epoll_ctl(epoll_fd, EPOLL_CTL_ADD, timer_fd, ...); while (running) { epoll_wait(epoll_fd, &events, 1, -1); read(timer_fd, &expirations, sizeof(expirations)); // 1. 读取传感器数据（IMU、关节编码器） // 2. 状态估计（低通滤波、四元数规范化） // 3. NPU 推理获得目标动作 // 4. 运动学解算 + 舵机指令发送 }

这个流程里最耗时的是第 3 步 NPU 推理。实测下来 RK3566 NPU 跑我们的三层 MLP 单次推理约 0.8ms（不开异步），加上数据预处理和拷贝，总耗时约 1.2ms，在 2ms 周期内能完成，但余量不多。如果网络再深一些，要么降低控制频率到 333Hz，要么做异步推理——用双缓冲交替推理和控制计算，能进一步压榨性能。

5.2 CPU 推理还是 NPU 推理：隐藏在实时性下的权衡

这个话题值得单独拿出来说。很多人一看到有 NPU 就觉得应该用 NPU，但那是“性能最大化”的思路，不是“系统最优”的思路。

RK3566 的 CPU 推理（FP32）大约耗时 1.5ms，和 NPU 量化的 0.8ms 相比差距不大。但 NPU 推理有个隐藏成本：数据要从 CPU 内存拷贝到 NPU 内存，再拷贝回来，这个拷贝在非共享内存架构下可能要 0.2ms 左右；另外 NPU 推理在 Linux 下是异步提交的，你需要处理同步逻辑，代码复杂度上升。

我当时做了一个对比实验：CPU 推理 + 2ms 控制周期，整体稳定运行；NPU 推理 + 2ms 控制周期，偶尔出现一次周期超时（timer 回调还没处理完就触发了下一轮）。原因是 NPU 推理的 0.8ms 不包含驱动调度的开销，在系统负载波动时，驱动层的等待时间会恶化。

最终我在量产版本上用了 CPU 推理。保留 RKNN 转换的流程是因为 NPU 推理在功耗上确实有优势（CPU 推理整机功耗多 0.5 瓦左右），如果你做的是电池供电的长续航场景，可以试试异步 NPU 推理，但代价是代码复杂度和可能引入的推理延迟抖动。

5.3 传感器同步：IMU 数据的相位延迟问题

强化学习策略是在仿真环境里以“地面真实状态”作为输入训练的，但真机上你只能拿到带噪声的传感器数据，而且这些数据是不同时刻采样的，不是同一瞬间的快照。这个问题如果处理不好，策略会表现得很差——看起来就像策略“没有学过这种情况”。

我的解决方案是在状态估计模块里维护一个 5ms 的缓冲区。IMU 数据到达时打上时间戳，关节角度数据到达时也打上时间戳，控制周期触发时，取缓冲区内时间戳最接近当前周期的数据，组成状态向量送入策略。这样虽然每个传感器数据都有微小延迟，但彼此之间的相对时间差被限制在 1ms 以内，策略对输入时序的假设不会被严重破坏。

另外一个细节是四元数的规范化。RK3566 上 IMU 数据通过 SPI 读取，偶发数据跳变会导致四元数模长偏离 1，不规范化直接送入网络，策略输出会异常。我在状态估计里加了强制规范化步骤，同时对四元数做了低通滤波（平滑系数 0.5），实测能明显降低输出动作的抖动。

5.4 舵机指令的平滑处理

Microduck 用的总线舵机接收位置指令，但从策略网络输出的是“关节位置增量”，需要叠加到当前关节位置得到目标位置，而且必须限制目标位置的增量变化速度，否则舵机会因为指令跳变而过流或抖动。

这里我踩过一个坑：策略在仿真里学会了比较激进的落地动作，真机上直接执行会导致膝关节舵机过流保护，整机直接趴下。后来加了一阶低通滤波器平滑目标位置：

target_filtered = alpha * target_raw + (1 - alpha) * target_filtered_prev;

alpha 取值 0.45，相当于截止频率约 90Hz 的低通滤波。这个参数也是实测调出来的：alpha 太大（>0.7）平滑效果不明显，太小（<0.3）动作延迟大，超过 60ms 后策略会不稳定。

6. Sim-to-Real 迁移：量化后策略为什么“腿软”，以及我的调优方法

6.1 量化误差带来的策略性能退化

即使量化校准集做得再好，INT8 量化对策略行为的影响依然是不可忽略的。我的测试数据是：量化前策略在仿真环境里可以稳定前进 0.8m/s，量化后掉到 0.5m/s，而且横向速度波动明显增大。

原因很好理解：量化相当于给观测和网络权重加了少量噪声。对分类任务而言，输出是离散类别，少量噪声通常不影响结果；但强化学习策略的输出是连续动作，一点点输入噪声经过网络放大，会导致动作抖动量增加，而步态本身是高度动态的系统，输出抖动会被积分放大，最终表现为步态紊乱。

解决思路有两个方向。一个是增强策略本身的鲁棒性——训练时加更大的观测噪声，让策略学会在噪声下维持性能；另一个是减小量化误差——改进校准集或使用混合量化方案，把敏感层保留为 FP16。

对 RK3566 NPU 来说，FP16 算力只有 INT8 的一半，但我们的网络很小，FP16 推理时间约 1.2ms，也还能接受。不过 RKNN 的混合精度量化是在 1.4.0 之后才支持的，如果你用的是老工具链，可能要升级版本。

我的最终方案是两者结合：训练时把观测噪声加大 30%，同时量化时把输出层和前两层保留为 FP16，其余层用 INT8。实机测试下来，前进速度恢复到了 0.75m/s 左右，步态稳定性肉眼可见地提升了。

6.2 真机上的 Iterative 调试：从“能走”到“走得好”

第一次让 Microduck 在真机上用 NPU 推理跑策略时，它能走，但像喝醉了酒，每走三四步就往左偏一下。这属于典型的 Sim-to-Real 迁移问题，在仿真里由于没有系统性偏差（机身的左右质量分布完全对称），策略学出来是左右对称的；但真机上电池的安装位置偏左，导致机身重心偏移，策略没有见过这种不对称性，就会随机地在某个步态相位做出错误补偿。

解决方法是分两步：

1. 在仿真里加入重心偏移（把机身质心在硬件坐标系里偏移 2 厘米），重新训练；
2. 真机调试时，在控制代码里加一个“重力补偿项”，根据 IMU 测量的机身倾角，给每只腿的膝关节额外叠加一个前馈力矩。

第二步的补偿公式是：

feedforward_hip_yaw = Kp * (desired_roll - measured_roll);

Kp 实测定为 0.8，这个补偿让 Microduck 在行走过程中机身侧倾角从 ±6 度降到了 ±2 度，步态眼看着就稳了。

这种调试思路就是经典的系统辨识加补偿，但它和强化学习是互补的：强化学习负责生成基础步态，传统控制负责修正仿真和真机的系统性差异。机器人运动控制里没有银弹，组合拳才是常态。

6.3 部署后的功耗和散热实测

整个系统调完以后，我专门测了一组功耗数据。Microduck 整机待机电流 0.4A（2S 电池，约 3 瓦），静态站立电流 1.2A（约 9 瓦，舵机维持力矩），行走电流 1.8 到 2.2A（约 14 到 17 瓦），峰值出现在大步幅快速前进时，约 2.8A（21 瓦）。

RK3566 核心板在行走工况下的温度，用热像仪测大约 45 到 52 摄氏度，A55 的散热压力不大。但我注意到一个问题：如果环境温度高（比如夏天室外 35 度），核心板温度会逼近 60 度，此时 NPU 推理偶发延迟增大（可能是热降频），控制周期出现超时。解决方案很简单——在 Buildroot 里设置 CPU 和 NPU 的 governor 策略为 performance，关闭动态调频，牺牲一点功耗换实时性。

这个细节对机器人项目尤其重要：服务器上 CPU 降频只是性能下降，机器人上控制周期超时是会摔机的。

7. 我从这个项目里总结的几条实操经验

写到这里，整个部署链路基本走完了。最后分享几条我踩过坑之后形成的实操经验，比那种列满 API 的技术文档有用得多。

第一，工具链版本和三方库版本需要“冷冻保存”。RKNN 工具链的坑特别多，我们项目从开始到稳定运行换了三个版本，每次升级都会带来新问题。后面我养成了习惯：把工具链、librknnrt、交叉编译器的版本号写进 README，并要求一起用pip freeze把 Python 环境锁住。这样换机器或者后来维护的人接手时，只需要按 README 重建环境。

第二，真机调试时，日志和可视化比模型更关键。我一开始把所有调试信息都往串口终端打，数据量太大根本看不过来。后来改成把所有状态、动作、指令都记录到板载 SD 卡（CSV 格式），跑完一段之后离线用 Python 脚本分析。这样能看到完整的时间线——哪一步出现抖动、哪一步指令跳变、传感器数据有没有毛刺，一目了然。强烈建议所有做真机部署的人提前设计好日志系统，别等到出了问题才补。

第三，给 NPU 推理的输出留好容错空间。有一段时间我的控制程序偶发出现关节指令跳变到极限值，查了很长时间，最后发现是 NPU 推理偶尔会输出一个异常大的值（量化噪声导致）。我在输出端加了一个简单的限幅器，把每步动作增量限制在 ±0.1 弧度以内，再配合低通滤波，这个问题就彻底消失了。这个改动很小，但对系统的稳定运行至关重要。

第四，仿真环境的建模精度决定了迁移的上限。很多人把 Sim-to-Real 失败归咎于训练算法，但大部分情况下是仿真环境跟真机差距太大。我在这个项目里花了不少时间在调 URDF 模型上——从舵机死区、力-转速曲线到机身柔性的近似，每一步都让最终迁移效果更好。如果你也有一个强化学习机器人项目，建议先把建模时间占比提上去，可能比调算法超参收益更大。

这个项目给我最大的感受是：强化学习的“训练”其实是最简单的部分，真正的挑战在于把训练好的策略塞进一个物理系统里并让它可靠地工作。部署环节的每一步——模型转换、量化校准、实时调度、传感器同步、系统辨识——都会在不经意间把你的策略“打回原形”。好在这些问题都有迹可循，只要耐心排查，总能找到解决方案。

最后再分享一个小技巧：如果你在一个边缘设备上部署强化学习策略遇到无法解释的行为退化，试着先把量化模型在 PC 上用模拟器跑一遍，再在板端 CPU 上跑一遍，最后才上 NPU——每换一次运行环境，你就能定位问题大概发生在哪一层，排查范围就小了很多。