簡介這份資源面向電力巡檢與目標檢測方向的開發(fā)者、學生及科研人員提供一套基于YOLO11與YOLOv8的輸電線路過熱檢測完整方案可用于課程大作業(yè)、畢業(yè)設計或電力智能巡檢原型驗證。壓縮包共2000個文件約407.5MB包含1331個txt標注與說明、194個Python源碼、93個yaml配置、356個md文檔以及少量xml、cpp、sh、pdf等輔助文件覆蓋數據處理、模型訓練、推理部署全流程。資源內含已處理好的2000張輸電線路過熱圖像數據類別為overheat并附帶訓練與測試源代碼、已訓練好的YOLO11和YOLOv8權重以及基于PySide的圖形化界面和基于Gradio的Web界面方便直接運行與二次開發(fā)。目前已有277人學習適合希望快速掌握電力設備過熱檢測、對比兩種YOLO版本性能并落地可視化交互的讀者參考。1. 輸電線路過熱檢測為什么 yolo11 和 yolov8 要放在同一套系統里輸電線路接頭、線夾、耐張線夾這些部位一旦接觸電阻變大溫度就會異常升高紅外巡檢時表現為明顯的亮斑。傳統做法是人工看紅外圖逐張判斷一條 220kV 線路幾百個桿塔看下來眼睛都花了漏檢率還高?；?yolo11 和 yolov8 的輸電線路過熱檢測系統本質是把紅外熱成像圖里的過熱區(qū)域當成目標檢測問題來做用 yolov8 快速跑通基線、驗證數據集質量再用 yolo11 做精度和部署上的迭代最后落到邊緣設備上做實時告警。這套方案適合三類人一是做電力巡檢方向的大作業(yè)或畢設需要一套能跑通、能寫進論文的完整流程二是想把 YOLO 系列真正部署到 RK3588 這類邊緣盒子上的工程師三是手里已經有紅外數據集但不確定該用哪個版本、怎么調參的從業(yè)者。下面按數據集準備、yolov8 基線、yolo11 迭代、部署驗證、避坑的順序講清楚。2. 數據集與標注紅外過熱區(qū)域怎么變成 YOLO 能吃的格式2.1 紅外過熱檢測的數據特點與類別設計輸電線路紅外圖有幾個和普通可見光數據集不一樣的地方。第一背景極其單調天空和桿塔占了大半畫面目標只占很小一塊正負樣本極度不平衡。第二過熱區(qū)域邊界模糊紅外圖上亮斑是漸變的標注時到底框到哪一圈不同人標出來能差十幾個像素。第三同一張圖里可能有多個過熱接頭也可能一個都沒有負樣本比例高。類別設計上我一般不建議一上來就分「一般過熱、嚴重過熱、危急過熱」三級。原因是紅外圖的絕對溫度受環(huán)境溫度、發(fā)射率、拍攝距離影響很大同一溫度在不同季節(jié)可能對應不同等級模型學不到穩(wěn)定特征。更穩(wěn)的做法是先做二分類overheat和背景把分級交給后處理里的溫度閾值去判。等數據量上到幾千張、標注一致性有保證之后再考慮加overheat_mild、overheat_severe兩個類。數據集目錄按 YOLO 標準結構組織datasets/transmission_ir/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yamldata.yaml內容path: /home/user/datasets/transmission_ir train: images/train val: images/val test: images/test nc: 1 names: [overheat]這里nc是類別數二分類就是 1。names的順序必須和標注文件里 class_id 對應標錯了模型會學反。劃分比例上輸電線路場景我建議 train:val:test 7:2:1驗證集要保證每個桿塔類型、每種拍攝角度都有覆蓋不能隨機切完發(fā)現驗證集全是晴天拍的。2.2 從 VOC/COCO 轉 YOLO 格式的腳本與邊界處理很多電力數據集原始標注是 VOC 的 XML 或者 COCO 的 JSON轉 YOLO 格式時最容易翻車的是坐標歸一化和越界裁剪。下面這個腳本處理 VOC 轉 YOLOimport os import xml.etree.ElementTree as ET from PIL import Image def voc_to_yolo(xml_dir, img_dir, out_dir, classes): os.makedirs(out_dir, exist_okTrue) for xml_file in os.listdir(xml_dir): if not xml_file.endswith(.xml): continue tree ET.parse(os.path.join(xml_dir, xml_file)) root tree.getroot() img_name root.find(filename).text img_path os.path.join(img_dir, img_name) # 用真實圖片尺寸不要信 XML 里的 size標注工具經常寫錯 w, h Image.open(img_path).size lines [] for obj in root.findall(object): cls_name obj.find(name).text if cls_name not in classes: continue cls_id classes.index(cls_name) bbox obj.find(bndbox) x1 float(bbox.find(xmin).text) y1 float(bbox.find(ymin).text) x2 float(bbox.find(xmax).text) y2 float(bbox.find(ymax).text) # 裁剪到圖像范圍內防止標注越界導致歸一化后出負數 x1, y1 max(0, x1), max(0, y1) x2, y2 min(w, x2), min(h, y2) if x2 x1 or y2 y1: continue # 裁剪后無效框直接丟 cx (x1 x2) / 2.0 / w cy (y1 y2) / 2.0 / h bw (x2 - x1) / w bh (y2 - y1) / h lines.append(f{cls_id} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) out_file os.path.join(out_dir, xml_file.replace(.xml, .txt)) with open(out_file, w) as f: f.write(\n.join(lines)) voc_to_yolo(annotations/xml, images/all, labels/all, [overheat])邏輯說明YOLO 格式要求class_id cx cy w h全部歸一化到 0~1。關鍵點是圖片寬高必須從真實圖片讀XML 里的size字段經常和實際不符用錯了整批標注都會偏。裁剪那兩行是后悔藥標注工具畫框時手一抖超出邊界很常見不裁的話歸一化后出現負數或大于 1訓練時 loss 直接 NaN。參數說明classes列表順序決定 class_id必須和data.yaml的names完全一致。:.6f保留六位小數YOLO 官方推薦至少六位位數太少小目標坐標會丟精度。2.3 數據增強策略紅外圖不能照搬可見光的配方可見光那套 Mosaic、HSV 增強直接搬到紅外圖上會出問題。HSV 里的 H 色調對紅外圖沒意義紅外圖基本是偽彩色或灰度調色調等于制造不存在的樣本。我一般這樣配增強方式參數是否啟用原因mosaic1.0啟用提升小目標召回紅外目標小fliplr0.5啟用左右翻轉符合巡檢視角變化flipud0.0關閉桿塔上下翻轉不符合物理hsv_h0.0關閉紅外無色調概念hsv_s0.3弱啟用模擬不同紅外增益hsv_v0.4啟用模擬環(huán)境溫度變化scale0.5啟用模擬不同拍攝距離Mosaic 對小目標幫助很大但要注意紅外圖拼接后亮斑可能被切到邊緣訓練后期建議最后 10 個 epoch 關掉 mosaic讓模型在真實分布上收斂。這個技巧在 yolov8 和 yolo11 上都適用。3. yolov8 基線先把環(huán)境配通再談精度3.1 yolov8 環(huán)境配置與最小訓練命令yolov8 環(huán)境配置是新手最容易卡住的地方。CUDA 版本、PyTorch 版本、ultralytics 版本三者要對上。我一般用 conda 隔離conda create -n yolo8 python3.10 -y conda activate yolo8 # 根據顯卡驅動選 CUDA 版本30 系 40 系一般 cu118 或 cu121 pip install torch2.1.0 torchvision0.16.0 --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics8.1.0裝完先驗證python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))輸出True和顯卡型號才算通。如果顯示False八成是 CUDA 版本和驅動不匹配別急著改代碼先解決環(huán)境。最小訓練命令yolo detect train \ datadatasets/transmission_ir/data.yaml \ modelyolov8n.pt \ epochs100 \ imgsz640 \ batch16 \ device0 \ projectruns/ir_detect \ nameyolov8n_baseline參數說明modelyolov8n.pt是 nano 版本先用小模型跑通流程確認數據沒問題再換 s/m。imgsz640是輸入尺寸紅外小目標如果特別小可以上到 1280但顯存翻倍。batch16在 8G 顯存上跑 640 尺寸基本夠GTX1660Ti 這種 6G 卡建議降到 8。device0指定第一塊 GPU多卡用0,1。3.2 用損失曲線判斷訓練是否真的在收斂訓練跑起來不代表在收斂。yolov8 訓練完會在runs/ir_detect/yolov8n_baseline/下生成results.csv畫損失曲線import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/ir_detect/yolov8n_baseline/results.csv) df.columns df.columns.str.strip() # 列名有空格必須去 fig, axes plt.subplots(1, 2, figsize(12, 4)) axes[0].plot(df[epoch], df[train/box_loss], labeltrain box) axes[0].plot(df[epoch], df[val/box_loss], labelval box) axes[0].set_xlabel(epoch); axes[0].set_ylabel(box loss); axes[0].legend() axes[1].plot(df[epoch], df[metrics/mAP50(B)], labelmAP50) axes[1].plot(df[epoch], df[metrics/mAP50-95(B)], labelmAP50-95) axes[1].set_xlabel(epoch); axes[1].set_ylabel(mAP); axes[1].legend() plt.tight_layout() plt.savefig(loss_curve.png, dpi150)邏輯說明results.csv的列名帶前后空格不 strip 會 KeyError這是血淚經驗?？辞€重點看三條train box loss 是否穩(wěn)定下降、val box loss 是否跟著降、mAP50 是否在漲。如果 train 降 val 不降甚至漲是過擬合加數據或加增強如果兩個都不降是學習率太大或數據標注有問題。參數說明metrics/mAP50(B)是 IoU0.5 的 mAP紅外過熱檢測主要看這個mAP50-95更嚴格小目標場景一般會低不少別拿它當唯一指標。3.3 可視化熱力圖定位模型到底在看哪模型 mAP 高不代表它學對了。紅外圖里如果過熱區(qū)域旁邊有個桿塔螺栓特別亮模型可能學的是螺栓而不是過熱。用熱力圖驗證from ultralytics import YOLO import cv2 import numpy as np model YOLO(runs/ir_detect/yolov8n_baseline/weights/best.pt) img cv2.imread(test_ir.jpg) results model(img, imgsz640) # 取第一個檢測框的梯度熱力圖 for r in results: if r.boxes is None or len(r.boxes) 0: continue for box in r.boxes: x1, y1, x2, y2 map(int, box.xyxy[0].tolist()) roi img[y1:y2, x1:x2] gray cv2.cvtColor(roi, cv2.COLOR_BGR2GRAY) heatmap cv2.applyColorMap(gray, cv2.COLORMAP_JET) overlay cv2.addWeighted(roi, 0.6, heatmap, 0.4, 0) cv2.imwrite(fheat_{x1}_{y1}.jpg, overlay)邏輯說明這里用 ROI 灰度做偽熱力圖快速看模型關注區(qū)域和真實過熱亮斑是否重合。更嚴謹的做法是 Grad-CAM但對紅外圖來說過熱區(qū)域本身就是高亮灰度偽彩已經夠用。如果發(fā)現模型框的位置和亮斑中心偏了說明標注框畫大了回去修標注。參數說明imgsz640要和訓練時一致否則檢測框坐標會偏。addWeighted的 0.6/0.4 是疊加比例想讓熱力圖更明顯就調成 0.4/0.6。4. yolo11 迭代結構變化帶來哪些實際收益4.1 yolo11 網絡結構里值得關注的兩個改動yolo11 相比 yolov8在 backbone 和 head 上都有調整。對輸電線路過熱檢測這種小目標場景值得關注兩點。一是 yolo11 在 neck 部分用了更高效的特征融合結構小目標的語義信息保留得更好實測在 640 輸入下小亮斑召回比 yolov8n 高幾個點。二是 head 的解耦方式有變化分類和回歸分支的獨立性更強對邊界模糊的紅外目標回歸框更穩(wěn)。但別指望換個版本就起飛。yolo11 的收益建立在數據集質量過關的基礎上如果標注本身框得歪換什么版本都白搭。我一般先用 yolov8 跑出基線 mAP再換 yolo11 同規(guī)模模型對比漲點超過 2 個點才值得切。4.2 從 yolov8 遷移到 yolo11 的訓練配置差異yolo11 同樣用 ultralytics 框架命令幾乎一樣但有幾個參數要注意yolo detect train \ datadatasets/transmission_ir/data.yaml \ modelyolo11n.pt \ epochs100 \ imgsz640 \ batch16 \ device0 \ optimizerAdamW \ lr00.001 \ warmup_epochs3 \ projectruns/ir_detect \ nameyolo11n_iter參數說明yolo11 默認優(yōu)化器在部分版本里是 auto小數據集上 AdamW 比 SGD 收斂更穩(wěn)lr00.001是 AdamW 的常用起點比 SGD 的 0.01 小一個量級。warmup_epochs3讓學習率在前 3 個 epoch 線性上升避免一開始就大步長把預訓練權重沖壞。如果顯存夠batch可以上到 32梯度更穩(wěn)。遷移時權重不能直接復用yolov8 的.pt和 yolo11 的結構不兼容必須用 yolo11 自己的預訓練權重。數據集和data.yaml可以直接復用這是同一套系統里兩個版本能共存的基礎。4.3 兩個版本同框對比mAP、速度、顯存怎么記對比要控制變量同一份數據、同一個 imgsz、同一個 batch只換模型。記錄表格模型mAP50mAP50-95單圖推理(ms)顯存(G)參數量(M)yolov8n0.860.528.23.13.2yolov8s0.890.5614.55.411.2yolo11n0.880.557.83.02.6yolo11s0.910.5913.95.29.4以上是典型量級具體數值隨數據集變化別照抄。推理速度用model.val()里的 speed 字段或者自己寫循環(huán)測 100 張取平均。顯存用torch.cuda.max_memory_allocated()讀。選型上如果邊緣設備算力緊張yolo11n 在精度略高于 yolov8n 的同時參數量更小是更優(yōu)解如果追求極致精度且算力夠yolo11s 是甜點。5. 部署到 RK3588從 PyTorch 到邊緣盒子的完整鏈路5.1 導出 ONNX 與 RKNN 轉換的關鍵參數RK3588 部署 yolov8/yolo11標準鏈路是 PyTorch → ONNX → RKNN。導出 ONNXyolo export modelruns/ir_detect/yolo11n_iter/weights/best.pt \ formatonnx imgsz640 opset12 simplifyTrue參數說明opset12兼容性最好RKNN 工具鏈對高版本 opset 支持不穩(wěn)。simplifyTrue會做圖優(yōu)化去掉冗余算子轉換成功率更高。導出后檢查輸入輸出名字RKNN 轉換時要對上。RKNN 轉換腳本from rknn.api import RKNN rknn RKNN(verboseTrue) # 均值方差要和訓練時一致YOLO 默認 0~1 歸一化 rknn.config(mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk3588) rknn.load_onnx(modelbest.onnx) rknn.build(do_quantizationTrue, datasetquant_dataset.txt) rknn.export_rknn(best.rknn)邏輯說明mean_values和std_values決定預處理YOLO 訓練時輸入是 0~1所以 std 用 255。do_quantizationTrue做 int8 量化能大幅提速但需要quant_dataset.txt里放幾百張代表性圖片做校準。量化后精度一般掉 1~3 個點如果掉太多檢查校準集是否覆蓋了各種光照和角度。參數說明target_platformrk3588必須寫對寫錯平臺轉換出來的模型跑不了。dataset文件每行一張圖片路徑建議 200~500 張從訓練集里均勻采樣。5.2 板端推理與后處理對齊RK3588 上跑 RKNN 模型后處理要自己寫因為 RKNN 輸出的是原始特征圖不是檢測框。yolo11 和 yolov8 的輸出格式類似都是多尺度特征圖需要做解碼import numpy as np def decode_yolo(outputs, conf_thres0.25, iou_thres0.45): # outputs: list of feature maps, shape [1, 4nc, h, w] boxes, scores, class_ids [], [], [] for out in outputs: _, c, h, w out.shape out out.reshape(1, c, h * w).transpose(0, 2, 1)[0] # 前 4 個是 xywh后面是類別分數 xywh out[:, :4] cls_scores out[:, 4:] cls_id np.argmax(cls_scores, axis1) conf np.max(cls_scores, axis1) mask conf conf_thres if not mask.any(): continue # 解碼到原圖坐標這里省略 stride 和 anchor 計算按實際輸出補 boxes.append(xywh[mask]) scores.append(conf[mask]) class_ids.append(cls_id[mask]) # NMS 部分用 cv2.dnn.NMSBoxes 或自己實現 return boxes, scores, class_ids邏輯說明RKNN 輸出的特征圖需要按 stride 還原到原圖坐標再拼成 xyxy 格式做 NMS。這段代碼省略了 stride 計算實際要按模型輸出的三個尺度分別處理。后處理對齊是部署最容易翻車的地方板端框位置偏了九成是解碼時 stride 或歸一化系數寫錯。參數說明conf_thres0.25是置信度閾值紅外過熱檢測寧可多報不可漏報可以降到 0.2。iou_thres0.45是 NMS 的 IoU 閾值過熱區(qū)域重疊少可以適當調高到 0.5。5.3 邊緣端性能實測與調優(yōu)方向RK3588 上 yolo11n 量化后單幀推理大概在 30~50msyolov8n 差不多。如果達不到先查是不是跑在 CPU 上RKNN 要顯式指定 NPU 核心。多核 NPU 可以用rknn.init_runtime(core_maskRKNN.NPU_CORE_0_1_2)把三個核心都用上速度能再提一截。輸入尺寸從 640 降到 416 能提速近一倍但小目標召回會掉紅外過熱檢測不建議降太多。6. 避坑與排查這套系統最容易翻車的五個地方6.1 訓練 loss 正常但 mAP 一直是 0現象訓練日志里 box loss 在降但 mAP50 始終是 0。原因標注文件的 class_id 從 1 開始而 YOLO 要求從 0 開始模型把所有目標當背景。解決檢查labels里第一列必須是 0 到 nc-1用腳本批量掃一遍發(fā)現最大值等于 nc 就整體減 1。6.2 驗證集 mAP 很高實際巡檢圖全漏檢現象val mAP 0.9拿現場新拍的圖測一個都沒框出來。原因訓練集和驗證集來自同一批拍攝分布太像模型沒學到泛化特征。解決劃分數據集時按桿塔或按拍攝日期切不要隨機切另外檢查現場圖的分辨率和訓練圖是否差太多差太多要做 resize 或切圖。6.3 RKNN 量化后精度斷崖式下跌現象ONNX 上 mAP 0.88轉 RKNN int8 后掉到 0.6。原因校準集沒覆蓋實際場景或者量化時某些層對數值敏感。解決校準集從訓練集里按類別和亮度分層采樣至少 300 張如果還不行對敏感層做混合量化把檢測 head 保留 fp16。6.4 板端推理框位置整體偏移現象框能出來但位置比真實目標偏了幾十像素。原因后處理解碼時 stride 用錯或者預處理 resize 的 padding 沒還原。解決打印第一個特征圖的輸出尺寸反推 strideletterbox 的 padding 值要在解碼后減掉再除以縮放比例。6.5 顯存夠但訓練中途 OOM現象GTX1660Ti 6Gbatch16 跑幾十個 epoch 后突然 OOM。原因驗證階段會額外占顯存加上 dataloader 的緩存累積。解決把batch降到 8開ampTrue混合精度workers從 8 降到 4驗證頻率從每 epoch 改成每 5 個 epoch。7. 一個能落地的技巧用溫度閾值做二次過濾模型輸出的是框但電力巡檢真正要的是「這個接頭到底過不過熱」。光靠檢測框置信度不夠因為紅外圖里陽光反射、金屬反光也會形成亮斑模型分不清。我一般加一層溫度閾值過濾如果紅外圖帶溫度矩陣很多紅外相機導出時帶 RAW 溫度數據取檢測框內的最高溫和環(huán)境溫度比超過 15K 才告警。import numpy as np def temp_filter(box, temp_matrix, ambient_temp, delta15.0): x1, y1, x2, y2 box roi temp_matrix[y1:y2, x1:x2] max_temp np.max(roi) # 相對溫差比絕對溫度穩(wěn)不受季節(jié)影響 return (max_temp - ambient_temp) delta, max_temp邏輯說明temp_matrix是紅外圖對應的溫度矩陣單位攝氏度。ambient_temp取畫面里桿塔背景區(qū)域的中位數溫度。用相對溫差而不是絕對溫度是因為夏天環(huán)境 40 度時接頭 55 度不算異常冬天環(huán)境 5 度時接頭 25 度就該查了。delta15.0是經驗閾值按 DL/T 664 的慣例相對溫差超過 15K 屬于一般缺陷超過 30K 是嚴重缺陷可以按需調。參數說明temp_matrix要和可見光圖對齊如果紅外和可見光有視差先做配準。ambient_temp別用整圖平均畫面里天空占比大會把均值拉低用桿塔區(qū)域的中位數更準。這套系統我從 yolov8 基線跑到 yolo11 迭代再到 RK3588 部署前后踩的坑基本都在上面了。最大的教訓是別一上來就追新版本、追改進模塊先把數據集標注一致性做到位把 yolov8 基線跑穩(wěn)后面換 yolo11、上邊緣設備都是順水推舟的事。數據集爛什么模型都救不了。希望幫到你。本文還有配套的精品資源點擊獲取 基于yolo11與yolov8的輸電線路紅外過熱檢測系統：從數據集到RK3588部署
簡介這份資源面向電力巡檢與目標檢測方向的開發(fā)者、學生及科研人員提供一套基于YOLO11與YOLOv8的輸電線路過熱檢測完整方案可用于課程大作業(yè)、畢業(yè)設計或電力智能巡檢原型驗證。壓縮包共2000個文件約407.5MB包含1331個txt標注與說明、194個Python源碼、93個yaml配置、356個md文檔以及少量xml、cpp、sh、pdf等輔助文件覆蓋數據處理、模型訓練、推理部署全流程。資源內含已處理好的2000張輸電線路過熱圖像數據類別為overheat并附帶訓練與測試源代碼、已訓練好的YOLO11和YOLOv8權重以及基于PySide的圖形化界面和基于Gradio的Web界面方便直接運行與二次開發(fā)。目前已有277人學習適合希望快速掌握電力設備過熱檢測、對比兩種YOLO版本性能并落地可視化交互的讀者參考。1. 輸電線路過熱檢測為什么 yolo11 和 yolov8 要放在同一套系統里輸電線路接頭、線夾、耐張線夾這些部位一旦接觸電阻變大溫度就會異常升高紅外巡檢時表現為明顯的亮斑。傳統做法是人工看紅外圖逐張判斷一條 220kV 線路幾百個桿塔看下來眼睛都花了漏檢率還高?；?yolo11 和 yolov8 的輸電線路過熱檢測系統本質是把紅外熱成像圖里的過熱區(qū)域當成目標檢測問題來做用 yolov8 快速跑通基線、驗證數據集質量再用 yolo11 做精度和部署上的迭代最后落到邊緣設備上做實時告警。這套方案適合三類人一是做電力巡檢方向的大作業(yè)或畢設需要一套能跑通、能寫進論文的完整流程二是想把 YOLO 系列真正部署到 RK3588 這類邊緣盒子上的工程師三是手里已經有紅外數據集但不確定該用哪個版本、怎么調參的從業(yè)者。下面按數據集準備、yolov8 基線、yolo11 迭代、部署驗證、避坑的順序講清楚。2. 數據集與標注紅外過熱區(qū)域怎么變成 YOLO 能吃的格式2.1 紅外過熱檢測的數據特點與類別設計輸電線路紅外圖有幾個和普通可見光數據集不一樣的地方。第一背景極其單調天空和桿塔占了大半畫面目標只占很小一塊正負樣本極度不平衡。第二過熱區(qū)域邊界模糊紅外圖上亮斑是漸變的標注時到底框到哪一圈不同人標出來能差十幾個像素。第三同一張圖里可能有多個過熱接頭也可能一個都沒有負樣本比例高。類別設計上我一般不建議一上來就分「一般過熱、嚴重過熱、危急過熱」三級。原因是紅外圖的絕對溫度受環(huán)境溫度、發(fā)射率、拍攝距離影響很大同一溫度在不同季節(jié)可能對應不同等級模型學不到穩(wěn)定特征。更穩(wěn)的做法是先做二分類overheat和背景把分級交給后處理里的溫度閾值去判。等數據量上到幾千張、標注一致性有保證之后再考慮加overheat_mild、overheat_severe兩個類。數據集目錄按 YOLO 標準結構組織datasets/transmission_ir/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yamldata.yaml內容path: /home/user/datasets/transmission_ir train: images/train val: images/val test: images/test nc: 1 names: [overheat]這里nc是類別數二分類就是 1。names的順序必須和標注文件里 class_id 對應標錯了模型會學反。劃分比例上輸電線路場景我建議 train:val:test 7:2:1驗證集要保證每個桿塔類型、每種拍攝角度都有覆蓋不能隨機切完發(fā)現驗證集全是晴天拍的。2.2 從 VOC/COCO 轉 YOLO 格式的腳本與邊界處理很多電力數據集原始標注是 VOC 的 XML 或者 COCO 的 JSON轉 YOLO 格式時最容易翻車的是坐標歸一化和越界裁剪。下面這個腳本處理 VOC 轉 YOLOimport os import xml.etree.ElementTree as ET from PIL import Image def voc_to_yolo(xml_dir, img_dir, out_dir, classes): os.makedirs(out_dir, exist_okTrue) for xml_file in os.listdir(xml_dir): if not xml_file.endswith(.xml): continue tree ET.parse(os.path.join(xml_dir, xml_file)) root tree.getroot() img_name root.find(filename).text img_path os.path.join(img_dir, img_name) # 用真實圖片尺寸不要信 XML 里的 size標注工具經常寫錯 w, h Image.open(img_path).size lines [] for obj in root.findall(object): cls_name obj.find(name).text if cls_name not in classes: continue cls_id classes.index(cls_name) bbox obj.find(bndbox) x1 float(bbox.find(xmin).text) y1 float(bbox.find(ymin).text) x2 float(bbox.find(xmax).text) y2 float(bbox.find(ymax).text) # 裁剪到圖像范圍內防止標注越界導致歸一化后出負數 x1, y1 max(0, x1), max(0, y1) x2, y2 min(w, x2), min(h, y2) if x2 x1 or y2 y1: continue # 裁剪后無效框直接丟 cx (x1 x2) / 2.0 / w cy (y1 y2) / 2.0 / h bw (x2 - x1) / w bh (y2 - y1) / h lines.append(f{cls_id} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) out_file os.path.join(out_dir, xml_file.replace(.xml, .txt)) with open(out_file, w) as f: f.write(\n.join(lines)) voc_to_yolo(annotations/xml, images/all, labels/all, [overheat])邏輯說明YOLO 格式要求class_id cx cy w h全部歸一化到 0~1。關鍵點是圖片寬高必須從真實圖片讀XML 里的size字段經常和實際不符用錯了整批標注都會偏。裁剪那兩行是后悔藥標注工具畫框時手一抖超出邊界很常見不裁的話歸一化后出現負數或大于 1訓練時 loss 直接 NaN。參數說明classes列表順序決定 class_id必須和data.yaml的names完全一致。:.6f保留六位小數YOLO 官方推薦至少六位位數太少小目標坐標會丟精度。2.3 數據增強策略紅外圖不能照搬可見光的配方可見光那套 Mosaic、HSV 增強直接搬到紅外圖上會出問題。HSV 里的 H 色調對紅外圖沒意義紅外圖基本是偽彩色或灰度調色調等于制造不存在的樣本。我一般這樣配增強方式參數是否啟用原因mosaic1.0啟用提升小目標召回紅外目標小fliplr0.5啟用左右翻轉符合巡檢視角變化flipud0.0關閉桿塔上下翻轉不符合物理hsv_h0.0關閉紅外無色調概念hsv_s0.3弱啟用模擬不同紅外增益hsv_v0.4啟用模擬環(huán)境溫度變化scale0.5啟用模擬不同拍攝距離Mosaic 對小目標幫助很大但要注意紅外圖拼接后亮斑可能被切到邊緣訓練后期建議最后 10 個 epoch 關掉 mosaic讓模型在真實分布上收斂。這個技巧在 yolov8 和 yolo11 上都適用。3. yolov8 基線先把環(huán)境配通再談精度3.1 yolov8 環(huán)境配置與最小訓練命令yolov8 環(huán)境配置是新手最容易卡住的地方。CUDA 版本、PyTorch 版本、ultralytics 版本三者要對上。我一般用 conda 隔離conda create -n yolo8 python3.10 -y conda activate yolo8 # 根據顯卡驅動選 CUDA 版本30 系 40 系一般 cu118 或 cu121 pip install torch2.1.0 torchvision0.16.0 --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics8.1.0裝完先驗證python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))輸出True和顯卡型號才算通。如果顯示False八成是 CUDA 版本和驅動不匹配別急著改代碼先解決環(huán)境。最小訓練命令yolo detect train \ datadatasets/transmission_ir/data.yaml \ modelyolov8n.pt \ epochs100 \ imgsz640 \ batch16 \ device0 \ projectruns/ir_detect \ nameyolov8n_baseline參數說明modelyolov8n.pt是 nano 版本先用小模型跑通流程確認數據沒問題再換 s/m。imgsz640是輸入尺寸紅外小目標如果特別小可以上到 1280但顯存翻倍。batch16在 8G 顯存上跑 640 尺寸基本夠GTX1660Ti 這種 6G 卡建議降到 8。device0指定第一塊 GPU多卡用0,1。3.2 用損失曲線判斷訓練是否真的在收斂訓練跑起來不代表在收斂。yolov8 訓練完會在runs/ir_detect/yolov8n_baseline/下生成results.csv畫損失曲線import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/ir_detect/yolov8n_baseline/results.csv) df.columns df.columns.str.strip() # 列名有空格必須去 fig, axes plt.subplots(1, 2, figsize(12, 4)) axes[0].plot(df[epoch], df[train/box_loss], labeltrain box) axes[0].plot(df[epoch], df[val/box_loss], labelval box) axes[0].set_xlabel(epoch); axes[0].set_ylabel(box loss); axes[0].legend() axes[1].plot(df[epoch], df[metrics/mAP50(B)], labelmAP50) axes[1].plot(df[epoch], df[metrics/mAP50-95(B)], labelmAP50-95) axes[1].set_xlabel(epoch); axes[1].set_ylabel(mAP); axes[1].legend() plt.tight_layout() plt.savefig(loss_curve.png, dpi150)邏輯說明results.csv的列名帶前后空格不 strip 會 KeyError這是血淚經驗?？辞€重點看三條train box loss 是否穩(wěn)定下降、val box loss 是否跟著降、mAP50 是否在漲。如果 train 降 val 不降甚至漲是過擬合加數據或加增強如果兩個都不降是學習率太大或數據標注有問題。參數說明metrics/mAP50(B)是 IoU0.5 的 mAP紅外過熱檢測主要看這個mAP50-95更嚴格小目標場景一般會低不少別拿它當唯一指標。3.3 可視化熱力圖定位模型到底在看哪模型 mAP 高不代表它學對了。紅外圖里如果過熱區(qū)域旁邊有個桿塔螺栓特別亮模型可能學的是螺栓而不是過熱。用熱力圖驗證from ultralytics import YOLO import cv2 import numpy as np model YOLO(runs/ir_detect/yolov8n_baseline/weights/best.pt) img cv2.imread(test_ir.jpg) results model(img, imgsz640) # 取第一個檢測框的梯度熱力圖 for r in results: if r.boxes is None or len(r.boxes) 0: continue for box in r.boxes: x1, y1, x2, y2 map(int, box.xyxy[0].tolist()) roi img[y1:y2, x1:x2] gray cv2.cvtColor(roi, cv2.COLOR_BGR2GRAY) heatmap cv2.applyColorMap(gray, cv2.COLORMAP_JET) overlay cv2.addWeighted(roi, 0.6, heatmap, 0.4, 0) cv2.imwrite(fheat_{x1}_{y1}.jpg, overlay)邏輯說明這里用 ROI 灰度做偽熱力圖快速看模型關注區(qū)域和真實過熱亮斑是否重合。更嚴謹的做法是 Grad-CAM但對紅外圖來說過熱區(qū)域本身就是高亮灰度偽彩已經夠用。如果發(fā)現模型框的位置和亮斑中心偏了說明標注框畫大了回去修標注。參數說明imgsz640要和訓練時一致否則檢測框坐標會偏。addWeighted的 0.6/0.4 是疊加比例想讓熱力圖更明顯就調成 0.4/0.6。4. yolo11 迭代結構變化帶來哪些實際收益4.1 yolo11 網絡結構里值得關注的兩個改動yolo11 相比 yolov8在 backbone 和 head 上都有調整。對輸電線路過熱檢測這種小目標場景值得關注兩點。一是 yolo11 在 neck 部分用了更高效的特征融合結構小目標的語義信息保留得更好實測在 640 輸入下小亮斑召回比 yolov8n 高幾個點。二是 head 的解耦方式有變化分類和回歸分支的獨立性更強對邊界模糊的紅外目標回歸框更穩(wěn)。但別指望換個版本就起飛。yolo11 的收益建立在數據集質量過關的基礎上如果標注本身框得歪換什么版本都白搭。我一般先用 yolov8 跑出基線 mAP再換 yolo11 同規(guī)模模型對比漲點超過 2 個點才值得切。4.2 從 yolov8 遷移到 yolo11 的訓練配置差異yolo11 同樣用 ultralytics 框架命令幾乎一樣但有幾個參數要注意yolo detect train \ datadatasets/transmission_ir/data.yaml \ modelyolo11n.pt \ epochs100 \ imgsz640 \ batch16 \ device0 \ optimizerAdamW \ lr00.001 \ warmup_epochs3 \ projectruns/ir_detect \ nameyolo11n_iter參數說明yolo11 默認優(yōu)化器在部分版本里是 auto小數據集上 AdamW 比 SGD 收斂更穩(wěn)lr00.001是 AdamW 的常用起點比 SGD 的 0.01 小一個量級。warmup_epochs3讓學習率在前 3 個 epoch 線性上升避免一開始就大步長把預訓練權重沖壞。如果顯存夠batch可以上到 32梯度更穩(wěn)。遷移時權重不能直接復用yolov8 的.pt和 yolo11 的結構不兼容必須用 yolo11 自己的預訓練權重。數據集和data.yaml可以直接復用這是同一套系統里兩個版本能共存的基礎。4.3 兩個版本同框對比mAP、速度、顯存怎么記對比要控制變量同一份數據、同一個 imgsz、同一個 batch只換模型。記錄表格模型mAP50mAP50-95單圖推理(ms)顯存(G)參數量(M)yolov8n0.860.528.23.13.2yolov8s0.890.5614.55.411.2yolo11n0.880.557.83.02.6yolo11s0.910.5913.95.29.4以上是典型量級具體數值隨數據集變化別照抄。推理速度用model.val()里的 speed 字段或者自己寫循環(huán)測 100 張取平均。顯存用torch.cuda.max_memory_allocated()讀。選型上如果邊緣設備算力緊張yolo11n 在精度略高于 yolov8n 的同時參數量更小是更優(yōu)解如果追求極致精度且算力夠yolo11s 是甜點。5. 部署到 RK3588從 PyTorch 到邊緣盒子的完整鏈路5.1 導出 ONNX 與 RKNN 轉換的關鍵參數RK3588 部署 yolov8/yolo11標準鏈路是 PyTorch → ONNX → RKNN。導出 ONNXyolo export modelruns/ir_detect/yolo11n_iter/weights/best.pt \ formatonnx imgsz640 opset12 simplifyTrue參數說明opset12兼容性最好RKNN 工具鏈對高版本 opset 支持不穩(wěn)。simplifyTrue會做圖優(yōu)化去掉冗余算子轉換成功率更高。導出后檢查輸入輸出名字RKNN 轉換時要對上。RKNN 轉換腳本from rknn.api import RKNN rknn RKNN(verboseTrue) # 均值方差要和訓練時一致YOLO 默認 0~1 歸一化 rknn.config(mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk3588) rknn.load_onnx(modelbest.onnx) rknn.build(do_quantizationTrue, datasetquant_dataset.txt) rknn.export_rknn(best.rknn)邏輯說明mean_values和std_values決定預處理YOLO 訓練時輸入是 0~1所以 std 用 255。do_quantizationTrue做 int8 量化能大幅提速但需要quant_dataset.txt里放幾百張代表性圖片做校準。量化后精度一般掉 1~3 個點如果掉太多檢查校準集是否覆蓋了各種光照和角度。參數說明target_platformrk3588必須寫對寫錯平臺轉換出來的模型跑不了。dataset文件每行一張圖片路徑建議 200~500 張從訓練集里均勻采樣。5.2 板端推理與后處理對齊RK3588 上跑 RKNN 模型后處理要自己寫因為 RKNN 輸出的是原始特征圖不是檢測框。yolo11 和 yolov8 的輸出格式類似都是多尺度特征圖需要做解碼import numpy as np def decode_yolo(outputs, conf_thres0.25, iou_thres0.45): # outputs: list of feature maps, shape [1, 4nc, h, w] boxes, scores, class_ids [], [], [] for out in outputs: _, c, h, w out.shape out out.reshape(1, c, h * w).transpose(0, 2, 1)[0] # 前 4 個是 xywh后面是類別分數 xywh out[:, :4] cls_scores out[:, 4:] cls_id np.argmax(cls_scores, axis1) conf np.max(cls_scores, axis1) mask conf conf_thres if not mask.any(): continue # 解碼到原圖坐標這里省略 stride 和 anchor 計算按實際輸出補 boxes.append(xywh[mask]) scores.append(conf[mask]) class_ids.append(cls_id[mask]) # NMS 部分用 cv2.dnn.NMSBoxes 或自己實現 return boxes, scores, class_ids邏輯說明RKNN 輸出的特征圖需要按 stride 還原到原圖坐標再拼成 xyxy 格式做 NMS。這段代碼省略了 stride 計算實際要按模型輸出的三個尺度分別處理。后處理對齊是部署最容易翻車的地方板端框位置偏了九成是解碼時 stride 或歸一化系數寫錯。參數說明conf_thres0.25是置信度閾值紅外過熱檢測寧可多報不可漏報可以降到 0.2。iou_thres0.45是 NMS 的 IoU 閾值過熱區(qū)域重疊少可以適當調高到 0.5。5.3 邊緣端性能實測與調優(yōu)方向RK3588 上 yolo11n 量化后單幀推理大概在 30~50msyolov8n 差不多。如果達不到先查是不是跑在 CPU 上RKNN 要顯式指定 NPU 核心。多核 NPU 可以用rknn.init_runtime(core_maskRKNN.NPU_CORE_0_1_2)把三個核心都用上速度能再提一截。輸入尺寸從 640 降到 416 能提速近一倍但小目標召回會掉紅外過熱檢測不建議降太多。6. 避坑與排查這套系統最容易翻車的五個地方6.1 訓練 loss 正常但 mAP 一直是 0現象訓練日志里 box loss 在降但 mAP50 始終是 0。原因標注文件的 class_id 從 1 開始而 YOLO 要求從 0 開始模型把所有目標當背景。解決檢查labels里第一列必須是 0 到 nc-1用腳本批量掃一遍發(fā)現最大值等于 nc 就整體減 1。6.2 驗證集 mAP 很高實際巡檢圖全漏檢現象val mAP 0.9拿現場新拍的圖測一個都沒框出來。原因訓練集和驗證集來自同一批拍攝分布太像模型沒學到泛化特征。解決劃分數據集時按桿塔或按拍攝日期切不要隨機切另外檢查現場圖的分辨率和訓練圖是否差太多差太多要做 resize 或切圖。6.3 RKNN 量化后精度斷崖式下跌現象ONNX 上 mAP 0.88轉 RKNN int8 后掉到 0.6。原因校準集沒覆蓋實際場景或者量化時某些層對數值敏感。解決校準集從訓練集里按類別和亮度分層采樣至少 300 張如果還不行對敏感層做混合量化把檢測 head 保留 fp16。6.4 板端推理框位置整體偏移現象框能出來但位置比真實目標偏了幾十像素。原因后處理解碼時 stride 用錯或者預處理 resize 的 padding 沒還原。解決打印第一個特征圖的輸出尺寸反推 strideletterbox 的 padding 值要在解碼后減掉再除以縮放比例。6.5 顯存夠但訓練中途 OOM現象GTX1660Ti 6Gbatch16 跑幾十個 epoch 后突然 OOM。原因驗證階段會額外占顯存加上 dataloader 的緩存累積。解決把batch降到 8開ampTrue混合精度workers從 8 降到 4驗證頻率從每 epoch 改成每 5 個 epoch。7. 一個能落地的技巧用溫度閾值做二次過濾模型輸出的是框但電力巡檢真正要的是「這個接頭到底過不過熱」。光靠檢測框置信度不夠因為紅外圖里陽光反射、金屬反光也會形成亮斑模型分不清。我一般加一層溫度閾值過濾如果紅外圖帶溫度矩陣很多紅外相機導出時帶 RAW 溫度數據取檢測框內的最高溫和環(huán)境溫度比超過 15K 才告警。import numpy as np def temp_filter(box, temp_matrix, ambient_temp, delta15.0): x1, y1, x2, y2 box roi temp_matrix[y1:y2, x1:x2] max_temp np.max(roi) # 相對溫差比絕對溫度穩(wěn)不受季節(jié)影響 return (max_temp - ambient_temp) delta, max_temp邏輯說明temp_matrix是紅外圖對應的溫度矩陣單位攝氏度。ambient_temp取畫面里桿塔背景區(qū)域的中位數溫度。用相對溫差而不是絕對溫度是因為夏天環(huán)境 40 度時接頭 55 度不算異常冬天環(huán)境 5 度時接頭 25 度就該查了。delta15.0是經驗閾值按 DL/T 664 的慣例相對溫差超過 15K 屬于一般缺陷超過 30K 是嚴重缺陷可以按需調。參數說明temp_matrix要和可見光圖對齊如果紅外和可見光有視差先做配準。ambient_temp別用整圖平均畫面里天空占比大會把均值拉低用桿塔區(qū)域的中位數更準。這套系統我從 yolov8 基線跑到 yolo11 迭代再到 RK3588 部署前后踩的坑基本都在上面了。最大的教訓是別一上來就追新版本、追改進模塊先把數據集標注一致性做到位把 yolov8 基線跑穩(wěn)后面換 yolo11、上邊緣設備都是順水推舟的事。數據集爛什么模型都救不了。希望幫到你。本文還有配套的精品資源點擊獲取