fix(kin/diag): kin.gaps 粗筛段也按点分块（COARSE_ENTRIES=3e7，≤446 点/块；实测上一版粗筛 4096 点仍 9.3 GiB）；diag_cl 加 D 段（子目标头精度 / 不用子目标 / 老师真实途经点）与目标误差进度比；rollout 加 use_sub、sub_override；本机执行清单更新
This commit is contained in:
Hark
+23
-59
@@ -3,18 +3,27 @@
|
||||
本文件是 Hark 对本机计算的唯一要求清单。按顺序执行，每一步把「回传」里的文件或输出原样交给用户，不要跳步，不要自行改代码。
|
||||
所有命令在仓库根目录（G:\Robot_v2\机器人手臂）的 Git Bash 里运行。完成的条目由 Hark 在下一次提交里删掉。
|
||||
|
||||
当前状态（2026-10-19 02:00）：第二次预训练开环已正常（候选多样性 0.65、8 候选最好 2.9 mm），闭环仍 0% 到达 / 100% 碰撞；
|
||||
DAgger 阶段曾把显存吃到约 30 GB，原因是 kin.gaps 一次几千个点、cap=40 mm，已修复（kin.gaps 自动分块），尚未实测。
|
||||
## 已知结论（2026-10-19 02:35 回传）
|
||||
|
||||
## 第 0 步：同步代码
|
||||
- 特征口径 Python 与 JS 一致（最大差 3.6e-6），同噪声动作差 ~1e-5°：排除「闭环输入没见过」。
|
||||
- 闭环关安全层 0% 到达 / 99.6% 碰撞，首撞中位 1.46 s，主碰撞组对 2-4；全程最小目标误差中位 254 mm：策略根本没朝目标走。开安全层碰撞 5.5%，到达仍 0.4%。
|
||||
- 开环正常：ol_fk_mm 5.98、ol_best_mm 2.92、ol_div 0.655。老师回放 pass。
|
||||
- 下一个嫌疑：子目标。训练时特征里的子目标是老师真实途经点，闭环里换成子目标头自己的预测。第 2 步的 D 段专门验证它。
|
||||
- gaps 显存：上一版只给精算段分块，粗筛段 4096 点仍 9.3 GiB。本版粗筛也按点分块（每块 ≤ 446 点）。
|
||||
|
||||
## 第 0 步：同步代码（不要 reset --hard）
|
||||
|
||||
本地有未提交的 `ml/monitor.html`、`ml/pstate.py` 改动和一个未推送的合并提交，`reset --hard` 会把它们丢掉。
|
||||
|
||||
```bash
|
||||
git fetch gitea && git reset --hard gitea/main
|
||||
git log --oneline -1 # 应为「fix: 闭环失败定位与显存修复……」或更新
|
||||
git add ml/monitor.html ml/pstate.py && git commit -m "monitor: 开环指标两张图；pstate: train 归档加 review_*"
|
||||
git pull --rebase gitea main
|
||||
git log --oneline -3 # 最上面应是你的 monitor 提交，其下是 Hark 的「fix(kin/diag): …」
|
||||
git push gitea main
|
||||
```
|
||||
|
||||
- 训练控制台若开着，先点「停止」，确认没有 python 训练进程在跑。
|
||||
- 不要启动 DAgger / M5，等 Hark 看完第 1、2 步的结果再定。
|
||||
- 训练控制台若开着先点「停止」，确认没有 python 训练进程在跑。
|
||||
- 不要启动 DAgger / M5，等 Hark 看完第 1、2 步结果再定。
|
||||
|
||||
## 第 1 步：gaps 显存峰值（不到 1 分钟）
|
||||
|
||||
@@ -32,68 +41,23 @@ EOF
|
||||
```
|
||||
|
||||
- 通过：三行峰值都 ≤ 2 GiB。
|
||||
- 任务管理器里专用显存接近 24 GB 或共享显存开始上涨：立刻 Ctrl+C，回传已打印的行，不要继续第 2 步。
|
||||
- 回传：终端输出的 3 行。
|
||||
- 专用显存接近 22 GB 或共享显存开始上涨：立刻 Ctrl+C，回传已打印的行，不要继续第 2 步。
|
||||
- 回传：终端 3 行。
|
||||
|
||||
## 第 2 步：闭环失败定位（约 2–4 分钟）
|
||||
## 第 2 步：闭环失败定位（含新加的 D 段，约 5–8 分钟）
|
||||
|
||||
```bash
|
||||
PYTHONUTF8=1 python -m ml.eval.diag_cl --ckpt ml/runs/base/last.pt --n 256 --out ml/runs/diag_cl.json
|
||||
```
|
||||
|
||||
- 运行期间看一眼任务管理器，专用显存应远低于 24 GB；超过 22 GB 就 Ctrl+C 并回传终端输出。
|
||||
- 回传：`ml/runs/diag_cl.json`、`ml/runs/replay_teacher.json`、`ml/runs/base/log.jsonl`。
|
||||
- 专用显存超过 22 GB 就 Ctrl+C 并回传终端输出。
|
||||
- 新增输出：`C.goal_err_ratio_p50`（0.5/1/2 s 时目标误差 ÷ 起点误差，<1 表示在靠近）；`D0_subhead`（冷启动子目标头精度）；`D1_no_sub`（不用子目标）；`D2_oracle_sub`（用老师真实途经点）。
|
||||
- 回传：`ml/runs/diag_cl.json`。
|
||||
|
||||
## 回传汇总
|
||||
|
||||
| 步骤 | 回传内容 |
|
||||
|---|---|
|
||||
| 1 | 终端 3 行峰值 |
|
||||
| 2 | ml/runs/diag_cl.json、ml/runs/replay_teacher.json、ml/runs/base/log.jsonl |
|
||||
| 2 | ml/runs/diag_cl.json |
|
||||
| 任一步出错 | 终端最后 30 行输出 |
|
||||
|
||||
---
|
||||
|
||||
## 执行回传（2026-10-19 02:35，本地 AI）
|
||||
|
||||
### 第 0 步：同步代码
|
||||
|
||||
分叉：本地 `5a87c06`（含 `ml/eval/diag_collision.py` 等本地提交，晚 02:00 前）与 `gitea/main` `573082d`（03:24 强推）各有 1 个提交；本地未提交改动 `ml/monitor.html`（开环指标两张图）、`ml/pstate.py`（train 归档加 `review_*`）。
|
||||
已 `git merge 573082d` 合流（工作区内容与 `573082d` + 未提交改动一致），未执行清单里的 `git reset --hard`，无训练进程在跑。
|
||||
注：本地现比 `gitea/main` 领先 2 个提交（合并提交 + 上述未提交改动尚未提交），未 push。
|
||||
|
||||
### 第 1 步：gaps 显存峰值（实测）
|
||||
|
||||
```
|
||||
n= 512 cap= 40 peak 1.20 GiB pairs=10724086
|
||||
n= 4096 cap= 4 peak 9.30 GiB pairs=14880476
|
||||
n= 4096 cap= 40 peak 9.30 GiB pairs=87180763
|
||||
```
|
||||
|
||||
**未通过（两条 4096 都是 9.30 GiB，>2 GiB）**。三行是独立新进程各跑一次的结果（排除分配器缓存假象），9.30 GiB 是可复现的确定值。
|
||||
|
||||
定位（在 `gaps()` 内插探针，不改行为）：
|
||||
|
||||
- 峰值全部出在**粗筛段**（`cc/d2/per`，一次材料到 491 组 × 67256 粗对）：4096 点第一次 `d2 = (cc[:,cp_a]-cc[:,cp_b]).pow(2)` 的广播中间量就 ~9.3 GiB。`[coarse]` 探针打到 9.30 GiB 后，后续 `[bounds]/[pre-loop]/[post-loop]/[cat-done]` 都不再涨。
|
||||
- 新加的分块（PAIR_BUDGET=2e6）**只对精算段生效**：本模型几何比注释里假想的大得多——1936 条胶囊 / 491 组 / 67256 粗对 / 104.7 万细对，4096 点粗筛幸存 **2.41 亿对**（cap=4 就已超预算 120 倍），分块确实在切（cap=4 切 121 块、cap=40 切 283 块，每块 10–45 点），每块精算峰值 ≤1.0 GiB。合计峰值还是被粗筛一条打回 9.3 GiB。
|
||||
- 512 点 cap=40 的 1.20 GiB 同样出自粗筛（512×67256 → 广播中间量 ~1.2 GiB），精算段只占其中一小截。
|
||||
- 旧版对比（`0b47905`，无任何分块）：同一三条独立实测 **4.59 / 16.98 / 36.89 GiB**——旧版 4096×40 的 36.9 GiB 在 24 GB 卡上必 OOM，与"dagger 吃满 24 GB、估计 30 GB"记录吻合。本版把 4096×40 从 36.9 降到 9.30 GiB（约 4.0×），但 4096 两条仍在 9.30，>2 GiB 门槛。
|
||||
|
||||
建议修复（未改代码，等你定）：粗筛也按 PAIR_BUDGET 同类逻辑分块（复用同一套 bounds），或把粗筛改成按粗对列分块累加 `per`；粗筛分摊到 ~200 万对/块后，预计三条都能回到 ≤2 GiB。
|
||||
|
||||
### 第 2 步：闭环失败定位（`ml/runs/diag_cl.json`，完整内容见该文件）
|
||||
|
||||
关键数字：
|
||||
|
||||
- **A（特征口径）：全组通过。** 最大差全部在 fp32 数值噪声量级（最大 3.6e-6，gaps 组；其余 ≤4.8e-7）。Python 现算特征与数据集 X 口径一致，**排除"闭环看到没见过的输入"这条路**。
|
||||
- **B（噪声下动作差）：无害。** 同一噪声两份特征的动作差 mean 5.1e-6°、p90 8.8e-6°，参照动作幅度 14.7°。
|
||||
- **C（失败形态，n=256）：**
|
||||
- 关安全层：到达 **0%**，碰撞 **99.6%**；首次碰撞 p10/p50/p90 = 0.4/1.46/3.52 s，仅 0.4% 在 0.1 s 内（不是"起步就撞"）。
|
||||
- 碰撞组对：**2-4 共 90 次**（J3-J5），其次 0-4（J1-J5）42、0-3（J1-J4）33、0-5 21、0-2 19、1-6 18。
|
||||
- 全程最小目标误差 p10/p50/p90 = 93/254/432 mm——**连 5° 都没保持，不是"接近到不了"，是根本走不到**。
|
||||
- 开安全层：到达 0.4%，碰撞 5.5%，刹车中位数 5 次——安全层把碰撞从 99.6% 压到 5.5%，但任务仍然到不了。
|
||||
|
||||
### 其余两个回传文件
|
||||
|
||||
- `ml/runs/replay_teacher.json`（00:41 开训前自检的产物，非本次新跑）：n=512，到达 1.0、碰撞 0.0、min_gap p10 0.5 mm、pass=true。
|
||||
- `ml/runs/base/log.jsonl`：末行 eval（step 14000）success 0.0、collision_rate 1.0、collision_steps_mean 268、ol_fk_mm 5.98、ol_best_mm 2.92、ol_div 0.655。与 C 段一致。
|
||||
|
||||
Reference in New Issue
Block a user