簡介面向工業(yè)自動化裝配、質(zhì)量監(jiān)控及機器人視覺引導(dǎo)等場景工具裝配檢測數(shù)據(jù)集提供1,873張真實工業(yè)環(huán)境標注圖片覆蓋槍型工具、鉗型工具、尖頭工具、掃描工具及手部交互五類目標采用YOLO格式邊界框與類別標注可直接用于YOLOv5/v8/v12等主流目標檢測模型的訓(xùn)練與驗證。包體共2000個文件其中1873個txt標注文件與125張jpg圖片一一對應(yīng)另含1個yaml配置文件用于定義數(shù)據(jù)集路徑與類別以及1份docx說明文檔輔助理解數(shù)據(jù)組織方式整個壓縮包約80.98MB輕量易部署。數(shù)據(jù)集包含多角度工具操作樣本貼近真實裝配線的光照與姿態(tài)變化有助于增強模型在復(fù)雜場景下的魯棒性配套說明文檔可幫助開發(fā)者快速完成數(shù)據(jù)劃分和模型配置。目前已有188人學(xué)習(xí)使用適合工業(yè)視覺算法工程師、智能制造研究者及職業(yè)院校師生作為項目實踐與教學(xué)參考。1. 工具裝配檢測數(shù)據(jù)集先從“有圖有框”說到工業(yè)落地的最后一公里拿到一個名為“工具裝配檢測數(shù)據(jù)集.zip”的壓縮包第一反應(yīng)不應(yīng)該是解壓看熱鬧而是先想清楚我要拿它干什么。工具裝配檢測拆開看是兩個動作——識別畫面里有沒有工具以及判斷這個工具裝配得對不對。前者是通用目標檢測后者是帶業(yè)務(wù)語義的精細分類。這個數(shù)據(jù)集存在的意義就是把“裝配正確/錯誤”這件事從人工目檢變成模型可學(xué)習(xí)的視覺任務(wù)。適合誰用做工業(yè)質(zhì)檢、產(chǎn)線視覺方案、機器人抓取前狀態(tài)確認的工程師以及正在用YOLOv8、MMRotate這類框架訓(xùn)練自己數(shù)據(jù)集的算法崗。它的價值不在于圖片數(shù)量有多大而在于標注里有沒有把“裝配狀態(tài)”作為一個顯式維度表達出來。這篇筆記我按自己落地的習(xí)慣從解壓開始到格式轉(zhuǎn)換、數(shù)據(jù)體檢、訓(xùn)練調(diào)參、后處理判定一步步把這條鏈路走通。2. 先看懂?dāng)?shù)據(jù)集里裝了什么目錄結(jié)構(gòu)、標注格式與一份能跑的檢查腳本解壓之后不要急著丟進訓(xùn)練腳本里。工業(yè)數(shù)據(jù)集的目錄結(jié)構(gòu)千差萬別有的仿VOC有的仿COCO有的干脆是廠商自定義的JSON。我拿到手的第一件事是tree看結(jié)構(gòu)再看標注文件的擴展名和字段組織。這個“工具裝配檢測數(shù)據(jù)集”。zip 從命名習(xí)慣看大概率是Pascal VOC風(fēng)格或YOLO txt風(fēng)格二選一因為這兩種是目標檢測交付時的主流格式COCO JSON反而不太會在zip包里直接給因為單文件JSON不易按目錄增量更新。unzip 工具裝配檢測數(shù)據(jù)集.zip -d ./tool_assembly cd ./tool_assembly find . -maxdepth 2 -type d | sort find . -maxdepth 2 -type f | head -50第一段命令把壓縮包解開第二段看兩層目錄結(jié)構(gòu)第三段抽50個文件樣本判斷標注格式。常見結(jié)構(gòu)是JPEGImages/、Annotations/、ImageSets/Main/三件套如果看到images/和labels/并列那就是YOLO風(fēng)格。先判斷格式再寫代碼能省掉后面絕大多數(shù)路徑報錯。import os from collections import Counter root ./tool_assembly if os.path.isdir(os.path.join(root, Annotations)): ann_dir os.path.join(root, Annotations) ext .xml elif os.path.isdir(os.path.join(root, labels)): ann_dir os.path.join(root, labels) ext .txt else: raise ValueError(未識別的標注目錄請人工檢查目錄結(jié)構(gòu)) ann_files [f for f in os.listdir(ann_dir) if f.endswith(ext)] print(f標注文件總數(shù): {len(ann_files)}) if ext .xml: import xml.etree.ElementTree as ET classes Counter() for f in ann_files[:200]: tree ET.parse(os.path.join(ann_dir, f)) for obj in tree.findall(object): classes[obj.find(name).text] 1 else: classes Counter() class_map {} for f in ann_files[:200]: with open(os.path.join(ann_dir, f)) as fh: for line in fh: cid int(line.split()[0]) classes[cid] 1 print(classes)這段腳本干了三件事識別格式、統(tǒng)計標注文件數(shù)量、抽樣統(tǒng)計類別分布。邏輯上先用目錄名判斷格式分支XML走ElementTree解析objectnametxt直接讀首列類別ID。參數(shù)上抽樣200個文件是折中——工業(yè)數(shù)據(jù)集動輒幾千張全量解析XML在純Python下要幾分鐘200個足以看出類別是否均衡。輸出里如果發(fā)現(xiàn)某個類占比超過80%后面必須做類別重采樣或增強否則模型會對多數(shù)類過擬合?？赐觐悇e還要看邊框質(zhì)量。VOC XML里bndbox的坐標是絕對像素值YOLO txt里是歸一化浮點。我見過不少交付的數(shù)據(jù)集邊框畫得隨意xminxmax、bbox超出圖像邊界這類問題在人工標注里屢見不鮮。下面這段檢查腳本值得長期保留換任何數(shù)據(jù)集都能用。import os import xml.etree.ElementTree as ET from PIL import Image bad_files [] for f in os.listdir(ann_dir): if not f.endswith(.xml): continue tree ET.parse(os.path.join(ann_dir, f)) root tree.getroot() img_path os.path.join(root, JPEGImages, root.find(filename).text) try: w, h Image.open(img_path).size except FileNotFoundError: bad_files.append((f, 圖片缺失)) continue for obj in root.findall(object): b obj.find(bndbox) xmin float(b.find(xmin).text) ymin float(b.find(ymin).text) xmax float(b.find(xmax).text) ymax float(b.find(ymax).text) if xmin xmax or ymin ymax: bad_files.append((f, 坐標倒掛)) if xmin 0 or ymin 0 or xmax w or ymax h: bad_files.append((f, 越界)) if (xmax - xmin) * (ymax - ymin) 100: bad_files.append((f, 疑似過小目標)) print(bad_files[:20])坐標倒掛是最低級的錯誤但出現(xiàn)頻率不低PyTorch的collate_fn在算IoU時遇到負寬高會直接崩。越界問題在YOLOv8里會被自動裁剪修正但在MMDetection里會報錯。疑似過小目標是提醒你注意——裝配檢測里扳手頭、螺栓這類小配件可能只有20x30像素如果標注里大量出現(xiàn)這種尺度的框訓(xùn)練時一定要開多尺度訓(xùn)練或在FPN高層特征上多下功夫。3. 把標注轉(zhuǎn)成YOLO能吃的格式轉(zhuǎn)換腳本與四個邊界坑如果你的zip解壓出來是VOC XML而你又想用YOLOv8訓(xùn)練那繞不開格式轉(zhuǎn)換這一步。YOLO txt格式每一行是class_id x_center y_center width height前四維都是相對圖片寬高的歸一化浮點值。這個轉(zhuǎn)換看起來簡單但我在接手CCPD、CrowdHuman這些公開數(shù)據(jù)集時踩過不少坑裝配檢測數(shù)據(jù)集比它們更隱蔽——因為工業(yè)場景的圖片分辨率高、配件尺寸跨度大歸一化精度直接決定小目標能不能學(xué)出來。import os import xml.etree.ElementTree as ET def voc_to_yolo(xml_file, out_dir, class_names, img_width, img_height): tree ET.parse(xml_file) root tree.getroot() lines [] for obj in root.findall(object): name obj.find(name).text if name not in class_names: continue cls_id class_names.index(name) b obj.find(bndbox) xmin float(b.find(xmin).text) ymin float(b.find(ymin).text) xmax float(b.find(xmax).text) ymax float(b.find(ymax).text) x_center ((xmin xmax) / 2) / img_width y_center ((ymin ymax) / 2) / img_height width (xmax - xmin) / img_width height (ymax - ymin) / img_height x_center min(max(x_center, 0), 1) y_center min(max(y_center, 0), 1) width min(width, 1) height min(height, 1) lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) base os.path.basename(xml_file).replace(.xml, .txt) with open(os.path.join(out_dir, base), w) as f: f.write(\n.join(lines))這段的核心是兩個除法——所有坐標除以img_width和img_height。參數(shù)上class_names是類別ID映射表順序必須和訓(xùn)練配置里的names完全一致否則類別錯位。輸出精度保留6位小數(shù)對8000px級大圖來說6位小數(shù)對應(yīng)約0.012像素的誤差足夠用。這段代碼里我做了min/max裁剪防止標注越界導(dǎo)致歸一化值超出[0,1]區(qū)間這屬于防御性寫法YOLO訓(xùn)練時其實對微小越界有容忍但過大的值會讓loss爆炸。轉(zhuǎn)換腳本跑完后驗證工作不能省。我習(xí)慣隨機抽3張圖把轉(zhuǎn)換后的txt畫回到原圖上肉眼比對邊框是否對齊。這一步能發(fā)現(xiàn)兩類問題一是不同標注工具導(dǎo)出的XML里object節(jié)點下的字段名不完全一致比如有的叫bndbox有的直接給xmin平鋪字段二是圖片尺寸讀的是XML里size字段還是實際文件尺寸——兩者一旦不一致全部邊框整體偏移。python - EOF import cv2 with open(labels/train/0001.txt) as f: for line in f: cid, xc, yc, w, h map(float, line.split()) x1 int((xc - w/2) * 1920) y1 int((yc - h/2) * 1080) x2 int((xc w/2) * 1920) y2 int((yc h/2) * 1080) cv2.rectangle(img, (x1, y1), (x2, y2), (0, 255, 0), 2) EOF這段驗證腳本假設(shè)圖片寬1920高1080按實測尺寸替換。第一行order0不需要line.split()直接解包5個浮點。畫框的像素坐標由歸一化值乘圖片實際寬高得出注意int()直接把浮點截斷而不是四舍五入誤差在1像素內(nèi)可視化驗證不構(gòu)成影響。四個邊界坑里最值得說的是類別篩選問題。工具裝配檢測往往是“同類別不同狀態(tài)”——比如扳手本身是一類但“扳手已到位”和“扳手未到位”在VOC XML里可能是兩個name也可能是一個name加一個state屬性。如果是后者轉(zhuǎn)換腳本里obj.find(name).text就丟掉了狀態(tài)維度必須改成拼接邏輯。這種細節(jié)在標注規(guī)范交付文檔里一般都有寫但zip包里的說明文件經(jīng)常被忽略我的習(xí)慣是先讀README再動代碼沒有README就解析XML字段名全量打印一目了然。# 如果裝配狀態(tài)在屬性里而不是類別名里 name obj.find(name).text state obj.find(state).text if obj.find(state) is not None else default combined f{name}_{state}4. 訓(xùn)練前先做一輪數(shù)據(jù)體檢類別平衡、清晰度與難例分布格式轉(zhuǎn)換完了別急著訓(xùn)練。裝配檢測的場景和公共數(shù)據(jù)集差很遠——工業(yè)相機固定機位、光源穩(wěn)定、背景單一但也有公共數(shù)據(jù)集沒有的問題同一把工具在裝配前、裝配中、裝配后三個狀態(tài)外觀差異可能只在幾度的角度偏移或一個卡扣的縫隙。這種細微差別的檢測模型容量和訓(xùn)練技巧都比通用檢測更吃數(shù)據(jù)質(zhì)量。數(shù)據(jù)體檢第一步是統(tǒng)計類別分布。不只是數(shù)量還要統(tǒng)計每類的平均框面積、寬高比分布。裝配工具的尺度差異極大——一把扳手可能占半張圖而一個螺絲墊圈只有幾十像素。這個差異直接決定你需不需要在MPDIoU或Inner-IoU這類損失函數(shù)上做文章也決定小目標增強的強度。python - EOF import os import numpy as np from collections import defaultdict stats defaultdict(list) for f in os.listdir(labels/train): if not f.endswith(.txt): continue with open(os.path.join(labels/train, f)) as fh: for line in fh: parts line.split() cid int(parts[0]) w float(parts[3]) * 1920 # 乘回像素寬 h float(parts[4]) * 1080 stats[cid].append((w * h, w / h, min(w, h))) for cid, items in stats.items(): areas [i[0] for i in items] ratios [i[1] for i in items] mins [i[2] for i in items] print(f類別{cid}: 數(shù)量{len(items)}, 面積中位數(shù){np.median(areas):.0f}, f寬高比中位數(shù){np.median(ratios):.2f}, 最小邊框{np.min(mins):.0f}px) EOF這段把歸一化的寬高乘回像素值這里假設(shè)1920x1080替換成你的實際尺寸得到三類指標面積、寬高比、最小邊。面積分布決定你是否需要做多尺度訓(xùn)練寬高比分布決定anchor設(shè)計——如果用YOLOv8這種anchor-free框架影響不大但轉(zhuǎn)成MMRotate的旋轉(zhuǎn)框任務(wù)時寬高比是旋轉(zhuǎn)角度的間接表征。最小邊低于30px的類別占比超過15%就要考慮SAHI切片推理或?qū)ｉT的小目標增強策略。第二步是清晰度與難例分析。工業(yè)裝配場景里反光、遮擋、運動模糊是三大殺手。我寫過一個小工具對每張圖提取Laplacian方差作為清晰度分數(shù)——這個指標的直覺是一張圖的邊緣越銳利二階導(dǎo)數(shù)響應(yīng)越強。模糊圖的Laplacian方差偏低能框出一批需要重點檢查的難例。import cv2 import numpy as np import os scores [] for img_name in os.listdir(images/train): img cv2.imread(os.path.join(images/train, img_name)) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) lap cv2.Laplacian(gray, cv2.CV_64F).var() scores.append((img_name, lap)) scores.sort(keylambda x: x[1]) print(最模糊的10張:) for name, score in scores[:10]: print(f{name}: {score:.2f})Laplacian方差低于100的圖建議人工核實——如果這個模糊是裝配動作本身造成的比如工具快速移動這類圖恰恰是難點要保留并標注如果是壓縮偽影或?qū)共粶式ㄗh剔出訓(xùn)練集否則模型會去學(xué)“模糊負樣本”的捷徑。這里有個容易翻車的點測試集里如果混入大量模糊圖指標會被拉得很低所以體檢要和數(shù)據(jù)集劃分同步做。提示模糊檢測不能只看數(shù)值。我見過一個數(shù)據(jù)集整體Laplacian方差偏低結(jié)果發(fā)現(xiàn)是相機自帶降噪濾波把所有圖都磨平了。正確做法是算完好圖的中位方差作為baseline再按比例圈定異常圖不要用絕對閾值一刀切。第三步是把難例分布畫到類別維度上。裝配檢測最常見的失敗模式是某類工具在小尺度下漏檢另一類在大尺度下誤檢。用上面統(tǒng)計的最小邊和面積中位數(shù)結(jié)合類別ID就能定位問題集中在哪個類別。這一步的價值在訓(xùn)練前因為調(diào)整數(shù)據(jù)策略的杠桿遠比調(diào)loss參數(shù)大——比如給某類做2倍過采樣或者對某類做mosaic增強時限制拼接比例。5. 裝配檢測翻車高頻區(qū)常見問題與排查清單這節(jié)寫我實際踩過的坑每一條都是“現(xiàn)象 → 原因 → 解決”的結(jié)構(gòu)按頻率排序。問題一精度和召回率都過得去但裝配狀態(tài)的錯分率高達30%。現(xiàn)象是整體mAP有0.85可生產(chǎn)線上誤檢全集中在“扳手已到位”被識別成“扳手未到位”。原因大概率是標注本身的問題——裝配前和裝配后的外觀差異只在一個卡扣的閉合角度上標注員如果沒按統(tǒng)一標準框選前一張圖框住整個工具后一張圖只框頭部模型學(xué)到的是“框內(nèi)內(nèi)容不同”而不是“裝配狀態(tài)不同”。解決方法是鎖定標注框選范圍規(guī)則統(tǒng)一以工具完整外形為框狀態(tài)差異靠分類分支表達不靠框的幾何變化。這是標注規(guī)范問題不是模型問題。問題二訓(xùn)練時loss正常下降驗證時小目標檢測幾乎全漏?，F(xiàn)象是mAP在0.6左右徘徊看混淆矩陣發(fā)現(xiàn)所有小尺寸類別都被預(yù)測成背景。原因有兩個方向一是原圖1280x1280輸入小配件下采樣后只剩幾個像素二是 mosaic 增強把小目標裁剪成殘片。解決方案分兩步先用自適應(yīng)切片把大圖切成重疊patch再訓(xùn)練跑通后再試YOLOv8自帶的scale增強參數(shù)回退把mosaic概率從1.0降到0.5。# yaml 配置片段 train: ./datasets/train val: ./datasets/val nc: 4 names: [wrench, screwdriver, bolt, washer] # 增強參數(shù) mosaic: 0.5 # 降低mosaic概率防止小目標被切碎 scale: 0.3 # 縮小尺度增強范圍避免目標縮到不可辨識 fliplr: 0.0 # 裝配有左右方向性時關(guān)閉水平翻轉(zhuǎn)這段配置的核心是fliplr: 0.0——裝配工具很多有方向性扳手頭朝左和朝右在部分場景是兩種狀態(tài)水平翻轉(zhuǎn)會把語義反轉(zhuǎn)。scale從默認的0.5收到0.3防止訓(xùn)練中把目標縮到太小。mosaic降一半是因為四圖拼接時小目標經(jīng)常落在拼縫處被判為背景。問題三訓(xùn)練集精度高同一批圖片換個光照就崩?，F(xiàn)象是驗證集用同一相機拍的mAP有0.9換一條產(chǎn)線的圖片直接掉到0.5。原因是數(shù)據(jù)采集時相機白平衡、曝光參數(shù)沒固定或者訓(xùn)練集只來自單一工位。解決方法是把不同工位、不同班次的圖混入訓(xùn)練集后重訓(xùn)同時在增強里加亮度擾動和HSV抖動——工業(yè)場景不需要太強的色彩增強但亮度的正負15%擾動是必須的。hsv_h: 0.01 # 色調(diào)擾動調(diào)低工業(yè)色彩有語義 hsv_s: 0.3 # 飽和度擾動適中 hsv_v: 0.3 # 亮度擾動覆蓋不同光照問題四旋轉(zhuǎn)工具檢測不準。現(xiàn)象是工具平放時檢測很好旋轉(zhuǎn)90度后漏檢。VOC格式數(shù)據(jù)集的標注是水平矩形框工具旋轉(zhuǎn)后水平框內(nèi)背景占比變大特征被稀釋。解決方向兩個一是如果裝配狀態(tài)不依賴角度把旋轉(zhuǎn)后的圖補進訓(xùn)練集做角度泛化二是如果依賴角度比如工具頭的朝向決定裝配是否正確那就不能用普通檢測要切到MMRotate用旋轉(zhuǎn)框。裝配檢測里90%的場景其實不需要旋轉(zhuǎn)框——狀態(tài)判定靠的是位置關(guān)系不是角度本身。問題五類別不平衡極端墊圈占了訓(xùn)練集80%?，F(xiàn)象是loss穩(wěn)定但墊圈類AP 0.95、扳手類AP 0.3。解決方法是先做類別重采樣用小眾類重復(fù)進batch的方式讓每個batch里比例不至懸殊再配合cls_loss的權(quán)重調(diào)整。我一般先調(diào)數(shù)據(jù)采樣不先調(diào)loss——數(shù)據(jù)層面的均衡解決的是“沒見過”的問題loss權(quán)重解決的是“見了但不重視”的問題前者是根因。6. 從檢測框到裝配結(jié)論后處理邏輯與一個可落地的判定方案模型輸出的是(類別, 坐標, 置信度)產(chǎn)線要的是“裝配合格/不合格”。中間這段后處理是質(zhì)檢項目里最容易被低估的部分。常見的做法是用目標間位置關(guān)系做規(guī)則判定比如“扳手在夾具槽內(nèi)且角度偏差小于15度判定為已裝配”。我一般會寫一個獨立于模型的后處理模塊輸入檢測結(jié)果輸出布爾判定并把判定條件做成JSON配置方便現(xiàn)場調(diào)試。def assembly_judge(detections, config): detections: [{cls, x, y, w, h, conf}] config: {slot: {cls: slot, inside: True, angle_tol: 15}} wrench [d for d in detections if d[cls] wrench] slot [d for d in detections if d[cls] slot] if not wrench or not slot: return False, 扳手或夾具槽缺失 wx wrench[0][x] wrench[0][w] / 2 wy wrench[0][y] wrench[0][h] / 2 sx slot[0][x] slot[0][w] / 2 sy slot[0][y] slot[0][h] / 2 dist ((wx - sx) ** 2 (wy - sy) ** 2) ** 0.5 if config[slot][inside] and dist config[slot][max_dist]: return False, f扳手中心距槽中心超限: {dist:.1f} return True, OK這段判定邏輯的做法先從檢測結(jié)果里按類別篩出扳手和夾具槽算兩者中心點距離再和配置里的閾值對比。參數(shù)上max_dist需要根據(jù)實際圖像分辨率標定——代碼里寫的是像素距離用歸一化坐標就要按圖片寬高換算。這里我沒寫角度判定因為水平框算不出準確角度真要判斷“歪了沒歪”要么用旋轉(zhuǎn)框檢測要么在框內(nèi)區(qū)域加一個局部分類器做姿態(tài)判斷。這就是前面說“90%場景不需要旋轉(zhuǎn)框”的原因——用中心距離加局部分類器能覆蓋大多數(shù)缺口、錯位、漏裝場景而且后處理規(guī)則透明現(xiàn)場調(diào)試時哪個判據(jù)觸發(fā)了、輸出什么原因全都寫在返回信息里。我自己的習(xí)慣是這個判定邏輯一定要做成支持熱更新的配置文件產(chǎn)線工程師在界面里調(diào)閾值不用改代碼重新部署。后處理模塊上線后前兩周每天收集誤報案例歸類后你會發(fā)現(xiàn)有些誤報是相機標定漂移有些是檢測模型對某種工具頭角度不夠魯棒這些反饋最終都會倒回去改訓(xùn)練數(shù)據(jù)分布。這類數(shù)據(jù)集的落地周期我經(jīng)歷過最快的是兩周——第一天摸清格式和類別定義第三天跑通轉(zhuǎn)換和訓(xùn)練第五天出第一版模型后面一周全在調(diào)后處理規(guī)則和修標注邊界問題。數(shù)據(jù)集本身永遠不是瓶頸瓶頸永遠是“你有沒有把裝配狀態(tài)的語義定義清楚”。希望這些從格式檢查到后處理的經(jīng)驗?zāi)軒湍闵僮呶易哌^的那些彎路。注意如果你發(fā)現(xiàn)zip包里的標注文件沒有狀態(tài)信息只有工具類別名先別否定這個數(shù)據(jù)集。你可以自己寫一段標注工具在現(xiàn)有框的基礎(chǔ)上手動補狀態(tài)標簽——這個過程通常半天到一天比重新采集數(shù)據(jù)快得多。數(shù)據(jù)集的價值在圖片不在那張寫好的標簽。本文還有配套的精品資源點擊獲取