工具装箱 / 运行剖面

完整仿真 · 单回合实测

规划能压到1秒吗?
热态检查已提速,完整规划待验收

单布局成功已证实,跨位置成功率仍未验收。此页以冻结成功回合拆解耗时,另列失败回合;不混算版本、不把未完成轨迹算成功。

耗时来自层层调用和重复求解。任务入口只有一个 assemble 调用;一次“规划”内部可能包含多次候选几何、逆运动学和轨迹求解。下面可以展开到具体输入、输出和函数。

提速验证 / 完整规划的1秒目标尚未达成

冻结数值输出的真实CPU几何检查;不含新IK或轨迹求解,不含物理执行。27项完整返回对象一致,包括碰撞结论、采样点数和末端误差;没有减少采样点、删减障碍物或放宽判据。

本次对照时间:2026-11-02T17:37:43.510741+00:00。原版累计56.80秒,候选累计8.39秒,均包含本进程首次加载。它们不能代替原网页的429.72秒完整规划累计。

所属规划原版检查累计 / 秒候选检查累计 / 秒
plan-00017.7916.709
plan-00410.1470.671
plan-0058.7350.287
plan-0097.1750.248
plan-0136.4260.218
plan-0146.5280.254

第一轮仍含冷启动;后续各轮检查累计低于1秒。这些时间不含重新求解轨迹,不能宣称完整规划已达到目标。

补齐数值求解计时:热态IK很快,轨迹求解仍超目标

冻结实测状态上的新数值求解;无HTTP、无物理执行,不等于完整任务。首次轨迹规划器初始化约62.65秒;热态成功关节轨迹的纯求解仍为8.24–8.81秒。本表与上方CPU检查独立测量,不能直接相加为完整规划耗时。

请求状态总秒场景更新秒轨迹初始化秒纯求解秒结果
ik冷态25.9060.0940.00018.215Success
pose冷态68.3200.16062.6465.468Fail
joint冷态10.9661.5790.0009.386Success
ik热态0.8780.8360.0000.032Success
pose热态6.0411.1430.0004.874Fail
joint热态8.4130.1670.0008.243Success
ik热态1.1121.0590.0000.029Success
pose热态7.9930.9350.0007.033Fail
joint热态10.3321.4840.0008.805Success

相同场景复用后的实测

完全相同的场景不再重复传入数值模型;场景变化仍重新更新,持物和关节状态逐请求处理。下表是另一轮冻结状态新求解的一次热态测量;IK查询约56毫秒,但成功轨迹总计仍约8.88秒。冷启动仍存在,没有把它计成已消失。

请求查询总秒场景处理秒纯求解秒结果
ik0.05570.00440.0283Success
pose4.21350.00414.1859Fail
joint8.88410.00438.8504Success
各模块功能、已测瓶颈与候选改动
模块功能已测结果候选变化与边界
任务搜索组合手臂、抓法和技能顺序原最慢请求中符号搜索0.090秒;不属于主要开销保留原搜索、候选和判据
CAD与碰撞模型读取三角网格并构建碰撞树单条冷态剖面中CAD构建8.39秒相同顶点和三角形批量传入;每回合保留静态缓存
夹爪几何构造覆盖开合范围的扫掠体同一路径重复构造188次;该剖面累计1.09秒按模型和精确夹爪范围复用;不改变几何范围
独立碰撞检查逐点检查桌面、双臂、持物和场景热态窄相位主要消耗在网格对桌面检测包围盒确定完全分离才排除;贴近、接触和穿透仍用原精查
规划子进程运行一次任务搜索及几何调用原实现每轮新建进程,静态缓存无法跨子计划复用候选按回合复用进程;场景、帧号、查询缓存和预算逐请求重建
数值求解与通信更新场景、求IK或轨迹并返回结果原请求计时包含往返与服务处理,纯求解耗时尚未分摊新增初始化、场景更新、求解、导出和客户端验证的独立计时;完整收益待测

完整规划低于1秒尚未验收;远端原版与候选的完整任务对照尚未完成。

01 / 时间花在哪里

顶层区间按完成事件减去实测调用时长重建。条形可点开,查看具体调用;它不是GPU内核级跟踪。

点击时间条,查看对应调用。

视觉组件计时与统计边界

这组数字来自带组件计时的对象估计。请求时间包含客户端往返和服务处理;没有独立GPU计算时间。部分感知与控制并行,不能叠加到上表总墙钟。固定目标复用、其他观测路径和失败恢复的覆盖不完整。

逐次任务规划:19个子进程到底输出了什么

完整子进程时间还包含启动、导入和结束开销;worker内部421.7秒,完整子进程429.7秒。内层RPC245.96秒已经包含在其中,不能重复相加。其余175.76秒包含首次RPC前准备62.87秒与未细分的几何检查、搜索和处理。

02 / 逐层拆开:输入 → 求解 → 输出

任务入口 → runtime编排 → 任务搜索 ⇄ 抓法/几何/IK/轨迹 → 动作执行 ⇄ 视觉反馈 → 释放与归位

03 / 一个具体失败:扳手搜索把时间用在哪里

已定位:搜索时间分配

调用链是 pick_component → GeometryStreams.sample → query → harness_motion_plan。外层固定抓法,内层继续枚举放置关系和高度;pose失败后又调用IK回退。原实现先把一个抓法的后续组合搜完,才换下一个抓法。

证据:同一冻结请求的原始结果中,38次持物pose失败、38次持物IK失败,只涉及两个持物起始关节配置;候选池有128个抓法,槽位有7个关系、3个高度。97次RPC累计139.19秒,180.07秒后超时。

结论范围:重复搜索消耗了大部分预算。它不证明所有抓法不可行,也不证明抓取模型差。

尚不能直接断言的部分

原来的抓起后搬运失败样本中,独立IK能到达部分目标,但检查发现link3/link5自碰撞。该结果只适用于检查过的解;原始求解器Fail不等于数学上不可达。

6条匹配回合已经结束,完整成功0条。新搜索在布局12/seed2暴露出高度备选饥饿:锤子先试2.5厘米失败后即换抓法,6个抓法均只试首高度便超时;父版同布局首次抓法接着试5厘米并找到路径。两回合测量略有差异,不能当作同输入因果实验。固定查询、有限预算的反例进一步确认了调度缺口。修正后先完成同一抓法的已有高度组,再交错抓法;8条新完整对照继续运行;布局12/seed2候选已在约59.8秒规划中选到5厘米高度并完成锤子释放,修复的局部行为已出现。完整任务与总耗时仍待验收。

证据明确度:把症状与原因分开
现象归属模块已经证实仍未知
抓法/任务规划很慢GeometryStreams.sample / query失败请求在少数持物配置上反复枚举,RPC占139/180秒单纯扩大抓法覆盖已暴露高度备选饥饿;分组调度的完整任务收益待验收
约137秒退出,却只记0.28秒RPCGeometryStreams._query / 客户端截止时间与计时总规划180秒,内部默认单调用120秒;失败等待未计时。4条钳子规划只记录2次快速IK后超时。源码与固定调用反例证实限制冲突和漏计新6条完整配对验证中;取消隐含限制能否使真实求解在原180秒内完成
首次运动规划129.8秒harness_motion_plan / planner缓存请求总时长;源码存在按手臂/夹爪区间初始化与缓存初始化、CUDA准备、求解、排队各占多少;未记录独立子段
IK有解但规划失败数值轨迹求解及独立碰撞验证检查过的部分端点解发生link3/link5自碰撞其他IK分支或抓法是否存在可行路径
到位后仍继续下压Assembly.read → support_release_ready一条失败轨迹的视觉1610/1650帧满足几何,控制帧领先导致同帧判断跳过4条对照无完整成功、确认分支触发0次;未证明修复收益
动作执行302.3秒execute_rows / 仿真执行RPC477请求执行840动作,物理33.6秒物理、渲染、序列化和调度的独立耗时
视觉看起来占很多等待perception及观测读取记录到的组件请求157.63秒,排队另16.88秒其他视觉路径、数据存储及未计时部分的完整分摊

04 / 代码规模与真实调用量

静态行数不等于执行次数,也不能推导耗时。下面是实际运行版本的文件行数;没有声称每行都执行过。

证据与可复核统计

成功回合:c547-functional-release-lazy-r2 / 布局24 / seed0。完整释放、撤手及归位;原始轨迹已做SHA核验。计时由events.jsonl、每次solver.process.json及result.json交叉提取。

失败回合:carry8-r4 / 布局12 / seed2 / plan-014;异步完成判断案例:同批布局24 / seed0。各自独立,不与成功回合混合汇总。

下载经过字段筛选的计时与调用数据 · 当前成果摘要

真实RGB-D观测按仿真时钟回放,非连续渲染录像。只代表该成功回合。

下一交付物

完整对照批次结果、跨位置任务表现,以及首次规划和仿真执行的更细计时。规划响应已在新候选中加入构建、场景更新、实际求解分段,尚待真实回合输出;未归因时间保持未知。