企业官网建设流程全解析

1. 关节物体为什么是仿真里的一道坎

Orbit 使用指南里“与关节物体交互”这一节，我前后翻了很多遍，也踩了不少坑。简单说，关节物体（articulated object）就是那种由一个根刚体带一串子刚体、彼此通过旋转或滑动关节连接起来的物体——抽屉、柜门、微波炉门、冰箱、打印机盖板、垃圾桶翻盖，都属于这一类。Isaac Sim 和 Omniverse 平台上做机器人操作仿真，绕不开它们。弄清楚这套流程能干什么：让机械臂在仿真里把一个抽屉真正拉开、把一扇柜门真正推开，而不是对着一个焊死的方块假装在做事。适合谁看：已经能在 Orbit 里跑通单臂抓取、想让场景从“桌上的方块”升级成“家用电器”的同学，以及正在给操作类任务搭训练环境的工程师。

为什么单拎出来讲？因为在纯刚体场景里，物体要么不动，要么整体飞出去，物理表现相对单纯。一旦引入关节，整个系统的自由度、约束链、接触对数量都会发生量级变化。机械臂去拉抽屉，力从夹爪传到把手，把手是抽屉面板上的一个凸起，面板和滑轨之间是移动关节，滑轨和柜体之间是固定连接，柜体又要固定在世界坐标系上——这条链路里任何一环参数不对，现象都是“拉不动”或者“飞了”，而且这两种现象背后的原因可能完全相反。所以这一篇我不打算只贴配置，而是把每一层为什么这么设讲清楚。

我个人的经验是：关节物体任务的调试时间，大概有六成花在资产和物理参数上，只有四成花在控制与策略上。很多人一开始就想上强化学习，结果训练几万步发现机械臂在门口反复横跳，最后定位到原因是柜体没锁死、整个柜子在跟着漂。这类问题不看现象背后的物理链路，是很难靠调超参救回来的。

1.1 从自由刚体到带约束的运动链

先把这个概念掰开。一个自由刚体在物理引擎里有 6 个自由度：3 个平移、3 个旋转。一个关节物体，假设是一个带一扇门的柜子，门相对柜体只有一个旋转自由度，那么整个系统的活动自由度就是 6（柜体）+ 1（门）= 7，但受约束的自由度远不止这些。PhysX 在求解时会把这些约束转成一组约束方程，和接触约束一起进同一个求解器迭代。

这带来两个直接后果。第一，求解器的迭代次数变得更敏感。原来一个只有接触的场景，position iteration 给 4 可能就够；加了关节之后，尤其是多个关节串联，4 次迭代经常解不开，表现就是关节看起来“软”，或者门被推着走的时候有一段延迟。我一般会把 position iteration 提到 8 到 16，velocity iteration 给 1 到 4，具体看链长。

第二，质量比变得致命。夹爪是个几公斤的刚体，柜门可能只有 0.3 公斤，柜体如果是动态的、几十公斤。约束求解对质量比很敏感，超过一两百比一就容易抖。所以关节物体的根节点，除非你就是要模拟“柜子被推着走”，否则一律固定。这一条是后面所有配置的前提。

还有一个容易被忽略的点：关节的驱动（drive）在 PhysX 里本质上是一个 PD 控制器，它输出的力有上限。默认上限往往很小，你给了目标位置，关节却纹丝不动，不是配置没生效，是 max force 卡住了。这一点在滑动关节上尤其明显，因为滑轨方向的摩擦力加上负载，很容易超过默认值。

1.2 Orbit 在这类任务里的角色分工

Orbit 这层的价值，是把 Isaac Sim 里那堆又长又散的 USD 路径、物理 API、传感器读取包装成声明式的配置对象。你写一个ArticulationCfg，里面塞UsdFileCfg、ArticulationRootPropertiesCfg、刚体属性、碰撞属性，然后在环境里声明scene.articulation["cabinet"] = CABINET_CFG.replace(prim_path=...)，它负责把资产引用进来、设置物理参数、在克隆环境时给每个环境复制一份。这套抽象对多环境并行训练非常关键，因为你不想手写循环去给 4096 个环境逐个设参数。

分工上我一般这么划分：USD 层面负责几何、材质、关节轴与限位这些“静态事实”；Orbit 配置层负责物理参数、初始状态、随机化范围这些“运行期策略”；任务脚本层负责控制器、奖励、终止条件。三层混着改会很痛苦，因为一旦发现问题，你不知道是资产本身有毛病还是配置写错了。我吃过这个亏，后来养成习惯：先在 Isaac Sim 的图形界面里单独把这个 USD 加载出来，手动拖一拖门，看关节转得顺不顺，确认资产没问题再进 Orbit。

这个“先 GUI 后代码”的顺序值得强调。USD 里的关节轴朝向错误、限位设反、局部坐标系原点偏移，这些问题在代码里表现为“门往奇怪的方向转”，你会怀疑控制器；但在 GUI 里用鼠标拖一下就一眼看出来了。省下来的时间远超你多花的那十分钟。

2. 资产准备：从哪里拿关节物体，怎么判断能不能用

2.1 三种常见来源与取舍

关节物体的来源大致三类，各有各的坑。

第一类是仿真平台自带的资产库。这类资产的优势是已经按仿真规范做好了碰撞体、关节轴和物理属性，加载就能用。缺点是种类有限，风格统一，而且往往是“通用家电”那一套，做特定任务的定制化程度不够。我建议新手期全部用这类资产把流程跑通，别一上来就自己建模。

第二类是从三维模型网站下载的家具模型。这类模型的通病是“只有皮没有骨”——视觉网格很漂亮，但完全没有关节定义，甚至连碰撞体都没有。你得自己在 USD 里给它加PhysicsArticulationRootAPI，手动摆关节轴的位置和朝向，再给每个刚体配凸包或者简化碰撞体。工作量不小，但可控性最高。我做过一个带三层抽屉的床头柜，光是把三个抽屉的滑动轴对齐就花了一个下午，因为原模型的面板不是严格平行的。

第三类是扫描重建或自己用 CAD 导出的模型。这类模型几何精度高，但三角面数往往爆炸，直接拿来做碰撞体，物理仿真会慢到没法用。必须做碰撞简化，通常保留每个刚体一个凸包（convex hull）就够了，复杂的凹形结构用几个凸包拼。

选型上的判断标准，我看三条：一是有没有明确的关节定义，没有的话评估一下手动加的工作量；二是碰撞几何能不能简化到可接受的面数，单刚体超过几百个三角面就该考虑凸包了；三是尺寸和质量的量级是否合理，有的模型导出时单位是厘米，进来之后抽屉有几百米大，物理引擎直接崩。

提示：单位问题比想象中普遍。USD 默认单位是厘米，但很多 Orbit 配置里的物理参数是按米写的。资产进来之后先用包围盒量一下尺寸，和真实物体的尺寸对一对，差一个数量级就赶紧改缩放，别带着错误的尺度往下调参数。

2.2 入场前的五项体检测试

在把资产接进 Orbit 之前，我有一套固定的检查清单，五条，全部过一遍再往下走。

第一条，关节轴对不对。在 GUI 里选中关节，看它的可视化轴是不是沿着你预期的方向。旋转关节的轴要沿着门的转轴，滑动关节的轴要沿着抽屉的滑轨方向。轴错了，后面所有控制都是白费。

第二条，限位有没有。门开到 90 度会撞到柜体，抽屉拉出 40 厘米会掉出来。物理引擎不会自动帮你判断这些，你得给关节设 lower 和 upper limit。限位不设的后果是门能转 360 度穿过柜子，训练出来的策略会利用这个漏洞，做出人类根本做不出来的动作。

第三条，根节点固定。选中柜体根节点，确认它是 kinematic 或者通过固定关节连到世界。这一步不做，你拉抽屉的时候整个柜子会跟着滑走。

第四条，碰撞体存在且不重叠。打开碰撞体显示，看每个刚体是不是都有碰撞几何。常见问题是面板有碰撞、把手没有，结果夹爪直接从把手上穿过去。另一个反向问题是相邻刚体的碰撞体重叠，比如门和柜体在闭合状态下互相嵌入，物理引擎一开始就会把它们猛烈弹开。

第五条，质量和惯量合理。抽屉面板 0.5 到 1 公斤，柜体 20 到 50 公斤，这些数量级要大致对。惯量如果是自动算的，检查一下有没有因为网格原点偏移导致惯量离谱。

这五条我写在便签上贴在显示器边，每次换资产都过一遍。听着啰嗦，但比在训练日志里对着不收敛的曲线猜原因高效得多。

3. 把关节物体接进 Orbit 场景

3.1 USD 引用层级与 Articulation 根节点

Orbit 里加载资产的入口是AssetBaseCfg和ArticulationCfg。两者的区别值得说清楚：前者是普通刚体资产，后者是带关节的资产，后者会额外绑定一个Articulation对象，提供关节位置、速度、力矩这些接口。

配置的骨架大概长这样：

import omni.isaac.orbit.sim as sim_utils from omni.isaac.orbit.assets import ArticulationCfg CABINET_CFG = ArticulationCfg( prim_path="/World/envs/env_.*/Cabinet", spawn=sim_utils.UsdFileCfg( usd_path="/path/to/cabinet.usd", activate_contact_sensors=True, rigid_props=sim_utils.RigidBodyPropertiesCfg( disable_gravity=False, max_depenetration_velocity=5.0, ), articulation_props=sim_utils.ArticulationRootPropertiesCfg( enabled_self_collisions=False, solver_position_iteration_count=16, solver_velocity_iteration_count=4, fix_root_link=True, ), ), init_state=ArticulationCfg.InitialStateCfg( pos=(0.0, 0.0, 0.0), joint_pos={"drawer_joint": 0.0, "door_joint": 0.0}, ), )

几个参数掰开说。prim_path里的env_.*是给多环境克隆用的通配路径，Orbit 会在每个环境实例化一份。这点很多人第一次写会漏，写成绝对路径，结果只有一个环境有柜子，其他环境空空荡荡，训练时机械臂在空气里抓。

enable_self_collisions我一般关掉。关节物体自碰撞的收益很小，但代价很大：相邻刚体在闭合状态本来就容易重叠，开了自碰撞会持续产生穿透修正力，表现为物体一直在抖。除非你的任务明确需要自碰撞（比如门关上时要和柜体产生接触），否则关掉更稳。真要判断门是否关上，用关节位置判断就行，不需要靠碰撞。

fix_root_link=True是这节的关键。它把根刚体固定在世界上，防止整个柜子被拖着走。但注意它固定的是“根链路”，如果你的 USD 里根节点选错了（比如把抽屉面板选成了 articulation root），那固定住的会是抽屉，柜体反而乱跑。选 root 的原则是：选那个支撑整个物体的、不应该动的部件。

init_state.joint_pos用来设初始关节位置，键名是 USD 里的关节名，要和资产里一致。写成空字典也能跑，但那意味着初始位置用 USD 里的默认值，你不一定知道那个值是多少，调试时会增加不确定性。

3.2 关节驱动参数的取值思路

驱动参数是这一节最容易拍脑袋的地方。PhysX 里关节驱动的模型是一个 PD 控制器：给定目标位置，输出力矩 = stiffness ×（目标 − 当前）− damping × 当前速度，然后被 max force 截断。三个参数各有各的物理含义。

stiffness（刚度）决定关节“多想回到目标位置”。设得太小，关节软绵绵，你给了目标位置它慢悠悠转过去，甚至转不到；设得太大，配合小的仿真步长会震荡发散。我的经验起点：滑动关节给 1e3 到 1e4 量级，旋转关节给 1e3 到 1e4，具体看负载。抽屉拉开需要克服滑轨摩擦和自身质量，刚度要给够。

damping（阻尼）决定关节“多想停下来”。阻尼不足的典型现象是门开到目标角度后来回弹几下，过冲明显；阻尼过大的现象是动作迟滞，像在糖浆里运动。经验值取刚度的 1% 到 10%，先取 5% 试，再看响应曲线调。

max force（最大力）是截断阈值，也是“关节不动”问题的头号嫌疑人。门槛原则：算一下你需要多大力量。假设抽屉质量 1 公斤，滑轨摩擦系数 0.3，拉动所需力大约 3 牛；再留三倍余量，给 10 牛。如果你设了 1e3 结果还是不动的，问题就不在 max force 上了。

仿真步长和这些参数是耦合的。仿真 dt 越小，刚度可以给得越大而不震荡。我常用 1/120 秒的物理步长配合控制频率 30 赫兹，也就是每个控制周期跑 4 个物理步（decimation=4）。如果 dt 给到 1/60，刚度上限大概要砍一半。这个换算没有精确公式，靠试，但方向是明确的。

关节摩擦（friction）也值得单独提。滑动关节的 friction 模拟的是滑轨阻力，设成 0.1 到 0.5 比较像真实抽屉；设成 0 会得到一个“悬浮抽屉”，轻轻一碰就滑出去，训练出来的策略在真机上完全失效。旋转关节的 friction 模拟铰链阻尼，0.5 到 2 之间，门会比较“有分量”。这些值的意义不只是好看，它们直接决定了策略需要输出多大力，是真机迁移的重要一环。

3.3 用代码读取与校验关节状态

配置完别急着训练，先写几行代码把关节状态读出来看看。校验的价值在于：你能确认关节名、数量、限位、初始位置都和预期一致，避免训练跑了几小时才发现关节名拼错了（这种情况下 Orbit 往往不报错，只是那个关节一直不动）。

cabinet = scene.articulations["cabinet"] print("num joints:", cabinet.num_joints) print("joint names:", cabinet.joint_names) print("joint limits:", cabinet.root_physx_view.get_dof_limits()) print("initial pos:", cabinet.data.joint_pos)

顺带说一句，joint_names的输出顺序和你在配置里写字典的顺序不一定一致，索引访问要用joint_names.index("drawer_joint")拿位置，别硬编码数字。这个坑我踩过，一开始按字典顺序写死了索引 0，换了个资产之后关节顺序变了，控制指令打到了错误的关节上，现象是“拉抽屉结果门开了”，排查了半天。

校验还可以加一步：手动给一个关节目标位置，跑几十个物理步，看关节能不能到位。

import torch idx = cabinet.joint_names.index("drawer_joint") target = torch.zeros(cabinet.num_instances, 1, device="cuda") target[:] = 0.15 # 目标 15 厘米 cabinet.set_joint_position_target(target, joint_ids=[idx]) for _ in range(60): sim.step() scene.update(sim.get_physics_dt()) print(cabinet.data.joint_pos[:, idx])

如果读出来的位置在 0.15 附近，说明驱动链路是通的，可以进下一步；如果一直在 0 附近，回头查 max force 和 stiffness；如果数值发散，查步长和刚度是否过大。这个十行的测试，我建议固定成一个脚本，每次换资产都跑一遍。

4. 交互控制：让机械臂真的把门拉开

4.1 抓取判定的三种实现路线

关节物体交互的核心难点在于“抓得住”。机械臂末端是个两指夹爪，把手是直径两厘米的圆柱，理论上靠摩擦就能夹住，但仿真里摩擦接触的稳定性远不如现实，夹爪稍微偏一点就滑。

我在实际项目里试过三条路线，各有适用场景。

路线一：刚性固定约束。当夹爪进入把手的判定半径，直接在两个刚体之间创建一个固定关节，把它们的相对位姿锁死；松开时销毁这个关节。优点是极其稳定，绝不会滑脱，抓取瞬间的物理跳变也小。缺点是“假”——它绕过了摩擦和接触，策略学到的是“靠近就有奖励”，而不是“需要正确施力”。适合流程打通阶段和奖励设计的早期验证。

路线二：表面抓取近似。Isaac Sim 提供表面抓取这类功能，本质也是固定约束，但带一个基于距离和面的判定逻辑。稳定性接近路线一，代码上更干净一些，但可控性略差。

路线三：真实摩擦夹爪。完全靠接触和摩擦，最接近真机。需要把夹爪指面的摩擦系数调到 1.0 以上，接触刚度调合适，夹持力给够。优点是策略迁移性好，缺点是调参痛苦，且训练早期成功率极低，需要配合课程学习。

我的建议是分阶段：先用路线一把整个环境、奖励、终止条件跑通，确认机械臂能走到把手、能拉开、关节位置能正确读取；然后把路线一换成路线三，看策略还能不能学会。换的时候通常需要调整奖励的形状，因为路线三需要“先对准再夹紧再拉”这样更长的动作序列。

路线三还有两个容易被忽略的细节。一是夹爪指面的碰撞体要单独设材质，摩擦系数写在材质上而不是刚体属性上，很多人找不到地方。二是夹持力的上限要够，两指夹爪的驱动默认力往往只有几十牛，夹一个光滑圆柱会打滑，得往上提。

4.2 抓取后的关节目标控制

抓住之后怎么拉？这里有两种思路，效果差别很大。

思路 A：直接控制关节。抓住之后，不控制机械臂末端，而是直接给被抓住的门或抽屉一个关节目标位置，让它以预设速度打开。这在仿真里能跑，但本质上是“物体自己在动”，机械臂只是挂着。如果你关心的是物体轨迹而不是机器人动作，这种方法简单可靠；但如果要做策略学习，它会污染动作空间，学出来的策略在真机上无效。

思路 B：控制末端轨迹，让物理去解关节。给末端执行器一个笛卡尔空间的轨迹或者速度指令，机械臂通过自己的关节控制器跟随，末端带着把手走，把手通过约束带动门旋转。这是正确但困难的路线，难点在于末端轨迹必须落在门的圆弧上——你让末端走直线，门只能开一小段就卡住，然后接触力暴涨，整个系统弹飞。

处理办法是加一个“顺应性”：不要用刚性位置控制，用导纳控制或者简单的阻抗控制，让末端在遇到阻力时能偏离参考轨迹。具体做法是降低末端位置控制的刚度和提高阻尼，或者在笛卡尔指令上叠加一个基于接触力的偏移。实操上，我通常先把轨迹直接按门的圆弧算好（前提是知道转轴位置和半径），这样阻力小很多，再逐步过渡到直线指令加阻抗控制。

圆弧轨迹的计算不复杂：知道门转轴在世界系的位置 p_axis 和方向 n，把手初始位置 p0，目标开角 θ，把 p0 绕轴旋转 θ 得到目标点。半径就是 p0 到轴的垂距。真实场景里不知道轴在哪，所以长期方案还是靠顺应性控制，或者干脆把“轴位置”作为域随机化的一部分，让策略学会不依赖精确模型。

4.3 在 Orbit 里封装成可训练的任务

环境封装这块，Orbit 的ManagerBasedEnv体系把事情分成了几个 manager：观测、动作、奖励、终止、课程、随机化。关节物体的任务，各个 manager 的关注点不一样。

观测里要有：机械臂关节位置速度、末端位姿、关节物体的关节位置（这一个最关键，策略需要知道门开到了多少）、以及可选的门板法向或者把手相对末端的位置。门开度这个观测项，用joint_pos的相对值比绝对值好，因为不同环境的初始位置可能不同。

动作一般是末端增量位姿加夹爪开合，维度 7。如果直接控关节，维度会高很多，训练难度上升。这一点上，笛卡尔增量动作配合阻抗底层是主流做法。

奖励的设计我拆成四项：接近奖励（末端到把手的距离，用指数衰减形式）、抓取奖励（夹爪闭合且距离小于阈值给个常数）、进度奖励（关节位置相对初始值的变化量，这一项是核心）、成功奖励（关节位置超过阈值给一次性大奖励）。进度奖励的尺度要小心，关节位移从 0 到 0.2 米，如果每步都给全额，累计奖励会远超其他项，策略会为了“多走几步”而故意慢慢拉。我的做法是进度奖励用每步增量而不是绝对位置，这样总奖励和最终开度成正比，和路径长短无关。

终止条件里要有：关节位置超过目标（成功）、末端偏离过远（失败）、超时。终止条件设错会导致训练不稳定，比如只设超时，策略学会“磨到最后一步”而不去完成目标。

课程对这类任务几乎是必需品。最直接的两个课程维度是初始门缝宽度（从开着的 20 度开始，逐步收到完全关闭）和把手位置随机范围（从小范围到大范围）。前者让策略先学“拉开”，再学“拉开锁着的”，后者提升泛化。

def _reward_joint_progress(self): cur = self.cabinet.data.joint_pos[:, self._drawer_idx] delta = cur - self._prev_joint_pos self._prev_joint_pos = cur.clone() return torch.clamp(delta / 0.01, -1.0, 1.0)

上面这段是增量式进度奖励的实现要点：除以一个尺度做归一化，再 clamp 防止单步突变给炸奖励。_prev_joint_pos要在每个 episode reset 时同步重置，忘了重置会得到跨 episode 的错误奖励，表现为训练曲线莫名其妙地周期性抖动。

5. 训练稳定性：域随机化与参数调优

5.1 该随机化什么，不该随机化什么

域随机化的目的是让策略不依赖精确模型参数。关节物体任务里，我觉得值得随机的有四类。

质量与惯量。质量给 ±20%，惯量跟着缩放。这一项能让策略不依赖“这个抽屉刚好一公斤”这种先验，对真机迁移帮助明显。

摩擦系数。把手与夹爪之间的摩擦给 0.5 到 1.5，滑轨摩擦给 0.1 到 0.6。摩擦是仿真和真机差距最大的参数之一，不随机化的话，策略在真机上会因为打滑直接失败。

关节阻尼与限位。阻尼 ±50%，限位给 ±5%。限位随机化容易被忽略，但真机上不同柜子的开合角度确实不一样。

把手位置与尺寸。位置 ±1 到 2 厘米，半径 ±20%。这是提升泛化最有效的一项，因为它直接改变了抓取的几何条件。范围要逐步放大，一开始太大策略学不会。

不该随机化的东西，我的看法是：关节轴的朝向别随机，那是资产的固有属性，随机了等于让策略去适应一个不存在的物理世界；传感噪声也别在一开始就加，会掩盖真实的问题。

还有一点，随机化的范围要和你的课程进度绑定。一上来就把所有参数拉满，策略在绝大多数环境里都失败，梯度信号全是噪声。我一般分三档：第一阶段只随机初始关节位置，第二阶段加质量摩擦，第三阶段全开。

5.2 求解器与并行规模的实测取舍

物理求解器的参数对训练速度影响很大，值得单独算一算。

每个环境的物理步耗时，大致和接触对数量、约束数量成正比。一个柜子加一个七自由度机械臂，接触对可能几十个，约束上百个。4096 个环境并行，每步的求解压力不小。我的实测经验是：把solver_position_iteration_count从 8 提到 16，单步耗时大概增加 20% 到 30%，但抓取失败率下降明显，总体训练效率是提升的。相反，把 velocity iteration 从 4 提到 8，收益很小，不值得。

环境数量上，关节物体任务比纯刚体任务吃显存和算力，我一般在 1024 到 2048 个环境之间找平衡。少于 1024 梯度噪声大，多于 2048 单步变慢太多，且策略更新频率下降。

decimation 的设置也值得说。控制频率 30 赫兹、物理步 120 赫兹，decimation=4。如果控制频率提到 60 赫兹，动作序列变长一倍，训练难度上升但控制精度提高。抽屉这种大位移任务，30 赫兹够用；门的精细操作，比如拧把手，可能需要 60 赫兹。

6. 常见问题速查与排查路径

6.1 现象到原因的对照表

下面这张表是我自己整理的，把遇到过的现象和最后定位到的原因列在一起。按现象查比按原因想快得多。

表里最值得展开的是“一进场景物体就炸开”。这个现象酷似物理参数错误，但十有八九是几何问题：门在闭合位置和柜体面板的碰撞体重叠了几毫米，物理引擎为了分离它们，施加了巨大的穿透修正力。解决办法是把门在 USD 里往开的方向挪一点点，或者把 penetration 修正速度上限调低（max_depenetration_velocity）。后者治标，前者治本。

6.2 几个反直觉的坑

有几个坑我觉得反直觉，值得单独说。

坑一：关节能转，但读出来的位置一直是 0。这个现象让人以为驱动没生效，实际上是读取了错误的关节索引，或者读的是joint_pos而实际应该读joint_pos_target。还有一种情况是读了data.joint_pos但没调scene.update()，拿到的是上一帧的缓存。这类问题的排查方法很土但有效：在循环里打印同一行三次，看数值有没有变化。

坑二：加大刚度反而更拉不动。直觉上刚度大了力就大，但实际上刚度太大配合大步长会震荡，震荡过程平均下来净位移很小。表现是门在原地高频抖动，看起来“卡住了”。这时候要做的不是继续加刚度，而是减小仿真步长或者降低刚度。

坑三：自碰撞打开后门永远关不严。门和柜体之间本来就有一层间隙，但如果几何上有一点重叠，自碰撞会持续把它们推开，门在接近关闭的位置反复弹。关掉自碰撞，用关节位置判断关闭状态，简单可靠。

坑四：随机化把手位置后训练崩了。不是随机化有问题，是随机化之后原来的奖励尺度失效了——把手位置变了，接近奖励的距离范围变大，指数衰减的尺度没跟着调，梯度信号被压平。每次改随机化范围，都要回头检查奖励的归一化尺度。

7. 我在关节物体任务上的几条实操心得

写到这里，把几条不太适合放进上面结构里的经验摊开说说。

第一，先把资产在 GUI 里手动玩一遍再写代码。这句话我在前面提过，但值得再强调。用鼠标拖门、拉抽屉、看有没有穿模、看限位对不对，五分钟能发现的问题，在代码里可能要查五小时。而且 GUI 里可以开物理调试可视化，看接触点和约束力的方向，这些信息在训练日志里是看不到的。

第二，固定约束先跑通，摩擦抓取后替换。别一开始就追求“真实物理”，先用固定约束把环境、奖励、观测、终止全部打通，确认机械臂能走到位、能拉开、关节位置能正确读出来。这一步大概占整个项目三成时间，但能省下后面七成的排查成本。等整条链路稳了，再把抓取换成真实的摩擦接触，这时候出了问题你能确定问题在抓取这一环，而不是在环境搭建。

第三，给每个关节单独记一条曲线。训练监控里别只看总奖励，把每个关节的位置、速度、接触力单独画出来。我遇到过一次总奖励在涨但抽屉实际没开的情况，原因是策略学会了推柜体让整个柜子倾斜，倾斜导致抽屉在重力分量下滑出来一点，奖励给了，任务没完成。单看总奖励是发现不了的，看关节曲线和柜体姿态才看得出来。

第四，关节限位宁可设紧一点。仿真里门能转 180 度，真机上可能 100 度就撞到墙。限位设得比预期紧一点，策略学出来的动作幅度更保守，迁移到真机时不容易撞。这个思路和“训练时加噪声提升鲁棒性”是一个道理，本质是让策略在受限条件下工作。

第五，观测里加上关节速度。很多人只放关节位置，但门在被推动的瞬间是有速度的，策略要根据速度判断“我已经把它推到多快”，从而决定下一步给多大力。缺了速度观测，策略容易过冲。加这一项的成本很低，收益不小。

最后再补一个关于调试节奏的想法。关节物体任务的调试，最忌讳的是同时改多个东西。改完刚度又改奖励，跑一轮发现变好了，你不知道是哪一项起的作用；变差了更麻烦，要往回退两个维度。我的习惯是一次只改一个参数，跑固定的步数，和基线对比，记录在案。听着笨，但这是唯一能积累下确定性经验的做法。前面那些参数区间，都是这么一次次试出来的，不是查文档查到的。