Salem RoboticsYC S26这次在 Launch HN 上公开的项目方向非常聚焦工业检测机器人的软件层。它要解决的不是“造出一台能动的机器人”而是让机器人真的能在工厂产线上做检测、做判断、出报告把质检从“老师傅盯眼力”变成“机器算法数据”的稳定流程。这类软件在国内讨论度一直不低但真正落地时往往会卡在几个地方部署环境怎么搭、视觉检测怎么验证、批量任务怎么调度、接口怎么对外开放。这篇文章不打算堆概念而是把工业检测机器人软件从选型到落地会涉及的工程细节拆开讲一遍包括软件核心模块、本地服务化部署、视觉检测测试、API 接口与批量任务设计、资源占用观察和常见问题排查。需要先说清楚目前公开资料里并没有 Salem Robotics 完整 SDK 文档和接口规范所以下面内容以工业检测机器人软件普遍采用的技术架构和工程实践作为参考框架。实际接入时具体参数、接口路径和部署命令要以项目官方文档为准。这篇文章更适合两类读者一类是工厂或集成商正在评估这类软件需要知道落地时要准备什么另一类是开发者准备基于机器人检测场景自研或二次开发。1. 核心能力速览能力项说明项目类型工业检测机器人软件平台YC S26 孵化项目核心功能机器人运动控制、视觉采集、缺陷识别、检测结果记录与报告输出典型应用场景产线外观缺陷检测、设备巡检、仪表读数识别、安全巡检软件形态服务化部署为主支持本地工控机运行通常可以容器化依赖硬件工业相机、机器人本体机械臂或移动底盘、GPU 工控机、传感器主要技术栈ROS/ROS2、OpenCV、深度学习推理框架、REST/gRPC、MQTT 等接口能力通常提供 REST 或 gRPC 接口用于任务下发和结果上报批量任务支持多检测点位、多工单的队列调度实时性检测结果延迟取决于模型推理速度和相机传输方式显存占用不确定取决于视觉模型大小和输入分辨率需按实际部署测试适合读者制造企业、自动化集成商、机器人应用开发者上表里面凡是标注“不确定”的项都不要直接照搬。比如显存占用不同检测模型、不同分辨率下的差异非常大必须用自己环境的实际测试数据来定。2. 这类软件解决什么问题先看一个常见场景一条生产线上有外观检测环节传统做法是安排质检员站在工位旁边拿产品对着光源看判断有没有划痕、脏污、缺料、尺寸偏差。这种做法有两个痛点首先是人的注意力会波动连续工作几个小时后漏检率会明显上升其次是标准很难统一不同质检员对“轻微划痕算不算不良”理解不一致容易出现扯皮。工业检测机器人软件要解决的就是这三个问题一致性、可追溯性和效率。机器人按照固定轨迹和固定采图参数去拍每次采图的光照和角度都保持一致视觉模型按相同阈值做判断不会因为疲劳改变标准检测结果自动写入数据库每一件产品的检测图片、判定结果、机器位置、时间戳都可以回溯。这就是它比人工质检更受工厂欢迎的核心原因。从应用边界来看这类软件不是万能的。比如复杂装配场景里多个零件相互遮挡单纯靠二维视觉很难判断再比如需要触觉反馈的检测像按键手感、线束插接是否到位视觉软件做不了。另外如果产品换型非常频繁每次都要重新标定和训练模型维护成本会很高。所以选型前一定先确认检测对象是否稳定、缺陷类型是否可见、换型频率是否可控。3. 软件核心模块拆解把工业检测机器人软件按功能切成模块通常会分成感知、规划与控制、数据与报告、任务调度四块。3.1 感知模块感知模块是整条检测链路的核心。它负责通过工业相机、3D 相机、红外相机等传感器采集数据然后做图像预处理和缺陷识别。图像预处理一般包括灰度化、滤波、亮度归一化、边缘增强目的是把光照差异和背景噪声压下去让模型专注于缺陷本身。缺陷识别这个环节现在主流做法有两种一种是传统图像处理算法适合特征非常明确的场景比如定位圆孔、测量直线尺寸另一种是基于深度学习的检测模型比如用 YOLO 做目标检测用分割模型做缺陷区域提取适合划痕、污渍、纹理异常这类没有固定形状的问题。工业场景里两种方法经常混合使用先用传统方法做定位和测量再用深度学习模型做分类。3.2 决策规划与控制机器人不能只拍照它要能准确到达检测位置。移动机器人或机械臂的路径规划、避障、轨迹插补都由这个模块负责。工业场景下机械臂的点位通常靠示教器人工示教后保存软件负责把点位和采图动作绑定起来移动巡检机器人则需要 SLAM 定位和导航模块让机器人知道自己在哪、下一步去哪。控制模块还负责与 PLC、传送带等现场设备通信。机器人到指定位置后需要等待产品到位、触发相机拍照、判断结果后决定继续运行还是报警停机。这里对实时性要求很高通信中间件通常使用 ROS2 的 DDS、工业现场的 OPC UA或者简单直接的 Modbus TCP。3.3 数据与报告检测软件必须把每一次检测结果变成可以查询的数据。这个模块要解决三件事第一检测结果的持久化存储建议记录检测时间、产品批次、检测点位、图片路径、判定结果、置信度第二异常告警一旦出现连续不良或者模型置信度低于阈值立即推送消息到产线看板或钉钉/企业微信第三统计报表产线管理者需要知道当班次良率、缺陷类型占比、趋势变化这需要软件定期生成聚合报告。3.4 任务调度一条检测线上通常有多个工位、多台机器人、多个检测任务。任务调度模块负责把检测工单派发给空闲机器人处理优先级、超时、重试。调度模块还要考虑机器人的充电、维护状态比如移动巡检机器人电量低于 20% 时应该把任务分配给其他机器人或者安排它先充电。4. 环境准备与前置条件工业检测机器人软件不是纯软件它对运行环境和硬件有明确要求。在选型和部署之前先确认下面几项。4.1 硬件选型视觉检测模块对算力比较敏感。如果检测模型是深度学习模型强烈建议配备 NVIDIA 显卡至少需要能运行 TensorRT 的型号。纯 CPU 推理在简单场景可以用但延迟会高很多不适合高节拍产线。工控机建议选择带有足够 USB 或 GigE 接口的型号方便同时接入多个工业相机。工业相机的选型要看检测精度和节拍分辨率太低看不出细小缺陷分辨率太高会拖慢传输和推理速度。普通产品外观检测500 万像素级工业相机是比较常见的起步配置但具体还是要通过实验验证。机器人本体方面固定工位检测一般用六轴机械臂巡检场景用 AGV 或移动底盘。这里要注意的是软件层和机器人控制器之间的接口协议不同品牌机器人协议差别很大选软件前要确认是否支持你现有机器人的通信协议。4.2 软件环境从通用技术栈角度看环境依赖通常包括下面几项依赖项用途Ubuntu 20.04/22.04常见操作系统环境ROS/ROS2机器人通信与运动控制Python 3.8视觉处理与业务逻辑OpenCV图像预处理PyTorch / TensorRT深度学习模型推理Docker服务化部署RabbitMQ / Redis任务队列与缓存数据库PostgreSQL / SQLite检测结果存储版本号不要照抄不同项目差异很大。比如有的软件目前只支持 Ubuntu 20.04 和 ROS1你要硬迁到 Ubuntu 22.04 很可能踩依赖坑。在没有官方文档确认前先按项目给出的环境版本执行是最稳的做法。5. 本地服务化部署与容器化工业检测机器人软件的部署形态可以分成三种直接装在工控机上的单体应用、拆分成多个微服务的容器化部署、还有带界面的一体化检测站。单体应用适合小规模试点逻辑简单部署快但后续扩展性差。容器化部署是目前工业软件的主流做法把视觉推理服务、调度服务、接口服务、界面服务分别打包成容器方便升级和隔离。一体化检测站则是软硬结合软件提前装好到现场通电即用适合工厂不愿意自己维护环境的场景。如果采用容器化方式下面是一个简化的 Docker Compose 模板。注意这只是一个通用示例实际必须按项目提供的镜像名和环境变量修改version: 3 services: vision: image: your-registry/vision-service:latest runtime: nvidia environment: - MODEL_PATH/models/detection.engine volumes: - ./models:/models - ./images:/images ports: - 8001:8001 scheduler: image: your-registry/scheduler-service:latest environment: - QUEUE_URLredis://redis:6379/0 volumes: - ./config:/config ports: - 8002:8002 depends_on: - vision - redis api: image: your-registry/api-service:latest ports: - 8080:8080 depends_on: - scheduler redis: image: redis:7 ports: - 6379:6379 db: image: postgres:15 environment: POSTGRES_USER: robot POSTGRES_PASSWORD: robot123 POSTGRES_DB: inspection volumes: - ./pgdata:/var/lib/postgresql/data启动命令docker compose up -d docker compose logs -f启动后要验证三件事第一个服务是否正常监听端口第二个容器之间网络是否通了第三个推理服务能否正常加载模型。6. 视觉检测功能测试与效果验证软件部署完不能直接投产。需要先按功能模块做一轮验证确认视觉检测效果、机器人动作准确性和整体稳定性。6.1 相机标定测试测试目的确认相机内参和坐标映射是否准确。操作步骤准备标定板放在检测工位中心采集 10 到 20 张不同角度图像执行标定算法输出相机内参和畸变系数。如果检测系统涉及机械臂引导定位还需要做手眼标定确认相机坐标和机器人基座坐标的转换关系。判断标准重投影误差小于 0.1 像素通常说明标定质量可以接受。如果误差明显偏大检查标定板是否平整、采集图像是否清晰、光源是否稳定。6.2 图像采集与缺陷识别测试测试目的确认机器人到位后能稳定触发相机并且识别结果正确。操作步骤准备合格品和带有典型缺陷的不良品样本放到检测工位上机器人按照预设检测点位依次采图软件输出每个样本的检测结果和置信度。输入样本示例把 50 个合格品和 50 个带缺陷样本混合编号记录软件判定的良率与人工标准结果做对比。预期结果合格品全部放行缺陷品被识别出来。最终判定参考指标是漏检率尽量低误检率也不能太高否则现场停机次数会非常频繁。6.3 漏检率和误检率评估漏检率等于实际有缺陷但软件判为合格的数量除以实际有缺陷总数误检率等于实际合格但软件判为缺陷的数量除以实际合格总数。测试做法是准备足够多的样本覆盖不同类型的缺陷比如划痕、污渍、变形、缺料分别统计在两个率上的表现。如果漏检率偏高说明模型对某些缺陷类型的特征学习不够需要补充样本重新训练如果误检率偏高说明阈值设置过紧可以调整置信度阈值。6.4 机器人重复定位精度测试目的确认机器人每次到达检测点位的位置是否一致位置漂移会影响采图质量。操作步骤让机器人反复执行同一检测任务 50 次每次到达目标点位后记录实际位姿计算位置偏差和角度偏差。判断标准重复定位偏差应该远小于检测精度要求。如果机械臂重复定位不稳定检查机器人关节是否磨损、负载是否超重、基座是否固定牢靠。7. 接口 API 与批量任务设计工业检测机器人软件除了界面操作还应该提供接口方便和工厂 MES、WMS、或自研系统对接。常见的接口设计包括任务下发、检测结果查询、机器人状态查询、实时告警。7.1 接口设计思路任务下发接口一般是这样的外部系统提交一个检测工单内容包括产品型号、批次号、检测点位、图片保存路径。软件收到后把任务放入队列调度模块按优先级分配机器人去执行。执行完成后检测结果通过回调或结果查询接口返回。下面是一段简化后的工单 JSON 示例{ order_id: WO20250101-001, product_model: A234, batch_no: B20250101, robot_id: R01, stations: [ { station_id: S1, detection_type: surface_defect, camera: camera_front }, { station_id: S2, detection_type: dimension, camera: camera_side } ], timeout_sec: 120 }7.2 Python 调用示例外部系统调用任务下发接口可以用下面的 Python 示例import requests import json base_url http://192.168.1.100:8080 payload { order_id: WO20250101-002, product_model: A234, batch_no: B20250101, robot_id: R01, stations: [ { station_id: S1, detection_type: surface_defect, camera: camera_front } ], timeout_sec: 120 } response requests.post( f{base_url}/api/tasks, headers{Content-Type: application/json}, datajson.dumps(payload), timeout30 ) print(response.status_code) print(response.json())接口返回结果时建议同时携带任务 ID 和状态字段外部系统可以轮询或通过回调接口接收检测结果。7.3 批量任务队列设计批量任务的难点不在“能跑”而在“跑完发现中途挂了怎么处理”。生产现场网络抖动、机器人报警、相机掉线都很常见任务队列必须能容忍这些异常。推荐在任务表里维护一个状态字段pending、running、success、failed、timeout。调度模块定时扫描 pending 和 timeout 状态的任务把超时任务重试或标记为失败。重试次数建议限制在 3 次以内每次重试间隔递增避免无意义地反复触发同一台故障设备。7.4 MQTT 实时告警对于实时性要求高的场景接口轮询效率不够。更常用的是 MQTT 发布/订阅模式。检测软件把结果发布到指定主题工厂中央监控系统订阅该主题实时收到告警。比如mosquitto_pub -h 192.168.1.200 -t factory/inspection/result \ -m {order_id:WO001,station:S1,result:NG,defect_type:scratch,score:0.93}MQTT 的优势是开销小、延迟低适合产线密集上报。缺点是消息没有持久化所以重要数据仍然要同时写入数据库。8. 资源占用与性能观察工业检测机器人软件在部署后要持续观察资源占用。重点看四个指标GPU 显存、GPU 利用率、CPU 使用率、内存占用。显存占用是视觉推理服务最容易出问题的地方。检测模型加载后会占一部分显存输入图像分辨率越高、批处理数量越大显存开销越高。观察方法是启动服务后用nvidia-smi查看watch -n 1 nvidia-smi重点看进程的显存占用是否稳定是否随着任务运行而缓慢增长。如果显存持续增长不释放大概率存在内存泄漏需要重启服务或排查推理框架的显存缓存。CPU 占用主要集中在图像预处理、编解码和业务逻辑。如果 CPU 占用长期接近 100%要先看是图像缩放在吃算力还是数据库慢查询在拖后腿。推理本身应该尽量用 GPU不要让模型在 CPU 上跑。影响性能的主要因素有三个输入分辨率。分辨率越高推理耗时越长。如果缺陷本身很大不需要超高分辨率可以先用预处理把图像缩到合适尺寸。模型推理耗时。检测模型不同速度差很多。轻量模型单帧可能只要几毫秒大模型要到几十甚至上百毫秒。生产上建议用 TensorRT 做加速。批量任务并发数。同一时间多个任务并行推理会显著拉高显存占用。调小并发数可以降低显存压力但会增加整体排队时间。9. 常见问题与排查方法工业现场问题千奇百怪但有一个通用排查思路先看日志再看网络再看硬件最后看算法。下面是一份常见问题排查表。问题现象可能原因排查方式解决方案相机一直连不上驱动未装、USB 带宽不足、IP 冲突查看系统日志、检查相机驱动状态重装驱动、更换 USB 接口、固定相机 IP检测服务启动失败模型路径配置错误、依赖缺失查看启动日志、检查模型文件是否存在修正路径、重新安装依赖推理速度很慢模型未使用 GPU、分辨率过高查看 GPU 利用率、检查推理框架配置启用 TensorRT、降低输入分辨率GPU 显存不足模型较大、并发推理数过多查看 nvidia-smi 显存占用降低批量大小、使用量化模型机器人到位位置偏移机械结构松动、手眼标定失效执行重复定位精度测试重新标定、检查机械部件批量任务卡住不执行队列消费者挂掉、数据库连接池耗尽查看任务状态字段、检查队列服务重启调度服务、清理积压任务缺陷漏检率高训练样本不足、光照变化统计缺陷类型和漏检分布补充样本、调整光源、重新训练接口调用超时后端推理耗时过长、网络不通用 curl 测试接口连通性、查看日志优化推理速度、增加超时时间排查时不要一上来就改代码。先确认环境层是否正常再判断是配置问题还是算法问题。比如任务卡住先查任务是不是处于 pending 状态如果一直在 pending问题大概率在调度或者队列如果任务已经是 running但那台机器人没有动作问题可能在机器人控制器通信。10. 最佳实践与使用建议工业检测机器人软件落地的难点不在单个点而在整个系统的稳定性。下面几条建议是从实际工程项目里沉淀出来的。第一先小范围试点不要一上来就全线上。挑一条产品结构固定、节拍压力小的产线跑通整个检测流程积累真实缺陷样本再逐步扩大范围。这样模型迭代有数据支撑现场运维压力也可控。第二数据管理从一开始就要规范。检测图片、结果记录、日志归档到独立目录按日期和产品型号分目录存储。图片文件最好保留原始图和标注图两份原始图用于回溯标注图用于后续训练。第三批量任务一定要加日志和失败重试机制。任务执行前记录请求参数执行中记录中间状态失败时记录错误栈和现场截图。没有日志的批量任务出问题后只能靠猜。第四接口服务要限制访问范围。检测软件的 API 可能包含产品型号和缺陷数据属于工厂生产数据不要直接暴露到公网。建议只在内网使用配合防火墙和认证机制。第五涉及人脸、声音、版权素材或第三方设备的检测场景必须提前确认授权。比如检测摄像头拍摄画面里有人脸信息要注意数据脱敏和隐私保护检测的物料外观如果涉及客户专利或保密设计也要在数据存储和传输上做好加密。第六模型发布前要做效果复核不要只看测试集准确率。拿一批现场真实图像重新跑一遍确认漏检率和误检率都在业务可接受范围内再上线。上线后也要定期抽检模型效果因为产品工艺变化、光源老化都会让模型性能下降。11. 总结与下一步Salem Robotics 这类工业检测机器人软件项目价值在于把机器人控制、视觉识别、数据报告和任务调度整合成一个可落地的产品。如果你正在评估这类方案建议按下面的顺序做验证先确认你的检测场景是否适合视觉方案再准备测试环境和样本数据跑通视觉识别的测试然后验证机器人和软件的联动最后才是接口和批量任务对接。最容易踩的坑有三个一是忽略环境依赖拿到软件就装结果卡在版本兼容性二是跳过样本采集直接上线模型在测试集上好看到产线就崩三是批量任务没有做失败重试和日志出问题只能现场盯着看。下一步可以继续关注的点包括检测模型针对具体产线的微调、容器化部署方案的完善、以及和工厂 MES 系统的深度集成。这类软件最理想的落地效果是把检测从“定时抽检”变成“全数在线检测”每件产品都有记录每个缺陷都能追溯。这个方向并不激进它只是在重复劳动这件事上让机器替人做了。 
长河君 · 2026/8/31 14:31:49 · 阅读 1.2k 工业检测机器人软件落地指南：从部署到视觉检测与API设计
Salem RoboticsYC S26这次在 Launch HN 上公开的项目方向非常聚焦工业检测机器人的软件层。它要解决的不是“造出一台能动的机器人”而是让机器人真的能在工厂产线上做检测、做判断、出报告把质检从“老师傅盯眼力”变成“机器算法数据”的稳定流程。这类软件在国内讨论度一直不低但真正落地时往往会卡在几个地方部署环境怎么搭、视觉检测怎么验证、批量任务怎么调度、接口怎么对外开放。这篇文章不打算堆概念而是把工业检测机器人软件从选型到落地会涉及的工程细节拆开讲一遍包括软件核心模块、本地服务化部署、视觉检测测试、API 接口与批量任务设计、资源占用观察和常见问题排查。需要先说清楚目前公开资料里并没有 Salem Robotics 完整 SDK 文档和接口规范所以下面内容以工业检测机器人软件普遍采用的技术架构和工程实践作为参考框架。实际接入时具体参数、接口路径和部署命令要以项目官方文档为准。这篇文章更适合两类读者一类是工厂或集成商正在评估这类软件需要知道落地时要准备什么另一类是开发者准备基于机器人检测场景自研或二次开发。1. 核心能力速览能力项说明项目类型工业检测机器人软件平台YC S26 孵化项目核心功能机器人运动控制、视觉采集、缺陷识别、检测结果记录与报告输出典型应用场景产线外观缺陷检测、设备巡检、仪表读数识别、安全巡检软件形态服务化部署为主支持本地工控机运行通常可以容器化依赖硬件工业相机、机器人本体机械臂或移动底盘、GPU 工控机、传感器主要技术栈ROS/ROS2、OpenCV、深度学习推理框架、REST/gRPC、MQTT 等接口能力通常提供 REST 或 gRPC 接口用于任务下发和结果上报批量任务支持多检测点位、多工单的队列调度实时性检测结果延迟取决于模型推理速度和相机传输方式显存占用不确定取决于视觉模型大小和输入分辨率需按实际部署测试适合读者制造企业、自动化集成商、机器人应用开发者上表里面凡是标注“不确定”的项都不要直接照搬。比如显存占用不同检测模型、不同分辨率下的差异非常大必须用自己环境的实际测试数据来定。2. 这类软件解决什么问题先看一个常见场景一条生产线上有外观检测环节传统做法是安排质检员站在工位旁边拿产品对着光源看判断有没有划痕、脏污、缺料、尺寸偏差。这种做法有两个痛点首先是人的注意力会波动连续工作几个小时后漏检率会明显上升其次是标准很难统一不同质检员对“轻微划痕算不算不良”理解不一致容易出现扯皮。工业检测机器人软件要解决的就是这三个问题一致性、可追溯性和效率。机器人按照固定轨迹和固定采图参数去拍每次采图的光照和角度都保持一致视觉模型按相同阈值做判断不会因为疲劳改变标准检测结果自动写入数据库每一件产品的检测图片、判定结果、机器位置、时间戳都可以回溯。这就是它比人工质检更受工厂欢迎的核心原因。从应用边界来看这类软件不是万能的。比如复杂装配场景里多个零件相互遮挡单纯靠二维视觉很难判断再比如需要触觉反馈的检测像按键手感、线束插接是否到位视觉软件做不了。另外如果产品换型非常频繁每次都要重新标定和训练模型维护成本会很高。所以选型前一定先确认检测对象是否稳定、缺陷类型是否可见、换型频率是否可控。3. 软件核心模块拆解把工业检测机器人软件按功能切成模块通常会分成感知、规划与控制、数据与报告、任务调度四块。3.1 感知模块感知模块是整条检测链路的核心。它负责通过工业相机、3D 相机、红外相机等传感器采集数据然后做图像预处理和缺陷识别。图像预处理一般包括灰度化、滤波、亮度归一化、边缘增强目的是把光照差异和背景噪声压下去让模型专注于缺陷本身。缺陷识别这个环节现在主流做法有两种一种是传统图像处理算法适合特征非常明确的场景比如定位圆孔、测量直线尺寸另一种是基于深度学习的检测模型比如用 YOLO 做目标检测用分割模型做缺陷区域提取适合划痕、污渍、纹理异常这类没有固定形状的问题。工业场景里两种方法经常混合使用先用传统方法做定位和测量再用深度学习模型做分类。3.2 决策规划与控制机器人不能只拍照它要能准确到达检测位置。移动机器人或机械臂的路径规划、避障、轨迹插补都由这个模块负责。工业场景下机械臂的点位通常靠示教器人工示教后保存软件负责把点位和采图动作绑定起来移动巡检机器人则需要 SLAM 定位和导航模块让机器人知道自己在哪、下一步去哪。控制模块还负责与 PLC、传送带等现场设备通信。机器人到指定位置后需要等待产品到位、触发相机拍照、判断结果后决定继续运行还是报警停机。这里对实时性要求很高通信中间件通常使用 ROS2 的 DDS、工业现场的 OPC UA或者简单直接的 Modbus TCP。3.3 数据与报告检测软件必须把每一次检测结果变成可以查询的数据。这个模块要解决三件事第一检测结果的持久化存储建议记录检测时间、产品批次、检测点位、图片路径、判定结果、置信度第二异常告警一旦出现连续不良或者模型置信度低于阈值立即推送消息到产线看板或钉钉/企业微信第三统计报表产线管理者需要知道当班次良率、缺陷类型占比、趋势变化这需要软件定期生成聚合报告。3.4 任务调度一条检测线上通常有多个工位、多台机器人、多个检测任务。任务调度模块负责把检测工单派发给空闲机器人处理优先级、超时、重试。调度模块还要考虑机器人的充电、维护状态比如移动巡检机器人电量低于 20% 时应该把任务分配给其他机器人或者安排它先充电。4. 环境准备与前置条件工业检测机器人软件不是纯软件它对运行环境和硬件有明确要求。在选型和部署之前先确认下面几项。4.1 硬件选型视觉检测模块对算力比较敏感。如果检测模型是深度学习模型强烈建议配备 NVIDIA 显卡至少需要能运行 TensorRT 的型号。纯 CPU 推理在简单场景可以用但延迟会高很多不适合高节拍产线。工控机建议选择带有足够 USB 或 GigE 接口的型号方便同时接入多个工业相机。工业相机的选型要看检测精度和节拍分辨率太低看不出细小缺陷分辨率太高会拖慢传输和推理速度。普通产品外观检测500 万像素级工业相机是比较常见的起步配置但具体还是要通过实验验证。机器人本体方面固定工位检测一般用六轴机械臂巡检场景用 AGV 或移动底盘。这里要注意的是软件层和机器人控制器之间的接口协议不同品牌机器人协议差别很大选软件前要确认是否支持你现有机器人的通信协议。4.2 软件环境从通用技术栈角度看环境依赖通常包括下面几项依赖项用途Ubuntu 20.04/22.04常见操作系统环境ROS/ROS2机器人通信与运动控制Python 3.8视觉处理与业务逻辑OpenCV图像预处理PyTorch / TensorRT深度学习模型推理Docker服务化部署RabbitMQ / Redis任务队列与缓存数据库PostgreSQL / SQLite检测结果存储版本号不要照抄不同项目差异很大。比如有的软件目前只支持 Ubuntu 20.04 和 ROS1你要硬迁到 Ubuntu 22.04 很可能踩依赖坑。在没有官方文档确认前先按项目给出的环境版本执行是最稳的做法。5. 本地服务化部署与容器化工业检测机器人软件的部署形态可以分成三种直接装在工控机上的单体应用、拆分成多个微服务的容器化部署、还有带界面的一体化检测站。单体应用适合小规模试点逻辑简单部署快但后续扩展性差。容器化部署是目前工业软件的主流做法把视觉推理服务、调度服务、接口服务、界面服务分别打包成容器方便升级和隔离。一体化检测站则是软硬结合软件提前装好到现场通电即用适合工厂不愿意自己维护环境的场景。如果采用容器化方式下面是一个简化的 Docker Compose 模板。注意这只是一个通用示例实际必须按项目提供的镜像名和环境变量修改version: 3 services: vision: image: your-registry/vision-service:latest runtime: nvidia environment: - MODEL_PATH/models/detection.engine volumes: - ./models:/models - ./images:/images ports: - 8001:8001 scheduler: image: your-registry/scheduler-service:latest environment: - QUEUE_URLredis://redis:6379/0 volumes: - ./config:/config ports: - 8002:8002 depends_on: - vision - redis api: image: your-registry/api-service:latest ports: - 8080:8080 depends_on: - scheduler redis: image: redis:7 ports: - 6379:6379 db: image: postgres:15 environment: POSTGRES_USER: robot POSTGRES_PASSWORD: robot123 POSTGRES_DB: inspection volumes: - ./pgdata:/var/lib/postgresql/data启动命令docker compose up -d docker compose logs -f启动后要验证三件事第一个服务是否正常监听端口第二个容器之间网络是否通了第三个推理服务能否正常加载模型。6. 视觉检测功能测试与效果验证软件部署完不能直接投产。需要先按功能模块做一轮验证确认视觉检测效果、机器人动作准确性和整体稳定性。6.1 相机标定测试测试目的确认相机内参和坐标映射是否准确。操作步骤准备标定板放在检测工位中心采集 10 到 20 张不同角度图像执行标定算法输出相机内参和畸变系数。如果检测系统涉及机械臂引导定位还需要做手眼标定确认相机坐标和机器人基座坐标的转换关系。判断标准重投影误差小于 0.1 像素通常说明标定质量可以接受。如果误差明显偏大检查标定板是否平整、采集图像是否清晰、光源是否稳定。6.2 图像采集与缺陷识别测试测试目的确认机器人到位后能稳定触发相机并且识别结果正确。操作步骤准备合格品和带有典型缺陷的不良品样本放到检测工位上机器人按照预设检测点位依次采图软件输出每个样本的检测结果和置信度。输入样本示例把 50 个合格品和 50 个带缺陷样本混合编号记录软件判定的良率与人工标准结果做对比。预期结果合格品全部放行缺陷品被识别出来。最终判定参考指标是漏检率尽量低误检率也不能太高否则现场停机次数会非常频繁。6.3 漏检率和误检率评估漏检率等于实际有缺陷但软件判为合格的数量除以实际有缺陷总数误检率等于实际合格但软件判为缺陷的数量除以实际合格总数。测试做法是准备足够多的样本覆盖不同类型的缺陷比如划痕、污渍、变形、缺料分别统计在两个率上的表现。如果漏检率偏高说明模型对某些缺陷类型的特征学习不够需要补充样本重新训练如果误检率偏高说明阈值设置过紧可以调整置信度阈值。6.4 机器人重复定位精度测试目的确认机器人每次到达检测点位的位置是否一致位置漂移会影响采图质量。操作步骤让机器人反复执行同一检测任务 50 次每次到达目标点位后记录实际位姿计算位置偏差和角度偏差。判断标准重复定位偏差应该远小于检测精度要求。如果机械臂重复定位不稳定检查机器人关节是否磨损、负载是否超重、基座是否固定牢靠。7. 接口 API 与批量任务设计工业检测机器人软件除了界面操作还应该提供接口方便和工厂 MES、WMS、或自研系统对接。常见的接口设计包括任务下发、检测结果查询、机器人状态查询、实时告警。7.1 接口设计思路任务下发接口一般是这样的外部系统提交一个检测工单内容包括产品型号、批次号、检测点位、图片保存路径。软件收到后把任务放入队列调度模块按优先级分配机器人去执行。执行完成后检测结果通过回调或结果查询接口返回。下面是一段简化后的工单 JSON 示例{ order_id: WO20250101-001, product_model: A234, batch_no: B20250101, robot_id: R01, stations: [ { station_id: S1, detection_type: surface_defect, camera: camera_front }, { station_id: S2, detection_type: dimension, camera: camera_side } ], timeout_sec: 120 }7.2 Python 调用示例外部系统调用任务下发接口可以用下面的 Python 示例import requests import json base_url http://192.168.1.100:8080 payload { order_id: WO20250101-002, product_model: A234, batch_no: B20250101, robot_id: R01, stations: [ { station_id: S1, detection_type: surface_defect, camera: camera_front } ], timeout_sec: 120 } response requests.post( f{base_url}/api/tasks, headers{Content-Type: application/json}, datajson.dumps(payload), timeout30 ) print(response.status_code) print(response.json())接口返回结果时建议同时携带任务 ID 和状态字段外部系统可以轮询或通过回调接口接收检测结果。7.3 批量任务队列设计批量任务的难点不在“能跑”而在“跑完发现中途挂了怎么处理”。生产现场网络抖动、机器人报警、相机掉线都很常见任务队列必须能容忍这些异常。推荐在任务表里维护一个状态字段pending、running、success、failed、timeout。调度模块定时扫描 pending 和 timeout 状态的任务把超时任务重试或标记为失败。重试次数建议限制在 3 次以内每次重试间隔递增避免无意义地反复触发同一台故障设备。7.4 MQTT 实时告警对于实时性要求高的场景接口轮询效率不够。更常用的是 MQTT 发布/订阅模式。检测软件把结果发布到指定主题工厂中央监控系统订阅该主题实时收到告警。比如mosquitto_pub -h 192.168.1.200 -t factory/inspection/result \ -m {order_id:WO001,station:S1,result:NG,defect_type:scratch,score:0.93}MQTT 的优势是开销小、延迟低适合产线密集上报。缺点是消息没有持久化所以重要数据仍然要同时写入数据库。8. 资源占用与性能观察工业检测机器人软件在部署后要持续观察资源占用。重点看四个指标GPU 显存、GPU 利用率、CPU 使用率、内存占用。显存占用是视觉推理服务最容易出问题的地方。检测模型加载后会占一部分显存输入图像分辨率越高、批处理数量越大显存开销越高。观察方法是启动服务后用nvidia-smi查看watch -n 1 nvidia-smi重点看进程的显存占用是否稳定是否随着任务运行而缓慢增长。如果显存持续增长不释放大概率存在内存泄漏需要重启服务或排查推理框架的显存缓存。CPU 占用主要集中在图像预处理、编解码和业务逻辑。如果 CPU 占用长期接近 100%要先看是图像缩放在吃算力还是数据库慢查询在拖后腿。推理本身应该尽量用 GPU不要让模型在 CPU 上跑。影响性能的主要因素有三个输入分辨率。分辨率越高推理耗时越长。如果缺陷本身很大不需要超高分辨率可以先用预处理把图像缩到合适尺寸。模型推理耗时。检测模型不同速度差很多。轻量模型单帧可能只要几毫秒大模型要到几十甚至上百毫秒。生产上建议用 TensorRT 做加速。批量任务并发数。同一时间多个任务并行推理会显著拉高显存占用。调小并发数可以降低显存压力但会增加整体排队时间。9. 常见问题与排查方法工业现场问题千奇百怪但有一个通用排查思路先看日志再看网络再看硬件最后看算法。下面是一份常见问题排查表。问题现象可能原因排查方式解决方案相机一直连不上驱动未装、USB 带宽不足、IP 冲突查看系统日志、检查相机驱动状态重装驱动、更换 USB 接口、固定相机 IP检测服务启动失败模型路径配置错误、依赖缺失查看启动日志、检查模型文件是否存在修正路径、重新安装依赖推理速度很慢模型未使用 GPU、分辨率过高查看 GPU 利用率、检查推理框架配置启用 TensorRT、降低输入分辨率GPU 显存不足模型较大、并发推理数过多查看 nvidia-smi 显存占用降低批量大小、使用量化模型机器人到位位置偏移机械结构松动、手眼标定失效执行重复定位精度测试重新标定、检查机械部件批量任务卡住不执行队列消费者挂掉、数据库连接池耗尽查看任务状态字段、检查队列服务重启调度服务、清理积压任务缺陷漏检率高训练样本不足、光照变化统计缺陷类型和漏检分布补充样本、调整光源、重新训练接口调用超时后端推理耗时过长、网络不通用 curl 测试接口连通性、查看日志优化推理速度、增加超时时间排查时不要一上来就改代码。先确认环境层是否正常再判断是配置问题还是算法问题。比如任务卡住先查任务是不是处于 pending 状态如果一直在 pending问题大概率在调度或者队列如果任务已经是 running但那台机器人没有动作问题可能在机器人控制器通信。10. 最佳实践与使用建议工业检测机器人软件落地的难点不在单个点而在整个系统的稳定性。下面几条建议是从实际工程项目里沉淀出来的。第一先小范围试点不要一上来就全线上。挑一条产品结构固定、节拍压力小的产线跑通整个检测流程积累真实缺陷样本再逐步扩大范围。这样模型迭代有数据支撑现场运维压力也可控。第二数据管理从一开始就要规范。检测图片、结果记录、日志归档到独立目录按日期和产品型号分目录存储。图片文件最好保留原始图和标注图两份原始图用于回溯标注图用于后续训练。第三批量任务一定要加日志和失败重试机制。任务执行前记录请求参数执行中记录中间状态失败时记录错误栈和现场截图。没有日志的批量任务出问题后只能靠猜。第四接口服务要限制访问范围。检测软件的 API 可能包含产品型号和缺陷数据属于工厂生产数据不要直接暴露到公网。建议只在内网使用配合防火墙和认证机制。第五涉及人脸、声音、版权素材或第三方设备的检测场景必须提前确认授权。比如检测摄像头拍摄画面里有人脸信息要注意数据脱敏和隐私保护检测的物料外观如果涉及客户专利或保密设计也要在数据存储和传输上做好加密。第六模型发布前要做效果复核不要只看测试集准确率。拿一批现场真实图像重新跑一遍确认漏检率和误检率都在业务可接受范围内再上线。上线后也要定期抽检模型效果因为产品工艺变化、光源老化都会让模型性能下降。11. 总结与下一步Salem Robotics 这类工业检测机器人软件项目价值在于把机器人控制、视觉识别、数据报告和任务调度整合成一个可落地的产品。如果你正在评估这类方案建议按下面的顺序做验证先确认你的检测场景是否适合视觉方案再准备测试环境和样本数据跑通视觉识别的测试然后验证机器人和软件的联动最后才是接口和批量任务对接。最容易踩的坑有三个一是忽略环境依赖拿到软件就装结果卡在版本兼容性二是跳过样本采集直接上线模型在测试集上好看到产线就崩三是批量任务没有做失败重试和日志出问题只能现场盯着看。下一步可以继续关注的点包括检测模型针对具体产线的微调、容器化部署方案的完善、以及和工厂 MES 系统的深度集成。这类软件最理想的落地效果是把检测从“定时抽检”变成“全数在线检测”每件产品都有记录每个缺陷都能追溯。这个方向并不激进它只是在重复劳动这件事上让机器替人做了。