基于视觉的机器人端到端抓取系统实习复盘

这篇内容由实习期间的 Notion 笔记、阶段总结和工作周报整理而来。和原始笔记相比，这一版尽量保留项目推进过程：包括最开始的方案设想、为什么中途换路线、做过哪些尝试、踩过哪些坑，以及最后怎样把系统逐步跑通。相比只保留结论，我更想把这段经历写成一篇真正能看出“项目是怎么做出来的”的复盘。

一、项目概述

这段实习主要围绕一个基于视觉的机器人抓取系统展开。项目场景偏工程落地：机器人需要在水下作业相关场景中，对固定物体或特定目标完成识别、定位、抓取与装配辅助。

从任务定义上看，核心问题并不只是“识别物体”，而是要完成下面这条完整链路：

1. 相机采集图像或 RGB-D 数据
2. 识别目标物体
3. 重建或提取目标点云
4. 计算合理的抓取面和抓取位姿
5. 通过手眼标定把视觉结果转换到机械臂坐标系
6. 输出机械臂可执行的末端位姿

也就是说，这不是一个单独的识别项目，而是一条从视觉感知 → 几何处理 → 坐标变换 → 机械臂执行串起来的系统工程。

二、如果先用一句话概括我做了什么

如果从职责角度压缩，这段实习里我主要参与了四部分工作：

1. 抓取方案调研与路线选择

前期调研了多种 2D / 3D 抓取与分割方法，包括：

• GraspNet Baseline
• Graspness
• EconomicGrasp
• E3GNet
• Contact-GraspNet
• Grounding DINO
• SAM / EfficientSAM / MobileSAM / EdgeSAM

最开始想直接利用现成 6D 抓取模型完成目标抓取，后面发现“能输出抓取候选”并不等于“能抓到任务里真正想抓的那个面”，于是逐步把路线调整成“目标检测 / 分割 + 点云几何分析 + 姿态估计”的组合方案。

2. 点云抓取面提取与姿态估计

围绕目标点云的局部表面提取，参与实现和调试了：

• 点云滤波 / 下采样
• 法向量估计
• DBSCAN / 距离聚类
• RANSAC 平面拟合
• PCA 主方向与法向提取
• 抓取面筛选与姿态估计

这部分的目标，不是只输出一组“看起来能抓”的 grasp，而是更明确地找到最适合机械爪接近的那个局部平面。

3. 手眼标定、坐标变换与机械臂联调

项目里还参与了：

• 单目 / 双目视觉场景下的手眼标定流程学习与测试
• 相机坐标系到机械臂基底坐标系的转换整理
• 机械臂姿态控制相关接口联调
• 欧拉角顺序、末端姿态方向等问题排查
• 水下视觉场景中的标定误差分析

4. 系统工程化与自动化升级

除了算法部分，还做了一些比较偏工程落地的事情：

• 抓取流程一键启动
• 标定模块重构
• 文件路径自动传递
• 标定类型自动识别
• 后台进程管理
• 模块文档 / 使用文档整理
• 从纯人工交互流程升级为“自动推荐 + 人工确认”的双模式流程

如果从结果上看，这段实习不只是“调了几个模型”，而是逐步把一条原本比较分散的抓取流程往可运行系统推进。

三、项目真正要解决的是什么问题

从项目视角看，真正需要解决的是两个问题。

1. 如何识别目标物体并提取抓取位姿

最终需要得到的不是简单的类别标签，而是：

• 目标在哪里
• 目标上哪个面更适合抓
• 机械爪应该从什么方向接近
• 最终抓取点和姿态是什么

2. 如何把视觉结果稳定转换成机械臂可执行位姿

即使视觉侧已经得到了抓取点和法向量，如果没有完成下面这些步骤，整个系统依然不能闭环：

• 手眼标定
• 相机坐标系到机械臂基底坐标系的转换
• 姿态表示统一（旋转矩阵 / 欧拉角顺序）
• 机械臂控制接口联调

所以这个项目的真正难点不是某一个算法模块，而是整条链路能不能稳定跑通。

四、前期调研：为什么一开始会考虑通用 6D 抓取模型

项目初期，最直观的想法其实是直接使用现有的抓取检测模型，从图像或点云中直接输出 6D 抓取姿态。

从调研过程看，抓取方法大致可以分成：

• 平面级抓取：估计抓取接触点或定向矩形
• 空间级抓取：面向对象或面向场景的 6D 抓取

这里也整理过一批典型方法，包括：

• GPD
• PointNetGPD
• GraspNet Baseline
• Graspness
• EconomicGrasp
• E3GNet
• Contact-GraspNet
• Scale Balanced
• ZeroGrasp

之所以一开始会考虑 EconomicGrasp / GraspNet 这类方法，主要是因为：

• 有开源实现
• 能直接输出抓取候选
• 在公开数据集上效果不错
• 如果能跑通，理论上可以减少很多几何后处理步骤

其中，EconomicGrasp 比较吸引人的地方在于它更轻量、工程成本也相对友好；而 GraspNet / Graspness 这类工作则更偏经典 6D 抓取基线和强基准路线。

五、第一轮现实反馈：现成 6D 抓取模型为什么不够用

真正跑到实际目标时，问题很快暴露出来。

项目里更关心的并不是“任意抓一下”，而是抓取特定目标物体的特定表面。例如白色把手这种目标，希望机械爪从更合理的前端面或目标面接近，而不是从边缘随意夹取。

这时通用 6D 抓取模型常见的问题就出来了：

• 输出的是一组“可抓”候选，而不是“任务上最想抓的那个位姿”
• 模型训练分布和当前场景差异很大
• 对特定物体、特定抓取面、特定接近方向的约束不够强

更具体一点说，公开抓取数据集里很多目标更像桌面物体抓取，模型更擅长回答“哪里能夹住”，但并不真的理解“这个任务里应该从哪个面抓才合理”。

这意味着：

仅靠通用抓取模型，并不能稳定解决“目标导向抓取”问题。

这个判断其实很重要。因为项目后面的很多路线调整，都是从这里开始的。

六、问题转向：从“直接抓取检测”改成“目标导向抓取”

后面逐渐明确了一件事：

如果目标只有一个特定把手或特定部件，那么重点不只是检测 grasp，而是先准确锁定目标，再在目标局部空间里求理想抓取位姿。

于是整体思路开始转向两阶段：

1. 先通过目标检测 / 分割把目标从复杂背景中分出来
2. 再在目标局部空间里做抓取面提取和位姿估计

这也是后面为什么会把更多精力放在：

• SAM
• Grounding DINO
• 点云分割与平面拟合
• 法向量分析
• 人机交互与自动化筛选

而不是继续死磕“一个模型端到端全包”。

七、围绕特定目标抓取做过哪些尝试

7.1 人工框选、模板匹配这类朴素方案

一开始也尝试过更直接的路线，例如：

• 人工框选
• 特征提取
• 模板匹配

但后面没有继续深入，原因主要是：

• 对目标尺度和旋转敏感
• 泛化能力差
• 在复杂场景里鲁棒性不够

所以这条路线更多停留在快速验证层面，没有作为最终方案。

7.2 为什么选择 Grounding DINO + SAM 路线

前期调研时大致看了两条路：

• 有样本方案：例如 YOLO / FastSAM 这类需要数据集训练的路线
• 无样本方案：例如 Grounding DINO + SAM

因为实际工程场景的数据采集、标注和泛化都比较麻烦，所以更偏向先尝试无样本路线。这样可以直接通过文本提示词锁定目标，再用分割模型切出目标区域。

这里的思路就是：

• DINO 负责“找到目标”
• SAM 负责“把目标像素级分出来”
• 深度图负责“把 2D mask 变成 3D 点云”

7.3 Grounding DINO 的价值

DINO 这条线的价值在于：

• 不强依赖专门数据集
• 可以零样本目标检测
• 能通过语义提示词描述目标

这一点很适合“目标明确但数据少”的工程场景。

7.4 DINO + EconomicGrasp 的组合尝试

后面做过一条比较自然的组合路线：

• 先用 DINO 检测目标
• 再用检测结果去过滤或约束 EconomicGrasp 的抓取候选

这样就不再是“整图随便抓”，而是希望把抓取候选限制到目标物体上。

这条路线能一定程度上缓解“抓错物体”的问题，但还不能保证抓取面就是理想面。也就是说，它解决了“抓哪个物体”的一部分问题，却没有彻底解决“从哪个面抓”这个更核心的问题。

八、SAM 系列模型测试：不是只看精度，也要看部署和场景表现

在实际分割过程中，一个很现实的问题是：

• 背景和目标颜色接近
• 白色把手和浅色背景容易混淆
• 模型大小、推理速度和精度之间必须权衡

因此后面专门比较了：

• SAM ViT-H
• MobileSAM
• EfficientSAM
• EdgeSAM
• FastSAM

这里一个比较明确的结论是：

• SAM ViT-H 效果强，但模型大、速度慢
• EfficientSAM 在一些背景颜色分割上反而更实用
• EdgeSAM / MobileSAM 在速度上更适合边缘设备思路

也就是说，模型参数量小不一定代表整条推理链更快，瓶颈有时候出现在 decoder，而不只是 encoder。

项目里也做过一些实际测试，例如：

• DINO + SAM 的组合验证
• EfficientSAM 对目标分割的替代测试
• 比较不同 SAM 版本在速度和分割质量上的差别

这些测试最后并没有导向“选一个完美模型”，而是帮我更清楚地知道：

2D 分割只是入口，真正决定抓取得是否合理的，还是后面的 3D 几何处理和姿态筛选。

九、路线进一步收敛：从点云角度重新定义抓取面问题

通用 6D grasp 检测不够稳定之后，问题被重新表述成：

先把目标物体从图像里分离出来，再在目标点云里找“最适合抓”的那个平面。

这个思路虽然没有端到端那么“整齐”，但更符合当前项目需求。

对把手类目标来说，一个重要观察是：

• 最前端抓取面和周围面在法向上通常有明显差异
• 前后表面虽然可能法向类似，但空间位置不同
• 局部平面如果能稳定提出来，就能进一步计算抓取姿态

因此后面形成的处理思路大致是：

1. 目标分割
2. 深度图转点云
3. 点云滤波 / 下采样
4. 法向量估计
5. 法向聚类 + 距离聚类
6. RANSAC 平面拟合
7. PCA 提取法向与主方向
8. 输出抓取点和抓取姿态

这一步其实是项目里非常关键的转折点：

• 前面更多是在“找目标”
• 到这里开始真正进入“找抓取面”

十、平面提取与姿态估计：这部分是怎么一点点试出来的

10.1 为什么最后会是“法向聚类 + 距离聚类 + RANSAC + PCA”这套组合

这个组合基本是反复试出来的一条相对稳定路线：

• 法向量聚类：先按方向把不同面分开
• 距离聚类：进一步把前后法向相近但空间位置不同的面拆开
• RANSAC 平面拟合：过滤噪声，得到稳定平面
• PCA 主成分分析：提取平面主方向和法向量

这条路线的出发点其实很工程化：不用追求一步到位的神经网络解法，而是优先把一个“可调、可解释、可验证”的几何流程跑顺。

10.2 为什么后来又加入 UI 交互

后来项目里又加入了交互式 UI，这一步很关键。

因为即便算法已经能给出候选平面，真实场景里依然会遇到：

• 点云质量波动
• 遮挡
• 反光或水下图像退化
• 参数稍有变化就导致平面不稳定

所以实际做法不是完全“黑盒自动化”，而是先支持：

• 点云可视化
• 自由旋转视角
• 2D 框选目标区域
• 锁定视角后局部处理
• 在框选区域内进一步做深度过滤和几何拟合

这等于在鲁棒性和可控性之间取了一个平衡。

这部分也让我对工程项目里一个很现实的事实有了更直接的理解：

很多时候，比起追求完全自动化，一个“自动推荐 + 人工确认”的流程更容易真正落地。

十一、自动化升级：从纯人工交互到半自动推荐

后面一段时间里，比较核心的工作其实就是把原本重度依赖人工的流程，升级成自动推荐 + 人工确认的双模式系统。

11.1 自动化升级的核心问题

系统要想从“能跑”走向“好用”，至少要解决两个算法问题：

问题 1：如何让系统自动识别并对齐法向量？

解决思路是把相机视野方向 [0, 0, 1] 作为参考基准：

• 先对候选平面法向量做方向校正
• 再计算法向量与视野方向夹角
• 过滤掉偏转角过大、不适合正面抓取的平面

问题 2：如何剥离复杂背景并精准锁定抓取面？

这里形成的方案是：

• 深度过滤
• SOR 去噪
• RANSAC 迭代多平面拟合
• 多候选平面评分与择优

11.2 四维评分机制是怎么来的

为了从多个候选平面中自动选出“最值得抓的那个”，后来设计了一套四维评分机制：

• 前端性（40%）：平面越靠近相机越优先
• 法向量一致性（30%）：越符合抓取姿态越优先
• 平整度（20%）：平面越稳定越优先
• 面积 / 点数（10%）：剔除过小干扰面

这一步很重要，因为它相当于把“人工挑平面”的经验，尽量编码成了程序逻辑。

11.3 具体参数调优

在工程实现里，还调过一批关键参数，比如：

• ransac_threshold = 0.002（2mm）
• ransac_n = 3
• ransac_iterations = 1000
• min_plane_points = 150

其中一个具体优化是把 RANSAC 内点距离阈值降到 2mm，避免拟合出明显偏斜的平面。

这类调参工作单看很碎，但它其实决定了系统是“经常出奇怪结果”，还是“在多数情况下都能给出一个可用候选”。

11.4 自动化带来的实际收益

这次自动化升级最直接的收益不只是“少点几下鼠标”，而是：

• 原本 13 分钟的人工操作流程，被压缩到 23 秒自动运行
• 自动结果不满意时，还能无缝退回交互模式
• 系统从“实验脚本”更接近“工程工具”

十二、实际踩坑：2D 分割、深度过滤和目标表面提取并没有想象中顺

如果只看最终结果，会觉得路线好像很自然，但实际中间有不少不顺的地方。

12.1 白色目标和背景白色混淆

这是一个很典型的问题：

• 2D 分割模型在颜色接近的场景下容易把背景和目标混在一起
• 对白色把手这类目标尤其明显

这里的处理思路包括：

• 比较不同 SAM 系列模型
• 引入深度图辅助过滤背景平面
• 把 2D mask 和深度信息结合起来做后处理

后面发现，单纯“先分割再直接用”通常不够，还是得配合深度和点云结构信息一起处理。

12.2 深度图里会有异常值

后面在尝试用深度图过滤背景时，又发现深度数据里会存在异常值。这一步提醒我：

• 深度信息不是天然可靠的
• 前景提取失败时，不一定是分割错了，也可能是深度本身有噪声和离群点

所以后面才会继续加入阈值、去噪和候选筛选，而不是只相信一张 mask。

12.3 RANSAC 找到的平面不一定是真正想要的抓取面

这也是一个很关键的认识。

RANSAC 更擅长找“拟合意义上最好的平面”，但这个平面不一定就是任务里最适合抓取的那一个。也正因为这样，后面才会：

• 做多平面提取
• 设计评分机制
• 再保留人工确认入口

所以整个系统后面的形态，其实是被这些实际问题一步步逼出来的。

十三、手眼标定与坐标变换：系统闭环里最容易被低估的部分

视觉侧求出抓取点和法向量之后，后面还有一道非常关键的门槛：手眼标定和坐标变换。

13.1 为什么这部分会卡很久

因为视觉里得到的抓取位姿往往是在：

• 相机坐标系
• 图像坐标系
• 点云局部坐标系

但机械臂真正执行时需要的是：

• 机械臂基底坐标系下的位姿
• 与控制接口一致的姿态表示
• 统一的欧拉角顺序或旋转矩阵表达

只要中间哪一步定义不一致，最后抓取就会明显偏掉。

13.2 实际踩过的坑

这个项目里实际踩到的典型问题包括：

• 夹爪物理方向和算法假设轴向不一致
• 欧拉角顺序不明确
• 是绕基底坐标旋转还是绕末端坐标旋转没有统一
• 手眼标定外参矩阵误差过大
• 仿真看起来正常，实际上机位置明显偏差

后面逐步确认下来的一些关键点包括：

• 夹爪对应方向实际是 Y 轴 而不是 X 轴
• 欧拉角顺序需要明确为 ZYX
• 手眼标定最终重新采用了更合适的 AX=XB 路线

13.3 水下标定问题带来的额外复杂度

周报里还记录了水下标定测试相关内容，这部分让我对“实验环境差异”有了很直接的体感。

水下视觉和普通陆地标定最大的不同在于：

• 折射会破坏理想线性成像模型
• 密封舱、玻璃界面、空气层都会引入额外变量
• 图像几何畸变和背景噪声会影响角点提取

所以水下双目标定、重投影误差和深度估计的稳定性，比最开始想象的复杂得多。

十四、工程重构：从“很多脚本”到“相对清晰的流程”

除了算法本身，实习期间还有一块很重要的工作是系统工程化。

14.1 标定模块重构

项目早期存在多套相互独立的标定脚本，例如：

• 单目眼在手上
• 单目眼在手外
• 双目眼在手外

这些脚本的参数、路径、调用方式都不统一，维护成本很高。后面做了一轮统一整理，包括：

• 标定结果文件命名规范化
• 路径自动映射
• 根据标定类型自动选择流程
• 执行入口统一

14.2 一键启动系统

原始流程往往需要：

• 手动开多个终端
• 分别运行 UDP 服务器、相机采集、平面提取、抓取执行
• 人工复制输入输出路径

后面把这些串成了一条流程：

1. UDP 服务器
2. 相机采集
3. 平面提取
4. 抓取执行

并加入：

• 后台进程管理
• 文件自动查找
• 路径自动传递
• 基础错误处理

14.3 文档建设

另一项很实际的工作是把原本分散在代码里的使用方式、路径和参数整理成文档，包括：

• 使用指南
• 模块级 README
• 常用命令参考
• 标定结果说明

这部分的意义在于：

• 新同学更容易接手
• 调试路径更清晰
• 系统从“只能作者自己运行”变成“别人也能跑”

十五、如果从“问题—尝试—调整—结果”来总结这段经历

我觉得这段项目最值得保留的，不是最后选了哪些方法，而是整条演化过程：

1. 最开始的设想

先用现成 6D 抓取模型，尽量少做后处理，直接输出抓取位姿。

2. 第一轮反馈

模型能给 grasp 候选，但抓的不是任务里真正想抓的那个面，目标导向能力不够。

3. 第一次调整

引入目标检测 / 分割，先解决“抓哪个物体”的问题，于是开始尝试 DINO、SAM 这条路线。

4. 第二轮反馈

目标能大致框出来，但“框出目标”不等于“得到理想抓取位姿”；2D 结果还需要进一步投到 3D 空间里处理。

5. 第二次调整

把重点转到点云局部几何分析上，用法向、聚类、RANSAC、PCA 去找最合适的抓取面。

6. 第三轮反馈

几何路线更可控，但在复杂场景里还是会受参数、噪声和候选平面选择影响。

7. 第三次调整

加入 UI 交互、深度过滤、多平面提取和评分机制，把流程从纯人工推进到半自动推荐。

8. 最后真正卡住系统闭环的地方

不是分割模型，也不是点云算法，而是手眼标定、姿态表示和机械臂坐标链路的一致性。

这个总结对我自己也挺重要，因为它让我更清楚地意识到：

真实机器人项目里，问题往往不是靠某一个模型一把梭解决的，而是靠不断缩小问题、拆分模块、重新定义路线，一点点把系统拼起来。

十六、结果与项目价值

这段实习里最直接的成果，并不是某一个单点指标，而是把一条原本比较分散的流程逐步跑通了。

从结果上看，至少实现了下面这些事情：

• 把目标检测、图像分割、点云处理、抓取位姿估计、手眼标定和机械臂执行串成了一条完整流程
• 将原本重度依赖人工的平面提取过程升级为“自动推荐 + 人工确认”的半自动化流程
• 将原来 13 分钟的人工处理流程压缩到 23 秒自动运行
• 对抓取系统中的标定、路径、启动流程和文档做了工程化整理，提高了系统可维护性和可交接性

如果从更大的角度看，这段工作的价值不只是“做了个 demo”，而是把一个机器人视觉项目从“单点算法尝试”往“可运行系统”推进了一大步。

十七、如果在面试里讲这段项目，我会怎么讲

如果把这段项目经历压缩成面试表达，我觉得比较合适的说法是：

这段实习里，参与的是一个机器人视觉抓取系统，不只是做单一算法，而是从目标识别、点云抓取面提取、姿态估计、手眼标定到机械臂执行链路都接触过。前期调研过通用 6D 抓取模型，但在实际场景里发现“能抓”和“抓得对”不是一回事，所以后面把路线改成了“目标检测 / 分割 + 点云几何分析”的组合方案。自己参与实现了目标点云上的平面提取、法向估计、RANSAC + PCA 姿态计算、平面自动评分，以及一部分手眼标定和系统自动化改造工作。最大的收获是更清楚地理解了机器人视觉项目里算法、坐标变换和工程实现是怎么真正串起来的。

这段表述比单纯列模型名更能体现：

• 做过真实项目
• 不只是看论文
• 能从问题出发调整路线
• 理解系统闭环而不是单模块实现

十八、这段实习里最核心的收获

回头看，这段经历最大的收获不是“学会了某个模型”，而是下面几件事：

1. 端到端模型不一定就是工程最优解

很多时候，真正落地的问题并不是“模型 AP 更高”，而是：

• 目标是不是特定对象
• 数据能不能采
• 模型能不能部署
• 结果是不是可解释
• 失败时能不能快速定位问题

2. 点云几何方法虽然朴素，但很有工程价值

法向量、聚类、RANSAC、PCA 这些方法听起来没有大模型那么显眼，但在受约束的工程场景里，往往更稳、更可控。

3. 手眼标定和坐标变换是系统能否闭环的关键

视觉做得再好，如果坐标链不对，最后机械臂还是抓不到。这个认知是通过很多次调试和踩坑才真正建立起来的。

4. 工程能力本身就是成果的一部分

一键启动、模块重构、自动化配置、文档整理，这些工作不一定体现在论文标题里，但它们直接决定了系统到底是“能演示一次”，还是“能长期维护和反复运行”。

十九、后续还值得继续做的方向

如果把这个项目继续往下推进，后面值得继续做的方向大致有：

1. 更强的目标导向抓取模型
   • 结合视觉、语言和抓取动作的多模态方法
2. 更稳定的目标分割与 2D-3D 联动
   • 解决遮挡、颜色混淆、深度异常值问题
3. 更自动化的平面筛选与参数自适应
   • 自动寻找更优深度阈值和评分参数
4. 更严格的标定与误差建模
   • 尤其是水下折射场景
5. 边缘设备部署优化
   • 针对 Jetson / NX 等板卡做轻量化与实时性优化

二十、总结

如果用一句话概括这段实习，我更愿意把它理解为：

在一个真实机器人视觉项目里，把“目标识别、点云处理、抓取位姿估计、手眼标定、系统自动化”这几条原本分散的链路，逐步拼接成了一个能实际运行的整体系统。

这段经历里既有模型调研，也有几何方法实现；既有坐标变换和手眼标定，也有 UI、自动化和文档重构。相比只停留在单点算法层面，这种完整链路上的参与，更能体现真实项目经验、问题分析能力和工程落地能力。