Software_introduction
各模型測試總整理
各模型測試總整理
第一部分： 人臉辨識
| 模型 / 技術 | 來源 / 部署方式 | 測試結果與特性摘要 | 決策狀態與原因 |
|---|---|---|---|
| YuNet 2023mar | OpenCV Zoo；cv2.FaceDetectorYN；CPU-only；ONNX | Jetson CPU 實測約 71.3 FPS 單模型推論，不佔 GPU；適合把 GPU 留給 YOLO 物體辨識 | 採用：主線人臉偵測器。部署簡單、CPU 即可跑、速度穩定 |
| SFace 2021dec | OpenCV Zoo；cv2.FaceRecognizerSF；CPU-only；ONNX | 輸出 128 維 embedding；搭配 cosine similarity 做身份比對；使用 face_db 儲存 roy / grama 等人臉資料 | 採用：主線人臉識別器。與 YuNet 同屬 OpenCV Zoo，部署一致 |
| SCRFD-500M | InsightFace 系列；CUDA/GPU | Jetson 實測約 34.7 FPS，但會吃 GPU，影響其他感知模組 | 未採用：備援候選。精度與泛用性可考慮，但 GPU 資源成本較高 |
| RetinaFace-R50 | 常見高精度人臉偵測模型 | 模型約 100MB，記憶體與算力負擔較高 | 未採用。Jetson 8GB 預算下不划算 |
| MediaPipe Face Detection | Google MediaPipe | Jetson ARM64 / GPU delegate 部署較麻煩 | 未採用。人臉線改用 OpenCV Zoo 更穩 |
第二部分： 物體辨識
| 模型 / 技術 | 來源 / 部署方式 | 測試結果與特性摘要 | 決策狀態與原因 |
|---|---|---|---|
| YOLO26n | Ultralytics YOLO26；ONNX / TensorRT FP16；Jetson GPU | 目前主線 object detector。輸入 640，COCO 類別，搭配 whitelist。杯子 0.7m / 1.0m / 1.5m 都能穩定偵測，但會與 phone / bottle 混淆 | 採用：目前主線。速度與部署成本最佳，已接入 ROS2 / Brain / Studio |
| YOLO26s | Ultralytics YOLO26；候選 ONNX / TensorRT FP16 | 官方整體 mAP 約比 n 高 +7.7 mAP，但 cup 小物提升幅度仍需 Jetson 實測 | 候選：待 A/B 測試。可能改善小物與類別混淆，但會增加 GPU/RAM 成本 |
| YOLO26n @ 960 / 高解析輸入 | 同 YOLO26n，調高 input size | 理論上可提升小物像素量，但目前 D435 RGB 來源與效能限制需實測 | 候選：待 benchmark。不直接進主線 |
| YOLO26-seg / Segmentation | YOLO26 segmentation 模型 | 可提供 mask，理論上能改善顏色/背景污染；但 GFLOPs、後處理與輸出契約成本較高 | 暫不採用。目前不作為 6/18 主線 |
| Supervision | Roboflow supervision；Python evidence / metrics 工具 | 適合做 detection metrics、confusion matrix、video evidence、tracking，不是 runtime 模型替換 | 採用為 benchmark / evidence 工具候選，不直接替換 detector |
| PINTO Model Zoo | PINTO0309 model zoo | 可找 Jetson / ONNX / TensorRT 候選模型 | 研究候選來源，需逐一 benchmark，不直接導入 |
| HSV12 顏色分類 | 目前 object pipeline 內建規則 | 快、簡單；但受光線、AWB、背景影響 | 目前 baseline |
| Lab-LUT / CIEDE2000 顏色分類 | 研究候選 | WSL microbench 顯示速度可接受，可能比 HSV 更穩 | 候選：待實測。需用真實光線矩陣驗證 |
第三部分： 姿勢辨識
| 模型 / 技術 | 來源 / 部署方式 | 測試結果與特性摘要 | 決策狀態與原因 |
|---|---|---|---|
| MediaPipe Pose | Google MediaPipe；CPU-friendly | 33 點人體骨架；目前用於 sitting / standing 等姿勢判定 | 採用：目前主線。部署簡單、即時性足夠 |
| Two-class sitting / standing classifier | 基於 pose landmarks 的規則 / 分類邏輯 | 真機測試 sitting conf 約 0.55、standing 約 0.50，坐站轉換可判斷 | 採用：demo-safe 模式。只保留坐/站比多類姿勢穩 |
| YOLOPose / YOLO26n-pose | YOLO pose 類候選 | 可與 object pipeline 同類工具鏈整合；但效能與準確度尚未在 Jetson 實測 | 候選：待 A/B |
| RTMPose | OpenMMLab pose 系列 | 精度可能較好，但部署與效能成本需評估 | 研究候選，未進主線 |
| bending / fallen 等多類姿勢 | 既有 pose 分類曾嘗試 | 多類更容易抖動，對 demo 風險較高 | 降級 / 暫不主秀 |
第四部分： 手勢辨識
| 模型 / 技術 | 來源 / 部署方式 | 測試結果與特性摘要 | 決策狀態與原因 |
|---|---|---|---|
| MediaPipe Hands | Google MediaPipe；21 點手部關鍵點 | 提供手部 landmarks，CPU-friendly | 採用：底層手部追蹤 |
| MediaPipe Gesture Recognizer | Google MediaPipe Tasks API | 可辨識 thumbs_up、peace、ok、open_palm 等手勢 | 採用：目前主線 |
| min_conf 0.7 + 3-vote stable gate | PawAI 後處理規則 | 真機測試 thumbs_up 0.80、peace 1.00；零 spam；open_palm 有被認成 ok 的小混淆 | 採用：目前防誤觸策略 |
| YOLOPose / RTMPose gesture pipeline | 候選替代路線 | 可能用全身/手部 pose 做 gesture 判斷，但尚未實測 | 候選：待 benchmark |
| 多手勢同時啟用 | 舊 demo 模式 | 容易誤觸與搶話 | 不建議。正式 demo 只保留少數手勢 |
第五部分： 導航避障
導航避障不是單一「模型」，比較像 ROS2 / Nav2 / LiDAR / D435 / safety policy 的組合技術。文件網站可以放在「導航技術選型」而不是「模型」。
| 技術 / 模組 | 來源 / 部署方式 | 測試結果與特性摘要 | 決策狀態與原因 |
|---|---|---|---|
| Nav2 + SLAM | ROS2 Navigation Stack | 用於已知地圖定位與導航 | 採用：導航主線基礎，但目前只適合短距/已知地圖 |
| RPLIDAR / 2D LiDAR+D435 | 外接 LiDAR+深度攝影機 | 用於前方障礙偵測、reactive stop、地圖/scan 顯示 | 採用：目前避障核心感測器 |
| indoor_tight profile | PawAI reactive profile | ±18° 窄錐改善誤擋；適合室內窄場 | 採用：室內 demo 建議 profile |
| D435 depth_clear gate | Intel RealSense D435 depth | 目前主要是 Brain / safety gate，不是真正接進 Nav2 costmap | 部分採用。不能宣稱 D435 已融合導航 |
| D435 + LiDAR fusion | 研究方向 | 目標是 depth → scan/costmap，補 2D LiDAR 的盲點 | 研究 / prototype，未完成 |
| 固定 route patrol | Nav route / run_route action | 可做固定路線巡邏 prototype，但需重錄 named poses / routes | prototype 候選 |
| free roam / dynamic detour | 自由巡邏 / 動態繞障 | 尚未穩定實作與驗證 | 不可宣稱 |
| approach person / approach Roy | 人臉/人物定位 + nav approach | 理想功能，但尚未 hardware proven | 研究候選，未進主線 |
第六部分：ASR (語音辨識) 模型評測與選型路徑
ASR 的核心需求在於「中文辨識精準」、「低延遲」以及「對 Go2 機器狗運作時的風扇/馬達噪音有足夠的抗性」。
| 模型候選 | 來源 / 開源狀態 | 測試結果與特性摘要 | 決策狀態與原因 |
|---|---|---|---|
| SenseVoice Cloud | GitHub: FunAudioLLM/SenseVoice | 🏆 準確度冠軍 / 情緒專家 在 Go2 噪音測試 (A/B Test) 中，正確率達 92%，Intent 命中率 96%，延遲約 600ms。能精準處理中英夾雜且具備獨家情緒辨識。 | ✅ 最終主線 準確率明顯優於 Whisper，解決了噪音環境下的辨識瓶頸。 |
| SenseVoice Local (int8) | 模型權重 (sherpa-onnx 格式) | 🚀 極致輕量 / 穩定備援 在 Jetson CPU 上執行，噪音測試正確率與 Intent 皆達 92%，延遲約 400ms，離線可用。 | ✅ 本地 Fallback 使用 CPU int8 執行，完全不佔用 Jetson 的 GPU，符合多模組共存需求。 |
| FunASR (Paraformer) | GitHub: modelscope/FunASR | ⚡ 流式王者 非自回歸設計，生成速度極快，能邊講邊出字，但 C++ 部署稍嫌繁瑣。 | 已淘汰 在特定情境下有選字錯誤（例如將瓦斯爐辨識為「瓦斯魯」），穩定性不如 SenseVoice。 |
| Faster-Whisper (Large-v3/Small/Tiny) | GitHub: SYSTRAN/faster-whisper | ⚖️ 相容性極佳 / 早期主線 Small/Tiny 版本曾在 3/21 benchmark 達到可用速度。 | ⚠️ 最終保底 (Fallback) 在真機 Go2 噪音環境下暴露準確率瓶頸 (最佳僅 64%)，且容易在無聲處產生幻覺。 |
| Sherpa-onnx | GitHub: k2-fsa/sherpa-onnx | 🪶 資源消耗極低 (14MB 模型) 毫秒級反應，但容錯率低。 | 已淘汰 在生活用語測試中出現「瓦斯 l l e」等嚴重幻覺亂碼。 |
| Qwen3-ASR (0.6B) | Qwen Research | 🧠 語意修正強但太重 能理解上下文修正錯字，但吃滿顯卡且延遲極高。 | 💀 不推薦 推論太慢，出現亂碼與注音文。 |
| Vosk | GitHub: alphacep/vosk-api | 🔋 零延遲、極省電 傳統架構，適合簡單指令喚醒。 | 已淘汰 準確度上限較低，無法應付長篇中文對話。 |
第七部分：LLM (大腦決策) 模型評測與選型路徑
LLM 負責生成自然回覆與意圖判斷。核心需求是「速度快」、「輸出 JSON 格式極度穩定」，且「成本必須在可控範圍」。
| 模型候選 | 來源 / 部署方式 | 測試結果與特性摘要 | 決策狀態與原因 |
|---|---|---|---|
openai/gpt-5.4-mini | 透過 OpenRouter 呼叫 | 👑 綜合最佳 P50 延遲僅 1.16s，P95 為 2.74s。成本低廉 ($0.018/12 calls)。 | ✅ 最終主線 在 8-model A/B 測試中，唯一同時滿足速度、成本、格式穩定與角色自然度的模型。 |
google/gemini-3-flash-preview | 雲端 API | 🥈 便宜穩定 P50 延遲 1.89s。曾在 5/4 評估中成為唯一穩定小於 2s 的主線。 | ✅ 雲端 Fallback 便宜穩定，但在角色扮演自然度與 Context 掌握上稍弱於 gpt-mini。 |
| RuleBrain | 本地端規則引擎 | 🧱 絕對安全網 不依賴模型生成，由系統寫死的邏輯判斷。 | ✅ 最終保底 (Fallback) 確保在所有 LLM 失效時，仍能維持基本安全與動作。 |
| Qwen2.5-7B-Instruct | 雲端 vLLM / 本地 | 🌟 中文精通 JSON 解析全通，P50 約 1.5s，曾為早期 (3/24) 雲端主線。但在 Jetson 8GB 上會 OOM (記憶體不足)。 | 已淘汰 (主線) 後續被速度更快、更穩定的 gpt-mini 取代。 |
| Qwen2.5-1.5B/0.5B | Jetson Ollama | 📉 輕量但有偏差 1.5B 曾作本地 fallback，但意圖映射有偏差；0.5B 中文會漂移。 | 已淘汰 品質不足以支撐展示。 |
| Llama-3.2-3B (Taiwan) | Hugging Face (微調版) | 🚀 8GB Jetson 救星 若硬性要求在 8GB Jetson 跑本地 LLM 的最佳解。 | 未進入最終主線 因架構轉向依賴雲端主線 + 規則 Fallback，未實際導入。 |
| Claude / DeepSeek 系列 | 透過 OpenRouter 呼叫 | 🔍 各有缺陷 Opus 成本過高；Haiku 會將 JSON 包在 markdown 中；DeepSeek reasoning 太慢 (P95 達 34s) 導致 demo 風險過高。 | 已淘汰 未能通過 8-model A/B 測試的嚴格標準。 |
第八部分：TTS (語音合成) 模型評測與選型路徑
TTS 的核心需求是「音色自然有感情 (符合 PawAI 角色)」、「支援語氣標籤 (Audio Tag)」，並且對於「短句/安全警告」有極快的反應速度。
| 模型候選 | 來源 / 部署方式 | 測試結果與特性摘要 | 決策狀態與原因 |
|---|---|---|---|
| Gemini 3.1 Flash TTS Preview (Despina) | 透過 OpenRouter Quality Lane | 🎭 情感最豐富 (Quality Lane) 延遲約 2.4s ~ 4.75s。對 [excited], [laughs] 等 audio tag 原生渲染極佳。 | ✅ 最終主線 (長句/角色句) 雖然犧牲了部分速度，但其中文音色與情緒標籤渲染明顯更適合 PawAI 的展示。 |
| Edge-TTS | Microsoft Azure (開源客戶端套件) | ⚡ 極速與廣播級穩定 P50 僅 1.13s，成功率 100%。不佔用本地 RAM。 | ✅ Fast Lane 主線 保留給首音小於 2s 的短句、無 emotional tag 的句子，以及安全警告等需要極速反應的情境。 |
| Piper (huayan) | GitHub: rhasspy/piper | 🔋 離線穩定保底 VITS / ONNX 架構，P50 約 2.03s，僅需 CPU，RAM 佔用極小。 | ✅ 本地 Fallback 作為雲端服務失效時的最後一道防線，確保機器狗不斷線。 |
| MeloTTS | GitHub: MyShell-ai/MeloTTS | 👑 本地端速度霸主 完全離線且秒回，但中英夾雜需手動調教字典。 | 已棄用 因有 ARM64 mecab 風險、PyTorch 依賴重，且需佔用 Jetson 500-800MB RAM，最終未採用。 |
| CosyVoice | GitHub: FunAudioLLM/CosyVoice | 🎨 高可玩性但效能災難 長句生成延遲高達 75s，硬體要求極高 (需高階 GPU)。 | 已淘汰 無法滿足機器狗互動的即時性需求。 |
| Qwen3-TTS (0.6B) | Qwen Research | 🤕 嚴重幻覺 長序列生成中會崩潰，出現亂碼與注音文，速度極慢。 | 💀 不推薦 模型未收斂，品質完全不可用。 |
總結：為何走向「雲端主力 + 本地 Fallback」架構？
回顧這些選型路徑，PawAI 團隊從最初嘗試「全本地運行 (Whisper + Qwen 1.5B/0.5B)」，逐漸演進到目前的「混合式架構」。核心原因在於硬體資源的殘酷現實：
「Jetson 8GB 必須與視覺 (物體辨識) 等模組共存，無法容納能提供高準確度與豐富情感的大型模型。」
因此，最終確立了以下務實且具備高可用性的 Dual-route routing (雙軌路由) 策略：
- 追求體驗極致 (主線走雲端)：利用
SenseVoice Cloud獲取高準確度與情緒，利用gpt-5.4-mini獲取聰明且穩定格式的大腦，再透過Gemini TTS渲染豐富的情感。 - 確保生命線 (Fallback 走本地/規則)：當遇到網路中斷或 API 失效時，立刻降級使用極輕量的
SenseVoice Local (CPU)、不依賴模型的RuleBrain，以及完全離線的Piper TTS，確保機器狗永遠不會「失聰」或「失語」。