# Jetson Orin NX 单机跑三路 YOLOv5 质检
## 1. 引言

随着人工智能和边缘计算技术的快速发展，工业视觉系统正朝着多通道协同、检测与决策一体化的方向演进。传统“相机 + 工控机 + PLC”的分立式架构链路长、成本高，而云端 AI 方案又难以满足产线数据不出厂的合规要求。基于轻量化检测模型（YOLOv5）与端侧推理加速（TensorRT FP16）的多路视觉质检系统，可以在一台边缘 AI 盒子上同时完成多工位并行分析、缺陷判定与执行器直控——本方案在 157TOPS 的 EA250 上实现三路相机实时检测（标签及设备侧螺丝）、毫秒级控制与本地大模型工单生成，全部推理离线闭环，为工业质检、自动化分拣与产线监控场景提供了兼顾精度、实时性与数据安全的落地范式。

## 2. 技术方案选型

### 2.1 检测端：为什么还是 YOLOv5，而不是 YOLOv8

检测模型的选型标准不是"新"，是"精度是否饱和、部署链路是否最短、省下的算力是否更有用处"。screw_v2 的 mAP50 已经打到 0.995，换 YOLOv8 精度收益并不会显著提升；而 v5n 三路只需约 84ms/周期，剩下的 GPU 空间正好用来部署一个 7B 本地大模型。 

### 2.2 推理端：为什么 TensorRT FP16

EA 是 Tegra 平台，JetPack 6 自带 TensorRT 10.3。选 FP16 而不是 INT8 的
理由：YOLOv5n 640 输入的 FP16 engine 单帧 28ms，三路加起来 84ms，对
10fps 的检测节拍（每路 150ms 周期）余量充足；INT8 还要准备校准集，对
28ms 的基数优化收益不超过 10ms，不值得再引入一层量化误差。

## 3. 实现步骤详解
### 3.1 环境准备

EA 出厂已经带了 numpy、OpenCV、
TensorRT 10.3，缺的只有 GPU 缓冲管理的 Python 绑定。

引擎用 trtexec 直构建：

```bash
# 螺丝模型 640 输入
/usr/src/tensorrt/bin/trtexec \
  --onnx=screw.onnx --saveEngine=screw.engine --fp16

# 标签模型 416 输入（复用 accessory 模型，不重新训练）
/usr/src/tensorrt/bin/trtexec \
  --onnx=label.onnx --saveEngine=label.engine --fp16
```

产出 `screw.engine` 6.2MB、`label.engine` 5.4MB，反序列化加载约 1 秒。

### 3.2 核心功能模块设计

每个检测通道是一个独立进程，内部四层，互不阻塞：

```
[Grabber 采集线程]  cv2 V4L2 + MJPG + 10fps 限帧, 队列深度1只留最新帧
        │
        ▼
[TrtYolo 推理]      letterbox 640/416 → cuda-python H2D → FP16 推理 ~28ms → D2H
        │
        ▼
[判定状态机]        numpy NMS → 检出数 → 连续5帧同向才翻转 OK/NG（~0.5s 防抖）
        │
        ├──────────────► [ModbusCoil] FC5 写线圈 → iolib:50200 → Y板 DO
        │                NG=常量吸合 / OK=释放 / 上电主动释放
        │
        └──────────────► [Preview 线程] 每300ms把带框帧原子写 /dev/shm
                         → preview_server(:8081) 推 MJPEG 到浏览器
```

三个通道 + 一个预览服务，四个 systemd 模板实例：

```ini
# /etc/systemd/system/ea-detector@.service（模板，front/back/label 三实例）
[Unit]
Description=EA visual QC channel %i
After=iolib.service
Wants=iolib.service

[Service]
Type=simple
User=bliiot
EnvironmentFile=/home/bliiot/ea_detector/%i.env
ExecStart=/usr/bin/python3 /home/bliiot/ea_detector/ea_detector.py
Restart=always
RestartSec=5
```

所有现场可变量全部进 env 文件，改参数不碰代码：

```ini
# front.env —— 正面螺丝通道
CHANNEL=front
DEVICE=4                                  # /dev/videoN
ENGINE=/home/bliiot/ea_detector/screw.engine
IMGSZ=640
MODE=screw                                # screw=数螺丝 / absent=查有无
COIL=1000                                 # FC5 线圈地址 → Y板 DO1
EXPECT=4                                  # 应检出的最少螺丝数
CONF=0.50
```

### 3.3 关键代码一：TensorRT 10 的 tensor API


```python
import tensorrt as trt
from cuda import cuda as cu, cudart as crt

crt.cudaFree(0)                    # 建立 primary context
self.engine = trt.Runtime(logger).deserialize_cuda_engine(f.read())
self.ctx = self.engine.create_execution_context()

# TRT10 用 num_io_tensors 属性（get_nb_io_tensors 是 C++ 接口名）
for i in range(self.engine.num_io_tensors):
    name = self.engine.get_tensor_name(i)
    self.ctx.set_tensor_address(name, int(dev_ptr[name]))

# 异步推理三段式
cu.cuMemcpyHtoDAsync(self.d_in, blob.ctypes.data, blob.nbytes, self.stream)
self.ctx.execute_async_v3(stream_handle=int(self.stream))
cu.cuMemcpyDtoHAsync(self.h_out.ctypes.data, self.d_out, self.h_out.nbytes, self.stream)
cu.cuStreamSynchronize(self.stream)
```

后处理不需要 torch：YOLOv5 输出 `(1,25200,6)`，obj×cls 过阈值 + numpy
写一个 IoU NMS，30 行以内。

### 3.4 关键代码二：FC5 写线圈直控 DO

iolib 的 Modbus TCP 服务端只认功能码 5（写单线圈），地址 1000~1003 对应
Y 板 4 路 DO。裸 socket 实现，带断线重连：

```python
def write_coil(self, addr, on, retry=3):
    pdu = struct.pack('>BHH', 5, addr, 0xFF00 if on else 0x0000)
    for i in range(retry):
        try:
            self.tid += 1
            mbap = struct.pack('>HHHB', self.tid, 0, len(pdu) + 1, 1)
            self.sock.sendall(mbap + pdu)
            r = self.sock.recv(256)
            if len(r) >= 12 and r[7] == 5:      # 事务号+功能码回显一致
                return True
        except Exception:
            self._connect()                     # 断线重连
    return False
```

NG 期间线圈常量吸合，回到 OK 才释放，程序启动时主动写一次释放——产线执行机构（蜂鸣器/剔除气缸）。

### 3.5 关键代码三：三路防抖状态机

判定不逐帧输出，连续 5 帧（10fps 下约 0.5s）同向才翻转，这是防误报的关键：

```python
ng_frame = (count < EXPECT) if MODE == 'screw' else (count == 0)

if ng_frame:
    ng_streak += 1; ok_streak = 0
else:
    ok_streak += 1; ng_streak = 0

if ng_streak >= STABLE_N and state != 'NG':
    state = 'NG'
    mb.write_coil(COIL, True, retry=5)          # 常量吸合
elif ok_streak >= STABLE_N and state != 'OK':
    state = 'OK'
    mb.write_coil(COIL, False, retry=5)         # 释放
```

实测行为：替换缺失螺丝设备后约 1 秒内翻 NG（5 帧防抖 + 帧间隔），换回回后约 1 秒恢复 OK 并释放 DO。

### 3.6 网页预览：共享内存代替 WebSocket

```python
# Preview 线程, 每 300ms
cv2.imencode('.jpg', img, [cv2.IMWRITE_JPEG_QUALITY, 80])[1].tofile(tmp)
os.replace(tmp, '/dev/shm/ea_%s.jpg' % CHANNEL)   # 原子替换, 读侧不会拿到半张图
```

预览服务读这三张图推 MJPEG，8081 端口单页三路。比 WebSocket+Base64
省 33% 带宽（免 Base64 膨胀），且检测进程和预览进程完全解耦——预览挂了不影响质检。

检测效果：
![Jetson Orin NX 边缘盒子三路工业相机 YOLOv5 螺丝检测正常画面](https://developer.qcloudimg.com/http-save/yehe-12877303/d4bc02715e7a2f4d25e9b81edfa05999.png)
![YOLOv5 检出螺丝缺失 NG 画面 边缘AI质检](https://developer.qcloudimg.com/http-save/yehe-12877303/6b5e75c972e282e0853ef43cd207e59c.png)

## 4. Jetson Orin NX 上部署 Qwen2.5-7B：质检日报自动生成

### 4.1 为什么要加这一层

EA 跑完三路 YOLO 之后，剩余算力足够再养一个 7B 级别的本地大模型——量化到 INT4 之后只占 4.7GB 内存和一部份 GPU 空闲算力，与三路检测互不挤兑。质检系统从"传感器"升级成"产线大脑"：感知（YOLO）→ 认知（Qwen）→ 执行三层全在一台设备、完全离线。

### 4.2 模型选型

| 候选 | 内存占用 | EA 实测/预估速度 | 定位 |
|---|---|---|---|
| Qwen2.5-0.5B q4 | ~0.6GB | 预估 60+ tok/s | 意图路由，能力过剩浪费 |
| Qwen2.5-1.5B q4 | ~1.2GB | 预估 40~60 tok/s | 轻量工单生成可用 |
| **Qwen2.5-7B q4_k_m（本项目）** | **4.7GB** | **实测 15.6 tok/s** | 报告+问答全部胜任 |
| Qwen2.5-VL 多模态 | 显著更高 | 不适用 | 视觉理解已由 YOLO 承担，重复建设 |

视觉理解交给 YOLO，LLM 只做文本层的汇总与路由——
agent 需要画面信息时，把检测框和置信度以 JSON 喂给它就够了，不要让大模型再看一遍图；

NG 几次、持续几秒这类数字全部由 Python 精确聚合后写进 prompt，模型只负责把数字组织成人话，从根上杜绝大模型编造统计数据。

### 4.3 数据地基：状态事件落盘

检测器在状态翻转处补了一行事件落盘（JSONL，O_APPEND 单行原子写，三个进程写同一个文件也不怕撕）：

```python
def log_event(**kw):
    kw['ts_full'] = time.strftime('%Y-%m-%d %H:%M:%S')
    kw['ch'] = C['CHANNEL']
    with open('/home/bliiot/ea_detector/events.jsonl', 'a') as f:
        f.write(json.dumps(kw, ensure_ascii=False) + '\n')
```

每个 NG/OK 翻转都带着时间戳、通道、检出数和检出框——这份 JSONL 就是下
面所有智能功能的唯一数据源。

### 4.4 agent 三种工作模式

一个百来行的纯标准库脚本（连 Ollama 的 HTTP 调用都是 urllib），三种模式：

```text
ea_agent.py archive  守护: 增量监视 events.jsonl
                     → NG 事件 → 归档该通道当前帧到 datasets/pending_review/(不调LLM)
ea_agent.py report   一次性: 聚合当日统计 + 异常时段 + 昨日对比 → LLM 写日报 → reports/
ea_agent.py ask ...  一次性: 统计+问题 → LLM 回答(数字与判断由脚本给出)
```


**归档**只做文件搬运：同通道 30 秒内只存一张，文件名带检出数
（`HHMMSS_n2.jpg`），攒够就是一轮"部署视角补采"的素材，为微调拉宽置信度
分界带备料——这条链路完全不需要大模型参与。

**日报**是主力功能。统计部分全在 Python 里算完：每通道 NG 次数、累计时长、
小时分布、5 分钟内≥3 次的异常时段、与昨日对比，再把这些交给 LLM 写 120 字
结论。实测输出：

![端侧质检智能体输出](https://developer.qcloudimg.com/http-save/yehe-12877303/f40cc7a66f74793b26547c26b51528d9.png)

**关键在"异常时段"这一行**：`front 在 3 分钟内连报 10 次` 这种模式，人去翻日志
要半小时，脚本一秒就算出来——这才是 agent 相对"打印计数表"的真正增量。

产线问答模式实测："哪条通道今天NG最多？现在还有没有通道处于NG状态？"
——模型正确引用统计回答了问题，没有编造。

### 4.5 部署形态

```text
[三路 ea-detector@*]──状态翻转──► events.jsonl
                                       │
                        ┌──────────────┴──────────────┐
                        ▼ 增量监视(NG)                 ▼ 定时 08:00 / 18:00
                  [ea-agent archive]              [ea-report]
                        │ 不调 LLM                     │ 聚合 → LLM 写结论
                        ▼                              ▼
              datasets/pending_review/          reports/YYYY-MM-DD_HHMM.md
              (微调素材)                          │
                                                  ▼
                                  [Ollama 127.0.0.1:11434] ← qwen2.5:7b q4
```

三个稳定化配置：Ollama 侧 `OLLAMA_NUM_PARALLEL=1`（LLM 是软任务，检测是硬实时，
限并发防止 GPU 争抢导致判定抖动）；日报用 `ea-report.timer` 定时触发，
`Persistent=true` 保证关机错过的时间点开机补跑；归档进程常驻但不碰 GPU，
对检测零影响。

### 4.6 这层带来的变化

- **质量数据有了"嘴"**：班次日报自动落到 `reports/`，异常时段一眼可见，
  不再需要人去 grep 日志；
- **实时动作不被干扰**：DO 报警仍由检测器毫秒级闭环，大模型只在事后介入，
  慢几秒不影响任何执行动作；
- **模型迭代有了料**：NG 帧自动归档，下一轮微调的样本是"攒"出来的，
  不用专门组织一次补采；
- **完全离线**：图像、质量数据、LLM 推理全部本地闭环，零数据出厂；
- **边际成本≈0**：agent 是一个百行脚本 + 一个已装好的 Ollama，没有新增
  硬件、没有新增云服务账单。
## 5. 总结

这套基于钡铼 EA250（Jetson Orin NX）的方案，其真正价值不在于“跑通了几个模型”，而在于用一台边缘 AI 盒子，打通了工业质检的“感知、认知与执行”闭环。
实践建议：
1. 大模型防“幻觉”机制：坚决不让大模型碰图像或原始数据。视觉由 YOLO 负责，统计算力由 Python 负责，LLM 仅作为“文本加工厂”将数据转化为工单，从源头杜绝 AI 编造数据。
2. 防抖：物理世界有震动和干扰，判定逻辑绝不能逐帧输出，须引入“连续 5 帧同向状态机（约0.5s）”防抖，确保执行动作准确无误。

---

随着人工智能和边缘计算技术的快速发展，工业视觉系统正朝着多通道协同、检测与决策一体化的方向演进。传统“相机 + 工控机 + PLC”的分立式架构链路长、成本高，而云端 AI 方案又难以满足产线数据不出厂的合规要求。基于轻量化检测模型（YOLOv5）与端侧推理加速（TensorRT FP16）的多路视觉质检系统，可以在一台边缘 AI 盒子上同时完成多工位并行分析、缺陷判定与执行器直控——本方案在 157TOPS 的 EA250 上实现三路相机实时检测（标签及设备侧螺丝）、毫秒级控制与本地大模型工单生成，全部推理离线闭环，为工业质检、自动化分拣与产线监控场景提供了兼顾精度、实时性与数据安全的落地范式。

Jetson Orin NX 单机跑三路 YOLOv5 质检

在 Jetson Orin NX 边缘盒子上用 YOLOv5 + TensorRT FP16 实现三路 10fps 工业视觉质检，Modbus FC5 直控 DO 报警，并用本地 Qwen2.5-7B 自动生成班次质量日报，全流程离线。

人工智能

物联网

硬件

基于Jetson Orin NX的EA250边缘AI盒子，实现三路YOLOv5实时质检，结合TensorRT FP16加速与7B本地大模型，完成感知-认知-执行全闭环离线部署，兼顾精度、实时性与数据安全。

代码解释

数据安全

WebSocket

边缘AI

路由

Python

Agent

JSON

YOLO

4核4G3M云服务器 新用户低至38元/年！

让每一个 Agent，都跑在云上

edgezone

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Jetson Orin NX 单机跑三路 YOLOv5 质检-腾讯云开发者社区-腾讯云

Jetson Orin NX 单机跑三路 YOLOv5 质检

Jetson Orin NX 单机跑三路 YOLOv5 质检

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐