PawAI / Go2

一分鐘認識 PawAI#

PawAI 的核心可以濃縮成四步：

1. 看見：由 D435 與感知模型辨識已註冊使用者、手勢、姿勢與近距離物體。
2. 理解：把攝影機、語音與系統狀態整理成一致的 ROS2 事件。
3. 決策：PawAI Brain 根據情境提出技能與回覆，但不直接控制機器狗。
4. 行動：Interaction Executive 經過安全規則與狀態檢查後，才允許語音或實體動作送到 Go2。

PawAI 的設計底線：LLM 只能提案；production sport-motion 主線只能由 Executive 放行。音訊與 hard-stop 保留獨立路徑，而 hard-stop 仍需獨立審計與驗證。

先看完整 Demo#

這段影片會依序展示即時感知、語音互動、安全拒絕，以及 PawAI Studio 如何留下決策 Trace。它是 2026 年 6 月的系統快照，不代表下方列出的實驗能力都已達到產品等級。

完整 Demo：PawAI—基於多模態感知融合之自主尋物與具身互動。

我為什麼開始做 PawAI#

一開始，我接觸的是 Go2 的 ROS2 與 WebRTC 驅動。讓機器狗走動、取得感測資料或呼叫一個動作並不算最難；真正困難的是，當人臉、物體、姿勢、語音、導航與 LLM 同時加入後，到底由誰決定現在該做什麼？如果兩個模組同時要求機器狗動作，誰有最後控制權？雲端服務中斷、感知誤判或 LLM 說錯話時，系統又該怎麼退回安全狀態？

這些問題讓 PawAI 從一組功能原型，逐步變成一個完整系統工程專案。開發重心也從「再加一個模型」，轉向三件更重要的事：

• 讓不同感知模組使用一致、可追蹤的事件契約。
• 把決策與實體控制分開，避免 LLM 越過安全邊界。
• 用證據與降級路徑描述能力，而不是只看 Demo 畫面有沒有成功。

這不是一開始就設計好的#

PawAI 啟動時，我仍是一個以 Web 與軟體開發為主、幾乎沒有機器人硬體整合經驗的學生。我們第一次挑戰機器人，就選了開發限制比 Go2 EDU 更多、主要依賴 WebRTC 與第三方 SDK 的 Go2 Pro。

我粗估自己在這個專案投入超過 500 小時。只要晚上、週末或課業空檔能用，我幾乎都在接線、重跑、看 log、錄 bag、改參數，或把前一天看似可行的方案整個推翻。

從 2025 年 11 月到公開版前，repository 橫跨 138 個有提交紀錄的日子，留下超過 1,300 次由我提交的 commit；後來的 lessons-learned 又整理出 70 多個具名 failure modes。這些數字不能換算成工時或品質，卻留下了密集迭代的痕跡。

2025 年 11 月的一個週日，我從午餐後一路做到凌晨一點。日記裡寫著：「做到凌晨一點，卻覺得工程師可能真的是我的天職。」

從感知到行動：系統架構#

PawAI 是一個由十個主要 ROS2 套件組成的 workspace。感知、決策、行動與共享契約彼此分層，依賴方向朝向共用介面，而不是讓每個功能直接互相呼叫。

這張圖可以從下往上理解：Go2 Driver 與硬體負責「真的做事」；Executive 負責「允不允許做」；Brain 負責「現在最適合做什麼」；各個感知節點只負責把世界轉成事件。中間的 go2_interfaces 與 pawai_contracts 則像共同語言，規定事件、技能提案與執行結果應該長什麼樣子。

這個分層刻意避免兩種常見問題：第一，感知模組不能因為看到某個東西就直接命令機器狗；第二，新增一個模型時，不需要同時修改 Brain、Studio 與 Go2 Driver。每個 ROS2 node 可以獨立啟動、停止、測試與替換，整體系統仍透過固定契約協作。

真正跑在 PawAI 裡的模型#

PawAI 不是只寫「使用 AI」；每一條感知與語音路徑都有明確模型、執行位置、資源預算與 fallback。下面是 2026 年 6 月 Demo／公開版所採用的主線。

這張表看起來像最後答案，但模型選型曾經三次翻案。手勢／姿勢從 RTMPose 的 GPU 滿載，走到 DWPose 的 TensorRT 精度偏移與 JetPack 6 部署困境，最後才用實測推翻「MediaPipe 在 Jetson 不可行」的早期判斷。

真正的選型條件從來不只是單模型準確率，而是：在 8GB unified memory 上，當人臉、姿勢、手勢、物體與語音一起跑時，它還能不能活著？

LLM 為什麼不能直接控制機器狗#

在 PawAI 裡，Brain 不是「想做什麼就做什麼」的 Agent。它產生的是一份提案，真正執行前還要經過三層處理：

1. Safety：先攔截危險、緊急或未授權的要求。
2. Policy：根據目前狀態與允許的技能決定能不能執行。
3. Expression：最後才決定要怎麼說、怎麼呈現在 Studio，以及是否送出合法動作。

這個設計不是為了讓架構看起來比較複雜，而是因為機器人會真的移動。當模型產生錯誤內容、感知資料不足，或系統同時收到多個事件時，預設不動、拒絕越權，以及保留人工介入，比讓 Demo 看起來更聰明重要。

目前能公開確認的是：deterministic Safety Gate 與技能 allowlist 的機制存在，並有單元測試保護；這不等於 PawAI 已經不會幻覺，也不代表所有安全情境都完成了實機端到端驗證。

LangGraph 怎麼參與決策#

PawAI 使用 LangGraph 編排 Conversation Engine，但它負責的不是馬達控制，而是把原本塞在單一 LLM bridge 裡的責任拆成可觀測的決策節點。實作上共有 12 個 graph stages；下方把它們合併成九個較容易閱讀的概念階段。

早期版本的 llm_bridge_node 同時負責 ROS adapter、Persona、模型 fallback、對話歷史、環境資訊、JSON 解析與 TTS 輸出。程式一路成長到很難定位錯誤；有一次中文回答總是在逗號附近被截斷，最後才發現不是模型問題，而是 Jetson 的 stale install/ 還留著舊版截斷邏輯。這讓我決定把 conversation orchestration 獨立成 pawai_brain package。

LangGraph 把一輪對話拆成類似以下的 pipeline：

1. Input normalization：統一文字、語音與事件輸入。
2. Safety gate：先處理停止、緊急與禁止情境。
3. World state：加入目前人臉、物體、姿勢、障礙與 TTS 狀態。
4. Capability context：只把現在可用的 SkillContract 提供給模型。
5. Memory / Persona：加入短期對話與 PawAI 的表達方式。
6. LLM decision：產生 reply、可選的 skill 與參數。
7. JSON validation / repair：結構錯誤時修復，失敗則回到規則式 canned response。
8. Skill gate：由 Brain 判斷提案是 accepted、trace-only、blocked，或不在 allowlist。
9. Output / trace：輸出回覆與提案，並把每一階段送到 Studio。

Conversation Engine 的輸出契約刻意很小：

1
{
2
  "reply": "我是 PawAI，一隻正在學習理解環境的機器狗。",
3
  "skill": "self_introduce",
4
  "args": {}
5
}

reply 可以成為語音；skill 只是提案。像 show_status 這類低風險技能可以經 gate 後執行，而較長的動作序列可以只留下 trace，改由 Studio 按鈕在有人控制的情況下觸發。導航與高風險動作不會因為 LLM 提議就自動開放。

Edge、Cloud 與 Go2 怎麼協作#

PawAI 並不是把全部工作都丟到雲端，也不是要求 Jetson 獨自完成所有推論。部署被拆成四個角色：

ASR、LLM 與 TTS 都設計了多層 fallback。Jetson 麥克風路徑可從 SenseVoice cloud 退到 local／Whisper；LLM 可退到替代模型與 RuleBrain；TTS 可退到 edge-tts／Piper。安全層、allowlist 與 Executive 則留在本地 runtime。

這不等於完整斷網語音閉環已被驗證。Studio 的筆電收音路徑目前仍只走 cloud SenseVoice，離線時會成為單點故障；因此 offline-first 是架構方向，不是目前已通過 baseline 的公開能力。

Repository 仍保留 legacy／demo 直發 publisher；production flags 必須將它們關閉。這是尚未完全消失的技術債，不能把「設計約束」誤寫成整個 repo 已無例外。

在 production flags 關閉 legacy／demo publisher 時，Brain 停止便不會產生新 proposal；Executive 停止則會關閉一般 sport-motion 主線。音訊與 hard-stop 仍刻意獨立，後者尚需完成獨立審計與驗證。

PawAI Studio：讓機器狗不再是黑箱#

整合多模態系統後，最常遇到的問題不是「完全沒資料」，而是資料到了、某個模組也判斷了，但最後沒有動作。只看終端輸出，很難知道事件在哪一層被忽略、降級或擋下。

因此我做了 PawAI Studio：一個結合對話主控台、感知面板與決策 Trace 的操作介面。它讓操作者能同時看到感知事件、Brain 提案、Safety Gate 結果與 Executive 的最終決定。

Studio 的價值不是用漂亮 UI 證明能力成功，而是保留一條可追查的證據鏈：機器狗為什麼有反應、為什麼沒有反應，以及是哪一層阻止了它。

目前做到什麼程度#

我不想用「支援很多功能」取代真正的驗證，所以 PawAI 把程式能力、開發觀察與可信的實測證據分開記錄。

這張表不是缺點清單。對我來說，它記錄了 PawAI 最重要的一次轉變：從展示功能，走向只對證據允許的範圍負責。

這套架構，是被失敗逼出來的#

如果只看現在的架構圖，很容易誤以為我們一開始就知道 Brain、Executive、LangGraph 與 Safety Gate 應該放在哪裡。實際上，很多邊界都是在硬體真的失控、模型真的誤判、Demo 真的卡住之後才寫進系統。

1. 2025-11-18｜畫面正常，控制卻全死。 我們逐層查 SDP、ICE、DTLS、SCTP，最後才定位到 aiortc 1.14 與 STUN 的相容問題。降回 1.9、移除 STUN 後，DataChannel 才從超時變成約 0.5 秒連上。
2. 2026-03-21｜模型選型三次翻案。 RTMPose 在 Jetson 上吃掉 91–99% GPU；DWPose 轉 TensorRT 後關鍵點偏移。最後是實機 benchmark 證明 MediaPipe CPU 路線更適合多模型共存。
3. 2026-03 至 04｜軟體第一次撞上供電與機構。 Jetson、D435、麥克風與喇叭背上 Go2 後，行走震動、USB 接觸、19V 供電與電流 spike 讓 Jetson 累計斷電八次以上。熱熔膠、泡棉與束帶都成了系統的一部分。
4. 2026-04 至 05｜沒聲音不代表 API 不存在。 Go2 Megaphone 對錯誤 payload 只會 silent-ignore，我們一度以為韌體拿掉 API，繞了近兩週遠路。另一晚換了三個模型仍截斷，真因卻是 ROS2 stale install/。
5. 2026-05 至 06｜「速度歸零」竟然不等於停車。 Go2 Sport Mode 會忽略過小的 Move{x}，沿用上一個命令滑行。事故迫使我們改用 StopMove(1003)、節流、heartbeat，並把 production sport 主線收斂到單一 arbiter。
6. 2026-06｜每個功能會跑，系統仍可能塞車。 Face、cup、pose、gesture 同時搶 TTS、Brain state、Go2 body 與 WebRTC owner。於是才有 pending queue、cooldown、phase gate、trace 與 fail-closed baseline。

這些事故不是勳章。每一次碰撞與誤判，都代表當時的安全設計還不夠完整。真正值得留下的是：我們沒有把失敗剪掉，而是把它轉成契約、測試、仲裁規則與更窄的公開宣稱。

八個多月的工程演進#

2026 年 4 月：當軟體工程師開始拆機器狗#

Jetson、D435、RPLIDAR、麥克風與喇叭不會自己長到 Go2 背上。我們處理電壓、瞬間電流、USB 接觸、散熱、配重、視野與雷達方向，並由我自行 3D 列印背蓋與支架，才讓軟體有地方可以運行。

2026-04-25｜裝上自製 3D 列印背蓋後，Jetson、D435 與 RPLIDAR 終於能以完整堆疊站上 Go2。

這一個月也很殘酷：一次 pip install ultralytics 讓 Torch／NumPy 與所有模型一起壞掉；RPLIDAR 到貨後又遇到 ARM64 crash、Cartographer、雷達方向相反、支架搖晃與四張作廢地圖。

我們怎麼開發這個系統#

PawAI 後期形成了一套比較保守，但很適合實體機器人的開發方式：

1. 先隔離單一路徑：人臉、物體、語音、LiDAR 與 Go2 Driver 先各自證明可用，再進完整 stack。
2. 先定契約再接功能：topic、event schema、SkillPlan 與 SkillResult 先固定，避免每個模組直接相依。
3. 新系統先跑 shadow：讓 LangGraph 或新策略觀察同一份輸入，但在足夠穩定前不取得實體控制權。
4. 所有 motion 先從 no-motion 證據開始：先確認 publisher、ownership、stop gate 與 world state，再進 HITL 小距離測試。
5. 保留 fallback 與 rollback：雲端、本地、規則路徑和 feature flag 都必須能在現場快速退回。
6. 用 evidence 決定文案：機制、觀察與通過基線是不同層次；網站只描述最後一層允許的範圍。

這套流程是在多次整合失敗後才逐漸形成。它讓 PawAI 從「功能很多的學生專題」，走向一個知道自己目前能證明什麼、也知道何時必須停下來的工程系統。

我在這個專案裡做了什麼#

PawAI 是團隊專題；這一頁聚焦我親自負責或深度參與的系統整合、Brain、語音、硬體 bring-up、測試與公開化工作。

我主要投入在把原本分散的硬體、感知模型與 AI 功能，整合成一條能被操作、觀測與驗證的系統：

• 整合 Go2、Jetson、D435、語音裝置與 ROS2 runtime。
• 建立多模態事件與決策流程，讓感知結果能安全地進入 Brain。
• 設計 Brain、Executive 與 Safety Gate 的控制邊界。
• 處理 ASR、LLM、TTS 與 Go2 音訊輸出的降級鏈。
• 建立 PawAI Studio、Trace、CLI、Demo runbook 與 capability evidence。
• 經歷導航、控制權衝突與現場 Demo 問題後，重新整理架構與公開文件。

我學到的三件事#

接下來#

PawAI 還會繼續改善，但我會維持同一個原則：先建立可重現的證據，再擴張公開宣稱。

下一階段包含：

• 補齊多使用者、多距離與不同光線的感知基線。
• 改善語音停止、手勢與完整語音端到端測試。
• 讓 Studio Evidence 與可信 baseline 直接連結。
• 在 no-motion、急停與 HITL 條件下重新驗證導航能力。
• 把架構、語音、感知、導航事故與 Demo 工程拆成獨立技術文章。

專案原始碼與公開文件：GitHub — roy4222/PawAI