“把衣服拿到洗衣机旁”听起来是一句指令落到代码里却是一串条件先找到人等衣物交接再找到洗衣机最后才是移动和放下。我翻了启元开源组织里的carry-clothes项目。任务流程已经写好视觉接口也留好了但默认的HeuristicDetector返回空列表--sim使用的SimDetector则从模拟世界读取目标信息并没有真的看图。这次就补其中一块让真实模型看照片把结果送进原项目的“寻找洗衣机”分支。推理跑在一台 RTX 5070 Ti 上动作端沿用 Mock不连接真机。这样可以把“模型有没有看见”和“技能有没有接受”放在同一条日志里检查。两张公开实拍照片上的实际预测框。左图Adrian Pingstone公有领域右图Fanti SalmsCC BY-SA 3.0。本图做了缩放、方向校正和检测框标注衍生图按 CC BY-SA 3.0 提供。1. 从一个能替换的接口开始启元的示例面向 T1视觉入口在src/vision.py输入 JPEG 字节输出Detection列表。_s7_find_washer()负责寻找洗衣机取图、调用检测器、检查类别和分数找到就返回找不到继续搜索超时则抛出TaskAborted。因此不用重写整套任务。本次只实现检测器、接入这一个阶段并给它加连续确认。接人、抱衣物和实际导航不在这次实验里。模型选用 OWL-ViT base-patch32。它可以根据文字查询返回目标框本文固定查询prompta photo of a washing machine这里用的是目标检测模型不需要让聊天模型先写一段解释再从回答里猜坐标。识别类别也明确限定为洗衣机避免把别的高分目标交给后面的伺服器。完整代码放在实验仓库的 vision-skill 目录。复现命令gitclone https://atomgit.com/gcw_JBmPZT05/primebot-mujoco-lab.gitcdprimebot-mujoco-lab/vision-skillbashcode/setup.sh# 单张图片保存检测框并在终端打印分数、坐标和耗时.venv/bin/python code/infer.py assets/washer_normal.jpg# 图片对照、技能分支、异步指令循环.venv/bin/python code/probe.py .venv/bin/python code/skill_demo.py .venv/bin/python code/loop_demo.py环境是 Ubuntu 22.04、Python 3.11.16、PyTorch 2.7.1cu128、Transformers 4.51.3。脚本固定了启元源码和模型的提交版本模型下载后从本地加载。没有 ROS2也不用云端推理 API。创建虚拟环境需要uv或可用的 Pythonvenv。2. 框找到了坐标单位别接错模型输出的是像素坐标[x1, y1, x2, y2]。接入时要转成示例所需的字段Detection(labelwashing_machine,confidencescore,# 保留模型原始分数cx(x1x2)/width-1,cy1-(y1y2)/height,heighty2-y1,# 这里传像素高度)cx以画面中心为零右侧为正cy向上为正。模型输出的越界框先裁剪到图像范围再做转换。height是这次遇到的第一个坑。Detection的字段注释写着“归一化框高度”但VisualServo.estimate()实际使用的是distancefocal_px_per_m*target_height_m/detection.heightSimDetector自己也传像素高度。接入时应以实际计算为准不能只照字段注释写。以图 A 为例模型框高约 581.7 像素。沿用示例中的焦距数值 900 和目标高度 0.85公式结果约为 1.32 米如果误传581.7 / 684计算结果会先膨胀到约 900 米再被代码限幅到 12 米。这只是接口算例并非照片的真实距离照片的相机没有按上述参数标定。本文因此只验证搜索和转向指令不用这个距离驱动前进。3. 遮挡以后调低门槛真的有用吗我给两张照片分别做了亮度降低和灰条遮挡再加一张没有洗衣机的 Q1 渲染图与纯灰图。共八种输入用来检查接口行为不把它们当成八个独立场景统计识别率。输入最高候选分数按 0.5 门槛处理图 A 原图0.679通过图 B 原图0.757通过图 A / B 亮度降至 25%0.720 / 0.697通过图 A / B 加灰条遮挡0.240 / 0.167拒绝无洗衣机的机器人画面0.015拒绝纯灰画面0.001拒绝调暗后分数没有下降不能据此说暗光一定更好识别它只说明这两张变换后的图片仍能通过。真正要盯住的是中间的遮挡图模型把洗衣机上半截当成了目标框。把门槛从 0.5 降到 0.12它确实能“检测成功”。但框高已经缩短到约 179.4 像素。同一套公式得到的距离从 1.32 米变成约 4.26 米。物体并没有变远只是框变短了。分数够不够与框能不能用于测距是两件事。0.5 也不是通用正确值这里保留示例门槛做对照0.12 专门用于暴露错误放行不能当成推荐参数。模型分数更不能直接解释为现实世界中的正确概率。4. 让技能亲自跑一次判断检测器外面加一个小门控连续三次通过分数门槛并且相邻框的 IoU 不低于 0.5才把结果交给技能。没有目标就清零计数且始终保留原始分数不把低分改写成高分。接着用PhotoBot继承原项目的MockPrimeBot只替换取图方法按指定顺序返回照片。实际调用的仍是原来的_s7_find_washer()唯一的任务源码调整是把写死的 0.5 提取成配置项补丁保存在results/upstream.patch。搜索超时设为 1.2 秒Mock 的模式切换等待设为零缩短回归测试。结果如下测试实际结果占位检测器 正常照片超时抛出搜索失败异常真实模型无目标 → 正常照片连续三次第 4 次取图后搜索正常返回始终没有目标超时退出正常照片、无目标画面交替确认计数反复清零超时退出遮挡照片门槛 0.5超时退出同一遮挡照片门槛 0.12第 3 次取图后放行但框不完整这里“搜索正常返回”表示找到目标条件成立后续才会进入前往洗衣机的阶段不代表搬运任务已经完成。测试还检查了每种分支最后都调用停止、搜索过程中前进速度始终为零。最后一行尤其有意思连续三帧只能过滤闪烁挡不住连续三次都相同的错误框。重复输入静态照片就是为了把这个问题单独暴露出来。5. 模型跑得挺快为什么循环还是慢了在 5070 Ti 上以 FP32、batch size 1 运行预热 5 次再对图 A 重复推理 40 次完整detect()的中位耗时为34.71 msP95 为35.27 ms。计时包含图片解码、预处理、GPU 推理和框后处理并在两端同步 CUDA不含模型加载和文件读取。单张图片 CLI 的首次推理为 391.55 ms启动阶段仍要单独预热。PyTorch 记录的峰值已分配显存约644 MiB这不等于nvidia-smi显示的整进程占用。这个小模型用不上 16 GB 显存的大部分空间。但示例搜索循环希望每 20 ms 下发一次指令。把 35 ms 的推理同步塞进去哪怕不再sleep也赶不上原定频率。目标缺失的那组实测中相邻搜索指令的中位间隔是36.21 ms。我另写了一个独立的 Mock 循环推理线程只发布最新观测指令线程按 50 Hz 读取画面超过 300 ms 没更新指令归零。# captured_at 在获取图像时记录不能在推理完成后才开始计时。agetime.monotonic()-captured_atifage0.30ornotconfirmed_detections:yaw0.0else:yawmax(-0.25,min(0.25,confirmed_detections[0].cx*0.4))bot.drive(0.0,0.0,yaw)完整脚本有锁保护、异常退出和finally: bot.stop()。这段只演示水平对准前进速度一直为零它是独立验证的改造方式没有声称整个上游任务已完成异步改造。这次运行 2 秒共记录 100 个指令周期中位间隔20.00 ms最大21.91 ms。运行到 1.2 秒时故意停止提供新画面约 1.5 秒后旧观测过期输出归零。这里验证的是桌面 Python 与 Mock 的实际时序不是机器人控制器的实时性保证。6. 换成自己的照片试一遍先别动模型和阈值换一张图最直接.venv/bin/python code/infer.py /path/to/your-photo.jpg\--outputresults/my-photo.png先看框有没有包住整台洗衣机再看类别和分数最后才把它交给技能。接自己的视频或相机时还要保留真正的取帧时间断流后反复返回同一张旧图不能算“新画面”。这次最有用的结果就是把这几个检查留在了代码里框的像素单位、三帧确认、搜索超时和观测过期。换模型时沿着这条链路再跑一次比只看一张漂亮的检测截图更容易发现问题。代码入口本地视觉与技能分支实验接口依据启元 carry-clothes、OWL-ViT 文档。这次最有用的结果是把像素单位、三帧确认、搜索超时和观测过期这些检查留在了代码里。沿着启元机器人开发者社区开源技能的接口继续扩展时我也会保留这些检查识别结果要足够可靠失败要能退回技能才有机会从一张检测图走到完整任务。