網頁

【Edge AI 實戰】從自然語言到韌體落地:使用 Realtek AMB82-MINI 打造智慧監控系統開發實錄

📌 前言:邊緣 AI 與人機協同開發的全新典範

在物聯網(AIoT)與邊緣運算(Edge AI)快速演進的今天,傳統網路攝影機(IP Cam)若僅具備錄影功能,將所有影像分析全丟給後端伺服器或雲端處理,不僅消耗龐大頻寬,還會產生顯著延遲與隱私風險。


然而,在微控制器(MCU)上整合「高清視訊串流 + 邊緣神經網路推論 + 安全加密傳輸 + 後端視覺儀表板」,過去往往需要在韌體(C++ / FreeRTOS)、網路協定(RTSP / MQTT TLS)與後端架構(Python / Flask / OpenCV)之間切換,耗費數天翻查 SDK 範例與排查驅動問題。


本專案以 Realtek AMB82-MINI (RTL8735B) 開發板為核心,透過自然語言與 AI 協同開發,在極短時間內完成一套 1080P RTSP、板載 YOLO 與 MQTT 三合一智慧監控系統:


  1. 1080P 30FPS 無線 RTSP 串流(供 VLC / NVR / 後端拉流)。

  2. 板載 NPU YOLOv4-tiny 即時人體偵測與精準 NTP 時間戳 JSON 告警。

  3. TLS 8883 MQTT 高速圖片快照上傳(支援 mqttgo.vip 雲端儀表板與指令控制)。

  4. 本機端雙模視覺分析儀表板(支援 AMB82-MINI 與 Iriun / USB WebCam 無縫切換)。





🏗️ 系統全景架構

AMB82-MINI 內建多媒體硬體 ISP 編碼引擎與類神經網路運算單元(NPU)。為最大化硬體效益,系統採用多通道視訊管線(Multi-Channel Pipeline)設計,並與雲端 Broker 及本地 Python 分析引擎無縫串接:

各通道職責與配置:

  • Channel 0:輸出 1080P @ 30FPS H.264 串流,供區網監看或 Python OpenCV 後端拉流。

  • Channel 1:VGA(640x480)硬體 JPEG 壓縮快照,定時(3 秒)或接收 MQTT CAPTURE 指令時上傳雲端。

  • Channel 3:576x320 RGB 影像直通 NPU,由 YOLO 模型進行毫秒級人體特徵辨識。



🛠️ 自然語言驅動的開發歷程與經典挑戰突破

在開發過程中,我們透過自然語言指令進行需求描述,AI 則負責架構設計、程式碼生成與精準除錯。以下的提示詞為此專案開發完後,由 AI 反向萃取出來的。


---------------------------------------------以下是提示詞------------------------------------------------------------------- 

想用 Realtek AMB82-MINI 做一個監控專案,寫出完整的 Arduino 程式碼,功能需要包含:

  1. 影像串流:開 1080P 的 RTSP 視訊,可以直接用 VLC 播放器看即時畫面。

  2. AI 人體偵測:用板子內建的 YOLOv4-tiny 偵測有沒有人走過去。只要看到人,就發送一則 JSON 警報(包含時間、人數、信心度)到 MQTT,並設定 3 秒的冷卻時間避免連續洗版。

  3. MQTT 圖片上傳:用 TLS (Port 8883) 連線,每 3 秒自動拍一張 640x480 的 JPEG 照片,用分包傳輸的方式發布到 MQTT 主題;同時也能接收控制指令拍照。

  4. 時間校時:連線 NTP 取得台灣時間 (UTC+8),讓警報訊息帶有精確的時間戳記。

請幫我把 Wi-Fi、MQTT 帳密與主題等設定抽成常數方便修改,並附上清晰的註解。

---------------------------------------------以上是提示詞------------------------------------------------------------------- 


以下記錄了關鍵的演進歷程與破局點:

🎯 挑戰一:從 USB UVC 的驅動泥淖,轉向 Wi-Fi RTSP 串流

  • 初期構想:嘗試將 AMB82-MINI 經由 OTG 埠以 USB UVC 模式接入電腦,供瀏覽器 getUserMedia() 讀取。

  • 遭遇問題:AMB82-MINI 輸出 H.264 壓縮串流,Windows 內建 DirectShow / MediaFoundation 驅動握手失敗,拋出 Timeout starting video source。

  • 破局解法:果斷放棄 USB 模式,啟用晶片原生 Wi-Fi RTSP 無線串流(rtsp://<IP>:554),電腦端由 Python OpenCV 拉流,徹底擺脫作業系統驅動死鎖。



🎯 挑戰二:嵌入式 SDK 差異與精準修復(Surgical Bug Fixing)

在加入人體辨識與時間戳功能時,編譯日誌直接交由 AI 診斷:


  1. 標頭檔缺失(ObjectClassList.h: No such file or directory):

  • 修復:AI 辨識出該檔案僅為名稱陣列,專案直接透過數值過濾(COCO 類別代碼 0 為 person),立即移除冗餘 include。

  1. 跨平台時間 API 差異(configTime was not declared in this scope):

  • 修復:AmebaPro2 核心不支援 ESP32 風格的 configTime(),AI 迅速切換為原生 NTPClient + WiFiUDP 搭配標準 C 函式 gmtime 與 snprintf 完成 UTC+8 校時。



🎯 挑戰三:破解 Windows 中文路徑的「沉默失敗(Silent Failure)」

在本地端實作 AI 快照分析時,曾出現畫面永遠停留在舊照片的異常:


  • 問題根源:專案位於中文路徑下(D:\project\影音視頻專案\...),OpenCV C++ 實作的 cv2.imwrite() 遇非 ASCII 字元會直接失敗且不擲出 Exception。

  • 破局解法:

  1. 改用 Python 二進位寫入

  2. 建立 /api/snapshot.jpg 記憶體直讀端點,直接由 RAM 取出最新影格,100% 繞過磁碟 I/O。



🎯 挑戰四:單連線衝突與「零中斷」快照讀取

AMB82-MINI 的 RTSP 服務為單一 Session 限制,若外部播放器占用通道或快照存檔造成同步阻塞,會導致影像掉包中斷。


  • 優化方案:

  • 快照擷取改採記憶體原子操作(In-Memory Thread-Safe Clone),耗時縮短至 0.1 毫秒。

  • 磁碟 I/O 與告警分析交由獨立 Daemon 執行緒處理,串流穩定順暢。



🎯 挑戰五:TLS 8883 MQTT 圖片高速分包傳輸(解決破圖與截斷)

透過 TLS (Port 8883) 傳輸 10~15KB 圖片時,單次 publish() 易導致 mbedtls 緩衝區溢位或網路卡頓,造成網頁端呈現「半截灰底破圖」。


  • 優化方案:

  1. 啟用 myClient.setBufferSize(32768) 擴充發送緩衝區。

  2. 調校 JPEG 壓縮品質(setJpegQuality(5))將圖檔壓至 ~10KB。

  3. 實作 1KB 區塊分包傳輸演算法(Chunked Write):




💻 系統整合與應用場景

   ┌────────────────┐


   │ AMB82-MINI Cam           │


   └──┬─────────────┘


           │


           ├─► [RTSP 554] ────────► VLC / Home Assistant (1080P 高清畫面)


           │


           └─► [MQTT 8883 (TLS)] ─► Node-RED / 雲端中控


                                         │


                                         ├─► /notify (人體告警) ──► LINE 推播


                                         └─► /amb82  (JPEG 截圖) ──► 儀表板監控呈現


  1. Home Assistant / NVR:直接加入 rtsp://<IP>:554 取得即時串流。

  2. Node-RED / 智慧家庭自動化:訂閱 /user/will_hsieh/amb82/notify 主題,一旦收到 person_detected 即觸發推播警報。


發出的 MQTT 告警 Payload (json 格式)範例:

{

  "event": "person_detected",

  "count": 1,

  "confidence": 88,

  "time": "2026-08-28 11:30:15"

}


  1. 主動控制:向 /user/will_hsieh/amb82/control 發送 CAPTURE,攝影機立即拍照上傳。


LINE 推播 :


儀表板監控呈現 :



🧠 人機協同開發的核心省思

在此次實戰中,自然語言程式設計展現了極高的生產力,同時也清晰定義了「軟體可全自動化,硬體存在實體邊界」的協作分工:


開發維度

AI 能夠全自動完成

必須由工程師介入與決策

架構規劃

跨平台雙模切換、多通道 ISP 串接、REST API 設計

依應用情境評估頻寬、算力與硬體選型

程式碼產出

撰寫 C++ 韌體、Python Flask 後端、HTML5 前端

審核關鍵業務邏輯與防禦機制

底層除錯

診斷 Windows 驅動衝突、TLS 分包傳輸、編譯器報錯

提供精準的 Log、網路封包與錯誤環境上下文

韌體燒錄

依 SDK 規範產生可編譯的源碼

實體按鍵操作(按住 BOOT + 按 RESET 進入 Download Mode)


💡 為什麼 AI 不能「100% 全自動直接幫你完成燒錄與重啟」AMB82-MINI? 


AMB82-MINI 為了工業級邊緣 AI 的防誤觸與抗干擾設計,預設(Auto Flash Mode: Disable)沒有硬體自動切換電路。晶片內部的 Bootloader ROM 必須在實體硬體上偵測到 UART DOWNLOAD (BOOT) 腳位為 Low 狀態開機,才會開啟燒錄通訊。這一步必須由人工按壓實體按鈕。



🏁 開發心得與總結

回顧整個開發歷程,自然語言程式設計(Natural Language Programming)為嵌入式韌體開發帶來了巨大優勢:


  1. 大幅縮短學習曲線:AMB82-MINI 的硬體暫存器與多通道串流概念複雜,透過 AI 能迅速生成符合官方規範的底層配置。

  2. 精準除錯效率:面對編譯錯誤,不再需要於論壇大海撈針,AI 能迅速指出 SDK 核心特徵並給出針對性的修復程式碼。

  3. 架構擴充自如:從單純的串流傳輸到疊加 YOLO AI 運算與 NTP 校時,所有功能均能在幾句對話間模組化整合完成。


自然語言開發並非取代工程師,而是讓工程師專注於架構設計與系統調度。 當清晰的系統觀念遇上 AI 的高速實作能力,嵌入式邊緣 AI 的開發週期將迎來質的飛躍!


沒有留言:

張貼留言