在 PCB 生產(chǎn)線上缺陷檢測并不只是模型推理問題。現(xiàn)場系統(tǒng)需要同時處理兩類工作一類是對歷史圖像或待檢圖片進行集中質(zhì)檢、留存標(biāo)注結(jié)果另一類是持續(xù)接入產(chǎn)線視頻流在節(jié)拍約束下把檢測結(jié)果送回給管理端。兩類工作對吞吐、延遲、存儲和運維的要求不同。若把它們壓在同一條處理鏈路中批處理容易擠占實時資源實時流又難以提供完整的追溯與管理能力。一、方案概覽把檢測、流媒體和管理端放到同一運行邊界獨角鯨PCB將 PCB 缺陷檢測組織為一個可由 Web 端統(tǒng)一管理的系統(tǒng)批量圖片檢測由 YOLOv5 鏈路承擔(dān)實時 RTSP 視頻流檢測由 YOLOv8 鏈路承擔(dān)Flask 提供管理界面和 RESTful APIMediaMTX 負(fù)責(zé) RTSP 流服務(wù)SQLite 承擔(dān)本地檢測歷史與統(tǒng)計數(shù)據(jù)的輕量化存儲。系統(tǒng)面向劃痕、缺損、污漬和氣泡等常見 PCB 缺陷的識別與分類。項目采用 MIT 開源許可證發(fā)布支持商業(yè)化使用并允許在遵守許可證條款的前提下進行修改、分發(fā)與二次開發(fā)。這種組合的重點不在于把多個組件放進同一項目而在于劃清職責(zé)邊界。管理端負(fù)責(zé)配置、任務(wù)控制、歷史查詢和資源觀察檢測執(zhí)行端負(fù)責(zé)解析輸入并調(diào)用對應(yīng)模型流媒體服務(wù)保持 RTSP 接入與多端觀看能力本地數(shù)據(jù)層保存需要回看的檢測結(jié)果。對需要先從單臺產(chǎn)線或邊緣設(shè)備落地的場景這種邊界比一開始引入復(fù)雜分布式架構(gòu)更直接。二、雙檢測鏈路把離線質(zhì)檢與在線響應(yīng)分開批量圖像檢測和實時流檢測看似都在調(diào)用目標(biāo)檢測模型實際上面對的是不同的輸入節(jié)奏。批量任務(wù)可以以文件集為單位上傳和執(zhí)行更關(guān)注結(jié)果標(biāo)注、報告生成與歷史回溯RTSP 檢測則要面對持續(xù)到達的幀需要控制排隊、解碼、推理和回傳的累計延遲。獨角鯨PCB 以 YOLOv5 處理批量檢測、以 YOLOv8 處理實時流避免讓單一路徑同時兼顧兩類調(diào)度模型。管理端可在檢測頁面配置 RTSP 地址、檢測參數(shù)和模型選擇并通過儀表板查看運行狀態(tài)與缺陷統(tǒng)計。這樣操作人員不必直接進入推理腳本修改參數(shù)任務(wù)配置與日常檢查被放到瀏覽器界面中適合由產(chǎn)線質(zhì)檢、設(shè)備運維和算法人員分別承擔(dān)各自的操作環(huán)節(jié)。歷史記錄支持按時間、缺陷類型檢索并導(dǎo)出報告使在線檢測不止停留在當(dāng)前畫面。三、實時路徑的取舍硬件加速、低延遲與跳幀控制系統(tǒng)以 22 FPS 實時檢測、約 30 ms 端到端延遲和 95% 以上準(zhǔn)確率作為設(shè)計指標(biāo)這些指標(biāo)不應(yīng)視為脫離硬件、樣本分布和測量方法的通用結(jié)論。跳幀和低延遲模式是實時鏈路中值得關(guān)注的工程決策。輸入幀持續(xù)積壓時逐幀推理會讓展示結(jié)果越來越滯后選擇跳過部分幀可控制計算負(fù)載把有限推理資源優(yōu)先用于較新的畫面。其代價是可能遺漏短暫出現(xiàn)的缺陷因此跳幀比例應(yīng)與產(chǎn)線速度、相機幀率、PCB 運動距離和可接受漏檢窗口一起確定而不是作為固定開關(guān)。四、控制面與數(shù)據(jù)面讓結(jié)果能被查看、篩選和追溯Flask 服務(wù)承擔(dān)系統(tǒng)控制面Web 儀表板、檢測控制、歷史記錄、系統(tǒng)監(jiān)控和設(shè)置頁面均通過該服務(wù)對外呈現(xiàn)。RESTful API 讓外部系統(tǒng)或前端頁面能夠以統(tǒng)一方式訪問功能但實際可調(diào)用的接口路徑、字段與鑒權(quán)策略仍應(yīng)以代碼和接口文檔為準(zhǔn)。將控制面與模型執(zhí)行路徑拆開后算法升級不必等同于管理頁面重構(gòu)檢測參數(shù)調(diào)整也不必直接改動模型邏輯。項目采用 SQLite 作為本地輕量級存儲適合保存單機或邊緣設(shè)備上的檢測記錄、統(tǒng)計信息和配置數(shù)據(jù)。它的優(yōu)勢是部署簡單、無需額外數(shù)據(jù)庫服務(wù)相應(yīng)地在多工位并發(fā)寫入、跨設(shè)備匯總或長期存放大量圖片時需要評估文件體積、備份策略、鎖競爭和數(shù)據(jù)遷移路徑。若后續(xù)需要集中管理多條產(chǎn)線可在不改變檢測鏈路職責(zé)的前提下把數(shù)據(jù)匯聚層替換為更適合并發(fā)和中心化運維的存儲服務(wù)。五、部署與安全生產(chǎn)上線前先收緊默認(rèn)邊界系統(tǒng)運行需要 Python 3.8 及以上版本、Linux 環(huán)境推薦 Ubuntu 18.04 及以上、Sophon BM1684X 開發(fā)板或兼容設(shè)備、至少 4 GB 內(nèi)存和 20 GB 存儲。服務(wù)啟動后Web 管理端默認(rèn)使用 5000 端口MediaMTX 的 RTSP 示例地址使用 8554 端口。部署時應(yīng)把數(shù)據(jù)庫路徑、監(jiān)聽地址、端口與 RTSP 流地址放在可管理的配置中并為設(shè)備 SDK、模型文件和流媒體進程建立明確的啟動順序與故障檢查項。系統(tǒng)默認(rèn)賬號為 admin、默認(rèn)密碼為 admin123生產(chǎn)環(huán)境應(yīng)立即替換默認(rèn)憑據(jù)。實際投產(chǎn)時這一步應(yīng)視為最低要求應(yīng)關(guān)閉或替換默認(rèn)憑據(jù)使用強密碼和最小權(quán)限角色限制管理端與 RTSP 端口的網(wǎng)絡(luò)暴露范圍并對檢測歷史、導(dǎo)出文件和配置備份設(shè)置訪問控制。系統(tǒng)監(jiān)控頁面可用于觀察 CPU、內(nèi)存和磁盤資源但還應(yīng)將推理進程存活、RTSP 連接狀態(tài)、磁盤余量和異常重啟納入日常巡檢。六、驗收應(yīng)圍繞生產(chǎn)鏈路而不是只看單項模型指標(biāo)對 獨角鯨PCB 這類系統(tǒng)建議把驗收拆為四組首先驗證批量圖片的上傳、推理、標(biāo)注結(jié)果和報告導(dǎo)出是否能形成閉環(huán)其次驗證 RTSP 斷連、重連、持續(xù)輸入和多路接入時的延遲與穩(wěn)定性再驗證用戶角色、默認(rèn)憑據(jù)替換、歷史數(shù)據(jù)檢索和備份恢復(fù)最后在目標(biāo) BM1684X 設(shè)備、實際相機分辨率和代表性缺陷樣本上記錄 FPS、端到端延遲、漏檢和誤檢情況。只有測量口徑與生產(chǎn)輸入一致性能數(shù)字才具備工程決策價值。結(jié)語獨角鯨PCB 的設(shè)計價值在于把批量圖片檢測、RTSP 在線檢測、流媒體接入和 Web 運維放在清晰的職責(zé)邊界內(nèi)。YOLOv5 與 YOLOv8 的雙鏈路分工回應(yīng)了離線回溯和在線響應(yīng)的不同需求BM1684X 加速與跳幀策略則面向邊緣側(cè)的資源和時延約束。對于準(zhǔn)備從單線試點開始的 PCB 缺陷檢測項目這套架構(gòu)提供了可繼續(xù)驗證和擴展的起點后續(xù)重點應(yīng)放在真實產(chǎn)線數(shù)據(jù)、設(shè)備環(huán)境和安全配置上的驗收而非脫離上下文地比較單一指標(biāo)。