Files
Robot_Arm/docs/本机执行清单.md
T

100 lines
6.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 本机执行清单(给本地 AI 逐条执行)
本文件是 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 自动分块),尚未实测。
## 第 0 步:同步代码
```bash
git fetch gitea && git reset --hard gitea/main
git log --oneline -1 # 应为「fix: 闭环失败定位与显存修复……」或更新
```
- 训练控制台若开着,先点「停止」,确认没有 python 训练进程在跑。
- 不要启动 DAgger / M5,等 Hark 看完第 1、2 步的结果再定。
## 第 1 步:gaps 显存峰值(不到 1 分钟)
```bash
PYTHONUTF8=1 python - <<'EOF'
import torch
from ml.common.kin_torch import Kin
kin = Kin(device='cuda')
for n, cap in [(512, 40.0), (4096, 4.0), (4096, 40.0)]:
q = kin.lo + (kin.hi - kin.lo) * torch.rand(n, 6, device='cuda')
torch.cuda.empty_cache(); torch.cuda.reset_peak_memory_stats()
with torch.no_grad(): kin.gaps(q, cap)
print(f'n={n:5d} cap={cap:4.0f} peak {torch.cuda.max_memory_allocated() / 2**30:6.2f} GiB', flush=True)
EOF
```
- 通过:三行峰值都 ≤ 2 GiB。
- 任务管理器里专用显存接近 24 GB 或共享显存开始上涨:立刻 Ctrl+C,回传已打印的行,不要继续第 2 步。
- 回传:终端输出的 3 行。
## 第 2 步:闭环失败定位(约 2–4 分钟)
```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`。
## 回传汇总
| 步骤 | 回传内容 |
|---|---|
| 1 | 终端 3 行峰值 |
| 2 | ml/runs/diag_cl.json、ml/runs/replay_teacher.json、ml/runs/base/log.jsonl |
| 任一步出错 | 终端最后 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 段一致。