机器人视觉项目这行，最不缺的就是Demo，最缺的是从进场到交付这条路上活下来的经验。我做过几个视觉引导抓取和定位类的项目，有产线改造的，也有全新集成的，每次复盘都会发现：真正让项目翻车的，往往不是算法精度不够，而是标定链路没对齐、通信架构没想清楚、联调节奏没控住。这篇就把我从进场到交付踩过的坑、留下的经验，按项目推进的真实顺序摊开讲，涉及相机标定、手眼标定、PLC通信、联调规范这些核心环节，适合正在做或准备做机器人视觉项目的朋友参考，也适合刚入行想少走弯路的工程师。
1. 进场前没想清楚的三件事，后面全要还债
1.1 视觉任务到底归谁触发：PLC还是上位机
很多项目在方案阶段只写了"视觉引导机器人抓取"，但没写清楚触发链路。我踩过的第一个坑就是：视觉系统到底由PLC触发，还是由上位机调度？这两种架构的联调方式、异常处理、节拍表现完全不同。
如果由PLC触发，典型链路是：PLC判断工件到位，通过Modbus TCP或OPC UA给视觉系统发拍照信号，视觉算完把坐标偏移量回传给PLC，PLC再驱动机器人。这种架构的优点是节拍稳定、逻辑闭环在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项目里，视觉系统传浮点数给PLC，PLC解析出来是乱码。排查了半天，发现是字节序不一致。视觉系统用的是小端序，PLC用的是大端序。后来统一了字节序，问题解决。这个坑让我明白：通信协议里的数据类型和字节序，必须在接口文档里写清楚。
6.3 机器人抓取失败后没有重试逻辑
在一个抓取项目里，机器人抓取失败后直接报警停机，整条线停了。后来加了重试逻辑，抓取失败后重试一次，还失败就放到NG工位，整条线继续跑。这个坑让我明白：异常处理不是可选项，是必选项。
6.4 联调时没有定义"跑通了"的标准
在一个项目里，联调时大家都觉得"跑通了"，但交付后客户发现异常场景没处理。后来复盘发现，联调时只测了正常抓取，没测异常场景。这个坑让我明白：测试联调规范必须提前定义，不能凭感觉。
7. 写在最后：一些个人体会
机器人视觉项目从进场到交付，技术只是一部分，更多的是项目管理和沟通。我现在的习惯是：进场前把接口文档、标定方案、测试规范全部写好，联调时按顺序推进，交付前做完整验证。这些看起来是额外工作，但实际做下来，反而省时间。
另外，别迷信算法。很多问题不是算法不够好，而是标定不准、光源不稳、通信不可靠。先把这些基础环节控住，再谈算法优化。
最后，留一手：标定数据、通信日志、测试记录全部存档，后面出问题可以快速定位。这个习惯让我在多个项目里省下了大量排查时间。
