说实话把强化学习策略从英伟达GPU的仿真环境里搬出来压进一块RK3566开发板再让一台25厘米的Microduck机器人实机跑起来这中间的距离常常被人低估。仿真里跑得好好的策略落到实机上要么原地抖成筛子要么走两步就劈叉真正能稳定跑步的视频背后几乎都是几个月的部署调试换来的。这篇文章就围绕Microduck这个25厘米级别的强化学习机器人项目把从GPU训练、模型导出、RKNN转换到RK3566实机部署的完整流程拆开讲一遍。重点不是我跑了多少个step、用了哪个网络结构而是那些资料里不写、但实际部署时绕不开的决策和坑为什么选RK3566而不选树莓派为什么强化学习策略还要配底层PIDINT8量化后精度掉了怎么处理以及实机步态不稳时应该先怀疑谁。如果你也正准备把仿真训练好的运动控制策略搬到嵌入式平台这篇手记应该能帮你少走不少弯路。1. 项目梳理与部署链路1.1 25厘米Microduck是一台什么机器人先说清楚Microduck到底是什么。从项目名就能看出来这是一台25厘米级别的开源机器人整体尺寸控制在一个手掌加小臂的范围里结构上用四足构型12个运动自由度整机重量大约在1.2到1.5千克这个区间采用锂电池供电。这个尺寸和重量段有个典型特征既有足够的负载能力搭载嵌入式主控和传感器又不像大型四足那样需要几万块的电机和减速器非常适合做强化学习运动控制的验证平台。这类小尺寸机器人最大的难点在于动力学特性。25厘米的腿长意味着惯量小、响应快同时关节间隙和摩擦对运动的影响又被明显放大。在仿真里我们用的是理想电机模型扭矩响应毫秒级到位真机上电机本身有响应延迟齿轮箱有背隙结构件有弹性形变这些都会让强化学习策略的假设失效。所以Microduck这个项目真正有意思的部分不是硬件本身而是如何在这种低成本、低算力平台上跑通强化学习从训练到落地的那条完整链路。GitHub仓库里有基础的硬件图纸、仿真环境和训练脚本但实机部署部分写得很简略。多数人卡住的地方也在这里训练环境能跑模型能出来但不知道下一步该往哪放。这篇文章就把这一段的空缺补上。1.2 为什么主控选RK3566而不是树莓派或Jetson当初选主控时我在RK3566、树莓派4B和NVIDIA Jetson系列之间纠结了很久。先排除Jetson的原因很实际Nano系列虽然算力强但价格和功耗对25厘米机器人来说都偏高Nano满载功耗能到5瓦甚至10瓦以上对一块小电池来说压力很大而且Jetson Developer Kit的体积和散热片塞进Microduck机身里非常局促。树莓派4B的问题则相反它CPU性能不算差但没有可用的NPU。强化学习策略网络虽然不大也只是一层MLP加一个LSTM但在树莓派上纯靠CPU推理延迟能做到10毫秒左右已经算不错而且要占掉一个完整CPU核心控制循环和IO稍微多一点实时性就不好保证。如果你只做站立和缓慢行走树莓派勉强能用但稍微提升速度或者加一点外部扰动CPU推理延迟的抖动就会直接体现到步态上。RK3566这枚芯片在这个场景下显得刚刚好四核Cortex-A55的CPU主频能到1.8GHz带一个0.8TOPS算力的NPU支持INT8量化整板功耗通常控制在3瓦以内。关键是瑞芯微的RKNN工具链能把ONNX模型转换到NPU上跑推理延迟稳定在几毫秒级别CPU核心全部腾出来做控制和通信。再加上RK3566开发板在市场上的价格很低货源也稳定对Microduck这种追求性价比的项目可以说是最合适的嵌入式算力选择。主控方案CPU算力情况典型功耗部署难度适合场景树莓派4B四核A72无NPUCPU推理3~7瓦低但实时性一般频率要求不高的控制Jetson Nano四核A57128核GPU约0.5TFLOPS5~10瓦中生态复杂需要较大模型或视觉RK3566四核A550.8TOPS NPUINT82~3瓦中RKNN工具链成熟小尺寸机器人端侧推理选型还有个细节容易被忽略RK3566的NPU走的是RKNN这套私有工具链一旦确定平台后续所有模型转换、量化、板端推理接口都绑在瑞芯微生态上。一旦中途想换平台模型侧的适配成本不低。所以建议在项目一开始就想清楚别等到模型训练完了才考虑部署平台。1.3 整体链路训练、导出、转换、实机整个部署链路可以拆成四个阶段。第一阶段是GPU端仿真训练用PyTorch搭策略网络在MuJoCo环境里跑强化学习算法训练一个能从观测到动作的Actor模型。第二阶段是模型导出把训练好的PyTorch模型转成ONNX格式固定输入输出维度去除训练相关的计算图结构。第三阶段是RKNN转换在x86主机上使用RKNN-Toolkit2将ONNX模型量化为INT8并生成RKNN格式的模型文件这一步非常关键因为会影响实机推理的精度和速度。第四阶段是板端部署把RKNN模型放在RK3566上加载写一个C控制程序按固定频率读取IMU和关节编码器数据把观测向量送入NPU推理得到动作输出再交给底层PID去执行。这四个阶段不是孤立的前一个阶段的输出格式和数值范围直接决定后一个阶段的工作量。比如训练时观测值如果没做标准化导出的ONNX模型层面的mean/std参数设置就会变得很麻烦又比如训练时如果用了LSTM这类带状态的结构导出时就要仔细处理隐状态的初始化和传递否则实机推理时策略会像失忆一样乱动。后面几章我会按这个链路顺序把每一环的具体做法和值得注意的细节展开。2. GPU端训练把行走能力训进模型2.1 仿真环境、算法与算力选型训练阶段是在英伟达GPU上完成的我用的是MuJoCo作为仿真器。选它是因为开源免费、物理精度足够、并且Python接口很干净。用PyTorch实现了PPO算法的完整训练脚本网上这类框架很多关键是结合Microduck的URDF模型文件搭建一个并行采样环境。为什么用PPO而不是SAC或者TD3主要原因是PPO在腿足机器人运动控制领域被验证得最多训练稳定超参数不那么敏感对奖励函数的噪声容忍度高。SAC虽然样本效率高一点但调Q函数和温度系数的时间成本不低对实机部署来说收益不明显。GPU选型方面我用的是一张RTX 3090。Microduck的仿真环境不算重单卡并行开4096个环境一张3090跑满大约能到每秒几万步采样。从零训练一个稳定的行走策略大约需要2000万到3000万步仿真数据实际墙钟时间大概三到六个小时取决于网络结构和并行环境数。如果你用的是2080Ti或者3060也完全能跑无非是多等几个小时。这里有个容易踩的坑很多人喜欢把并行环境数开得特别大以为采样快就一定好。但环境数越大每个batch的体验样本分布越杂PPO更新时策略梯度方差会变大反而可能导致训练不收敛。我自己的经验是4096个环境配2048的batch size是一个比较稳的起点。训练过程中还有一个常被忽略的点simulation timestep和control timestep的分离。MuJoCo里可以用dt控制物理步长用ctrl_timestep控制策略动作更新频率。我让仿真物理步长设为0.002秒策略控制周期为0.01秒即100Hz。这样的设置既贴近实机控制频率也让每个动作之间有足够的物理演化时间避免策略学到过于激进的振荡动作。2.2 观测空间、动作空间和奖励函数怎么设计强化学习运动控制的观测空间设计直接决定了实机部署的难度。Microduck的观测向量大概是这样的12个关节的角度和角速度加上IMU的机体角速度三轴数据、姿态四元数以及上一时刻的动作输出总共约35维。关节角度和角速度是部署时最容易获取的IMU数据需要滤波处理。这里建议训练时一定加入观测噪声噪声幅度不要太小因为实机传感器的噪声远比仿真大。如果你训练时用的是干净观测实机部署后策略会表现得非常急躁关节输出会频繁抖动。动作空间我选择的是12个关节的目标位置偏移量需要在训练时定义好关节位置的上下限和初始零位。这里有一个重要的设计决策动作不直接输出关节力矩而是输出目标位置。原因有两点。第一25厘米级别的Microduck用的是带位置闭环的串行总线电机底层本身就有PID位置控制器直接输出目标位置能和电机驱动协议无缝对接。第二底层PID能帮强化学习策略兜底把高频的力矩波动平滑掉相当于白送了一层滤波这对部署稳定性非常关键。在后面的部署章节我会再展开这个两层控制结构。奖励函数是训练中最耗时间的部分。我的设定包含几个分量速度跟踪奖励、机体姿态稳定惩罚、关节动作平滑惩罚、以及能耗惩罚。速度跟踪奖励用来鼓励策略跟随期望的前向速度指令姿态稳定惩罚用来避免机体过度倾斜动作平滑和能耗惩罚则用于抑制高频抖动。权重需要反复试经验是姿态惩罚和平滑惩罚的权重不能太小否则策略会找到一种快速但剧烈抖动的局部最优解仿真里看着能走实机上一落地就震得传感器满量程。2.3 训练收敛判断与策略导出训练是否收敛不能只看平均奖励曲线。在PPO训练里reward曲线常常是振荡向上的中期还会出现断崖式下降这通常是策略探索到了不稳定的参数区域。我的判断标准是两条一是平均episode长度稳定在目标步数附近说明策略很少跌倒二是观测空间内随机采样若干组初始状态策略都能恢复到稳定姿态。第二条非常实用如果策略只能从固定初始姿态启动那实机几乎不可能复用。模型导出阶段需要特别小心。训练时的Actor网络通常包含噪声采样层、值函数分支、甚至LSTM隐状态导出ONNX时要只保留推理路径。我的做法是重新定义一个新的forward函数输入维度为[batch, obs_dim]输出是[batch, act_dim]然后把训练好的state_dict加载进去。如果包含LSTM需要处理隐状态参数我建议部署第一版时干脆不用RNN结构纯MLP策略网络已经能实现稳定的行走等基础流程跑通后再考虑加时序建模。导出ONNX时固定batch维度为1并手动验证几个已知输入的输出值确保和PyTorch结果一致。这一步如果省略后面RKNN转换时出现问题会很难定位是转换错误还是网络结构错误。3. RK3566实机部署从模型到关节3.1 硬件资源评估与控制线程设计RK3566的硬件资源说强不算强说弱也完全够用。四核Cortex-A55的CPU不做重活NPU处理INT8模型则是强项。我的Microduck策略网络是一个三层MLP每层128个神经元激活函数用ReLU。转成INT8后模型文件大约几十KB在NPU上单次推理延迟实测稳定在2到3毫秒。这个数据是整条控制链路里非常重要的一项因为控制循环的周期抖动直接影响步态稳定性如果推理延迟忽高忽低策略输出的更新节奏就会乱。板端程序我分了三个线程。线程1是主控制循环绑定到CPU核心0负责读取关节编码器和IMU数据、拼装观测向量、触发NPU推理、解析输出并拼接控制指令目标周期是100Hz也就是10毫秒一帧。线程2绑定到CPU核心1负责和底层电机驱动的串口或者是CAN总线通信处理收包和发包。线程3绑定到CPU核心2负责日志记录和调试信息输出。核心3保留给系统内核和网络协议栈。线程绑核这个操作非常重要Linux默认调度器在四核CPU上会把线程来回迁移cache命中率变低控制循环的抖动可能从几百微秒恶化到几毫秒这对强化学习部署来说几乎是灾难。控制线程的基准时间用clock_gettime配合CLOCK_MONOTONIC来获取而不是gettimeofday因为前者不受系统时间跳变影响。我在每个控制周期开始和结束时都打一个时间戳把周期实际间隔记录到环形缓冲区里后续分析抖动就靠这份日志。3.2 RKNN模型转换与INT8量化模型转换是部署链路里技术细节最多的一环。我在x86主机上安装RKNN-Toolkit2然后用下面的脚本把之前导出的policy.onnx转为RKNN格式。from rknn.api import RKNN rknn RKNN() rknn.config( mean_values[[0.0, 0.0, 0.0]], std_values[[1.0, 1.0, 1.0]], target_platformrk3566 ) rknn.load_onnx(modelpolicy.onnx) rknn.build(do_quantizationTrue, datasetcalib_dataset.txt) rknn.export_rknn(policy.rknn)这里最值得展开的是do_quantizationTrue这一步。INT8量化不是简单把浮点权重转成8位整数它会根据校准数据集统计每一层激活值的数值范围然后映射到0到255或者-128到127的整数区间。校准数据集的质量直接决定量化后精度损失有多大。我在calib_dataset.txt里放了大约500条从仿真rollout中随机采样的观测向量注意不是随机噪声而是策略实际运行时可能遇到的状态分布。如果你只随便放几组零向量量化后模型输出会飘得离谱。量化后的模型在我的场景里精度损失并不大。我将同样的观测输入分别喂给原始ONNX模型和RKNN模型输出的动作向量最大偏差大约在0.03到0.06弧度范围内。考虑到底层PID本身有容错能力这个误差可以被吸收。但如果你发现量化后机器人步态明显变差有几个备选方案将某些敏感层保留为float16使用per-channel量化或者干脆降低量化强度。RKNN-Toolkit2里支持量化层级设置可以逐层指定量化类型只对那些输出分布特别集中的层用更高精度其余层继续INT8。这种半量方案能在精度和速度之间找到更好的平衡点。3.3 两层控制结构策略做决策PID做执行强化学习策略在RK3566上以100Hz运行但关节电机的位置闭环频率要求要高得多。Microduck用的串行总线电机内部有位置环但响应带宽通常有限如果直接用100Hz的目标位置去驱动电机会出现明显跟踪滞后。所以在实机上我采用了经典的两层控制结构强化学习策略作为上层输出目标关节位置底层每个关节的PID控制器以500Hz左右高频运行去逼近这个目标。这个设计和基于强化学习的PID控制思路有个明显区别。后者是用强化学习去在线调整PID参数或者直接让策略输出力矩替代PID而我的方案是强化学习负责决策PID负责执行两者分工明确。这样做的好处是策略不需要感知电机内部的非线性特性比如死区、饱和、温度导致的力矩下降这些都由底层的PID闭环去补偿。坏处是策略动作被限制在了目标位置空间无法输出超出自定义范围的复杂力矩轨迹但对于Microduck这种小尺寸机器人这个限制影响很小。底层PID三个系数的整定也有讲究。我先把策略输出固定为零位让机器人保持默认站姿手动调节三关节的PD参数让电机能够快速响应小幅位置指令而不振荡。然后再接通策略模型。如果在接通策略后出现高频抖动优先检查策略输出的速率限制而不是去调PID。我最初没有做动作限幅策略每帧输出一个很大的位置跳变底层PID拼命追整台机器人就像抽搐一样。后来在策略输出后加了一阶低通滤波并且限制每帧最大变化量步态立刻稳定了一个量级。3.4 25厘米机体的供电、散热与机械配合实机部署里还有一个很容易翻车的地方供电。RK3566开发板本身功耗不大但加上12个电机同时启动、瞬时电流达到几安培如果电池内阻大或者电源模块压降明显NPU推理时的电压跌落会导致主控复位。我的处理方式是用一块2S锂电池供电主控和电机驱动分开供电避免电机大电流波动影响到逻辑电路。如果你用的是一体化供电设计至少要在电机驱动器输入端加一个大容量电解电容做缓冲否则跑不到两分钟就会随机重启。散热方面RK3566开发板在Microduck机身上通常是竖着安装通风条件不如桌面测试环境。我实测连续运行半小时后NPU温度会升到70度左右虽然芯片规格说可以到85度但高温会让NPU自动降频推理延迟从2.5毫秒慢慢涨到4毫秒以上。解决办法很朴素在RK3566上加一个小尺寸散热片和5V风扇温度能压到50度以内推理延迟全程稳定。机械配合上最容易忽视的是电机的安装方向和关节零位。仿真URDF里默认的关节零位是理论上的中位但实机装配时每个电机的中位都会有一点偏差。我写了一个校准程序上电后先把所有关节缓慢运动到机械限位再读取编码器值作为零位基准把这个零位偏移量保存在板端配置文件里。如果跳过这一步直接加载模型策略观测到的关节角度和仿真里的语义不一致再好的训练结果也跑不稳。4. Sim-to-Real迁移仿真里能走地上也能走4.1 为什么仿真策略直接落地一定会摔仿真里的物理模型再精确和现实之间也有一条宽到离谱的鸿沟。摩擦系数仿真里永远是个常数现实中地面材质、灰尘、湿度都会改变接触特性仿真电机的响应模型是理想的一阶系统现实电机有延迟、有死区、有温度漂移仿真的IMU数据是干净的实机IMU信号里混着电机带来的大幅度电磁噪声。这些差异累积起来会让一个在仿真里成功率99%的策略在实机上从第一步开始就走形。我第一次把训练好的模型直接部署到Microduck上时机器人启动站姿还算正常一旦给速度指令前几步还能跟住然后右前腿突然抬得很高紧接着整个机体往左侧翻倒。回看遥测数据策略输出的关节命令在某个时刻出现了明显的跳变。原因就是实机观测到的机体姿态噪声比仿真训练时大很多策略误判为机体即将失稳输出了激进的补偿动作。这种问题就是典型的sim-to-real gap需要通过训练阶段的扰动注入和部署阶段的信号处理共同解决。4.2 域随机化提前把现实世界的方差加进训练域随机化是解决sim-to-real gap最有效的手段之一做法是在训练时随机改变仿真环境里的一部分物理参数让策略见过各种世界版本而不是只在理想参数下过拟合。我的MuJoCo训练脚本里对四组参数做了随机化关节摩擦系数在0.8到1.5倍之间均匀采样机体质量在0.9到1.1倍之间变化模拟不同电池电量下的重量差异电机控制延迟从0到20毫秒随机抽取模拟通信和底层执行延迟IMU观测噪声也随机放大和缩小。这里的关键是随机化的幅度要把握好。太小起不到泛化作用太大策略会觉得环境不可控最后学到的动作会变得保守迟钝。我的经验是先从15%的扰动幅度开始观察训练curve如果收敛速度明显变慢就降到10%如果实机测试仍然失败就提到20%。另外不要一次性把所有参数都随机化建议逐个加这样你能知道到底是哪个参数对实机稳定性影响最大。除了域随机化训练时给动作指令添加一个低频正弦干扰也能显著提升策略的抗扰能力。我让期望速度指令在每个episode里按照正弦变化幅值和频率都随机这样策略必须学会连续跟踪动态目标而不是只学会一个恒速行走的反射。实机上切换速度模式时能明显感觉到策略的适应能力变强了。4.3 实机联调顺序与遥测分析实机联调绝对不能一上来就放开跑。我的顺序是第一步不通电手动检查所有关节的自由度和运动方向确保电机方向与仿真一致。第二步通电但移除策略只运行底层PID和关节位置闭环让每个关节都保持初始姿态观察电机是否平稳、有没有异常发热。第三步加上策略但把输出路径屏蔽板端程序照常推理打印输出到日志对比实测输出和仿真环境的输出分布。第四步挂上安全绳让策略真正控制机器人首先只测试站立和缓慢原地转向不前进。第四步如果稳定才开始测试前进、后退和避障。整个过程最少要给一天时间慢慢观察。遥测数据在这期间是最重要的排障依据。我在RK3566板端记录每一帧的时间戳、观测向量前几维、策略输出、底层PID误差和IMU原始数据通过无线串口或局域网实时传回电脑。实测中遇到步态不稳时先打开遥测log看控制周期是否抖动再看策略输出有没有高频振荡最后看IMU信号是否含大量尖峰这样能快速定位问题层次。我遇到过一种比较隐蔽的情况控制周期在整体上稳定在10毫秒但每隔几十帧会出现一次20毫秒的突发延迟正好和某个后台线程的调度周期重合。这种问题光看平均延迟发现不了要画出周期间隔的时间序列图才能看到规律性的尖峰。后来把日志线程的调度优先级调低并且挪到另一个核心上这个问题就消失了。所以说遥测分析不是可有可无的它直接决定了你能在多少小时内把步态问题收敛掉。5. 常见问题与排查技巧实录5.1 模型导出和RKNN转换阶段的问题这个阶段我踩过最典型的坑是ONNX整形操作不被RKNN支持。训练好的PyTorch模型里有一些动态shape的reshape比如view(-1, ...)或者基于张量形状的条件分支这些在PyTorch里没问题导出ONNX后RKNN-Toolkit2就报unsupported operator或者干脆构建失败。解决办法是先跑一遍onnx-simplifier多数动态shape会被重写成静态shape。如果还不行就要手动修改网络定义把所有reshape都改成静态维度。另一个高发问题是校准数据集与实际部署时的数据分布不一致。我在早期用一种随机姿态采集校准数据量化后的模型在实机上输出偏差很大动作幅度明显被压缩。排查后确认是量化时激活值的截断阈值不合理把原本分布在边缘的极端值全截断了。后来校准数据改成从训练好的策略rollout中采样这个问题就好了。这里有个经验校准数据集宁多勿少500条起步要覆盖站立、行走、转弯、遇到扰动这几种典型状态。RKNN的板端运行时版本和工具链版本不匹配也会导致启动异常。我的主机上用的是RKNN-Toolkit2 1.6版本板端librknnmrt.so也是对应版本。如果你换了一块预装旧版固件的开发板记得先升级板端运行时库否则模型加载时可能报版本错误也可能静默加载成功但推理结果完全不对。5.2 实机控制与步态问题排查实机常见的步态问题无非三类原地抖动、前进偏航、走着走着摔倒。原地抖动通常是策略输出频率和底层PID带宽不匹配或者动作限幅太紧。你把策略输出的动作曲线拉出来看如果相邻帧之间变化量已经超过限幅值说明策略在试图做高频调整这时候优先考虑增大姿态惩罚权重重新训练而不是盲目调PID。PID只能帮你平滑执行不能消除策略本身的不稳定指令。前进偏航问题多数出在左右两侧关节零位不一致或者机械装配的对称性上。可以先做一次静态校准把机器人悬空让所有腿伸直检查左右两侧关节角度是否存在固定偏差。如果偏差很小那么偏航可能来自策略在仿真里没有见过不对称的摩擦条件这时候可以适当增加横摆方向的动作惩罚或者在训练时加入一个小的随机横向推力扰动。走着走着摔倒的问题最复杂需要结合遥测看是哪个环节先崩溃。如果控制周期保持稳定那就是观测空间里某些维度存在明显的噪声尖峰比如IMU角速度在电机换向时出现毛刺。处理方法通常是在IMU数据接入策略之前做一个滑动窗口滤波或者使用互补滤波把加速度计和陀螺仪融合后再送入模型。这里有个细节滤波会增加信号延迟如果延迟超过一个控制周期需要把这个延迟加入训练时的观测延迟模拟中否则策略会变得不稳定。5.3 问题速查表与避坑清单现象可能的根因推荐处理策略模型加载失败RKNN-Toolkit版本与板端运行时不对应统一工具链版本升级librknnmrt.so部署后动作幅度变小INT8量化激活截断设置不合理重新采集校准数据覆盖真实状态分布控制周期偶发抖动日志线程抢占CPU线程绑核降低日志线程优先级电机启动后主控复位电机大电流拉低逻辑供电电压主控与电机分离供电加大电容步态高频抖动策略输出未限幅或底层PID带宽过高限制动作变化率适当降低PID增益前进时持续偏航关节零位不对称重新做机械零位校准检查左右安装方向实机表现明显不如仿真域随机化幅度不足或没有建模电机延迟增加摩擦、质量、延迟、观测噪声随机化训练曲线不收敛并行环境数过大导致样本分布过散减小环境数和batch size适当降低学习率上面这张表基本覆盖了我这一路遇到的九成问题。如果你也在做类似项目建议把这些问题和排查方法抄下来贴在工位上能省不少时间。5.4 几个容易被忽略的小细节最后分享几个容易踩但很少被写在教程里的细节。第一个RKNN的输入数据格式要求通道维度在前而且数据在内存中是连续的。如果你在板端用Python做推理可能会被numpy数组的stride坑到用C接口时建议直接用连续内存拷贝观测数据不要做转置或者切片否则延迟会异常升高。第二个RKNN模型加载后的输入输出缓冲区最好复用同一块内存用rknn_query获取输入属性后用malloc分配一次后面每次推理只更新数据内容不再反复分配。这个优化能省掉大约20%到30%的推理开销。第三个IMU的安装方向和数据坐标系要和仿真完全一致。我的Microduck在仿真里IMU的z轴是竖直向上的但实机安装时由于固定片设计问题IMU方向差了180度导致策略读到的姿态一直是反的机器人从第一次上电就试图用脚去够天花板。排查了很久才发现是坐标系没对齐。这个教训是实机联调之前一定要用一个已知姿态去验证IMU数据的方向和量纲。第四个安全措施永远不要省。我在调试过程中至少三次靠安全绳救回了机器人如果没有任何保护一根舵机臂或者一块PCB可能就报废了。调试时把速度指令的初始值设为零通过一个独立的遥控按钮来逐步增加速度不要直接让策略自主跑这些看似底层的习惯能让你在调试强化学习机器人时少损失很多钱。说实话把这些所有细节都整理到一起我才意识到一个25厘米的小机器人的强化学习部署工作量一大半都花在了仿真和现实的这条边界上。每一次重新训练、每一版模型导出、每一行板端控制代码都是在缩小这条边界上的误差。如果你也正在做类似的事情希望这篇手记能让你少踩几个我已经踩平的坑。