去年接焊接视觉跟踪项目时客户的一句话让我印象很深“能不能让机器人自己找缝” 这句话落到工程上就是一套C#上位机加Halcon视觉处理再叠加机器人二次开发接口的焊缝跟踪系统。先给结论这个系统不神秘核心就三件事——让相机看到焊缝让软件算出焊缝位置让机器人按修正量把焊枪对准焊缝。但真要把这三件事跑稳定中间隔着标定、图像处理、通信协议、现场调试四座山。下面我把整套思路、关键代码骨架和踩坑记录完整写出来给正在做机器人视觉集成、尤其被焊缝跟踪卡住的人一个可以直接参考的版本。文章不吹概念全部按能落地的工程口径讲。1. 这个项目的本质把“人眼找缝”变成“机器找缝”焊接产线上最常见的做法是示教路径工程师拿着示教器把焊缝起点、过渡点、终点一个一个点位录进去机器人按直线或圆弧把这些点连起来配上焊接参数就开工。这套方案在工件规格非常稳定、拼缝间隙均匀、夹具没有磨损的前提下能工作但实际产线远没有这么理想。示教路径的误差来源有几个板材厚度公差让坡口实际位置偏移夹具反复装夹后定位销磨损同一套程序每次放上去位置都不一样焊接过程中的热变形会让薄板发生翘曲原本对准的缝口越焊越偏还有拼缝间隙波动间隙大一点小一点焊缝填充量都跟着变。弧焊对焊缝中心的要求一般在±1mm以内而示教是纯开环所有这些误差都会直接作用到焊枪上结果就是偏焊、咬边、焊缝高度不一致严重时直接烧穿试件。焊缝跟踪要解决的就是把这个开环变成闭环。视觉传感器装在焊枪前方激光器在工件表面打出一条亮线相机拍摄包含激光条纹的图像Halcon在图像里提取焊缝特征点上位机把特征点换算成机器人坐标系下的纠偏量机器人收到纠偏量后对当前焊接路径做横向修正。这个过程不是定位一次就结束而是每一帧都重复执行所以后面所有代码设计都围绕“实时、稳定、可恢复”三个词展开。还有一点容易被新人忽略焊缝跟踪和一般的机器人视觉引导定位不一样。定位抓取是“看到目标算一次坐标抓一次”对实时性要求没那么苛刻焊缝跟踪是连续动态修正焊枪一直在走图像一直在来算法处理慢一帧都可能让修正量失去意义。项目开始时我就跟团队定了一条规矩所有模块先按最坏延迟做预算而不是按平均延迟做预算。2. 整体架构选型C#、Halcon和机器人三者怎么分工焊缝跟踪上位机不是一个人干所有事C#、Halcon、机器人各自有明确边界。选型时不要先想“哪个技术栈最好”先想“现场最怕什么”。做视觉集成的新手很容易把精力花在算法炫技上结果界面卡、通信断、标定错一到现场全崩。下面说说我实际采用的架构和理由。2.1 为什么上位机选C#而不是其他机器人视觉类上位机语言选择有很多但我最终选了C#。不是因为它“生态好”这种虚话而是三个现实原因。一是视觉集成团队里C#的接受度最高。现场维护的人不一定是专职软件工程师C#的代码结构直观好交接。二是Windows Forms或者WPF做现场界面效率确实高实时图像窗口、偏差曲线、参数面板半天就能搭起来。三是Halcon官方提供HalconDotNetC#可以直接调用算子不需要自己写DLL桥接省掉大量底层工作。对比一下其他方案C当然性能最好但开发和调试成本明显高如果项目帧率要求没有极端到毫秒级C#的托管代码完全够用。Python做算法原型很快但到了机器人通信、多线程控制、部署环境时包管理、解释器版本、工控机兼容性都会变成额外负担现场设备又普遍是Windows老工控机。对我这个项目来说实时性需求是“每帧处理在20毫秒上下”C#没有任何压力。技术方案开发效率实时性部署稳定性适用阶段C# HalconDotNet高足够高正式工程C Halcon C API低高高极端性能要求Python Halcon库高一般较低算法原型验证2.2 Halcon只做它最擅长的事Halcon在这套系统里的角色是“图像处理引擎”不是“整个系统”。很多初学者喜欢把界面、线程、通信全部塞进HDevelop脚本里这是很典型的错误认知。HDevelop适合做算法验证不适合做工程应用因为它本身是个交互式环境无法优雅地处理多线程、异常恢复和协议问题。工程里正确做法是引用HalconDotNet把HDevelop里验证好的算子流程打包成C#方法封装成一个独立的视觉服务。外部调用者看到的接口很少比如传入一帧图像和机器人当前位姿返回一个纠偏坐标。这样视觉算法内部怎么改都不会影响通信模块和界面模块后期调试也方便很多。我在项目里把Halcon负责的内容圈得很死图像采集、ROI裁剪、预处理、激光条纹分割、焊缝特征点提取、坐标换算。C#负责的是流程调度、线程管理、机器人通信、界面展示、参数保存、日志记录。这个边界一旦划清楚写代码的时候思路就非常干净。2.3 两端通信TCP最省事也最考验协议设计机器人与上位机之间的通信方案市面上常见的是IO硬接线、ModbusTCP、TCP Socket、厂商SDK这几种。IO硬接线只能传触发信号焊缝跟踪需要连续传输坐标直接排除。ModbusTCP能读点位但它本质是周期轮询抖动比较明显不适合高频纠偏。厂商SDK功能强大但绑定特定平台升级和维护受制于人我一般只在必须读机器人内部状态时才用。通信方案能传什么延迟/稳定性实际使用评价IO硬接线开关量、触发低但信息量小只适合启停ModbusTCP寄存器、点位周期5-20ms抖动一般适合状态读取TCP Socket自定义报文1-5ms可控焊缝跟踪首选厂商SDK复杂状态和数据稳定但绑平台深度集成才值得最后选TCP Socket因为传输量很小就是坐标和状态不需要走工业总线。TCP最通用也最可控但前提是协议必须自己严格设计报文帧头、长度、累加和校验、异常回复、断线重连都要在联调前定清楚。协议设计不好的话现场会出现各种灵异问题比如收了一堆乱码、机器人偶尔不响应、上位机假死。3. 坐标系和标定所有跟踪精度都从这里来视觉引导机器人最绕不开的是坐标转换。很多项目做到一半发现“为什么识别挺准但机器人就是焊歪了”十有八九是坐标系没理清。焊缝跟踪对空间关系的依赖比视觉定位还要强因为你的纠偏量最终要叠加到机器人路径上哪怕差两三个毫米焊接效果都完全不同。3.1 三个坐标系之间的变换链一套完整的焊缝跟踪系统里至少有三个坐标系像素坐标系、相机坐标系、机器人基坐标系。相机拍到的是一张二维图像图像里的行和列只是像素位置要把它变成机器人能用的空间坐标必须经过一连串变换。变换链可以这样理解激光条纹上的一个像素点先通过相机内参变成相机坐标系下的一个三维点得到的是相机“眼睛”看到的空间位置再通过手眼矩阵变成机器人末端法兰坐标系下的点最后通过机器人当前位姿的正解变成机器人基坐标系下的点。写成矩阵链就是P_base T_base_flange × T_flange_cam × P_cam这个公式看起来有点吓人实际思想很简单就像你在手机地图APP里看到一个点APP先把屏幕上的像素点换算成手机坐标系再考虑手机朝向和位置最终给到你所在城市街道上的经纬度。机器人也是这个流程只是每一步都用矩阵表示。实际项目中注意别把“机器人当前位姿”和“视觉处理时刻的位姿”搞混。图像采到的时候机器人已经在移动处理完再下发时机器人已经走了几十毫米这个时间差必须用延迟补偿来吸收否则坐标永远对不上。3.2 手眼标定与像素当量相机装在机器人上有两种方式焊缝跟踪几乎都用Eye-in-Hand也就是相机固定在焊枪或者传感器支架上跟着焊枪走。好处是视野里永远是焊枪前方的一小段工件摆放偏一点也无所谓标定一次后换同类工件不用重新标定。标定的标准做法是把标定板固定在焊接工作台上机器人末端带着相机移动到多个不同位置和姿态每次拍照并记录当前的机器人法兰位姿然后用Halcon的CalibrateHandEye算子求出相机相对法兰坐标系的位姿。这个过程需要标定板项目里用的是Halcon标准标定板其他的标定板算法兼容性没有前者好。有一个非常容易踩的坑有人图省事不做完整手眼标定只在一个固定高度下测量“每像素对应多少毫米”的像素当量二维纠偏就靠这个比例实现。这种方案在工件表面高度几乎不变的情况下能凑合但只要焊枪高度稍微变一点镜头到工件距离变物距一变比例就失效纠偏量就开始漂。既然项目叫焊缝跟踪就不该省这一步至少做一次完整手眼标定精度才有基本保障。3.3 前视距离与延迟补偿激光传感器永远不会装在焊枪正下方而是装在焊枪前方大概20到50毫米的位置这个距离就是“前视距离”。为什么必须在前面因为视觉系统需要时间焊枪到达某个焊缝点之前视觉必须已经算出那个点需要的纠偏量。延迟补偿的核心公式很简单提前量 物理前视距离 焊接速度 × 系统总延迟举一个实际算例前视距离20mm焊接速度10mm/s系统总延迟60ms那么提前量是20 10 × 0.06 20.6mm。也就是说视觉在焊枪前方20.6mm处已经提前知道了纠偏需求等焊枪真正走到那个位置所有修正都已经完成。反过来如果前视距离太小、速度又很快图像还没处理完焊枪就已经压上缝了这时再纠偏就会走出S形路径焊缝外观很难看还会加剧机械磨损。我在项目中一般把前视距离取在20到50mm之间给处理链路至少留出50到100ms的时间余量。前视距离也不能过大过大意味着视觉点在很远处焊缝走向一旦有弧度预测误差会变大所以具体取值要根据工件形状和焊接速度实测权衡。4. Halcon焊缝特征提取从一帧激光条纹图到纠偏坐标整个系统里最容易被拿来炫耀的就是图像算法但真正到现场你会发现算法稳定比算法复杂重要得多。我在这个项目里用的Halcon特征提取流程非常传统没有上深度学习但现场运行稳定性反而更好。原因很简单激光结构光场景里条纹特征清晰、规律固定传统几何方法可解释、可调试、可控。4.1 预处理滤飞溅、增强对比、锁ROI原始图像里除了激光器打出的亮条纹还有环境光、焊接弧光、金属飞溅。如果一上来就直接做阈值分割飞溅很容易被误判成激光条纹焊缝特征点就会被带偏。预处理第一步是限制ROI。用ROI把图像范围锁在激光条纹附近比如焊枪前方的一条带状区域。这么做有两个好处一是减少处理像素数量节省计算时间二是从物理上排除电弧区域和大部分飞溅区域。ROI不是随便画的要和传感器安装位置对应好现场换装后必须重新调整。预处理第二步是中值滤波。中值滤波对飞溅这类椒盐噪声的抑制效果比高斯滤波好同时还能保留条纹边缘。我用的核大小是5×5圆形。第三步是做对比度拉伸或者直方图均衡让暗色金属背景和亮色激光条纹之间的差距更明显。预处理段的Halcon代码大致是这个风格HObject image, roi, imageReduced, median; HOperatorSet.ReadImage(out image, framePath); // 实际工程中是 GrabImageAsync HOperatorSet.ReduceDomain(image, roi, out imageReduced); HOperatorSet.MedianImage(imageReduced, out median, 5, circle);这里要注意Halcon里所有中间对象都要及时释放特别是在长时间运行的跟踪任务里HObject句柄泄漏会导致内存持续上涨程序跑几小时就卡死。4.2 激光条纹分割与中心线提取预处理之后激光条纹在图像里是一块高亮区域。用阈值分割把亮条纹提取出来阈值的选择可以直接固定也可以根据灰度直方图双峰自动选取。我习惯先算一次直方图在两个峰之间的谷底取阈值这样对光线微弱变化有一定自适应能力。阈值提取出来的区域还需要用connection算子做连通域分离因为图像里可能同时存在激光条纹和个别漏网的飞溅点。分离之后用select_shape按面积和宽度过滤只留下面积最大、形状最接近“细长三角”的条纹区域。这一步过滤掉绝大多数干扰。条纹区域出来后直接用skeleton算子提取骨架再用gen_contour_region_xld把骨架转成XLD轮廓最后用fit_line_contour_xld拟合直线段。这样每一段激光条纹都会变成一条带起止点的直线。对于V型坡口激光条纹在坡口处会出现一个明显的折角条纹整体看起来是两段直线拼出一个角度正是这个折角就是焊缝中心特征。HObject region, connected, selected, skeleton, contours; HTuple area; HOperatorSet.Threshold(median, out region, minGray, maxGray); HOperatorSet.Connection(region, out connected); HOperatorSet.SelectShape(connected, out selected, area, and, 800, 99999); HOperatorSet.Skeleton(selected, out skeleton); HOperatorSet.GenContourRegionXld(skeleton, out contours, codelet);select_shape里的面积阈值800要按实际图像分辨率调整不能写死。我通常的做法是把它放到配置文件里现场用参数面板直接调。4.3 坡口特征点定位与坐标换算拿到两条拟合直线后焊缝特征点的定位就比较直接了。V型坡口就是求两条直线的交点Halcon里用intersection_lines算子一步到位。搭接焊缝和角焊缝稍有变化搭接处激光条纹存在高度跳变目视就是一个错位需要用端点识别或者检测条纹断裂位置角焊缝两条直线的夹角相对固定交点即是特征点。特征点拿到的是像素坐标必须通过标定矩阵和机器人位姿换算成机器人坐标系下的纠偏坐标。二维纠偏场景下用affine_trans_point_2d做仿射变换就够了如果工件表面高度变化大我会换成完整的三维坐标转换把交点映射到基坐标系下的X、Y、Z。还有一个容易坑人的细节图像的行方向和列方向与机器人X轴、Y轴并不一定一一对应标定完必须做一次方向符号验证。我验证的方法是让机器人在焊缝垂直方向手动偏移1mm观察图像里特征点往哪个方向移动确认图像坐标与机器人坐标的方向一致。如果符号搞反就会出现“明明有偏差一纠偏反而更歪”的诡异情况而且很难排查。单帧图像不一定每次都能提取到有效特征点。所以代码里必须设计异常分支当这一帧没有找到交点或者交点置信度太低时保持上一帧纠偏量继续执行连续多帧失败才报警。这比直接输出一个异常坐标要安全得多因为焊接过程不能随便中断。5. C#工程骨架与联合编程源码到底应该怎么写说完了算法再来讲代码工程。很多新人拿到一块项目就先把界面拖出来结果代码全堆在MainForm里几百行的事件处理函数后面谁都不敢动。焊缝跟踪这种实时系统源码结构必须一开始就设计好。5.1 工程分层让每个模块都能单独测试我采用的工程分层如下按接口和职责划分不按文件随机堆放。CameraService负责相机连接、参数配置、图像采集对外只暴露Start、Stop和最新帧事件。VisionService封装所有Halcon算子调用负责ROI、标定、特征提取、坐标换算对外暴露ProcessFrame方法。RobotService负责TCP Socket通信、协议编码解码、断线重连对外暴露SendOffset和CurrentPose事件。TrackingService负责任务编排把图像帧、处理结果、通信时机串起来是整个系统的调度中枢。MainForm只负责界面显示和参数配置不写业务逻辑。AppConfig集中管理所有可调参数比如曝光时间、ROI坐标、标定文件路径、TCP地址端口。这么分层最大的好处是每个模块都可以单独测试。VisionService可以用保存的图片回放测试RobotService可以用模拟服务器测试不需要机器人动起来就能验证大部分逻辑。联调时一旦出错也能很快定位问题在哪个服务里。5.2 采集线程与图像队列永远处理最新帧实时系统最怕串行化处理。如果在UI线程里抓图、跑算法、发命令全部串行执行界面一定会卡而且焊接过程中一直有新的纠偏需求进来旧的还没来得及处理整个链路就堵死了。我的线程模型是三个独立线程加两个队列采集线程不断GrabImageAsync抓帧把图像放进有限队列处理线程从队列取出最新一帧调用VisionService处理得到纠偏坐标通信线程负责把纠偏坐标发送给机器人同时接收机器人回传的当前位置。界面线程只在需要时从共享数据里读取最新结果显示。这里有个关键点队列满的时候要丢旧帧绝不能阻塞采集。视觉跟踪只关心当前时刻的图像早几帧的旧图一点用都没有。处理线程永远取队列里最新的一帧这样即使偶尔处理慢了一拍机器人用的也是最新视觉结果。用C#实现时可以用线程安全的BlockingCollection也可以自己写一个环形缓冲关键是定好超时和丢弃策略。我实际用的是容量为4的环形缓冲最坏情况下也只落后3帧。5.3 Halcon算子的C#封装直接从HDevelop导出再改造HDevelop里调试好的算法最终要变成C#代码。最简单的方式是HDevelop的“导出”功能生成C#代码但生成的代码通常包含大量中间变量和交互脚本不能直接用。我的做法是导出来作为参考然后重组成一个干净的方法。一个完整的视觉处理方法签名大致是这个样子public TrackResult ProcessFrame(HObject image, RobotPose pose) { TrackResult result new TrackResult(); HObject roi, imageReduced, median, region, selected, skeleton, contours; HTuple row, col, isOverlapping; HOperatorSet.ReduceDomain(image, roi, out imageReduced); HOperatorSet.MedianImage(imageReduced, out median, 5, circle); HOperatorSet.Threshold(median, out region, config.MinGray, config.MaxGray); HOperatorSet.Connection(region, out connected); HOperatorSet.SelectShape(connected, out selected, area, and, config.MinArea, 99999); HOperatorSet.Skeleton(selected, out skeleton); HOperatorSet.GenContourRegionXld(skeleton, out contours, codelet); // 直线拟合 交点计算 坐标转换 // 结果存入 result.OffsetX / result.OffsetY / result.Valid return result; }写这段代码时有两个细节要注意。一是命名冲突System.Drawing命名空间里也有Region我在C#工程里把Halcon的区域变量统一命名为hRegion或者直接全名引用避免编译器一会儿说类型冲突一会儿说找不到类型。二是中间对象用完要DisposeHalcon的HObject继承自IDisposable长时间运行的项目漏一次释放内存曲线就会一路向上跑一个班次下来程序基本不可用。5.4 机器人纠偏协议与指令循环机器人通信协议是现场问题高发区我的自定义协议参考了工业现场常见的做法。机器人作为TCP服务器上位机主动连接建立后机器人以固定周期向外发当前位置上位机每收到一帧位置就回发对应的纠偏量。报文设计尽量简单直观文本行协议就够比如机器人 - 上位机: R,SEQ1024,X210.35,Y88.46,Z12.00,E10.00,E20.00 上位机 - 机器人: C,SEQ1024,DX0.35,DY-0.12R开头的是机器人位置SEQ是帧序号上位机原样带回对应序号这样机器人侧能做校验避免发了旧数据被当成新数据使用。DX和DY分别是横向和高度方向的纠偏量。协议里必须带累加和校验位我用的是所有字节相加取低字节方法简单但特别有效。指令循环里还要加死区判断偏差绝对值小于0.3mm时不发送纠偏指令否则机器人会持续抖动焊缝看起来虽然准但机械结构寿命受影响。最关键的一点纠偏量不是原始路径的替代而是偏移叠加。也就是说机器人始终沿示教路径走上位机给的纠偏只是在这条路径上叠加一个侧向修正。这样设计的好处是万一视觉通信临时中断机器人至少还能按原始路径继续焊而不是停在原地把工件烧穿。5.5 界面和日志别小看这两块界面看起来是面子工程但焊缝跟踪现场调试时界面是唯一的观察窗口。我界面上固定显示三样东西实时图像窗口、跟踪偏差曲线、机器人当前坐标。实时图像窗口用Halcon的HWindowControl控件注意刷新操作必须在UI线程执行否则会闪屏甚至崩溃。偏差曲线用简单的自绘控件或者第三方图表控件横轴是时间纵轴是横向偏差能直接看到纠偏过程是收敛还是发散。有一次现场问题排查我就是靠偏差曲线发现的曲线在焊缝接头位置出现周期性尖峰后来检查发现传感器支架螺丝松动视觉视野在抖动。日志要有绝对时序记录每一帧的处理耗时、特征点坐标、机器人位置、纠偏量、通信状态。现场最忌“刚才好像报错了”这种模糊描述有完整日志就能回放数据流快速定位问题。我用的日志格式是TextWriterTraceListener输出到文件每行带毫秒级时间戳。6. 现场调试最容易翻车的五个环节前面讲的都是设计阶段的思路真正决定项目成败的是现场。我做过的焊缝跟踪项目几乎每一个都在现场暴露出实验室里根本没出现的问题。下面五个环节是我认为最应该提前做预案的地方。6.1 弧光和飞溅不是“调高阈值”就能解决的弧光对视觉干扰是立体的不光是图像灰度高还有热辐射、强光散射、飞溅反光。软件里调阈值只能过滤掉一部分均匀灰度抬高但弧光瞬间的高亮会直接淹没激光条纹这时候把阈值拉到很高条纹也没了。我的做法是物理过滤优先激光器前面加窄带滤光片只允许激光波长附近的光通过环境光和大部分弧光都会被滤掉相机的曝光时间压到1ms以内让弧光的“瞬时光晕”来不及积累。如果弧光干扰仍然严重可以用焊接电源的起弧信号做曝光同步只在不起弧或者起弧间歇曝光这样图像里永远没有电弧。飞溅颗粒是另一个问题它们的亮度和激光条纹相近飞行速度快单帧里就是一条短线。ROI限制在条纹附近可以有效避开大部分飞溅剩下的用median滤波和select_shape的几何过滤处理掉不要一上来就上深度学习去识别飞溅。6.2 镜面反光和氧化皮导致条纹断裂不锈钢和铝板表面容易产生镜面反射激光条纹打上去会被“漂白”成一片高光或者被氧化皮遮挡导致条纹中间断掉。这种情况单纯靠图像算法很难救因为信息本身丢失了。最有效的解决办法还是光学层面的。激光器功率降低到“刚好可见”的程度避免过曝光在相机镜头前加偏振片消除镜面物体反射产生的偏振光条纹对比度会大幅提升。我在现场实测过加偏振片后激光条纹断裂数量能减少八成以上比换任何图像后处理算法都管用。条纹断了之后用形态学闭运算可以把小间隙连起来但如果断裂超过总长度的一半建议直接丢帧保持上一帧纠偏量而不要做外推。6.3 快门、频闪与运动模糊机器人焊接是一个移动过程相机曝光时间稍微长一点激光条纹就糊成一片了。运动模糊和曝光时间、移动速度之间的关系可以用下面这个式子估算单个像素内位移 焊接速度 × 曝光时间 ÷ 像元尺寸假设像元尺寸5微米焊接速度10mm/s曝光时间2ms一个像素内位移是0.02mm完全清晰。如果速度提升到50mm/s曝光时间还是5ms单像素内位移就是0.25mm相当于条纹在图像里被拉出了将近50个像素的拖影特征点定位自然就差。所以速度提上去之后曝光时间必须压下来同时提高激光功率或者增益保证亮度这是一组配套调整。部分传感器自带频闪功能通过极短的高功率脉冲照明能有效解决运动模糊但需要控制器支持同步信号联调时别忽略接线和参数。6.4 标定参数漂移先验证矩阵再怀疑算法现场最隐蔽的问题是标定参数失效但界面和代码看起来一切正常。机器人碰撞、夹具松动、相机镜头被撞歪任何机械上的微小变动都会让原来的手眼矩阵完全失效此时图像算法再好输出的坐标也是错的。我的习惯是标定完成之后固化一个验证流程在工件表面放一个带特征点的基准块机器人走到某个固定位姿上位机计算该特征点的坐标再和机器人实际示教的坐标做对比误差超过0.5mm就提示重新标定。焊接不准时先跑这个验证流程往往几分钟就能排除或确认标定漂移问题而不用在图像算法上盲目调参。6.5 通信超时、粘包与异常恢复TCP长时间运行必然遇到粘包、半包、偶发超时。粘包是多个报文粘在一起送达半包是一个报文被拆成好几段如果解析代码只按固定长度读迟早会解析错乱。我的协议解析器做成了状态机先找帧头再读长度字段攒够整帧后再校验校验通过才交给业务层。断线重连必须做成自动的不能每掉一次线就重启程序。重连机制里要加入退避策略第一次失败等500ms再试连续失败把间隔逐步拉长到3秒避免机器人系统被频繁连接请求打挂。还有一条需要联调前和机器人侧工程师明确如果机器人连续多帧没有收到上位机纠偏量它应该继续沿示教路径直行而不是停机等待除非人工按下急停。这个约定不对焊接中途停机等于报废一块工件。最后说点个人体会。焊缝跟踪项目里最容易出彩的是算法最容易翻车的却是边界条件坐标方向、通信粘包、标定漂移、弧光干扰全是细节里的细节。我做这个系统时前期一半时间花在标定和通信稳定性上图像算法反而是最早完成的。如果你也要做同类系统我的建议是先把坐标系搞对再上Halcon先把断线重连做好再优化识别精度先在一块小工件上把纠偏闭环跑通再上产线。这个顺序反了后面每天都是救火现场。希望这份源码讲解的思路能帮你少走几段弯路。
去年接焊接视觉跟踪项目时客户的一句话让我印象很深“能不能让机器人自己找缝” 这句话落到工程上就是一套C#上位机加Halcon视觉处理再叠加机器人二次开发接口的焊缝跟踪系统。先给结论这个系统不神秘核心就三件事——让相机看到焊缝让软件算出焊缝位置让机器人按修正量把焊枪对准焊缝。但真要把这三件事跑稳定中间隔着标定、图像处理、通信协议、现场调试四座山。下面我把整套思路、关键代码骨架和踩坑记录完整写出来给正在做机器人视觉集成、尤其被焊缝跟踪卡住的人一个可以直接参考的版本。文章不吹概念全部按能落地的工程口径讲。1. 这个项目的本质把“人眼找缝”变成“机器找缝”焊接产线上最常见的做法是示教路径工程师拿着示教器把焊缝起点、过渡点、终点一个一个点位录进去机器人按直线或圆弧把这些点连起来配上焊接参数就开工。这套方案在工件规格非常稳定、拼缝间隙均匀、夹具没有磨损的前提下能工作但实际产线远没有这么理想。示教路径的误差来源有几个板材厚度公差让坡口实际位置偏移夹具反复装夹后定位销磨损同一套程序每次放上去位置都不一样焊接过程中的热变形会让薄板发生翘曲原本对准的缝口越焊越偏还有拼缝间隙波动间隙大一点小一点焊缝填充量都跟着变。弧焊对焊缝中心的要求一般在±1mm以内而示教是纯开环所有这些误差都会直接作用到焊枪上结果就是偏焊、咬边、焊缝高度不一致严重时直接烧穿试件。焊缝跟踪要解决的就是把这个开环变成闭环。视觉传感器装在焊枪前方激光器在工件表面打出一条亮线相机拍摄包含激光条纹的图像Halcon在图像里提取焊缝特征点上位机把特征点换算成机器人坐标系下的纠偏量机器人收到纠偏量后对当前焊接路径做横向修正。这个过程不是定位一次就结束而是每一帧都重复执行所以后面所有代码设计都围绕“实时、稳定、可恢复”三个词展开。还有一点容易被新人忽略焊缝跟踪和一般的机器人视觉引导定位不一样。定位抓取是“看到目标算一次坐标抓一次”对实时性要求没那么苛刻焊缝跟踪是连续动态修正焊枪一直在走图像一直在来算法处理慢一帧都可能让修正量失去意义。项目开始时我就跟团队定了一条规矩所有模块先按最坏延迟做预算而不是按平均延迟做预算。2. 整体架构选型C#、Halcon和机器人三者怎么分工焊缝跟踪上位机不是一个人干所有事C#、Halcon、机器人各自有明确边界。选型时不要先想“哪个技术栈最好”先想“现场最怕什么”。做视觉集成的新手很容易把精力花在算法炫技上结果界面卡、通信断、标定错一到现场全崩。下面说说我实际采用的架构和理由。2.1 为什么上位机选C#而不是其他机器人视觉类上位机语言选择有很多但我最终选了C#。不是因为它“生态好”这种虚话而是三个现实原因。一是视觉集成团队里C#的接受度最高。现场维护的人不一定是专职软件工程师C#的代码结构直观好交接。二是Windows Forms或者WPF做现场界面效率确实高实时图像窗口、偏差曲线、参数面板半天就能搭起来。三是Halcon官方提供HalconDotNetC#可以直接调用算子不需要自己写DLL桥接省掉大量底层工作。对比一下其他方案C当然性能最好但开发和调试成本明显高如果项目帧率要求没有极端到毫秒级C#的托管代码完全够用。Python做算法原型很快但到了机器人通信、多线程控制、部署环境时包管理、解释器版本、工控机兼容性都会变成额外负担现场设备又普遍是Windows老工控机。对我这个项目来说实时性需求是“每帧处理在20毫秒上下”C#没有任何压力。技术方案开发效率实时性部署稳定性适用阶段C# HalconDotNet高足够高正式工程C Halcon C API低高高极端性能要求Python Halcon库高一般较低算法原型验证2.2 Halcon只做它最擅长的事Halcon在这套系统里的角色是“图像处理引擎”不是“整个系统”。很多初学者喜欢把界面、线程、通信全部塞进HDevelop脚本里这是很典型的错误认知。HDevelop适合做算法验证不适合做工程应用因为它本身是个交互式环境无法优雅地处理多线程、异常恢复和协议问题。工程里正确做法是引用HalconDotNet把HDevelop里验证好的算子流程打包成C#方法封装成一个独立的视觉服务。外部调用者看到的接口很少比如传入一帧图像和机器人当前位姿返回一个纠偏坐标。这样视觉算法内部怎么改都不会影响通信模块和界面模块后期调试也方便很多。我在项目里把Halcon负责的内容圈得很死图像采集、ROI裁剪、预处理、激光条纹分割、焊缝特征点提取、坐标换算。C#负责的是流程调度、线程管理、机器人通信、界面展示、参数保存、日志记录。这个边界一旦划清楚写代码的时候思路就非常干净。2.3 两端通信TCP最省事也最考验协议设计机器人与上位机之间的通信方案市面上常见的是IO硬接线、ModbusTCP、TCP Socket、厂商SDK这几种。IO硬接线只能传触发信号焊缝跟踪需要连续传输坐标直接排除。ModbusTCP能读点位但它本质是周期轮询抖动比较明显不适合高频纠偏。厂商SDK功能强大但绑定特定平台升级和维护受制于人我一般只在必须读机器人内部状态时才用。通信方案能传什么延迟/稳定性实际使用评价IO硬接线开关量、触发低但信息量小只适合启停ModbusTCP寄存器、点位周期5-20ms抖动一般适合状态读取TCP Socket自定义报文1-5ms可控焊缝跟踪首选厂商SDK复杂状态和数据稳定但绑平台深度集成才值得最后选TCP Socket因为传输量很小就是坐标和状态不需要走工业总线。TCP最通用也最可控但前提是协议必须自己严格设计报文帧头、长度、累加和校验、异常回复、断线重连都要在联调前定清楚。协议设计不好的话现场会出现各种灵异问题比如收了一堆乱码、机器人偶尔不响应、上位机假死。3. 坐标系和标定所有跟踪精度都从这里来视觉引导机器人最绕不开的是坐标转换。很多项目做到一半发现“为什么识别挺准但机器人就是焊歪了”十有八九是坐标系没理清。焊缝跟踪对空间关系的依赖比视觉定位还要强因为你的纠偏量最终要叠加到机器人路径上哪怕差两三个毫米焊接效果都完全不同。3.1 三个坐标系之间的变换链一套完整的焊缝跟踪系统里至少有三个坐标系像素坐标系、相机坐标系、机器人基坐标系。相机拍到的是一张二维图像图像里的行和列只是像素位置要把它变成机器人能用的空间坐标必须经过一连串变换。变换链可以这样理解激光条纹上的一个像素点先通过相机内参变成相机坐标系下的一个三维点得到的是相机“眼睛”看到的空间位置再通过手眼矩阵变成机器人末端法兰坐标系下的点最后通过机器人当前位姿的正解变成机器人基坐标系下的点。写成矩阵链就是P_base T_base_flange × T_flange_cam × P_cam这个公式看起来有点吓人实际思想很简单就像你在手机地图APP里看到一个点APP先把屏幕上的像素点换算成手机坐标系再考虑手机朝向和位置最终给到你所在城市街道上的经纬度。机器人也是这个流程只是每一步都用矩阵表示。实际项目中注意别把“机器人当前位姿”和“视觉处理时刻的位姿”搞混。图像采到的时候机器人已经在移动处理完再下发时机器人已经走了几十毫米这个时间差必须用延迟补偿来吸收否则坐标永远对不上。3.2 手眼标定与像素当量相机装在机器人上有两种方式焊缝跟踪几乎都用Eye-in-Hand也就是相机固定在焊枪或者传感器支架上跟着焊枪走。好处是视野里永远是焊枪前方的一小段工件摆放偏一点也无所谓标定一次后换同类工件不用重新标定。标定的标准做法是把标定板固定在焊接工作台上机器人末端带着相机移动到多个不同位置和姿态每次拍照并记录当前的机器人法兰位姿然后用Halcon的CalibrateHandEye算子求出相机相对法兰坐标系的位姿。这个过程需要标定板项目里用的是Halcon标准标定板其他的标定板算法兼容性没有前者好。有一个非常容易踩的坑有人图省事不做完整手眼标定只在一个固定高度下测量“每像素对应多少毫米”的像素当量二维纠偏就靠这个比例实现。这种方案在工件表面高度几乎不变的情况下能凑合但只要焊枪高度稍微变一点镜头到工件距离变物距一变比例就失效纠偏量就开始漂。既然项目叫焊缝跟踪就不该省这一步至少做一次完整手眼标定精度才有基本保障。3.3 前视距离与延迟补偿激光传感器永远不会装在焊枪正下方而是装在焊枪前方大概20到50毫米的位置这个距离就是“前视距离”。为什么必须在前面因为视觉系统需要时间焊枪到达某个焊缝点之前视觉必须已经算出那个点需要的纠偏量。延迟补偿的核心公式很简单提前量 物理前视距离 焊接速度 × 系统总延迟举一个实际算例前视距离20mm焊接速度10mm/s系统总延迟60ms那么提前量是20 10 × 0.06 20.6mm。也就是说视觉在焊枪前方20.6mm处已经提前知道了纠偏需求等焊枪真正走到那个位置所有修正都已经完成。反过来如果前视距离太小、速度又很快图像还没处理完焊枪就已经压上缝了这时再纠偏就会走出S形路径焊缝外观很难看还会加剧机械磨损。我在项目中一般把前视距离取在20到50mm之间给处理链路至少留出50到100ms的时间余量。前视距离也不能过大过大意味着视觉点在很远处焊缝走向一旦有弧度预测误差会变大所以具体取值要根据工件形状和焊接速度实测权衡。4. Halcon焊缝特征提取从一帧激光条纹图到纠偏坐标整个系统里最容易被拿来炫耀的就是图像算法但真正到现场你会发现算法稳定比算法复杂重要得多。我在这个项目里用的Halcon特征提取流程非常传统没有上深度学习但现场运行稳定性反而更好。原因很简单激光结构光场景里条纹特征清晰、规律固定传统几何方法可解释、可调试、可控。4.1 预处理滤飞溅、增强对比、锁ROI原始图像里除了激光器打出的亮条纹还有环境光、焊接弧光、金属飞溅。如果一上来就直接做阈值分割飞溅很容易被误判成激光条纹焊缝特征点就会被带偏。预处理第一步是限制ROI。用ROI把图像范围锁在激光条纹附近比如焊枪前方的一条带状区域。这么做有两个好处一是减少处理像素数量节省计算时间二是从物理上排除电弧区域和大部分飞溅区域。ROI不是随便画的要和传感器安装位置对应好现场换装后必须重新调整。预处理第二步是中值滤波。中值滤波对飞溅这类椒盐噪声的抑制效果比高斯滤波好同时还能保留条纹边缘。我用的核大小是5×5圆形。第三步是做对比度拉伸或者直方图均衡让暗色金属背景和亮色激光条纹之间的差距更明显。预处理段的Halcon代码大致是这个风格HObject image, roi, imageReduced, median; HOperatorSet.ReadImage(out image, framePath); // 实际工程中是 GrabImageAsync HOperatorSet.ReduceDomain(image, roi, out imageReduced); HOperatorSet.MedianImage(imageReduced, out median, 5, circle);这里要注意Halcon里所有中间对象都要及时释放特别是在长时间运行的跟踪任务里HObject句柄泄漏会导致内存持续上涨程序跑几小时就卡死。4.2 激光条纹分割与中心线提取预处理之后激光条纹在图像里是一块高亮区域。用阈值分割把亮条纹提取出来阈值的选择可以直接固定也可以根据灰度直方图双峰自动选取。我习惯先算一次直方图在两个峰之间的谷底取阈值这样对光线微弱变化有一定自适应能力。阈值提取出来的区域还需要用connection算子做连通域分离因为图像里可能同时存在激光条纹和个别漏网的飞溅点。分离之后用select_shape按面积和宽度过滤只留下面积最大、形状最接近“细长三角”的条纹区域。这一步过滤掉绝大多数干扰。条纹区域出来后直接用skeleton算子提取骨架再用gen_contour_region_xld把骨架转成XLD轮廓最后用fit_line_contour_xld拟合直线段。这样每一段激光条纹都会变成一条带起止点的直线。对于V型坡口激光条纹在坡口处会出现一个明显的折角条纹整体看起来是两段直线拼出一个角度正是这个折角就是焊缝中心特征。HObject region, connected, selected, skeleton, contours; HTuple area; HOperatorSet.Threshold(median, out region, minGray, maxGray); HOperatorSet.Connection(region, out connected); HOperatorSet.SelectShape(connected, out selected, area, and, 800, 99999); HOperatorSet.Skeleton(selected, out skeleton); HOperatorSet.GenContourRegionXld(skeleton, out contours, codelet);select_shape里的面积阈值800要按实际图像分辨率调整不能写死。我通常的做法是把它放到配置文件里现场用参数面板直接调。4.3 坡口特征点定位与坐标换算拿到两条拟合直线后焊缝特征点的定位就比较直接了。V型坡口就是求两条直线的交点Halcon里用intersection_lines算子一步到位。搭接焊缝和角焊缝稍有变化搭接处激光条纹存在高度跳变目视就是一个错位需要用端点识别或者检测条纹断裂位置角焊缝两条直线的夹角相对固定交点即是特征点。特征点拿到的是像素坐标必须通过标定矩阵和机器人位姿换算成机器人坐标系下的纠偏坐标。二维纠偏场景下用affine_trans_point_2d做仿射变换就够了如果工件表面高度变化大我会换成完整的三维坐标转换把交点映射到基坐标系下的X、Y、Z。还有一个容易坑人的细节图像的行方向和列方向与机器人X轴、Y轴并不一定一一对应标定完必须做一次方向符号验证。我验证的方法是让机器人在焊缝垂直方向手动偏移1mm观察图像里特征点往哪个方向移动确认图像坐标与机器人坐标的方向一致。如果符号搞反就会出现“明明有偏差一纠偏反而更歪”的诡异情况而且很难排查。单帧图像不一定每次都能提取到有效特征点。所以代码里必须设计异常分支当这一帧没有找到交点或者交点置信度太低时保持上一帧纠偏量继续执行连续多帧失败才报警。这比直接输出一个异常坐标要安全得多因为焊接过程不能随便中断。5. C#工程骨架与联合编程源码到底应该怎么写说完了算法再来讲代码工程。很多新人拿到一块项目就先把界面拖出来结果代码全堆在MainForm里几百行的事件处理函数后面谁都不敢动。焊缝跟踪这种实时系统源码结构必须一开始就设计好。5.1 工程分层让每个模块都能单独测试我采用的工程分层如下按接口和职责划分不按文件随机堆放。CameraService负责相机连接、参数配置、图像采集对外只暴露Start、Stop和最新帧事件。VisionService封装所有Halcon算子调用负责ROI、标定、特征提取、坐标换算对外暴露ProcessFrame方法。RobotService负责TCP Socket通信、协议编码解码、断线重连对外暴露SendOffset和CurrentPose事件。TrackingService负责任务编排把图像帧、处理结果、通信时机串起来是整个系统的调度中枢。MainForm只负责界面显示和参数配置不写业务逻辑。AppConfig集中管理所有可调参数比如曝光时间、ROI坐标、标定文件路径、TCP地址端口。这么分层最大的好处是每个模块都可以单独测试。VisionService可以用保存的图片回放测试RobotService可以用模拟服务器测试不需要机器人动起来就能验证大部分逻辑。联调时一旦出错也能很快定位问题在哪个服务里。5.2 采集线程与图像队列永远处理最新帧实时系统最怕串行化处理。如果在UI线程里抓图、跑算法、发命令全部串行执行界面一定会卡而且焊接过程中一直有新的纠偏需求进来旧的还没来得及处理整个链路就堵死了。我的线程模型是三个独立线程加两个队列采集线程不断GrabImageAsync抓帧把图像放进有限队列处理线程从队列取出最新一帧调用VisionService处理得到纠偏坐标通信线程负责把纠偏坐标发送给机器人同时接收机器人回传的当前位置。界面线程只在需要时从共享数据里读取最新结果显示。这里有个关键点队列满的时候要丢旧帧绝不能阻塞采集。视觉跟踪只关心当前时刻的图像早几帧的旧图一点用都没有。处理线程永远取队列里最新的一帧这样即使偶尔处理慢了一拍机器人用的也是最新视觉结果。用C#实现时可以用线程安全的BlockingCollection也可以自己写一个环形缓冲关键是定好超时和丢弃策略。我实际用的是容量为4的环形缓冲最坏情况下也只落后3帧。5.3 Halcon算子的C#封装直接从HDevelop导出再改造HDevelop里调试好的算法最终要变成C#代码。最简单的方式是HDevelop的“导出”功能生成C#代码但生成的代码通常包含大量中间变量和交互脚本不能直接用。我的做法是导出来作为参考然后重组成一个干净的方法。一个完整的视觉处理方法签名大致是这个样子public TrackResult ProcessFrame(HObject image, RobotPose pose) { TrackResult result new TrackResult(); HObject roi, imageReduced, median, region, selected, skeleton, contours; HTuple row, col, isOverlapping; HOperatorSet.ReduceDomain(image, roi, out imageReduced); HOperatorSet.MedianImage(imageReduced, out median, 5, circle); HOperatorSet.Threshold(median, out region, config.MinGray, config.MaxGray); HOperatorSet.Connection(region, out connected); HOperatorSet.SelectShape(connected, out selected, area, and, config.MinArea, 99999); HOperatorSet.Skeleton(selected, out skeleton); HOperatorSet.GenContourRegionXld(skeleton, out contours, codelet); // 直线拟合 交点计算 坐标转换 // 结果存入 result.OffsetX / result.OffsetY / result.Valid return result; }写这段代码时有两个细节要注意。一是命名冲突System.Drawing命名空间里也有Region我在C#工程里把Halcon的区域变量统一命名为hRegion或者直接全名引用避免编译器一会儿说类型冲突一会儿说找不到类型。二是中间对象用完要DisposeHalcon的HObject继承自IDisposable长时间运行的项目漏一次释放内存曲线就会一路向上跑一个班次下来程序基本不可用。5.4 机器人纠偏协议与指令循环机器人通信协议是现场问题高发区我的自定义协议参考了工业现场常见的做法。机器人作为TCP服务器上位机主动连接建立后机器人以固定周期向外发当前位置上位机每收到一帧位置就回发对应的纠偏量。报文设计尽量简单直观文本行协议就够比如机器人 - 上位机: R,SEQ1024,X210.35,Y88.46,Z12.00,E10.00,E20.00 上位机 - 机器人: C,SEQ1024,DX0.35,DY-0.12R开头的是机器人位置SEQ是帧序号上位机原样带回对应序号这样机器人侧能做校验避免发了旧数据被当成新数据使用。DX和DY分别是横向和高度方向的纠偏量。协议里必须带累加和校验位我用的是所有字节相加取低字节方法简单但特别有效。指令循环里还要加死区判断偏差绝对值小于0.3mm时不发送纠偏指令否则机器人会持续抖动焊缝看起来虽然准但机械结构寿命受影响。最关键的一点纠偏量不是原始路径的替代而是偏移叠加。也就是说机器人始终沿示教路径走上位机给的纠偏只是在这条路径上叠加一个侧向修正。这样设计的好处是万一视觉通信临时中断机器人至少还能按原始路径继续焊而不是停在原地把工件烧穿。5.5 界面和日志别小看这两块界面看起来是面子工程但焊缝跟踪现场调试时界面是唯一的观察窗口。我界面上固定显示三样东西实时图像窗口、跟踪偏差曲线、机器人当前坐标。实时图像窗口用Halcon的HWindowControl控件注意刷新操作必须在UI线程执行否则会闪屏甚至崩溃。偏差曲线用简单的自绘控件或者第三方图表控件横轴是时间纵轴是横向偏差能直接看到纠偏过程是收敛还是发散。有一次现场问题排查我就是靠偏差曲线发现的曲线在焊缝接头位置出现周期性尖峰后来检查发现传感器支架螺丝松动视觉视野在抖动。日志要有绝对时序记录每一帧的处理耗时、特征点坐标、机器人位置、纠偏量、通信状态。现场最忌“刚才好像报错了”这种模糊描述有完整日志就能回放数据流快速定位问题。我用的日志格式是TextWriterTraceListener输出到文件每行带毫秒级时间戳。6. 现场调试最容易翻车的五个环节前面讲的都是设计阶段的思路真正决定项目成败的是现场。我做过的焊缝跟踪项目几乎每一个都在现场暴露出实验室里根本没出现的问题。下面五个环节是我认为最应该提前做预案的地方。6.1 弧光和飞溅不是“调高阈值”就能解决的弧光对视觉干扰是立体的不光是图像灰度高还有热辐射、强光散射、飞溅反光。软件里调阈值只能过滤掉一部分均匀灰度抬高但弧光瞬间的高亮会直接淹没激光条纹这时候把阈值拉到很高条纹也没了。我的做法是物理过滤优先激光器前面加窄带滤光片只允许激光波长附近的光通过环境光和大部分弧光都会被滤掉相机的曝光时间压到1ms以内让弧光的“瞬时光晕”来不及积累。如果弧光干扰仍然严重可以用焊接电源的起弧信号做曝光同步只在不起弧或者起弧间歇曝光这样图像里永远没有电弧。飞溅颗粒是另一个问题它们的亮度和激光条纹相近飞行速度快单帧里就是一条短线。ROI限制在条纹附近可以有效避开大部分飞溅剩下的用median滤波和select_shape的几何过滤处理掉不要一上来就上深度学习去识别飞溅。6.2 镜面反光和氧化皮导致条纹断裂不锈钢和铝板表面容易产生镜面反射激光条纹打上去会被“漂白”成一片高光或者被氧化皮遮挡导致条纹中间断掉。这种情况单纯靠图像算法很难救因为信息本身丢失了。最有效的解决办法还是光学层面的。激光器功率降低到“刚好可见”的程度避免过曝光在相机镜头前加偏振片消除镜面物体反射产生的偏振光条纹对比度会大幅提升。我在现场实测过加偏振片后激光条纹断裂数量能减少八成以上比换任何图像后处理算法都管用。条纹断了之后用形态学闭运算可以把小间隙连起来但如果断裂超过总长度的一半建议直接丢帧保持上一帧纠偏量而不要做外推。6.3 快门、频闪与运动模糊机器人焊接是一个移动过程相机曝光时间稍微长一点激光条纹就糊成一片了。运动模糊和曝光时间、移动速度之间的关系可以用下面这个式子估算单个像素内位移 焊接速度 × 曝光时间 ÷ 像元尺寸假设像元尺寸5微米焊接速度10mm/s曝光时间2ms一个像素内位移是0.02mm完全清晰。如果速度提升到50mm/s曝光时间还是5ms单像素内位移就是0.25mm相当于条纹在图像里被拉出了将近50个像素的拖影特征点定位自然就差。所以速度提上去之后曝光时间必须压下来同时提高激光功率或者增益保证亮度这是一组配套调整。部分传感器自带频闪功能通过极短的高功率脉冲照明能有效解决运动模糊但需要控制器支持同步信号联调时别忽略接线和参数。6.4 标定参数漂移先验证矩阵再怀疑算法现场最隐蔽的问题是标定参数失效但界面和代码看起来一切正常。机器人碰撞、夹具松动、相机镜头被撞歪任何机械上的微小变动都会让原来的手眼矩阵完全失效此时图像算法再好输出的坐标也是错的。我的习惯是标定完成之后固化一个验证流程在工件表面放一个带特征点的基准块机器人走到某个固定位姿上位机计算该特征点的坐标再和机器人实际示教的坐标做对比误差超过0.5mm就提示重新标定。焊接不准时先跑这个验证流程往往几分钟就能排除或确认标定漂移问题而不用在图像算法上盲目调参。6.5 通信超时、粘包与异常恢复TCP长时间运行必然遇到粘包、半包、偶发超时。粘包是多个报文粘在一起送达半包是一个报文被拆成好几段如果解析代码只按固定长度读迟早会解析错乱。我的协议解析器做成了状态机先找帧头再读长度字段攒够整帧后再校验校验通过才交给业务层。断线重连必须做成自动的不能每掉一次线就重启程序。重连机制里要加入退避策略第一次失败等500ms再试连续失败把间隔逐步拉长到3秒避免机器人系统被频繁连接请求打挂。还有一条需要联调前和机器人侧工程师明确如果机器人连续多帧没有收到上位机纠偏量它应该继续沿示教路径直行而不是停机等待除非人工按下急停。这个约定不对焊接中途停机等于报废一块工件。最后说点个人体会。焊缝跟踪项目里最容易出彩的是算法最容易翻车的却是边界条件坐标方向、通信粘包、标定漂移、弧光干扰全是细节里的细节。我做这个系统时前期一半时间花在标定和通信稳定性上图像算法反而是最早完成的。如果你也要做同类系统我的建议是先把坐标系搞对再上Halcon先把断线重连做好再优化识别精度先在一块小工件上把纠偏闭环跑通再上产线。这个顺序反了后面每天都是救火现场。希望这份源码讲解的思路能帮你少走几段弯路。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
