机器人视觉项目这行最不缺的就是Demo最缺的是从进场到交付这条路上活下来的经验。我做过几个视觉引导抓取和定位类的项目有产线改造的也有全新集成的每次复盘都会发现真正让项目翻车的往往不是算法精度不够而是标定链路没对齐、通信架构没想清楚、联调节奏没控住。这篇就把我从进场到交付踩过的坑、留下的经验按项目推进的真实顺序摊开讲涉及相机标定、手眼标定、PLC通信、联调规范这些核心环节适合正在做或准备做机器人视觉项目的朋友参考也适合刚入行想少走弯路的工程师。1. 进场前没想清楚的三件事后面全要还债1.1 视觉任务到底归谁触发PLC还是上位机很多项目在方案阶段只写了视觉引导机器人抓取但没写清楚触发链路。我踩过的第一个坑就是视觉系统到底由PLC触发还是由上位机调度这两种架构的联调方式、异常处理、节拍表现完全不同。如果由PLC触发典型链路是PLC判断工件到位通过Modbus TCP或OPC UA给视觉系统发拍照信号视觉算完把坐标偏移量回传给PLCPLC再驱动机器人。这种架构的优点是节拍稳定、逻辑闭环在PLC侧缺点是视觉系统的状态很难实时透传给上位机出了问题排查链路长。如果由上位机调度视觉系统通常直接和机器人控制器通信PLC只负责产线逻辑。这种架构灵活但上位机一旦卡顿或崩溃整条线就停了。我现在的习惯是在方案评审阶段就把触发源、异常回退、心跳检测这三件事写进接口文档不然后面联调时双方扯皮谁都觉得自己没问题。1.2 标定链路要在进场前规划好不能到现场再想相机标定、手眼标定、九点标定这些不是到现场拿个标定板晃两下就完事的。进场前必须明确标定板类型和尺寸、标定时的光照条件、标定工位是否和实际生产工位一致、标定数据的保存和复现方式。我遇到过最典型的问题是现场标定用的标定板是A尺寸但实际工件视野需要B尺寸结果标定完了发现边缘畸变校正不够抓取精度在视野边缘直接掉了一个数量级。后来学乖了进场前先确认视野范围和精度要求反推标定板尺寸和标定距离。张正友标定法虽然经典但标定板占视野的比例、拍摄角度数量、棋盘格角点提取质量这些细节直接决定内参的可靠性。1.3 通信协议选型Modbus够用但OPC UA更省心PLC和视觉系统之间的通信Modbus TCP和OPC UA我都用过。Modbus TCP简单直接寄存器映射清晰调试工具多但它的数据类型支持有限传浮点数要拆寄存器字节序还容易搞错。OPC UA在西门子、倍福这些PLC上支持得越来越好结构化数据类型直接传节点管理也规范缺点是配置比Modbus重老PLC可能不支持。我的经验是如果只是传几个触发信号和坐标偏移量Modbus TCP完全够用调试快如果要传设备状态、配方参数、诊断信息OPC UA更合适。但不管选哪个进场前一定要用PLC仿真或离线工具把通信跑通别到了现场才发现寄存器地址对不上。2. 相机标定和手眼标定精度不是标出来的是控出来的2.1 内参标定别迷信标定板数量先控光照和角度相机内参标定很多人觉得多拍几张标定板图片就行。但实际项目中内参的稳定性受光照和拍摄角度影响极大。我在一个金属件抓取项目里标定时用的是均匀环形光实际生产时换成了条形光结果图像对比度变了角点提取偏差变大内参虽然没变但外参和实际抓取位置对不上。内参标定的核心是标定时的光照条件要尽量接近实际生产条件。如果做不到至少要在标定后做验证用标定结果去测一个已知尺寸的工件看误差是否在允许范围内。另外标定板的平整度很关键我见过用打印纸贴在不锈钢板上的标定板平整度不够角点提取噪声大内参重复性差。双目相机标定比单目多一个步骤立体校正。两个相机之间的外参标定完要做极线校正让左右图像的对应点在同一行上。这一步如果没做好后续的视差计算和三维重建误差会很大。我通常会在标定后检查校正后的图像看极线是否水平再决定是否重新标定。2.2 手眼标定九点标定和标定板标定的区别很多人没搞明白手眼标定是机器人视觉项目里最容易出问题的环节。九点标定和标定板标定很多人混着用但它们的适用场景完全不同。九点标定是在机器人工作空间内取九个点让机器人末端带着标定针去触碰这些点同时视觉系统识别这些点的图像坐标通过求解仿射变换得到图像坐标到机器人坐标的映射。它的优点是操作简单不需要标定板适合二维平面抓取场景。缺点是它假设工作平面是平的如果工件有高度变化或者相机有倾斜九点标定的精度会急剧下降。标定板标定比如棋盘格标定板是通过识别标定板上的特征点结合机器人末端位姿求解相机坐标系和机器人坐标系的变换矩阵。它的优点是精度高能处理三维空间的手眼关系缺点是操作复杂需要机器人走多个位姿标定时间长。我的经验是如果是二维平面抓取九点标定够用但一定要确保工作平面平整相机光轴垂直于工作平面。如果是三维抓取或者相机安装在机器人末端眼在手上必须用标定板标定而且标定时的机器人位姿要覆盖实际工作空间不能只在一个小范围内标定。2.3 标定验证别只看重投影误差要看实际抓取误差标定完成后很多人只看重投影误差觉得误差小于0.5像素就万事大吉。但重投影误差小不代表实际抓取精度高。我踩过的坑是标定重投影误差0.3像素但实际抓取时工件边缘的抓取偏差有2毫米。后来我总结了一个验证方法标定完成后让机器人去抓取一个已知位置的工件用视觉系统测量工件实际位置和机器人抓取位置之间的偏差重复多次看偏差的均值和方差。如果均值大说明标定有系统误差如果方差大说明标定重复性不好。这个验证比看重投影误差靠谱得多。另外标定数据的保存和复现也很重要。我习惯把标定时的图像、机器人位姿、标定参数全部存档后面如果精度下降可以快速定位是标定问题还是其他问题。3. 通信架构PLC、视觉、机器人之间的数据流怎么设计3.1 Modbus TCP和OPC UA的实战对比在机器人视觉项目里PLC通常负责产线逻辑和信号交互视觉系统负责图像处理和坐标计算机器人负责执行抓取。这三者之间的通信架构直接决定联调效率和系统稳定性。Modbus TCP的优点是简单、通用、调试工具多。我通常用Python的pymodbus库或者PLC自带的Modbus库来测试通信。但Modbus的寄存器映射需要提前规划好比如用D寄存器存触发信号用M寄存器存状态标志浮点数要拆成两个16位寄存器字节序要统一。我见过因为字节序不一致坐标偏移量传过去变成乱码的情况。OPC UA的优点是结构化数据类型、节点管理规范、支持订阅模式。在西门子S7-1500或者倍福PLC上OPC UA配置起来很方便视觉系统可以直接读取PLC的变量节点不需要手动映射寄存器。但OPC UA的配置比Modbus复杂需要证书管理、端点配置老PLC可能不支持。我的建议是如果项目周期紧、通信数据量小用Modbus TCP如果项目周期充裕、需要传结构化数据用OPC UA。但不管选哪个都要在进场前用仿真工具把通信跑通别到现场再调。3.2 数据流设计触发、拍照、计算、回传、执行一个典型的视觉引导抓取流程是这样的PLC判断工件到位通过Modbus TCP或OPC UA给视觉系统发触发信号。视觉系统收到触发信号控制相机拍照进行图像处理计算工件坐标。视觉系统把坐标偏移量回传给PLC。PLC把坐标偏移量转发给机器人或者机器人直接从视觉系统读取。机器人执行抓取完成后给PLC发完成信号。这个流程看起来简单但每个环节都有坑。比如触发信号的去抖、拍照和计算的超时处理、坐标偏移量的有效性校验、机器人抓取失败后的重试逻辑。我通常会在视觉系统里加一个状态机把每个环节的状态和超时都管理起来PLC侧也加对应的状态监控这样出了问题能快速定位。3.3 异常处理通信断了、拍照失败、抓取失败怎么办异常处理是联调阶段最耗时的部分。我踩过的坑是通信断了视觉系统还在等触发信号PLC以为视觉系统在计算机器人以为PLC会发坐标结果整条线卡死。后来我加了三层保护第一层是心跳检测PLC和视觉系统每隔一定时间互发心跳信号超时则报警第二层是超时处理每个环节都有超时时间超时则回退到安全状态第三层是异常日志所有异常都记录到日志文件方便事后排查。另外抓取失败后的重试逻辑也很重要。我通常会让机器人重试一次如果还失败就把工件放到NG工位同时给PLC发NG信号PLC记录并继续下一个工件。这样不会因为一个工件卡住整条线。4. 联调阶段从单机调试到整线跑通4.1 单机调试先让视觉系统自己跑通联调的第一步是单机调试也就是让视觉系统自己跑通。这个阶段不需要PLC和机器人参与只需要相机、光源、视觉软件。我通常会用一批标准工件让视觉系统连续跑几百次看识别率、精度、耗时是否稳定。这个阶段最容易发现的问题是光源稳定性、相机曝光时间、图像处理算法的鲁棒性。我遇到过光源频闪导致图像亮度波动进而影响识别率的情况。后来换了恒流光源问题解决。还有相机曝光时间设置不当运动中的工件拍出来有拖影调整曝光时间和触发方式后解决。单机调试阶段还要做标定验证用标定结果去测已知位置的工件看误差是否在允许范围内。如果误差大先别急着怀疑算法先检查标定和光源。4.2 联调PLC、视觉、机器人三方对接单机调试通过后进入联调阶段。这个阶段的核心是三方对接PLC、视觉系统、机器人。我通常按以下顺序推进先让PLC和视觉系统通信跑通用手动触发的方式测试拍照和坐标回传。再让视觉系统和机器人通信跑通用模拟坐标测试机器人抓取。最后让PLC、视觉、机器人三方联动跑完整的抓取流程。这个顺序的好处是每次只引入一个新的变量出了问题容易定位。我见过有人一上来就三方联动结果通信断了、拍照失败、抓取偏差三个问题混在一起排查了一整天。联调阶段还要注意节拍。视觉系统的处理时间、通信的延迟、机器人的运动时间这些加起来不能超过产线节拍。我通常会在联调时用示波器或者日志时间戳来测量每个环节的耗时找出瓶颈。4.3 测试联调规范怎么定义跑通了跑通了这三个字在项目里很模糊。我现在的做法是定义明确的测试联调规范包括测试用例、通过标准、异常场景。测试用例包括正常抓取、工件位置偏移、工件缺失、通信中断、拍照失败、抓取失败。通过标准包括识别率、抓取精度、节拍、异常处理响应时间。异常场景要模拟真实故障比如拔网线、遮挡相机、放错工件看系统是否能正确报警和回退。这个规范不是写给客户看的是写给自己的。有了它联调阶段就有章可循不会漏掉关键场景。而且交付后如果出问题可以对照规范快速定位。5. 交付前必须做的几项验证5.1 精度验证不是测一次是测一批交付前的精度验证不能只测一个工件。我通常会用一批工件至少20个在不同位置、不同姿态下测试抓取精度统计均值和方差。如果均值大说明标定有系统误差如果方差大说明重复性不好。精度验证还要覆盖工作空间的全范围不能只测中心区域。我遇到过中心区域精度很好边缘区域精度掉了一半的情况原因是镜头畸变校正不够。后来换了畸变更小的镜头或者调整了标定参数问题解决。5.2 稳定性验证连续跑看会不会漂稳定性验证是连续跑几个小时甚至几天看视觉系统的识别率、精度、耗时是否会漂移。我遇到过相机温度升高后图像噪声变大识别率下降的情况。后来加了相机散热问题解决。还有光源老化导致亮度下降需要定期校准。稳定性验证还要看通信是否稳定。我通常会让系统连续跑24小时记录通信中断次数、异常次数、平均无故障时间。如果通信不稳定先检查网线、交换机、IP配置再检查PLC和视觉系统的通信程序。5.3 文档和培训别让交付变成人走茶凉交付不只是把系统跑通还要把文档和培训做好。我通常会给客户准备以下文档系统架构图、通信协议说明、标定步骤、常见问题排查、维护计划。培训包括操作培训、标定培训、简单故障排查培训。我踩过的坑是交付时没做培训客户操作人员不会标定相机稍微动了一下就抓不准最后又找回来。后来学乖了交付前一定要做培训而且要让客户的操作人员自己动手操作一遍确保他们真的会。6. 几个让我印象深刻的踩坑实录6.1 标定板反光导致角点提取失败在一个铝合金工件抓取项目里标定板放在工件旁边结果标定板表面反光角点提取失败。后来换了哑光标定板问题解决。这个坑让我明白标定板的材质和表面处理很重要不能随便拿个打印纸就用。6.2 通信字节序不一致导致坐标乱码在一个Modbus TCP项目里视觉系统传浮点数给PLCPLC解析出来是乱码。排查了半天发现是字节序不一致。视觉系统用的是小端序PLC用的是大端序。后来统一了字节序问题解决。这个坑让我明白通信协议里的数据类型和字节序必须在接口文档里写清楚。6.3 机器人抓取失败后没有重试逻辑在一个抓取项目里机器人抓取失败后直接报警停机整条线停了。后来加了重试逻辑抓取失败后重试一次还失败就放到NG工位整条线继续跑。这个坑让我明白异常处理不是可选项是必选项。6.4 联调时没有定义跑通了的标准在一个项目里联调时大家都觉得跑通了但交付后客户发现异常场景没处理。后来复盘发现联调时只测了正常抓取没测异常场景。这个坑让我明白测试联调规范必须提前定义不能凭感觉。7. 写在最后一些个人体会机器人视觉项目从进场到交付技术只是一部分更多的是项目管理和沟通。我现在的习惯是进场前把接口文档、标定方案、测试规范全部写好联调时按顺序推进交付前做完整验证。这些看起来是额外工作但实际做下来反而省时间。另外别迷信算法。很多问题不是算法不够好而是标定不准、光源不稳、通信不可靠。先把这些基础环节控住再谈算法优化。最后留一手标定数据、通信日志、测试记录全部存档后面出问题可以快速定位。这个习惯让我在多个项目里省下了大量排查时间。 
长河君 · 2026/11/2 6:08:04 · 阅读 1.2k 机器人视觉项目从进场到交付的避坑指南：标定、通信与联调实战
机器人视觉项目这行最不缺的就是Demo最缺的是从进场到交付这条路上活下来的经验。我做过几个视觉引导抓取和定位类的项目有产线改造的也有全新集成的每次复盘都会发现真正让项目翻车的往往不是算法精度不够而是标定链路没对齐、通信架构没想清楚、联调节奏没控住。这篇就把我从进场到交付踩过的坑、留下的经验按项目推进的真实顺序摊开讲涉及相机标定、手眼标定、PLC通信、联调规范这些核心环节适合正在做或准备做机器人视觉项目的朋友参考也适合刚入行想少走弯路的工程师。1. 进场前没想清楚的三件事后面全要还债1.1 视觉任务到底归谁触发PLC还是上位机很多项目在方案阶段只写了视觉引导机器人抓取但没写清楚触发链路。我踩过的第一个坑就是视觉系统到底由PLC触发还是由上位机调度这两种架构的联调方式、异常处理、节拍表现完全不同。如果由PLC触发典型链路是PLC判断工件到位通过Modbus TCP或OPC UA给视觉系统发拍照信号视觉算完把坐标偏移量回传给PLCPLC再驱动机器人。这种架构的优点是节拍稳定、逻辑闭环在PLC侧缺点是视觉系统的状态很难实时透传给上位机出了问题排查链路长。如果由上位机调度视觉系统通常直接和机器人控制器通信PLC只负责产线逻辑。这种架构灵活但上位机一旦卡顿或崩溃整条线就停了。我现在的习惯是在方案评审阶段就把触发源、异常回退、心跳检测这三件事写进接口文档不然后面联调时双方扯皮谁都觉得自己没问题。1.2 标定链路要在进场前规划好不能到现场再想相机标定、手眼标定、九点标定这些不是到现场拿个标定板晃两下就完事的。进场前必须明确标定板类型和尺寸、标定时的光照条件、标定工位是否和实际生产工位一致、标定数据的保存和复现方式。我遇到过最典型的问题是现场标定用的标定板是A尺寸但实际工件视野需要B尺寸结果标定完了发现边缘畸变校正不够抓取精度在视野边缘直接掉了一个数量级。后来学乖了进场前先确认视野范围和精度要求反推标定板尺寸和标定距离。张正友标定法虽然经典但标定板占视野的比例、拍摄角度数量、棋盘格角点提取质量这些细节直接决定内参的可靠性。1.3 通信协议选型Modbus够用但OPC UA更省心PLC和视觉系统之间的通信Modbus TCP和OPC UA我都用过。Modbus TCP简单直接寄存器映射清晰调试工具多但它的数据类型支持有限传浮点数要拆寄存器字节序还容易搞错。OPC UA在西门子、倍福这些PLC上支持得越来越好结构化数据类型直接传节点管理也规范缺点是配置比Modbus重老PLC可能不支持。我的经验是如果只是传几个触发信号和坐标偏移量Modbus TCP完全够用调试快如果要传设备状态、配方参数、诊断信息OPC UA更合适。但不管选哪个进场前一定要用PLC仿真或离线工具把通信跑通别到了现场才发现寄存器地址对不上。2. 相机标定和手眼标定精度不是标出来的是控出来的2.1 内参标定别迷信标定板数量先控光照和角度相机内参标定很多人觉得多拍几张标定板图片就行。但实际项目中内参的稳定性受光照和拍摄角度影响极大。我在一个金属件抓取项目里标定时用的是均匀环形光实际生产时换成了条形光结果图像对比度变了角点提取偏差变大内参虽然没变但外参和实际抓取位置对不上。内参标定的核心是标定时的光照条件要尽量接近实际生产条件。如果做不到至少要在标定后做验证用标定结果去测一个已知尺寸的工件看误差是否在允许范围内。另外标定板的平整度很关键我见过用打印纸贴在不锈钢板上的标定板平整度不够角点提取噪声大内参重复性差。双目相机标定比单目多一个步骤立体校正。两个相机之间的外参标定完要做极线校正让左右图像的对应点在同一行上。这一步如果没做好后续的视差计算和三维重建误差会很大。我通常会在标定后检查校正后的图像看极线是否水平再决定是否重新标定。2.2 手眼标定九点标定和标定板标定的区别很多人没搞明白手眼标定是机器人视觉项目里最容易出问题的环节。九点标定和标定板标定很多人混着用但它们的适用场景完全不同。九点标定是在机器人工作空间内取九个点让机器人末端带着标定针去触碰这些点同时视觉系统识别这些点的图像坐标通过求解仿射变换得到图像坐标到机器人坐标的映射。它的优点是操作简单不需要标定板适合二维平面抓取场景。缺点是它假设工作平面是平的如果工件有高度变化或者相机有倾斜九点标定的精度会急剧下降。标定板标定比如棋盘格标定板是通过识别标定板上的特征点结合机器人末端位姿求解相机坐标系和机器人坐标系的变换矩阵。它的优点是精度高能处理三维空间的手眼关系缺点是操作复杂需要机器人走多个位姿标定时间长。我的经验是如果是二维平面抓取九点标定够用但一定要确保工作平面平整相机光轴垂直于工作平面。如果是三维抓取或者相机安装在机器人末端眼在手上必须用标定板标定而且标定时的机器人位姿要覆盖实际工作空间不能只在一个小范围内标定。2.3 标定验证别只看重投影误差要看实际抓取误差标定完成后很多人只看重投影误差觉得误差小于0.5像素就万事大吉。但重投影误差小不代表实际抓取精度高。我踩过的坑是标定重投影误差0.3像素但实际抓取时工件边缘的抓取偏差有2毫米。后来我总结了一个验证方法标定完成后让机器人去抓取一个已知位置的工件用视觉系统测量工件实际位置和机器人抓取位置之间的偏差重复多次看偏差的均值和方差。如果均值大说明标定有系统误差如果方差大说明标定重复性不好。这个验证比看重投影误差靠谱得多。另外标定数据的保存和复现也很重要。我习惯把标定时的图像、机器人位姿、标定参数全部存档后面如果精度下降可以快速定位是标定问题还是其他问题。3. 通信架构PLC、视觉、机器人之间的数据流怎么设计3.1 Modbus TCP和OPC UA的实战对比在机器人视觉项目里PLC通常负责产线逻辑和信号交互视觉系统负责图像处理和坐标计算机器人负责执行抓取。这三者之间的通信架构直接决定联调效率和系统稳定性。Modbus TCP的优点是简单、通用、调试工具多。我通常用Python的pymodbus库或者PLC自带的Modbus库来测试通信。但Modbus的寄存器映射需要提前规划好比如用D寄存器存触发信号用M寄存器存状态标志浮点数要拆成两个16位寄存器字节序要统一。我见过因为字节序不一致坐标偏移量传过去变成乱码的情况。OPC UA的优点是结构化数据类型、节点管理规范、支持订阅模式。在西门子S7-1500或者倍福PLC上OPC UA配置起来很方便视觉系统可以直接读取PLC的变量节点不需要手动映射寄存器。但OPC UA的配置比Modbus复杂需要证书管理、端点配置老PLC可能不支持。我的建议是如果项目周期紧、通信数据量小用Modbus TCP如果项目周期充裕、需要传结构化数据用OPC UA。但不管选哪个都要在进场前用仿真工具把通信跑通别到现场再调。3.2 数据流设计触发、拍照、计算、回传、执行一个典型的视觉引导抓取流程是这样的PLC判断工件到位通过Modbus TCP或OPC UA给视觉系统发触发信号。视觉系统收到触发信号控制相机拍照进行图像处理计算工件坐标。视觉系统把坐标偏移量回传给PLC。PLC把坐标偏移量转发给机器人或者机器人直接从视觉系统读取。机器人执行抓取完成后给PLC发完成信号。这个流程看起来简单但每个环节都有坑。比如触发信号的去抖、拍照和计算的超时处理、坐标偏移量的有效性校验、机器人抓取失败后的重试逻辑。我通常会在视觉系统里加一个状态机把每个环节的状态和超时都管理起来PLC侧也加对应的状态监控这样出了问题能快速定位。3.3 异常处理通信断了、拍照失败、抓取失败怎么办异常处理是联调阶段最耗时的部分。我踩过的坑是通信断了视觉系统还在等触发信号PLC以为视觉系统在计算机器人以为PLC会发坐标结果整条线卡死。后来我加了三层保护第一层是心跳检测PLC和视觉系统每隔一定时间互发心跳信号超时则报警第二层是超时处理每个环节都有超时时间超时则回退到安全状态第三层是异常日志所有异常都记录到日志文件方便事后排查。另外抓取失败后的重试逻辑也很重要。我通常会让机器人重试一次如果还失败就把工件放到NG工位同时给PLC发NG信号PLC记录并继续下一个工件。这样不会因为一个工件卡住整条线。4. 联调阶段从单机调试到整线跑通4.1 单机调试先让视觉系统自己跑通联调的第一步是单机调试也就是让视觉系统自己跑通。这个阶段不需要PLC和机器人参与只需要相机、光源、视觉软件。我通常会用一批标准工件让视觉系统连续跑几百次看识别率、精度、耗时是否稳定。这个阶段最容易发现的问题是光源稳定性、相机曝光时间、图像处理算法的鲁棒性。我遇到过光源频闪导致图像亮度波动进而影响识别率的情况。后来换了恒流光源问题解决。还有相机曝光时间设置不当运动中的工件拍出来有拖影调整曝光时间和触发方式后解决。单机调试阶段还要做标定验证用标定结果去测已知位置的工件看误差是否在允许范围内。如果误差大先别急着怀疑算法先检查标定和光源。4.2 联调PLC、视觉、机器人三方对接单机调试通过后进入联调阶段。这个阶段的核心是三方对接PLC、视觉系统、机器人。我通常按以下顺序推进先让PLC和视觉系统通信跑通用手动触发的方式测试拍照和坐标回传。再让视觉系统和机器人通信跑通用模拟坐标测试机器人抓取。最后让PLC、视觉、机器人三方联动跑完整的抓取流程。这个顺序的好处是每次只引入一个新的变量出了问题容易定位。我见过有人一上来就三方联动结果通信断了、拍照失败、抓取偏差三个问题混在一起排查了一整天。联调阶段还要注意节拍。视觉系统的处理时间、通信的延迟、机器人的运动时间这些加起来不能超过产线节拍。我通常会在联调时用示波器或者日志时间戳来测量每个环节的耗时找出瓶颈。4.3 测试联调规范怎么定义跑通了跑通了这三个字在项目里很模糊。我现在的做法是定义明确的测试联调规范包括测试用例、通过标准、异常场景。测试用例包括正常抓取、工件位置偏移、工件缺失、通信中断、拍照失败、抓取失败。通过标准包括识别率、抓取精度、节拍、异常处理响应时间。异常场景要模拟真实故障比如拔网线、遮挡相机、放错工件看系统是否能正确报警和回退。这个规范不是写给客户看的是写给自己的。有了它联调阶段就有章可循不会漏掉关键场景。而且交付后如果出问题可以对照规范快速定位。5. 交付前必须做的几项验证5.1 精度验证不是测一次是测一批交付前的精度验证不能只测一个工件。我通常会用一批工件至少20个在不同位置、不同姿态下测试抓取精度统计均值和方差。如果均值大说明标定有系统误差如果方差大说明重复性不好。精度验证还要覆盖工作空间的全范围不能只测中心区域。我遇到过中心区域精度很好边缘区域精度掉了一半的情况原因是镜头畸变校正不够。后来换了畸变更小的镜头或者调整了标定参数问题解决。5.2 稳定性验证连续跑看会不会漂稳定性验证是连续跑几个小时甚至几天看视觉系统的识别率、精度、耗时是否会漂移。我遇到过相机温度升高后图像噪声变大识别率下降的情况。后来加了相机散热问题解决。还有光源老化导致亮度下降需要定期校准。稳定性验证还要看通信是否稳定。我通常会让系统连续跑24小时记录通信中断次数、异常次数、平均无故障时间。如果通信不稳定先检查网线、交换机、IP配置再检查PLC和视觉系统的通信程序。5.3 文档和培训别让交付变成人走茶凉交付不只是把系统跑通还要把文档和培训做好。我通常会给客户准备以下文档系统架构图、通信协议说明、标定步骤、常见问题排查、维护计划。培训包括操作培训、标定培训、简单故障排查培训。我踩过的坑是交付时没做培训客户操作人员不会标定相机稍微动了一下就抓不准最后又找回来。后来学乖了交付前一定要做培训而且要让客户的操作人员自己动手操作一遍确保他们真的会。6. 几个让我印象深刻的踩坑实录6.1 标定板反光导致角点提取失败在一个铝合金工件抓取项目里标定板放在工件旁边结果标定板表面反光角点提取失败。后来换了哑光标定板问题解决。这个坑让我明白标定板的材质和表面处理很重要不能随便拿个打印纸就用。6.2 通信字节序不一致导致坐标乱码在一个Modbus TCP项目里视觉系统传浮点数给PLCPLC解析出来是乱码。排查了半天发现是字节序不一致。视觉系统用的是小端序PLC用的是大端序。后来统一了字节序问题解决。这个坑让我明白通信协议里的数据类型和字节序必须在接口文档里写清楚。6.3 机器人抓取失败后没有重试逻辑在一个抓取项目里机器人抓取失败后直接报警停机整条线停了。后来加了重试逻辑抓取失败后重试一次还失败就放到NG工位整条线继续跑。这个坑让我明白异常处理不是可选项是必选项。6.4 联调时没有定义跑通了的标准在一个项目里联调时大家都觉得跑通了但交付后客户发现异常场景没处理。后来复盘发现联调时只测了正常抓取没测异常场景。这个坑让我明白测试联调规范必须提前定义不能凭感觉。7. 写在最后一些个人体会机器人视觉项目从进场到交付技术只是一部分更多的是项目管理和沟通。我现在的习惯是进场前把接口文档、标定方案、测试规范全部写好联调时按顺序推进交付前做完整验证。这些看起来是额外工作但实际做下来反而省时间。另外别迷信算法。很多问题不是算法不够好而是标定不准、光源不稳、通信不可靠。先把这些基础环节控住再谈算法优化。最后留一手标定数据、通信日志、测试记录全部存档后面出问题可以快速定位。这个习惯让我在多个项目里省下了大量排查时间。