去年底，一家浙江台州的汽车零部件厂找到我们。他们有12台六轴焊接机器人，用来焊接车架和底盘组件，每条焊缝都需要达到一定的熔深和外观标准。

但最近半年，有两台机器人的焊缝质量开始不稳定——偶尔出现气孔、焊偏、熔深不够。QC抽检数据也显示焊缝尺寸偏差在增大。厂家派人来校准过一次机器人，好了两个月又复发。更让人头疼的是，生产计划经常被突发的机器人故障打乱——一台机器人突然报"关节过载"，一查是减速器坏了，换配件等了5天。

老板说了一句话特别实在："机器人不说人话，它快坏了我们完全不知道。"

这篇文章记录我们是怎么用边缘AI网关给这12台机器人做"体检"的。不是什么高深的AI模型，就是老老实实采集数据、找规律、设阈值。但做下来发现，工业机器人的预测维护跟普通旋转设备完全不是一回事。

一、现场情况摸底

第一次去车间跑了一圈，跟设备主管聊了聊，又翻了翻维修记录，发现几个关键信息：

翻维修记录时发现一个有意思的规律：最近一年发生的11次机器人非计划停机中，有7次集中在同一台机器人上。维修记录写的都是"减速器异响"、"J2轴过载"、"编码器故障"。这台机器人的工作时间已经超过3.7万小时，远超其他机器人。

这说明一个问题：机器人的寿命消耗不是均匀的。同一批购买的机器人，因为焊接负载、工作节拍、安装位置的不同，实际磨损差异很大。用统一的保养周期来管，要么过度保养浪费钱，要么保养不足出故障。

二、方案设计

给机器人做预测维护，跟给电机、泵、风机那种旋转设备完全不一样。旋转设备的故障信号很明确——振动变化就是直观的信号。但机器人的关节是一个伺服电机+减速器的组合系统，信号来源复杂得多。

我们的思路：监测三组信号

1. 关节电流/力矩——这是最容易拿到的数据。机器人控制器实时输出每个关节的电流值。电流异常升高，通常意味着关节内部阻力变大（润滑油变质、轴承磨损）。电流波动变大，可能意味着减速器齿轮间隙增大。

2. 关节位置跟随误差——控制指令要求机器人转到某个角度，实际位置和指令位置的差值叫"跟随误差"。正常值很小（通常0.01-0.05度），如果这个差值持续增大，说明关节的传动间隙在变大——也就是我们常说的"机械臂有框量了"。

3. 关节累积转数和峰值力矩——每个关节的实际使用情况不同。J1（腰回转）和J2（大臂）承重比较大，J4~J6（腕部）虽然负荷轻但动作频率高。累积转数比其他关节高很多的，可能就是薄弱环节。

架构设计

最终方案分两层：

采集层：在每台机器人控制器上加装数据采集模块，通过机器人厂商提供的API接口实时读取运行参数。发那科提供FOCAS2以太网协议，安川提供MPI/MCP协议。我们把两种协议都对接到一个统一的采集程序中。

边缘层：在车间部署一台边缘AI网关，汇总12台机器人的数据，本地做异常检测分析。选择边缘计算而不是全上云，原因是：12台机器人每100毫秒采集一次，每秒产生上千条数据，全上传云端带宽不够；而且机器人出故障了需要秒级告警，走云端延迟太长。

边缘网关运行两个核心模块：

三、实施过程

第一周：接口对接——比想象的麻烦

第一件事就是跟机器人控制器"对话"。发那科的FOCAS2协议虽然有SDK，但需要在控制器上装一个FOCAS2 Ethernet Server选项。设备主管打电话问发那科代理，对方报价每台控制器加装这个选项要收几千块。12台就是一笔不小的费用。

跟老板商量后，先选了4台"重点监护"的机器人（包括出问题最多那台）加装FOCAS2选项，其余8台通过机器人I/O模块间接采集部分数据——比如焊枪动作次数、报警代码这些基础信息。

教训：不要假设机器人控制器自带了数据接口。发那科的FOCAS2是选配功能，默认不装。对接前一定要先确认控制器的具体配置。这个信息在代理商报价单里就有，但我们一开始没仔细看。

安川的接口反而顺利一些——MPI协议走以太网，控制器默认支持，只需要在控制器设置里开一个端口号。

协议对接花了将近一周。主要问题不是协议本身，而是每台机器人的设置不一样——IP地址分配不规范（有些是固定的192.168.1.x，有些是DHCP），有些机器人在同一个网段但子网掩码不同。设备主管说"以前调试的人各搞各的，没有统一规划"。

第二周：数据采集与基线建立

数据开始来了之后，第一个发现让我很惊讶：两台同一型号的发那科机器人，在焊接同样的零件时，J3关节的峰值电流差了将近30%。

一开始怀疑传感器问题，查了很久。最后发现根本原因是其中一台机器人安装时底座垫了5mm的调整垫片，导致机器人的姿态略有不同，焊接时J3关节承受了更大的偏载力矩。这台机器人的J3电流一直比另一台高，不是最近才开始的——只是因为之前没有数据，没人注意到。

这条信息很有价值：不是故障信号，但说明机器人的安装偏差会直接影响关节的受力。如果长期偏载运行，这个关节的减速器寿命会明显缩短。

第二周后半段，我们开始建立每台机器人的基线模型。每台机器人打同样的零件、同样的焊点，记录各关节的电流和跟随误差分布。有了基线之后才发现，有几台机器人的基线本身就"不正常"——出厂就偏高或者有偏差。

第三周：异常检测逻辑上线与试运行

我们建了三层异常检测：

第一层：阈值型（硬告警）

第二层：趋势型（软告警）

第三层：对比型（横向比较）

刚开始上线时，第三层对比型检测触发了很多告警。因为之前已经发现，即使是同一型号的机器人，因为安装位置、基座调整、焊接夹具的不同，各关节的负载本身就有差异。我们不能简单用"所有机器人一样"来比较。后来改成了按"工位"分组——同一个工位上做同一种零件的机器人互相比较，这才合理。

第四周：第一例异常——SUN-04机器人J6轴电流异常

系统上线后的第8天，趋势检测发出了一条"建议关注"通知：SUN-04号机器人（出问题最多的那台）的J6关节平均电流在4天内上升了12%。

设备主管去现场检查，噪音听不出来、运动看过去正常。我们建议他用手转一下焊枪感受腕部的阻力——结果发现，和另一台同型号的机器人比，SUN-04的腕部转动有明显涩感。

后来拆开检查，J6关节的交叉滚子轴承润滑脂已经变黑、有金属粉末。轴承的保持架已经开始磨损。拆下来换新轴承时发现，保持架已经有裂纹了——再跑下去就是轴承卡死，到时候机器人腕部直接锁死，焊枪停在某个位置动不了，整条线必停。

这次提前发现让设备主管态度明显转变了。之前他对"数据监测"半信半疑，觉得"这么多年没用数据不也过来了"。但看到提前10天发现了轴承问题、在计划停机时间就完成了更换，他也承认"有数据确实不一样"。

设备主管事后说的一句话让我印象很深："以前我们知道机器人会坏，但永远是在它已经坏了之后才知道。现在至少能在它坏之前给我们打个招呼。"

四、实际效果

系统上线2个月后，我们看了看数据：

提前发现的故障隐患：4起
J6轴承磨损（SUN-04）、J3减速器异常温升（SUN-07）、J2编码器信号衰减（SUN-11）、J1关节润滑油水分超标（SUN-02）。除了润滑油问题是在计划检修中发现的，其余3起都避免了非计划停机。
非计划停机减少：约8次
相比前6个月平均每月1.8次非计划停机，这2个月只发生了1次意外停机（SUN-09的焊枪碰撞导致机器人外部电缆损坏，是人为失误，和机器人自身无关）。
维护成本的变化
原来按固定周期换油换密封圈，1年保养下来费用比较固定。现在可以"按需保养"——润滑油状态良好的关节延长保养周期，状态不好的提前干预。总体保养次数没有减少太多，但换件的时机更精准了。
异常数据发现：3台机器人的基线偏差
对比型检测发现3台机器人的关节电流基线明显偏离同型号平均水平。排查后确认：1台是安装基座偏斜导致的偏载，2台是出厂参数校准偏差。对安装基座做了微调后，J3峰值电流降低了约15%。

当然也有没解决好的问题。最麻烦的是：数据采集偶尔会断。FOCAS2连接有时候会莫名其妙断开，需要重启控制器的Ethernet Server服务。我们加了一个自动重连机制，但偶尔还是会掉线——频率从每天2-3次降到了每周1-2次。要彻底解决可能得升级控制器固件，但设备主管担心升级会影响生产，先这么用着。

五、遇到的问题和解决办法

1. 数据标定的时间窗口不够长

一周的基线数据对于工业机器人来说偏短。因为机器人在不同焊接姿态下、不同负载条件下、不同环境温度下，关节的电流和跟随误差都有差异。一周数据只覆盖了部分工况。我们在第一周后发现基线偏差较大，又加了两周的数据采集，覆盖了更多焊接姿态。

2. 编码器信号干扰

SUN-07机器人的J2跟随误差偶尔出现剧增——从正常的0.03度突然跳到0.3度，再马上恢复正常。起初以为是减速器间隙出了问题，查了很久发现是焊接电源的电磁干扰——机器人焊接时电流大，电磁场干扰了编码器信号线。在编码器线上加磁环后问题明显改善。

3. 示教器和数据采集的竞争

有一次设备工程师在用示教器手动操作机器人调整焊点位置，同时数据采集程序在读取控制器数据。结果机器人控制器报"通信总线繁忙"错误，机器人直接停了。调查发现示教器和FOCAS2共享同一条通信总线，高负载下会冲突。解决方案是给数据采集的读取频率降级——设备工程师使用示教器时，采集程序自动暂停10秒。

4. 不同品牌机器人的数据标准化

发那科和安川的数据格式完全不同。发那科返回的是"负载率百分比"（0-100%），安川返回的是"电流实际值"（A）。不能直接对比。我们统一做了一层换算——把两种数据都换算成"额定值的百分比"，这才有了横向可比性。

六、个人的思考

做完这个项目，几点体会：

工业机器人的"健康"跟人的体检很像。单项指标异常不一定说明有问题（比如某台机器人的J3电流就是一直比其他高），但指标的趋势变化比绝对值更说明问题。就像人的血压——130/85不一定有问题，但如果这个月是120/80、下个月变成130/85，就值得关注了。

数据接口是最容易被低估的成本。协议对接、软件许可、网络配置——这些东西花的功夫比写算法多得多。12台机器人，2种品牌、2种协议、各有各的IP配置，光是把所有机器人的数据读出来就花了一周。如果谁想自己搞类似的项目，一定要把接口准备工作算进预算里。

"阈值检测"比"AI模型"落得快。我们一开始想过用无监督异常检测模型来自动发现异常，但后来发现：工业场景里，符合简单阈值规则的异常检测已经能满足80%的需求。真正难的不是检测算法，而是正确的基线数据——知道"正常的机器人是什么样的"。有了这个，简单的趋势判断就很有用。

机器人预测维护有它的特殊性，不能套用旋转设备的方案。振动监测对电机、风机很有效，但对机器人就不太好用——机器人一直在动，振动信号被运动本身淹没了。关节电流和跟随误差反而是更直接的信号。每个行业、每种设备的预测维护方案都不一样，没有万能的方案。

数据采集本身就有价值。即使不做AI分析，仅仅是"能看到每台机器的运行参数"这件事，对工厂来说就已经很有用了。设备主管说他以前只能靠"耳朵听"来判断机器人有没有问题——听到异响再去查。现在他每天早上看一遍14个参数（12台+2台新增的备用机器人）的趋势图，心里就有数了。

七、给你的建议

如果你的工厂也在用工业机器人、想尝试预测维护，几点实际经验：

  1. 先确认机器人的数据接口能力。机器人控制器不一定默认提供数据读取接口。发那科的FOCAS2需要加装选配软件包，库卡的KUKA.Connectivity需要额外授权。提前跟厂家或代理商确认，把许可成本算进预算。
  2. 从"重点监护"的1-2台开始试。12台全上不可控因素太多，先从故障率比较高的机器人开始试点。验证了方案可行、数据有用，再扩展到其他设备。
  3. 建立基线要留够时间。至少2-3周的真实运行数据。一周不够——覆盖不全机器人的各种工况。
  4. 给维修人员开发一个容易理解的看板。不要让设备主管看爬虫图或PCA降维。一个简单的红黄绿状态灯+趋势曲线，就够了。
  5. 注意现场的EMC干扰。焊接电源、变频器、大功率电机——这些设备都会对编码器和传感器信号产生干扰。布线时注意屏蔽和隔离，信号线远离动力线。
  6. 不要忽视安装偏差。机器人基座的水平度、垫片厚度、基座螺栓紧固度，都会影响关节的实际负载。在建立基线时把"安装偏差"这个因素记录清楚，不要当作"系统误差"忽略掉。