Files
arm_dev 806efe4df1 修掉两个"存在但跑不起来"的脚本:CRLF 行尾 + 新增 .gitattributes 统一为 LF
症状(没有报错,只有"文件在、文档说能用、一跑就死")
    $ bash scripts/run_hole_detect.sh --arm 89 --preview
    scripts/run_hole_detect.sh: 行 11: $'\r': 未找到命令
    scripts/run_hole_detect.sh: 第 12 行: set: pipefail: 无效的选项名
  另一处 $'\r': 未找到命令 来自 scripts/run_dual_gripper.sh(同样症状)。

根因
  这两个 .sh 是 100% CRLF 行尾。bash 会把行尾的 \r 当成标识符的一部分,
  于是 `case "$1" in\r`、`set -eo pipefail\r` 全部变成非法记号。
  而文档在五处告诉用户跑它:README.md、docs/WORKSPACE.md、docs/ARCHITECTURE.md、
  docs/SITE_CONFIG.md、docs/HOLE_DETECT.md(HOLE_DETECT.md 直接给了命令)。
  即"文档齐全、文件存在、命令一敲就死",报错信息里的那个 \r 又完全看不出来。

为什么之前没人发现(这是本次真正的教训)
  bash -n 会漏报:对 run_dual_gripper.sh 它返回 OK,可实际执行立刻死在第 6 行。
  所以"静态检查通过"不能当成"脚本能用"。验脚本要么真跑 --help,要么用
  file/bat 看行尾。这条已写进 .gitattributes 的注释里。

改了什么
  1. scripts/run_hole_detect.sh、scripts/run_dual_gripper.sh 由 CRLF 改为 LF。
     去行尾符后与改前逐字节相同 —— 只动行尾,一个字符内容都没动。
     已验证:两个脚本 bash -n 通过,且 run_hole_detect.sh --help 能正常打印中文帮助。
  2. 新增 .gitattributes:
       * text=auto eol=lf      —— 本仓库自己的文件一律 LF
       /src/flexiv_*/** -text  —— 厂商上游代码内容与行尾都不动(R4.4)
       /thirdparty/** -text
       *.onnx/*.engine/*.trt 等二进制显式标 binary,避免被当成文本转换
  3. 顺带把本仓库其余 19 个仍是 CRLF 的文件(.py 9 个、.yaml 2 个、.launch.py 2 个、
     .msg 5 个、.srv 1 个)统一为 LF。这些文件在 Python/YAML 下本来能正常读,
     所以此前没有症状;但同一仓库混着两种行尾,下次再有一个 .sh 中招就是必然。
     已核对:去掉行尾符后与 HEAD 逐字节相同 —— 内容零变化。

验收
  21 个文件:git diff --ignore-cr-at-eol -w 只列出 .gitattributes(零内容变化)
  scripts/*.sh scripts/lib/*.sh:bash -n 失败数 0(改前是 2)
  单测:608 passed,与改动前一致

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-23 17:41:06 +08:00

36 lines
1.5 KiB
Markdown
Raw Permalink 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.
# 入孔检测权重
> **改这个目录之前先读 [`../README.md`](../README.md)**(权重模块的规则)。
用于"把孔当框来检测"的模型(`hole_detect.backend: yolo`)。
当前现场用的是 `two_stage`(两阶段)后端,它用的是**工件**权重
(`hole_detect.workpiece_weights`,指向 `models/yolo/` 里的模型),
本目录的模型并不是每次都会用到。
## 现状
- `detect_best_1.onnx` —— 被 `hole_detect.workpiece_weights` 使用(`two_stage` 后端)。
这是本目录唯一在用的模型。
## 已修掉的悬空引用
`config/site.yaml` 的 `paths.hole_weights` 与 `hole_detect.weights` 原先都指向
**不存在**的文件 `models/hole_insert/best.pt`。`backend: two_stage` 时这两处不被读取,
所以一直没暴露;一旦切成 `backend: yolo` 就会启动失败。
现已改为实际存在的 `detect_best_1.onnx`。同一个悬空的 `best.pt` 还藏在代码里
(`hole_detector.py` 的 `weights_from_site` / `_default_model_path`,那里三个候选
路径全都不存在,函数却总会返回第一个),也一并修成了以 site.yaml 为准、
再退到实际存在的模型。
改权重相关路径后,用 `bash ~/ros2/scripts/weights.sh doctor` 复查悬空引用。
## 加新模型 / 看标签
和 `models/yolo/` 完全一样,只是分组名换成 `hole_insert`:
```bash
bash ~/ros2/scripts/weights.sh convert staging/xxx.onnx --name hole_detect --group hole_insert
bash ~/ros2/scripts/weights.sh labels detect_best_1 --group hole_insert
```