RoboSimStudio 与 DexLab：交互式 Real2Sim、物理可信度与可借鉴路线 / Comparison and next steps

[huangkiki]

RoboSimStudio 最值得 DexLab 学习的是：让用户在同一个场景里完成“搭建、操作、改参、看结果”的循环。DexLab 应先把一个已有案例的这条路径做顺，再考虑接入更多引擎。 物理方面则要单独判断：当前公开擦拭示例用了辅助保持约束，不能用它证明纯摩擦抓持或手内操作已经可靠。

先看它替用户省了哪一步

假设我们要让机器人拿一块海绵擦桌子。通常需要自己整理几何和材料、写场景、运行控制脚本，再到别处看视频和数据；发现海绵滑脱后，还要判断该改夹爪动作、摩擦还是海绵刚度。

RoboSimStudio 把这些操作组织在一个可反复修改的场景周围：人或 agent 编辑场景代码，保存后重建；在界面里观察和操作；agent 可以取快照、对照参考画面、执行动作、查询结果，再修改场景。它的价值在于缩短“发现不对 → 找到要改的地方 → 再看效果”的距离。 这是对工作流程的判断，还没有双方用户耗时的对照结果。场景迭代说明、agent 可用操作

从任务、照片或视频开始建模，也不意味着一次生成就获得可信物理。论文中的擦拭案例仍经历了调整、真机失败和模型修正；作者明确把真机迁移评价限于一个任务，主要是定性比较。论文 §4.3、§5

两个最值得借鉴的做法

第一，把操作与反馈放在一起。 用户修改后应马上知道发生了什么，以及下一步该查哪里。RSS 已有场景检查、日志和运行轨迹，并非只有漂亮画面。DexLab 也已有运行器、回放、力曲线和评分，但这些能力的入口仍较分散。我们的缺口更像是“把现有能力串成一条可用路径”，而不是再写一套仿真平台。RSS 检查实现、DexLab 选型入口

第二，让用户知道参数到底有没有生效。 比如把摩擦系数从 0.4 改成 0.8，界面数字变了，并不代表当前模型已经在用 0.8。RSS 为参数注明单位、范围，以及修改后是直接生效、刷新计算图还是重建模型。这能防止“以为比较了两组参数，实际一直在跑旧值”。DexLab 已经记录请求值与有效值，值得把这项能力带到用户改参的位置。这里的数值只是解释例子。RSS 参数应用、DexLab 试参实现

两者各有侧重：RSS 擅长把场景搭起来并反复操作；DexLab 更集中于解释接触为何失败、参数实际是什么、结果怎样判定。后者是值得保留的能力，但“记录更严谨”本身不能证明我们的物理更准确。

为什么不能照搬演示里的成功

擦拭时，海绵既要被夹住，又受到桌面拖拽。当前 RSS 示例公开记录了纯摩擦保持会滑脱的问题，并加入了一组柔顺的辅助约束：满足夹取条件后，让部分海绵节点随夹爪移动，张开时解除。它保留了初始接触过程，也公开了失败；不过后续保持已经不只靠摩擦。示例说明、辅助约束实现

这一区别对任务选择很重要。研究擦拭轨迹时，这种简化可能有用；研究手指怎样让物体滚动、滑移、换指时，它可能限制恰恰需要研究的相对运动。应学的是把这种假设清楚展示出来，并允许按问题选择；不能把“演示没有掉落”直接计作抓取能力。 这描述的是当前公开代码，不能倒推论文所有实验都用了同样的约束。

另外，这个示例的 SuperDex 外部耦合把新反力留给下一控制周期使用。慢求解器造成的等待会降低运行速度；交换不够及时、反力被滤波或力矩表达不完整，才会进一步影响模拟的接触过程。两件事不能混在一起。具体时序与手内操作风险见耦合追问的重写回答。

我的取舍：先做一个能走通的案例入口

建议先用 DexLab 已有的法向加载—卸载案例：让一个物体压下、再抬起，观察力随位移的变化。它已有初始失败、校准记录和运行入口，适合集中解决使用流程问题。已有案例记录

这个入口至少应让用户连续完成：看初始结果 → 修改一个参数并确认生效 → 运行 → 对齐前后力曲线 → 看判定及原因 → 保存可复现配置。 已有视频和曲线直接复用。验收重点是用户能独立完成这一轮，而非页面是否像一个完整 Studio。

反对意见是：法向加载看起来不像机器人任务，可能证明不了真正易用。这个担忧成立。因此它只作为第一步；之后要用“夹持—抬升—释放”检验同一流程是否仍能帮助用户定位问题。若新用户仍需频繁离开入口找脚本和解释，就说明第一步还没有解决问题。

暂不优先整套接入 RSS。它会带来新的引擎依赖、场景适配和耦合验证工作，却未必先解决入口分散的问题。只有现有后端确实缺少所需材料或接触能力，并且候选路径通过该任务的检查时，接入才更有理由。正式接入仍应沿用 DexLab 与 UniSim 已有的职责分配。

这次建议的新增认识：我们需要借鉴 RSS 的短反馈循环，让 DexLab 的严谨结果在操作过程中就能被用户用上。 是否值得投入，可用同一任务下完成首次复现、定位一次失败所需的步骤和时间判断；目前没有测得加速比例。该建议延续 #189 的任务入口方向，尚不改变现有开发顺序。

核查范围、补充来源与历史版本

2026-10-20，单一 AI 助手查阅论文、文档和源码后整理，并按读者视角重写、自查；未进行独立多方评审，未运行双方实验或做性能、精度排名。正文中的优先级是待采纳建议。

• 固定版本：RoboSimStudio 23417de，DexLab b955d85。
• 参数单位、范围和更新类型：参数定义。部分参数作用于全局，不能假定每个对象都可独立设置。
• DexLab 的独立结果判定：复评实现。这说明检查方式，不代表所有材料和任务已通过。
• RSS 的 安装说明与 耦合实现供后续接入评估；不同设备路径可能采用不同后端。
• 重写前主帖及耦合评论的完整存档。旧版偏重源码审计，这次重排了解释和优先级；旧结论不会因此变成已采纳任务。

English summary

RoboSimStudio's clearest transferable strength is a short interactive loop: edit a scene, operate it, inspect the result and revise it in one place. DexLab already has useful experimental records and checks; the proposed first step is to connect one existing load/unload case into a complete user workflow, including confirmation that parameter changes actually take effect.

The current public wiping demo adds compliant grasp assistance. It does not establish friction-only retention or reliable in-hand manipulation, and the finding should not be generalized to every paper rollout. The linked coupling reply separates computational waiting from delayed physical feedback.

Start with the existing case, then test the workflow on grasp–lift–release. Defer a full RSS integration until a concrete capability gap justifies its dependency and qualification costs. These are proposals based on source inspection, not measured accuracy, usability or runtime improvements.

[huangkiki]

会有等待，但“慢的求解器让快的等着”本身，不足以推出做不了手内操作。 对当前 RoboSimStudio 的 SuperDex 路径，更值得担心的是：刚体侧先走完一段时间，才拿到软体的新反力；下一段才能用上。手内操作还依赖滑移、转动和换指，辅助保持约束可能掩盖这些困难。

先分清“电脑算得慢”和“模拟里的反馈来晚了”

假设两侧都要计算同一段 1 ms 的物理过程。刚体侧用电脑算 1 ms，软体侧算 20 ms，串行完成约需 21 ms，再加通信开销。

这时电脑过去了约 21 ms，模拟世界只前进了 1 ms。刚体侧等待时没有自己再往前跑，所以在离线、控制器也跟随仿真时间的条件下，等待主要意味着训练和实验更慢。这里的数字只是解释用例。真机闭环或墙钟定时的控制器另有实时期限，等太久就可能直接影响控制。耦合时间窗口说明

另一种问题是：模拟里已经前进了 16.7 ms，却一直没让刚体收到这段时间中新产生的软体反力。即使电脑瞬间算完，这个反馈滞后仍然存在。 不能靠换一张更快的 GPU 自动消掉它。

RSS 这条回路实际怎么走

当前外部 SuperDex 路径可以简化成：

本周期：刚体使用上一周期的反力，先推进
    ↓ 等待设备完成，取得刚体的新位姿
软体跟随这段位姿变化推进，算出新的反力
    ↓ 对反力做滤波和限幅
下一周期：刚体才使用这次的新反力

也就是有串行等待，并且没有在本周期内反复回退、重算，让刚体轨迹和新反力共同收敛。软体碰撞体的位姿插值可以减小运动跳变，却不能让已经算完的刚体轨迹提前响应新反力。主循环、反力时序

从公开擦拭示例的配置推算：

环节	每个仿真秒的次数	意味着什么
刚体内部步进	960	每约 1.04 ms 积分一次
SuperDex 内部步进	120	每约 8.33 ms 积分一次
两侧交换新反力	60	每约 16.67 ms 交换一次，新力在下一周期使用

内部算 960 次，不代表两侧有 960 次新的相互反馈。 这些是配置推导出的仿真时序，不是实测运行 FPS。示例配置、外部引擎步长定义

为什么你的手内操作担忧有道理

稳定保持时，接触可能变化较慢；手内转物时，手指需要有控制地松开、滑动、重新接触，反力和转动力矩会持续变化。旧反力、滤波后的反力，可能让机器人对这些变化反应不对。不过风险有多大仍取决于动作速度、接触刚度和交换周期，不能仅凭 60 Hz 就判定必然失败。

还有两个更具体的限制：

• 当前擦拭示例增加了柔顺的辅助保持约束。 它有助于把海绵留在夹爪里，但会约束部分相对运动。因此连“稳定抓持”也要区分是摩擦做到的，还是辅助约束帮忙做到的；更不能直接拿来证明手内重定位。示例说明及代码
• 所读桥接路径的力矩表达有近似。 它由合力和形状参考点估算力矩，没有返回完整接触分布的独立力偶。不同位置的一对反向力，即使合力为零，也能让物体转动；这种效果对手内旋转尤其值得检查。反力与力矩收集

所以我会把原来的假设改成：当前实现值得怀疑的是，它是否保留了手内操作需要的及时反力、力矩和相对运动；而非仅仅“两个求解器速度不一样”。 这是有源码依据的风险判断，目前还没有运行结果证明它一定能或一定不能完成手内操作。

DexLab 应怎样验证这件事

先做一个可解释的加载—卸载或小幅扭转案例：只改变两侧交换周期，记录原始反力、实际施加的反力及其时刻，观察误差和稳定性怎样变化。内部步长、控制器、滤波的时间响应和力上限要保持可比，否则同时改了几件事就分不清原因。

随后再做“保持 → 主动滑移／转动 → 换指／释放”，明确有无辅助约束。若保持通过但主动转动失败，再根据力、力矩和接触事件判断缺口，才有理由决定缩短交换周期、改用同周期迭代，还是调整接口传递的信息。代价是更多求解或通信，可能进一步降低吞吐。

这也给 #222 的交互控制案例提供一个明确检查项：发出了正确要求之后，控制器收到的反馈是否还足够及时、完整。

技术细节：不同耦合路径、参数混杂与历史记录

• 以上限于 RSS 23417de 的外部 SuperDex host 路径。VBD 是求解方法／实现家族，MuJoCo 与 SuperDex 是具体引擎／实现栈；不能只按名字排一个普遍速度顺序。Newton 原生 Proxy／ADMM 路径与此不同，不能把一条回路的结论推广到全部耦合。Newton 官方说明、RSS 耦合实现
• one_way 表示机械手能推动软体，软体不把反力返回机械手。对需要机器人感受物体载荷的任务，这会改变问题本身，不能只看软体画面是否合理。单向配置
• 这条反馈实现对上升段做 EMA 平滑，下降段直接跟随；限幅为 F_max = body_mass × feedback_dv_max / H。提高交换频率同时会改变这个上限；固定 EMA 系数也会改变相对仿真时间的滤波响应。测试时应把这些变化拆开。反馈实现
• 通用默认 feedback_dv_max=0.5 m/s，擦拭示例实际覆写为 5.0 m/s，评估该示例应使用后者。这个参数用于数值稳定化，并非已标定的执行器力上限。
• 核查日期 2026-10-20。单一 AI 助手源码分析、配置推导及可读性自查，未进行独立多方评审；没有运行性能剖析、耦合实验或手内操作。这些验证仍是提案。
• 重写前主帖与本评论的完整存档。

English summary

Computational waiting primarily reduces offline throughput when every component follows simulation time. It is distinct from using stale interaction forces within the simulated dynamics.

In the inspected external SuperDex path, rigid bodies advance before fresh soft-body feedback becomes available for the next control period. The public wiping configuration implies 960 rigid steps, 120 soft steps and 60 feedback exchanges per simulated second. These are configuration-derived rates, not runtime measurements.

Delayed or shaped forces, approximate contact moments and compliant grasp assistance motivate specific concerns about in-hand manipulation. They do not prove universal impossibility or even establish friction-only stable grasping. Test exchange timing under controlled conditions, then progress from holding to active slip, rotation and contact changes.

[huangkiki]

补充追问：那手内操作是不是就会有概率失败？

会有这种风险，尤其在换指、滚动和主动滑动时。更需要弄清楚的是：失败来自控制动作本身，还是仿真把接触过程算错了？误差也可能反过来制造“成功”。 仅凭两个 solver 运行速度不同，还判断不了失败概率，更不能据此认定手内操作做不了。

用一个自拟例子说明：拇指和食指捏着一颗葡萄，准备换成拇指和中指。中指先接住，食指逐渐卸力、离开，葡萄在交接中稍微转动。

这段动作要求“谁正在接触、谁承担多少力”及时更新。如果接触状态已经改变，手的求解器还使用上一段时间的反作用力，手指后续的运动就可能被算偏，进而改变葡萄会不会掉。这里是机制推演，不是已经运行的葡萄实验。我们检查的 RSS 外部 SuperDex 桥接版本，确实把新反力用于下一控制步；源码也提醒了表面分离后，旧力仍可能在这个步内继续作用的问题。固定版本的反馈说明

看见的现象	可能的原因	应怎样理解
中指还没接稳，食指就松开，葡萄掉了	控制动作确实缺少支撑	仿真应能表现出这种任务失败
本来能完成的交接，被耦合误差算得掉落	反馈时序等数值误差改变了运动	可能是“假失败”，不能直接归咎于控制策略
本来会掉落，却在仿真里保持住了	数值误差，或额外辅助约束改变了保持条件	可能是“假成功”，不能据此认定真机也能完成

后两种是需要用参照和对照检验的可能性，不能只看一段视频就确定原因。辅助约束可以用于特定研究目的，但其成功不应被解释为纯摩擦手内操作成功。

“有概率失败”也不意味着 solver 每次随机出错。初始条件、输入和计算过程完全确定时，它可能反复在同一次换指中失败。要报告成功率，需要说明测试了哪些初始姿态、材料参数和扰动，以及总共多少次。

快 solver 等慢 solver，和反力来晚了，是两件事。 在离线、所有控制都跟随仿真时钟的条件下，等待主要使计算更慢；交换间隔过大、使用旧反力，才会影响这里讨论的接触过程。按真实时间运行的硬件闭环还要另查实时期限。时间窗口与不同步长

preCICE 可以协调数据交换，并支持在同一段仿真时间内重算、迭代，直到所检查的接口量满足收敛条件。这有助于减小两边结果的不一致，但不能代替接触、摩擦和材料模型的验证，也不意味着 RSS 这条路径已经采用这种机制。preCICE 耦合方案

对 DexLab，建议先回答一个小问题：同一个换指动作，缩短信息交换间隔后，轨迹、接触切换时刻和成功率是否逐渐稳定？ 对照中要保持控制器采样周期、内部步长等设置可比，尤其不能让力限幅和滤波的实际时间响应随着交换频率一起变化。否则即使结果改善，也分不清原因。成功率应使用同一组预先确定的初始条件和扰动。

如果这些结果随细化仍显著漂移，就不能急于用它评价策略好坏；临界动作的一次成败翻转本身也不足以定位原因。结果稳定只增加数值上的可信度，仍需要适用的物理参照或实物测量。我们需要同时能识别真实失败、假失败和假成功，不能只统计“物体最后有没有掉”。

本补充延续前面的耦合分析。2026-10-20 由单一 AI 助手根据官方文档和固定版本源码整理、自查；本次未运行手内操作实验，没有测得失败概率，以上验证仍是讨论建议。入门解释也已整理到 README 科普段落。

English summary

In-hand manipulation can fail physically, but coupling errors can also create false failures or false successes. A finger-transfer example illustrates the concern: using stale reaction forces after contact changes can alter subsequent finger motion and the outcome. This is a hypothetical example, not a measured failure rate.

Offline waiting primarily affects throughput when all participants follow simulation time. Implicit coupling can reduce interface inconsistency, but it does not validate contact or friction models. The proposed DexLab check is to refine the exchange interval while keeping other factors comparable, then examine trajectories, contact transitions and outcomes over the same predefined trial set. Numerical stability under refinement still requires appropriate physical references. No in-hand experiment was run for this follow-up.

[huangkiki]

preCICE 的局限：耦合开销与统一求解架构的取舍

preCICE 的价值是复用已有求解器：让各自负责一部分物理的程序交换数据、协调推进。代价是增加接口适配、数据交换和协调工作。对于频繁换指、滑移和接触切换的机器人任务，这些成本值得单独评估；“能够耦合”还不足以说明适合高频控制。官方定位

第一，通信、映射和同步确实需要时间，但慢在哪里必须拆开看。

例如手的求解器已经算完，仍要等软体算出这一轮的反力。这个等待可能很长，却未必是通信库传输得慢。preCICE 官方特别说明：串行耦合中，部分耦合 API 的计时包含另一参与者的求解时间。因此，直接把整个 advance() 耗时叫作“preCICE 通信延迟”，会把不同成本混在一起。性能分析说明

通信方式、网格规模、交换次数都会影响开销，需要测具体配置。并行执行可以重叠部分计算，但交换点仍可能受较慢一侧制约。对单步本来很快、却要频繁交换数据的任务，接口开销占比可能更突出；这是需要测量的工程判断，尚无本项目数据给出固定延迟数值。通信配置与测量建议、串行与并行耦合

第二，提高耦合一致性，往往要付出重复求解和回滚的成本。

隐式耦合会在同一段仿真时间内反复计算。例如采用串行隐式方案时，手先算一次，软体给出反力，再回到这段时间的起点重新计算，直到满足所检查的收敛条件。它有助于解决强相互作用下的不一致，但每轮都可能重复求解和交换；适配器还必须能保存、恢复求解器所需的完整状态。隐式耦合与检查点要求

只打开“隐式”开关也不保证收敛。官方文档说明，简单固定点迭代仍有稳定性问题，需要合适的松弛或加速方法，各参与者内部也要正确收敛。对接触突然建立、消失的场景，迭代次数及其波动应当作为待测指标。加速与收敛条件

离线运行时，这些成本主要影响吞吐；若接入真实时间运行的控制或硬件，还要检查整条回路是否按时完成。数值上收敛，和实时期限内算完，是两个验收条件。

第三，接口适配仍需要物理判断。

两侧网格不一致时，要决定怎样把位移、力等量映射过去；映射方法本身也有精度与计算成本的取舍。对于手内操作，还应核对接触位置、力矩和数据生效时刻。把数据传过去，并不自动证明这些量表达正确。映射配置

统一求解架构能改善什么？

作为架构推断，如果能够共同设计各物理模块，共享状态、接触表示和调度，就有机会减少重复转换、数据搬运及外部同步，并把手—物体的强相互作用放到更紧密的求解过程中。这里有三个层次：

做法	可能获得的收益	仍需承担的成本或验证
通过 preCICE 等库连接独立求解器	复用成熟能力，保留各自实现	适配、通信、映射、同步和耦合迭代
在同一程序内共享数据并专门设计耦合	减少部分搬运和调用边界开销	若仍分步推进，仍要检查旧数据、分裂误差和稳定性
把强相互作用的自由度和接触条件联合求解	更直接处理同一时刻的相互作用	联合问题的规模、非线性求解、实现维护和物理验证

这些是候选架构的取舍，不是已测得的性能排名。由同一团队编写、放进同一程序，并不等于物理上不再需要耦合。 即使采用联合求解，也不保证更快；分区方法配合充分的隐式迭代，同样可以实现强耦合。

对 DexLab，建议先比较已有可用实现中“高频手—物体接触留在同一求解系统”和“通过外部接口交换”的成本与误差。用同一个简化换指或滑移任务，在相同物理目标和误差要求下，分别记录求解、数据转换／映射、通信、等待及迭代成本，并将初始化成本与运行中每步成本分开。实时评估还要看耗时波动和超期次数。这样才能判断瓶颈值得通过优化接口解决，还是需要改变求解边界；目前不据此建议重写全部引擎。

核查范围与补充边界

• 2026-10-20 核查 preCICE 官方文档。本文为公开资料分析和架构建议；本次未执行 preCICE 基准、实时资格测试或手内操作实验，没有测得其在 DexLab 中的额外延迟或失败率。
• 上述代价有些属于分区多物理耦合的一般问题，不是 preCICE 独有缺陷；库本身还提供通信、映射和耦合加速方面的优化。
• 部分映射方法支持 GPU 后端，不能把“所有映射都在 CPU”或“所有配置都必然经过同样的 CPU/GPU 往返”当作前提。需按具体方法、编译配置和适配器核查。GPU 映射支持
• 以上不表示 RoboSimStudio 已使用 preCICE，也不将其现有 SuperDex 桥接路径的时序归因于 preCICE。相关上下文见原耦合分析与手内操作失败的辨别。

English summary

preCICE enables reuse of independent solvers, with costs in adaptation, communication, mapping, synchronization and coupling iterations. Time inside a coupling API can include waiting for another solver, so it should not all be attributed to communication overhead. Implicit coupling requires repeated solves, complete state restoration and appropriate convergence methods.

A jointly designed implementation may reduce data movement and external synchronization. Common authorship or a single executable does not eliminate physical coupling; staggered updates can still introduce splitting errors, and a monolithic solve is not automatically faster. DexLab should compare available architectures under matched physical objectives and accuracy requirements, separating startup, solver, interface and iteration costs. Numerical accuracy and meeting real-time deadlines require separate checks. These are source-based design considerations, not measured latency or manipulation results.

[huangkiki]

历史存档：2026-10-20 重写前版本。 为保留原判断与纠错关系，完整保存旧文。当前结论请看本讨论主帖及原技术评论的更新版本。

展开重写前主帖

RoboSimStudio 值得 DexLab 认真学习。我的判断是：它在把机器人任务快速做成可交互仿真这件事上，产品路径更完整；DexLab 在明确比较条件、追查物理偏差、独立评分和保存失败证据方面，有更集中的研究方向。 下一步值得补上的是从任务到可信基线的使用流程，并把 RoboSimStudio 暴露的真实工程困难变成诊断问题。

这是按维护者请求发布的 AI 辅助调研与建议，由同一位助手查证整理，不代表独立多方评审或维护者已采纳。核查日期：2026-10-20。本轮读了论文全文、项目页、双方代码与 DexLab 当前工作入口、Project 和相关讨论／Issue；没有安装运行 RoboSimStudio，没有重跑双方实验，也没有测得双方性能或精度排名。

固定源码：RoboSimStudio 23417de，DexLab b955d85。论文采用维护者提供的项目 PDF，文件 SHA-256 为 904297e6f27c76b4a487b6a89e48796add1215938ed6959ee7c629d81696f105。下文把作者报告、源码事实和建议分开。

双方主要解决什么问题

维度	RoboSimStudio	DexLab	对我们的启发
用户起点	从任务、照片或视频构建场景，再交互调整	从接触／摩擦异常或配置选型问题开始	把“我要完成什么任务”接到现有诊断流程
工作界面	Scene/Sim/Ref、浏览器 Studio、保存即重建、agent 的 ctl 命令	已有运行器、参数试验、回放、报告和文档入口	把现有能力组织成一条连续操作路径
物理组织	Newton 为主要基础，组合域内 solver 与外部引擎耦合	多引擎／配置的实验协议、资格、独立评分；正式接入按 UniSim 边界收敛	区分同场景耦合与跨配置比较，不能用统一接口推导物理等价
证据侧重点	场景交互、任务效果、迭代反馈；源码也有检查、日志和回归轨迹	原生读回、物理参照、负例、参数来源、失败、成本与历史版本	可以互补；不能把对方概括为“只有视频”，也不能把我们概括为“只有脚本”

依据：RSS 入门、RSS live 工作流、DexLab 诊断入口、已确定的接入职责 #142。

RoboSimStudio 做得好的地方

1. 人和 agent 在同一个场景上迭代。 scene.py 保存后重建，界面允许观察和操作，agent 可取快照、与参考帧比较、执行动作并查询结果。这让错误更早暴露，也降低了“写一大段脚本后才看结果”的调试成本。这里的成本优势是工作流判断，本轮没有做用户计时实验。工作流与命令

2. 参数界面有真正的执行语义。 参数元数据包含单位、范围和 live / recapture / rebuild：有的改动下一子步生效，有的需要重新捕获 CUDA graph，有的必须重建模型。代码还说明部分接触参数是全局标量，不能假定两块布可以各自独立设置。这比单纯做一组滑块更值得借鉴。参数定义、参数应用

3. 可用的多物理场景组合与任务反馈。 代码区分物理域、后端、接触通道和单向／双向耦合；agent 工具区分机器人可获得的观测和模拟器特权状态。公开的观测白名单检查是值得保留的边界，但检查函数存在不等于所有外部部署路径已经通过验证。耦合实现、观测边界

4. 有工程验证，也愿意保留失败。 live 检查包括状态有限性、穿入和静置漂移等，日志绑定场景代码身份；回归轨迹记录首次成功时刻、过程指标与变化次数，并支持由重复运行估计波动范围。这些值得学习，但场景健全性和评分回归仍不能替代真实材料验证。live checks、trace

RoboSimStudio 的不足与需要读清的边界

• 论文证据还是 pilot。 作者展示 18 个任务场景；§4.3／Fig.7 报告从视频构建擦拭仿真、改进策略、上真机，再用支撑物移位的失败修正约束。§5 明确说明：真机迁移只评估了一个任务，仿真与现实主要定性比较，系统量化评估仍待开展。56 分钟建模和仿真擦除面积 0→100% 是该案例的作者报告，不能当作通用建模耗时或真机成功率。PDF，§4.3，印刷页 7–8；局限，页 9

• 当前公开擦拭示例含接触触发的辅助保持约束。 README 披露纯摩擦擦拭会滑脱；Latch 在闭合稳定、双侧接触力和压缩条件满足后，对接触附近海绵节点施加随手移动的柔顺约束，张开时解除。它仍然经过初始接触抓取，也公开保留无 latch 的失败，不能说成全程无物理作用；但持续保持阶段已经增加了约束，不能作为纯摩擦保持的验证。这只描述当前代码示例，未核对论文每次 rollout 的源码身份，不能倒推论文全部实验都采用相同实现。 示例说明、Latch 代码

• 双向反力回传含明确近似。 SuperDex bridge 将反力交给下一控制周期，采用保持、上升段 EMA 和速度增量限幅；默认 alpha=0.35、dv_max=0.5 m/s。这有稳定性动机，但会改变瞬态响应。所读回路用合力及形状参考点估算力矩，没有取得完整接触分布的独立力偶。因此需要分别检查原始力、实际施加力、时延、力矩、滤波／限幅触发和步长敏感性；不能把“双向”直接等同于保真或守恒已验证。该结论限于这条外部引擎回路，不能泛化到所有 Newton 耦合器。bridge、反力收集、滤波和限幅

• 安装与设备切换有实际成本。 项目标记为 Alpha，推荐 Linux/Python 3.12；部分依赖来自 Git，checkout 默认 RTX 组约 1.8 GB，可禁用。CPU 路径会更换部分物理后端，支持范围也不同，不能当成同配置换设备。CI 配置覆盖 fast/CPU，GPU medium tier 需另行执行；这里确认的是配置，未核验其全部历史运行结果。安装、依赖、CI 配置

DexLab 的长处，以及我们自己的缺口

长处有三项，而且已有代码和记录支撑：

• 问题拆得更细。 把记录完整性、数值一致性、物理参照和任务结果分开，保留失败与不可观测字段；这些能避免“视频成功，所以物理正确”的误判。证据复评实现
• 受控试参已经有可复用基础。 contact_trials 冻结候选、假设、参照和预算，区分请求／解析／有效参数，用独立评分判断结果。实现；现有集成记录包含两个 1600 步 MuJoCo 案例，一失败、一通过，性质是历史候选流程验证。已发布记录
• 已有可解释的机器人／材料案例。 当前主页展示接触、斜面、夹持、LIBERO 和切割，并明确区分控制输入、保存状态、合成材料和历史协议。切割案例已经提供力与位移展示，不能说 DexLab 完全缺少可视化。当前 README

但以下缺口应正视：

1. 研究能力还没有充分变成易用入口。 读者需要在场景指南、运行脚本、证据、报告和 Issue 之间切换；当前主页首屏又以切割案例为主。新用户可能知道“做了很多实验”，却不容易知道“我的任务下一步运行什么、看什么、改什么”。这是基于入口结构的产品判断，不是已经测得的用户失败率。选型入口
2. 严谨规则不等于全部证据已经补齐。 SDF #178和布料 #179仍开放。六引擎覆盖、完整机器人任务、真实材料和跨场景迁移有各自边界。我们不能据此宣布比 RSS 更准确、更稳定或更容易 sim-to-real。
3. 架构收敛和依赖约束仍影响交付速度。 #142仍开放，当前依赖锁在明确的 UniSim 版本范围；新增软体或耦合能力可能需要公共契约工作。直接再包一套 RSS 场景／步进／读回，容易增加重复维护。依赖快照、候选 UIPC 评估 #218

建议借鉴的部分，按投入顺序讨论

下表是提案顺序，不修改现有任务优先级，也不表示已安排实现或实验。

顺序	建议交付	复用什么	完成时应能验证什么
1	一个“任务 → 起步策略 → 配置 → 物理检查”的完整入口	#189、现有 selection/diagnosis、一个已有记录的任务族	新用户找到操作步骤、完整配置、运行入口、通过／失败样例和适用边界；不能只有推荐文字
2	单个案例的同步回放与事件说明	现有状态、力曲线、视频、独立评分	接触开始、加载、滑移／保持、卸载／释放可定位到同一时间与原始记录；缺测明确显示
3	展示有效参数及修改何时生效	contact_trials.parameter_record，后续经已准入的公共接口读回	请求值、有效值、单位、来源、作用域和重建要求一致；不能只改界面数值
4	给 agent 的结构化失败反馈	既有 runner、独立 scorer、预算账本	输出哪个假设未满足、证据位置、下一项可区分原因的试验；新尝试保留旧失败，agent 不能修改评分阈值
5	RSS 辅助夹持／耦合作为独立研究参考	上述 latch 与 bridge 证据；#179、#142、#218 的相关边界	先冻结是否有辅助约束、反力与时序、材料和控制；分别验证接触、保持、卸载，再谈完整任务
6	从真实失败修正模型，再做新条件预测	现有诊断方法，未来获得的真实测量	先判断几何／边界条件／观测／材料／控制哪个假设失配；修正数据与留出数据分开，不能只追求拟合原视频

参数检查器未必需要先做完整 Studio。先把一个案例的读回、对照、回放和导出做完整，再按真实使用需要增加在线操作。已有支持的视频／曲线不重复建设；优先补上从异常到下一步试验的连接。

建议首先复用合成法向加载—卸载的历史初始／校准记录，做出最小可检查路径：选择案例 → 查看初始失败 → 查看有效参数差异 → 对齐响应曲线 → 查看独立判定 → 获取复现入口。它已有 runner 和集成证据，适合减少新增物理不确定性。之后把同一呈现方式用于夹持—抬升—保持—释放；不是把法向响应的通过结论推广到抓取。

衡量“更快开始正确仿真”时，建议分别记录环境准备时间，以及任务定义冻结后到首个可重放、通过预先声明物理检查的基线的时间，并保留失败次数和计算成本。若比较两种工作流，应使用相同起始资料、任务、预算和验收。现在没有这样的比较结果，不能先承诺加速比例。

值得继续讨论的三项取舍

• 首个交付先用法向响应把路径做完整，还是直接选择机器人夹持？前者风险较低，后者任务感更强；建议前者先形成可用路径，后者紧接着检验可迁移性。
• RSS 暂时作为外部案例与参考组合，还是未来接入为可运行候选？建议先做前者。它本身包含具体引擎与耦合路径，不应在矩阵里被计作一个独立的新物理核心。正式接入若需要改变 UniSim 接入收敛 · 架构总任务 #142 的职责分配，应明确另作决定。
• latch、人工 pin、运动学拖拽和反力滤波如何展示？建议在记录与界面中显式标注其启停、作用对象和影响；可保留为建模／交互手段，但纯摩擦保持与双向耦合资格应有对应的无辅助对照及独立物理参照。对照出现失稳也保留，不为拿到“通过”隐藏它。

以上延续 #189 已采纳的任务入口方向。当前顺序仍由 current-work与实时 Issue／PR 决定。新建议待采纳后再形成有依赖、预算和验收条件的工作项；本讨论本身不启动实验或恢复定时开发。

---

English discussion summary

RoboSimStudio offers a more cohesive interactive route from a task to a simulated scene. DexLab has a more focused experimental mission: explain contact failures and qualify configurations using explicit references, independent scoring, provenance, negative controls and cost. This is an assessment of the inspected artifacts, not a measured accuracy or usability ranking.

The most transferable ideas are the shared human/agent editing loop, parameter metadata that distinguishes live updates from graph recapture and model rebuilding, scene-linked feedback, and explicit separation of privileged simulation information from deployable observations. RSS already has checks, logs and regression traces; calling it a visualization-only toolkit would be inaccurate. See the pinned source links above.

Two implementation details deserve separate experiments. The current public wiping demo adds compliant node constraints after a contact-triggered grasp; it transparently documents friction-only failures. The inspected SuperDex feedback path introduces a control-period delay, force shaping and limiting, and an approximate moment arm. These observations identify qualification questions, not proof that every RSS task or paper rollout uses the same mechanisms. We have not independently executed either system in this review.

DexLab should connect its existing capabilities into one usable path before expanding scope: task and starting strategy → configuration → synchronized observations → independent physical checks → evidence-backed revision. A small first candidate is the existing synthetic normal-load/unload case with initial and calibrated records; grasping should then exercise the same workflow under its own protocol. Parameter changes must retain effective readbacks, and agent feedback must not change acceptance criteria.

RSS should initially remain an external reference and candidate system configuration. Any production integration must respect the existing UniSim ownership decision or explicitly reopen it. Proposed success measures are setup time, time to the first reproducible baseline passing predefined checks, failed attempts and compute cost under matched conditions. No speedup has been measured. These are proposals for discussion, not adopted implementation priorities or authorization to resume scheduled experiments.

展开重写前技术评论 1

原评论位置：#220 (comment)

补充讨论：不同 solver 的计算速度差很多，是否只是互相等待？这种耦合能否支持手内操作？

维护者提出的假设是：速度差异导致等待，可能还能稳定抓取，但难以完成手内操作。沿上一轮的 RoboSimStudio 23417de 继续查代码后，我的判断是：手内操作的风险值得重点研究，但“等待”本身主要限制吞吐；更直接的物理问题是交换周期、反馈延迟、接触／力矩表达，以及为了稳定而增加的约束或删掉的反作用。稳定抓取本身也未必已经通过这些检查。

以下为 AI 辅助源码分析、数值推导和待验证假设。没有运行性能 profiling、耦合实验或手内操作，不把作者源码中的实验叙述当作本轮复现结果。

先分清三个时间尺度

时间尺度	表示什么	可能造成什么限制
墙钟耗时	电脑计算一段仿真需要多久	离线运行速度、训练成本、实时/HIL 是否赶得上
内部积分步长 h	各 solver 每一步推进多少仿真时间	各自的积分、碰撞和材料响应误差
耦合交换周期 H	两侧多久交换新的状态与反力	接口数据新鲜度、接触切换和反馈误差

离线仿真中，假设 A 计算一段 1 ms 的物理过程需要 1 ms 墙钟，B 需要 20 ms。串行执行可能花约 21 ms 加通信开销，但两侧最终仍只推进同一段 1 ms 仿真时间。A 等待 B 时，不应自行多推进 20 ms。只要控制器也按仿真时钟推进，这个等待不会自动变成 20 ms 的物理反馈延迟；实时遥操作、硬件闭环或使用墙钟定时的外部控制器则另当别论。这里的数字是解释用例，非实测。

串行／并行描述计算顺序；显式／迭代耦合描述一个时间窗口内交换、校正多少次；多速率描述内部步长可以不同。这是不同维度。并行可以减少部分等待，但不会自动消除使用旧接口数据的问题；多做内部子步，也不等于更频繁交换反力。preCICE 时间窗口说明、耦合方案分类

此外，VBD 是求解方法／实现家族，MuJoCo 和 SuperDex 是引擎／实现栈。比较效率应固定对象、离散精度、接触数、容差、设备和观测成本，不能给这三个名字一个普遍快慢顺序。

RSS 的 SuperDex 路径具体怎样执行

固定版本中的主循环先执行 Newton 侧的子步；after 阶段需要读设备状态时，显式调用 wp.synchronize_device；然后按顺序调用 host engine 的 host_tick。SuperDex 完成后才结束该控制周期，推进公共仿真时钟。因此这条回路确实存在串行依赖与等待，并不是两个 solver 各自按墙钟自由跑。调度器、host 合约

一次外部引擎交换可概括为：

第 n 个耦合窗口，长度 H
刚体侧：用上一窗口留下的反力，完成本窗口内部子步
   ↓ 等待 GPU 完成，读取本窗口末的刚体位姿
软体侧：把镜像碰撞体从旧位姿插值到新位姿，完成自己的子步
   ↓ 读取软体反力，滤波／限幅，写回软体状态
第 n+1 个窗口：刚体侧开始使用这次新反力

镜像插值使用窗口两端位姿，不是把刚体侧所有内部轨迹点都交给软体。它可减少大位姿跳变，但并没有让本窗口刚体轨迹响应本窗口刚算出的软体反力。默认 pose_source="fresh" 避免额外读取旧快照，不等于整个双向回路零延迟。镜像插值、host 阶段注册

以当前公开擦拭示例的配置推算：

项目	源码配置／推导值
控制及这条 host 交换周期	control_hz=60 → H≈16.67 ms
MuJoCo 侧内部步进	每周期 16 子步 → h≈1.04 ms，名义 960 步／仿真秒
SuperDex 内部步进	每控制周期 2 子步 → h≈8.33 ms，名义 120 步／仿真秒
新反力回传	每控制周期一次，供下一周期使用

960 Hz 的刚体内部步进，并不意味着 960 Hz 的刚柔双向反馈。 SuperDex 的 substeps=2 在 host 合约中是每控制周期两次，不是刚体的每个子步再做两次。表中是源码计算出的仿真时间安排，不是墙钟 FPS 或测得的吞吐。案例配置、外部引擎 dt 定义

已有稳定化手段为什么会影响操作

这条桥接路径的源码明确说明反力在下一控制周期施加。返回的反力还经过上升段 EMA 和限幅；下降段直接跟随原始值。因此并非一个固定线性低通，也不能简单给它套一个固定总延迟。反力时序、整形实现

限幅公式值得单独记录：F_max = body_mass × feedback_dv_max / H，并按力幅值比例缩放整个 wrench。它是数值稳定化限制，不是已经标定的执行器能力。用案例注释的 71 g 指体和 60 Hz 推算，通用默认 dv_max=0.5 m/s 对应约 2.13 N；该擦拭示例实际覆写为 5.0 m/s，约 21.3 N，不能拿通用默认值代表这个案例。还需注意这里用的是 body mass，不是完整关节系统的方向相关有效质量。

由此产生两个实验混杂：提高交换频率而保持 dv_max 不变，会同时提高力上限；保持 EMA 系数不变，也会改变滤波相对仿真时间的响应。因此“提高耦合频率之后变好了”还不能直接归因于延迟下降。

VBD／MuJoCo 不一定走同一条回路

Newton 原生耦合有 Proxy 和 ADMM 路径，可在一次顶层物理步中组织子求解与接口校正。ADMM 固定迭代不是自动收敛保证，Proxy 的稳定性也依赖参数与调度。RSS 的外部 SuperDex host 回路不因场景里出现 admm 字样，就自动加入同一窗口的迭代校正。Newton 1.6.0 官方耦合说明、RSS SolverCosim

更关键的是，RSS 还明确提供 one_way：机械手推动软体，软体不把反力返回机械手。当前折毛巾示例就选了这条路径；相关说明交代了 full-surface 接触与反力回传之间的支持限制。它能展示受运动边界驱动的布料操作，但不能据此证明有限执行器下的双向操作。单向回路、折毛巾配置

另一个直接相关的例子是 CPU preset 的绳索：源码把 SuperDex feedback 设为 off，说明双向延迟反馈在作者测试中造成抓持不稳；关闭后更容易保持，但绳索拉紧不会拉住机械手，也不能向自由刚体传递推力。配置是本轮核实的源码事实；测试次数和效果叙述属于作者报告，没有在这里独立复现。 CPU 绳索配置与限制

对“能抓稳，但难做手内操作”的判断

我的判断是方向成立，但需要改成可验证的条件命题：保持接触集合基本不变的慢速操作，可能容忍较大的交换窗口；依赖滑移、滚动、扭转和换指的操作，更容易暴露接口误差。不能据此给出失败概率，也不能说稳定抓取天然没有问题。

手内操作中的挑战包括：

• 接触建立／消失很快，旧反力可能在新的接触状态下继续作用，或新接触反力尚未进入机械手动力学。
• 接触点、法向和力臂持续移动，法向支撑力看起来合理，不代表转动力矩正确。当前 SuperDex 回传路径读取合力并用形状参考点计算力矩，需另核对接触分布对应的力矩是否保留。回传实现
• 手内调整往往需要“允许一定滑动，然后重新粘着”。辅助 pin/latch 能帮助保持，却改变了要研究的摩擦和相对运动；不能用它的保持成功证明纯接触重定位能力。擦拭示例的 latch 边界
• 切向、扭转和滚动摩擦的模型与参数会影响结果；单纯提高法向刚度或摩擦来“不掉落”，可能同时消除了目标操作需要的自由度。MuJoCo 接触模型说明

作为尺度示例，切向速度 100 mm/s 在 16.67 ms 内移动约 1.67 mm。这不是预测出的耦合误差，但说明应把交换窗口与接触斑、几何特征、滑移距离及控制动态一起检查。准静态、慢速的手内操作仍可能可行；快速手内操作是否可信，需要实际的收敛与任务证据。

这可以成为 DexLab 更具体的研究问题

建议研究的对象是：多速率刚柔耦合在抓持、可控滑移、滚动和接触切换中的准确性—稳定性—计算成本边界。 它比只比较每秒多少步，更能回答实际用户能做什么。以下为待采纳的实验提案，不启动运行或更改现有队列：

层次	最小问题	主要观测
接口资格	加载、接触突变、卸载分离时，两边是否正确交换作用与反作用？	原始／施加 wrench、采样与生效时刻、线／角冲量、滤波和限幅触发；核对读回是末子步力、平均力还是积分冲量
连续接触	两指保持后做小幅转动或可控滑移	物体姿态与角速度、接触点轨迹、滑移／粘着切换、驱动力限额
接触切换	三指简化换指或一次释放—重接触	接触顺序、失稳／掉落边界、重新建立支撑的时间；不能只评分最终姿态

对照时把内部积分步长、交换周期、控制器采样周期和耦合迭代次数分别记录。只扫交换周期时，应保持控制输入、内部离散和其他物理设置可比；RSS 现有 host 周期绑定控制周期，简单改 control_hz 会同时改变多个因素，需先设计可辨别的调度或输入保持方案。滤波对照要说明是固定离散系数还是固定时间响应；力限幅应说明固定的是速度增量还是力上限。

性能也要分账：solver 本体、镜像几何更新、CPU/GPU 传输、同步等待、记录和渲染。源码作者曾在特定场景指出镜像更新而非求解占主要时间，说明“慢的一定是 SuperDex 数值求解”也应经过 profiling。桥接工作量说明

参考可选经过收敛检查的单一求解系统／更细耦合结果、适用解析关系，以及后续真实测量；同一 solver 的更细步长也不是自动获得真值。记录任务结果、物理误差和成本，最终给出适用范围，而非预设某个组合一定胜出。

可考虑的改进方向是缩短接触期间的交换窗口、增加接口迭代，或把强耦合的手—物体接触留在同一求解系统，把其他物理过程交给外部 solver。每条都有成本和能力前提；增加强耦合通常更费计算，统一求解也不自动保证准确。用简化软指模型替代完整 FEM 时，应重新验证其操作范围，而不是因为快就当成等价。

前帖的交互流程建议保留；本补充把“耦合是否足够支持操作”列为需要独立验证的研究问题。结论不能停在“多引擎已经接起来”或“抓住一次”。

---

English summary

Wall-clock waiting and delay in simulated time are different. A slower participant reduces offline throughput; it does not inherently break manipulation if all solvers and the controller advance on a consistent simulation clock. Coupling accuracy instead depends on the exchange window, internal timesteps, interface data and iteration scheme.

The inspected RSS SuperDex path is sequential: advance the Newton side, synchronize, drive the external engine using interpolated rigid poses, then collect feedback for the next control period. In the public wiping configuration, the inferred rates are 960 rigid substeps/s, 120 SuperDex substeps/s, but only 60 external exchanges/s. These are configured simulation rates, not measured throughput.

In-hand manipulation is a stronger test than holding because it depends on controlled slip, rolling, changing contact locations and switching support. Yet even holding is not automatically qualified: RSS explicitly uses a one-way rope configuration, and the wiping demo uses contact-triggered auxiliary constraints. These are disclosed engineering choices with applicability limits.

A suitable DexLab study would separate internal timestep, coupling window, controller period, feedback shaping and coupling iterations, then test interface impulses, controlled rotation/slip and contact switching. Report physical error, failures and full computational cost. This is a proposed study based on source inspection, not a demonstrated failure probability or an authorization to start experiments.