企业官网建设流程全解析

这次我们来看一个工业检测机器人软件项目：Salem Robotics。它来自 Y Combinator S26 批次，做的是工业检测机器人软件层的事情。所谓检测机器人，通常分两类，一类是固定工位上的机械臂视觉检测，另一类是移动巡检机器人。Salem Robotics 的方向更接近后者，把机器人、视觉采集、AI 推理、任务调度和数据上报做成一套可落地的软件系统。

这类软件最大的价值，不是让机器人“会动”，而是把巡检、识别、判定、上报这条链路标准化。对技术工程师来说，真正要关心的是三件事：第一，能不能跑在现有的机器人硬件上；第二，视觉检测模型能不能稳定识别缺陷；第三，有没有 API 能接进自己的 MES 或告警系统。这篇文章不堆概念，直接按落地路径拆解：系统架构、环境准备、部署启动、功能测试、API 调用、批量任务、性能观察和问题排查。

需要先说明一点：Salem Robotics 目前公开的技术细节有限，下面很多命令和配置文件是工业检测机器人软件平台的通用模板，不是项目官方文档的一比一截图。实际部署时，镜像名、端口、模型路径都要按项目仓库和官方文档替换。你可以把本文当成一套验收清单，用来判断一个工业检测机器人软件平台值不值得试、怎么快速跑通最小链路。

1. Salem Robotics 核心能力速览

先把关键信息放在前面。工业检测机器人软件和普通 Web 项目不一样，它对硬件环境、相机 SDK、GPU 驱动和机器人通信都有强依赖，选型前必须先看清楚规格。

从公开信息看，这个方向典型的落地形态是：一台 AGV 巡检机器人，带着工业相机按预设点位行驶，到达检测位后触发拍照，图像上传到边缘服务器，AI 模型判断是否有表面缺陷、仪表读数异常或异物状态，最后把结果写入数据库并推送告警。软件平台需要把这条链路完整串起来。

2. 工业检测机器人软件解决什么问题

工业检测机器人软件解决的是“人工检测不稳定、数据不闭环”的问题。传统产线质检大量依赖人工目检，人员流动、疲劳、光照变化都会导致漏检。机器人检测如果能做到“同一套相机参数、同一套模型、同一套判定标准”，复现性会比人工高很多。

这类软件通常包含下面这套标准流程：

1. 管理端下发巡检任务，指定检测点位和检测次数。
2. 机器人导航到目标位置，云台或机械臂调整相机角度。
3. 工业相机触发拍照，图像进入边缘计算节点。
4. 预处理后送入 AI 模型，输出缺陷类别、置信度和位置坐标。
5. 根据规则引擎判定通过、告警或返修。
6. 结果写入数据库，生成检测报告，同步到 MES 或第三方系统。

适合使用这类软件的团队主要是：工厂自动化工程师、视觉检测系统集成商、设备巡检运维团队、以及做智能制造数字化的技术负责人。它能解决的问题是标准化的视觉质检闭环，而不是简单的“跑一个模型”。

但也有不适合的场景。第一，高速运动场景，例如传送带上每秒几十个工件的实时分拣，这需要专门的在线视觉系统和 PLC 联动，通用检测机器人软件做不了低延迟控制。第二，对算法可解释性要求极高的医疗、航空等领域，单一黑盒模型不能直接用于最终判定，必须做人工复核和冗余地验证。第三，没有稳定供电和网络环境的室外移动巡检，对续航、防水和通信的要求会远超普通软件平台的范畴。

这里也要强调使用边界。工厂内部图像数据涉及商业机密，部署时要考虑本地存储和数据脱敏。机器人运动控制涉及人身安全，任何自动巡检功能都应该先仿真、再小范围实测，不能直接把未验证的路径计划放到产线运行。

3. 系统架构与核心模块

从软件工程角度看，这类平台一般可以拆成 5 层：控制层、感知层、推理层、调度层和数据集成层。

3.1 控制层

控制层是机器人本体通信层。它负责接收任务指令，控制机器人移动、云台转动、机械臂动作，并且返回当前位姿和状态。最常见的实现方式是 ROS2，节点之间通过 Topic 和 Service 通信。比如一个navigation_node负责导航，一个camera_trigger_node负责在到达检测点后触发拍照。工业场景还会保留急停和安全 PLC，这层不能完全依赖软件，必须包含硬件安全回路。

3.2 感知层

感知层处理相机、激光雷达、传感器数据。工业相机的 SDK 通常由相机厂商提供，例如海康机器人、Basler、大恒图像等。软件平台要做的是将不同品牌相机统一封装成标准接口，这样检测算法不需要关心底层相机型号。图像采集之后，一般还要做增益调整、白平衡、畸变校正、降噪等预处理。

3.3 推理层

推理层是核心。它加载训练好的缺陷检测模型，接收图像，输出检测结果。常用的模型类型包括图像分类、目标检测和实例分割。表面划痕检测用目标检测模型更多一些，仪表读数识别通常先做目标定位再分类，缺陷区域测量可能需要分割模型。推理加速方面，工业场景普遍使用 TensorRT、OpenVINO 或者 ONNX Runtime，把模型转为优化后的引擎格式，减少显存占用和推理延迟。

3.4 调度层

调度层负责任务生命周期管理。一个检测任务从“待执行”到“执行中”，再到“成功”或“失败”，需要可靠的状态流转。多台机器人同时在线时，调度层还要处理点位冲突、充电优先级和任务抢占。这里通常会引入消息队列，把任务请求先入队，再由 Worker 并发消费。

3.5 数据集成层

数据集成层解决“检测完之后数据去哪”的问题。常见做法是把检测结果写入 PostgreSQL 或时序数据库，同时保留原始图像路径和裁剪后的缺陷子图。对外提供 REST API 或 gRPC 接口，让 MES、ERP 和告警系统可以获得检测数据。工业场景下导出 CSV、Excel 或 PDF 检测报告也是刚需。

这个架构最难的地方不是某个模型，而是这么多节点怎么稳定协同。图像时间戳要对齐，任务状态要可追踪，异常要能自动重试，模型版本要可以回滚。新平台上线时，我建议先只看两层：控制层到感知层能否稳定采集图片，推理层到数据层能否稳定输出结果。这两条链路通了，再往上加调度和外部对接。

4. 本地部署环境准备

在安装之前，先确认设备清单和软件依赖。工业场景没有统一的公网环境，很多工厂现场是内网部署，所以环境准备要特别仔细。

4.1 硬件配置建议

这里不写死具体显卡型号，因为不同检测模型的差距很大。一个 YOLOv8 模型和两个分割模型同时跑，显存占用完全不同。稳妥的做法是先准备一张 8GB 显存以上的 NVIDIA 卡，后面根据实际帧率和并发需求调整。

4.2 操作系统与依赖检查

如果按通用部署流程，推荐 Ubuntu 20.04 LTS 或 Ubuntu 22.04 LTS。先做一次环境检查：

# 查看显卡驱动和 CUDA 版本 nvidia-smi # 查看系统版本 cat /etc/os-release python3 --version # 查看 Docker 和 Compose 是否安装 docker --version docker compose version

如果跑 ROS2 相关节点，还要确认 ROS2 发行版。Ubuntu 22.04 一般对应 ROS2 Humble，Ubuntu 20.04 对应 ROS2 Foxy。相机 SDK、CUDA 和 ROS2 之间的版本匹配，往往是整个部署过程中最耗时的部分。

4.3 常用软件清单

内网部署时一定要提前准备好离线安装包，尤其是 Docker 镜像、Python 依赖和 CUDA 安装包。很多工厂现场无法直连外网下载依赖，离线包不提前备好，部署进度会被卡住。

5. 安装部署与启动服务

工业检测机器人软件平台没有一个统一的“双击安装”包，常规做法是 Docker Compose 编排服务。下面给一套通用的容器编排模板，实际使用时要替换成你项目里的镜像名和端口号。

5.1 Docker Compose 服务编排

创建docker-compose.yml，内容可以长这样：

version: "3.8" services: detector: image: your-registry/inspection-detector:latest runtime: nvidia environment: - CUDA_VISIBLE_DEVICES=0 - MODEL_PATH=/models/surface_defect_v3.engine volumes: - ./models:/models - ./data/inputs:/data/inputs - ./data/outputs:/data/outputs - ./configs:/configs ports: - "8000:8000" restart: unless-stopped webui: image: your-registry/inspection-webui:latest ports: - "8080:8080" depends_on: - detector restart: unless-stopped

这个文件里有两个服务：detector是推理服务，webui是管理界面。runtime: nvidia表示容器使用 NVIDIA GPU，前提是宿主机已经安装好 NVIDIA Container Toolkit。镜像名需要替换成实际项目地址。

启动命令：

# 检查配置 docker compose config # 后台启动 docker compose up -d # 查看日志 docker compose logs -f

5.2 访问 WebUI 和 API 服务

服务启动后，一般是这样的访问方式：

如果是在局域网访问，把127.0.0.1换成边缘服务器的实际 IP。如果页面打不开，第一步先看端口有没有被占用：

sudo apt install net-tools -y netstat -tlnp | grep -E "8000|8080"

5.3 ROS2 启动方式

如果软件平台包含 ROS2 机器人控制节点，通常是用ros2 launch启动工作空间：

source /opt/ros/humble/setup.bash source ~/inspection_ws/install/setup.bash ros2 launch inspection_bringup inspection.launch.py

启动后可以用ros2 node list查看节点列表，用ros2 topic list查看话题列表。如果节点没起来，多半是依赖没安装或者相机 SDK 没找到。

6. 功能测试与效果验证

部署完成不代表能用，必须按功能逐项验证。我建议按下面的顺序来，先打通基础链路，再测高级能力。

6.1 相机连接与图像采集测试

测试目的：确认软件平台能正确发现相机，并稳定采集图像。

操作步骤：

1. 启动相机节点或相机服务。
2. 打开 WebUI，找到相机配置页面。
3. 确认相机被识别，设置曝光、增益和白平衡。
4. 触发一次拍照，查看图像是否清晰、曝光是否正常。
5. 连续采集 100 帧，观察是否有丢帧。

预期结果：相机能被软件识别，图像能正常显示，连续采集无明显丢帧。

如果相机无法连接，优先排查：

• 相机 SDK 是否安装正确。
• IP 地址是否与相机在同一网段。
• 网线、供电和相机驱动是否正常。
• 相机是否被其他进程占用。

6.2 相机标定与坐标对齐测试

测试目的：确认图像检测结果能映射到物理空间，缺陷位置可以换算成真实坐标。

操作步骤：

1. 准备棋盘格标定板或已知尺寸的标准工件。
2. 在软件中录入标定参数或执行自动标定。
3. 拍照后，在图像上标注检测框，检查与实际工件的偏差。

判断标准：检测框中心点与实际缺陷物理中心的偏差在项目允许范围内。不同项目的尺寸偏差容忍度不同，一般要求检测框能准确对应到工件表面区域。

6.3 缺陷识别测试

测试目的：验证 AI 模型能否识别目标缺陷类型。

输入示例：

• 一张带划痕的金属表面图。
• 一张正常的工件图。
• 一张带异物的电路板图。

操作步骤：

1. 上传单张测试图或选择已采集的图像。
2. 运行表面缺陷检测模型。
3. 查看输出结果中的缺陷类别、置信度和坐标。
4. 对比正常图和缺陷图的输出差异。

预期结果：正常图无缺陷框或置信度极低；缺陷图能正确检出，并且置信度达到设定阈值。

常见问题：误检多、漏检多。先看训练数据集是否覆盖当前光照和角度，再看预处理是否一致。现场环境与训练环境差异较大时，模型效果会明显下降。

6.4 批量检测与定时巡检测试

测试目的：确认平台能处理多个检测点位、多张图片的批量任务。

操作步骤：

1. 在 WebUI 创建批量任务，选中多个检测点位。
2. 提交任务，观察队列状态变化。
3. 等待任务完成，查看每个点位的检测结果。
4. 测试失败重试机制，模拟某一路图像采集失败。

预期结果：任务能按顺序或并发执行，单个点位失败不影响其他点位，重试后能恢复。

这类测试重点看调度层。如果某个 Worker 崩溃，任务是否能被其他 Worker 接管。这里不能只看单测，要模拟至少 50 个任务的积压情况。

6.5 检测报告与告警测试

测试目的：验证检测结果是否能形成报告，能否触发告警通知。

操作步骤：

1. 选择一段时间的检测记录。
2. 导出 CSV 或 PDF 报告。
3. 模拟一次不合格检测，检查告警是否推送到配置的接收端。
4. 检查原始图像、缺陷子图是否与报告记录正确关联。

预期结果：报告中的每条检测记录都能追溯到原始任务、图像和模型版本。

7. 接口 API 与批量任务调度

工业检测机器人软件一定要有 API，因为大多数工厂不是手工操作 WebUI，而是要从 MES 自动下发任务、自动获取结果。下面给一个通用的 REST API 调用示例。

7.1 提交检测任务

任务提交端主动推送检测点位信息，服务端返回任务 ID。这里的请求字段是通用模板，实际以项目 OpenAPI 文档为准。

import requests API_BASE = "http://127.0.0.1:8000/api/v1" payload = { "camera_id": "cam_01", "inspection_point": "line_A_02", "model_name": "surface_defect_v3", "priority": 5, "images": [ "/data/inputs/lineA/part_001.png", "/data/inputs/lineA/part_002.png" ], "callback_url": "http://your-server/industrial-api/callback" } resp = requests.post(f"{API_BASE}/tasks", json=payload, timeout=10) resp.raise_for_status() task_id = resp.json()["task_id"] print("task id:", task_id)

也可以直接使用 curl 验证：

curl -X POST "http://127.0.0.1:8000/api/v1/tasks" \ -H "Content-Type: application/json" \ -d '{ "camera_id": "cam_01", "inspection_point": "line_A_02", "model_name": "surface_defect_v3" }'

7.2 查询任务状态

提交任务后，客户端需要轮询状态或等待回调。

import requests API_BASE = "http://127.0.0.1:8000/api/v1" task_id = "task_001" status = requests.get(f"{API_BASE}/tasks/{task_id}", timeout=10).json() print(status)

典型的任务状态包括：

如果是产线对接，优先用回调方式而不是长时间轮询，回调可以在任务完成时主动推送结果，减少 MES 侧的空转请求。

7.3 批量任务设计

批量检测不要一个一个请求调用，应该设计成目录扫描、任务队列和并发 Worker 三层结构。

{ "batch_name": "night_shift_inspection", "input_dir": "/data/inputs/night_shift", "output_dir": "/data/outputs/night_shift", "model_name": "surface_defect_v3", "concurrency": 2, "retry_count": 3, "save_crops": true }

批量任务的处理逻辑：

1. 扫描输入目录，生成待检测文件列表。
2. 将每个文件封装成独立任务，写入队列。
3. Worker 按并发数拉取任务，调用模型推理。
4. 写结果到输出目录，同时记录任务日志。
5. 失败任务自动重试，超过重试次数则标记失败。

批处理时最容易踩的坑是内存暴涨。如果图像一次性全部读进内存，几百张高分辨率图就能把服务器内存耗尽。正确做法是流式读取，每张图处理完就释放内存，只保留结果索引。

8. 资源占用与性能观察

工业检测机器人软件的稳定性和资源占用直接相关。建议部署后在测试环境观察一轮完整巡检任务，重点看四个指标：GPU 利用率、显存占用、推理时延、队列积压量。

8.1 使用 nvidia-smi 监控 GPU

# 实时刷新 GPU 状态 watch -n 1 nvidia-smi

主要观察：

• GPU 利用率是否长时间接近 100%。
• 显存是否持续增长。
• 是否有其他进程占用 GPU。

如果 Docker 容器内看不到 GPU，检查 NVIDIA Container Toolkit：

docker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi

能正常打印 GPU 信息，说明容器 GPU 环境正常。

8.2 性能影响因素

8.3 降低显存占用的通用思路

如果显卡显存不够，通用调整方向包括：

• 降低输入分辨率，从 1920x1080 降到 1280x720。
• 推理 batch 固定为 1，减少显存突发占用。
• 使用 TensorRT 的 FP16 或 INT8 量化。
• 检查是否同时加载了多个模型，按任务动态加载单模型。
• 给系统增加 swap 或 zram，但这只能缓解，不能完全替代显存。

8.4 端到端时延观察

单张图像从拍照到返回检测结果的端到端时延，应拆开看：取流耗时、预处理耗时、推理耗时、结果写库耗时。先用日志统计各部分耗时，再决定优化哪一环。机器人巡检对时延要求通常比在线分拣低，但如果发现机器人已经在下一个点拍照，上一张图还没有推理完，就要考虑增加边缘计算节点或降低采集频率。

9. 常见问题与排查方法

下面整理一份通用排查表，覆盖部署、运行和接口对接的常见问题。

实际排查时，不要凭感觉改配置，先在干净环境下复现，把日志和现场截图保存好，再做最小化验证。工业环境里“重启解决”不靠谱，因为问题背后往往是硬件兼容性、驱动版本或数据链路问题。

10. 最佳实践与合规边界

10.1 部署与工程化建议

第一次跑通链路建议用最小配置：一台相机、一个检测点位、一个模型。先把拍照、推理、写库这条最小链路跑通，再逐步加移动巡检、多机器人调度和 MES 对接。

任务队列要考虑幂等性。同一条任务重复推送时，服务端要能识别并跳过，否则批量巡检时会产生重复检测数据。模型文件要保存版本号，检测结果记录里必须写明模型版本，这样后续发现检测效果变差时可以快速定位是哪次模型更新引入的问题。

日志和监控是工业软件最容易忽略但最重要的一环。至少要为每台机器人、每个检测点位、每个任务记录完整生命周期。后续出了问题，没有日志很难排查。

10.2 数据安全和隐私边界

工厂现场的图像通常包含产品工艺、客户型号、设备布局等敏感信息。建议：

• 检测图像默认存储在边缘侧，不上传公网。
• 如果必须对接云端管理平台，先做脱敏处理。
• 数据库访问账号最小化，只给运行服务必需权限。
• 对外 API 必须做认证和访问控制，不能挂在公网裸跑。

10.3 版权、授权与合规

使用开源视觉模型、预训练权重、机器人控制框架时，要确认许可证是否允许商用。相机 SDK 和机器人 SDK 通常有授权范围，内网部署和商业集成要仔细阅读协议。

涉及人脸识别的安防巡检场景，必须严格遵循当地个人信息保护法规。工业检测机器人如果会拍摄到员工人脸，也应在部署方案中处理隐私问题。最稳妥的办法是：只采集检测区域，对非必要区域做遮挡或模糊处理。

10.4 安全边界

任何自动巡检和运动控制功能，都必须设计独立的安全回路。机器人软件负责“做检测”，但不应该负责“绝对防碰撞”。急停、安全围栏、光电传感器等硬件安全措施不能省。

11. 总结与下一步

Salem Robotics 代表的工业检测机器人软件方向，值得所有做智能制造和工厂自动化的技术人关注。它的核心价值不是某个识别算法有多强，而是把机器人移动、视觉采集、AI 推理、任务调度和数据报表真正做成了可运营的软件系统。

如果准备试这个方向，我建议最先验证三件事：第一，相机到推理服务的图像链路是否稳定，这是整个系统的基础；第二，缺陷检测模型在自己产线数据上的误报率是否能接受；第三，API 能否顺利对接现有 MES 或告警系统，数据是否能闭环。

最容易踩的坑是相机 SDK 兼容性、GPU 容器环境和图像时间戳错位。这三类问题在实验室环境不容易暴露，往往一到现场才爆发，前期选型时一定要留出环境适配时间。

后续可以继续扩展的方向包括：多机器人任务协同、模型自动迭代、边缘和云端数据同步、以及把检测数据和设备运维数据打通。只要基础软件链路做得足够稳，这套系统的价值会随着数据积累越来越大。如果只能带走一条经验，那就是：先把拍照触发和模型推理的最小链路跑通，再去做调度和报表系统。