AI學習與應用體會系列文章09:物聯網感應器與低成本開發板
接上文
喺數碼世界，AI 可以讀文字、分析數據同產生內容；當佢連接感應器、通訊模組同控制器，就開始能夠感知溫度、距離、聲音同移動，甚至驅動燈、屏幕同摩打。不過，現實世界冇咁容易 undo，延遲、斷網、誤讀同失效都會變成真正嘅工程同安全問題。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
上一篇講到，一個人配合 AI Agent，已經可以同時處理研究、程式、內容、測試同營運。但到嗰個階段為止，大部分工作仍然發生喺數碼世界：輸入係文件、網站同數據，輸出係文章、程式、報告或者畫面。
之後筆者開始接觸物聯網，想了解當 AI 唔再只係讀文字，而係要知道房間有幾熱、物件離自己幾遠、裝置有冇震動、周圍有冇聲音，甚至要控制一盞燈或者一個摩打時，系統會有咩不同。呢一步看似只係多咗幾件硬件，但實際上，AI 面對嘅世界由相對整齊嘅數據，變成充滿噪音、延遲、磨損同意外嘅現實環境。
電腦本身唔知道乜嘢叫熱、光同移動
人可以直接感覺凍熱、聽到聲音、睇到光暗，亦會自然判斷一件物件係咪靠近。電腦本身並冇呢啲感覺。對佢嚟講，現實世界必須先被轉換成可以讀取嘅電壓、脈衝、數字或者資料封包。
感應器就係呢個轉換入口。溫度感應器將熱力變化轉成讀數；距離感應器根據光、聲波或者其他訊號估算距離；加速度同方向感應器可以反映裝置有冇郁、向邊個方向傾；咪高峰將空氣震動變成音訊訊號；鏡頭就將光轉成影像資料。
因此，物聯網唔只係「將一件物件駁上 Wi-Fi」。真正重要嘅係建立一條由物理狀態、感應器、數碼訊號、程式判斷，再去到畫面、提示或者實際動作嘅完整鏈路。中間任何一層讀錯、延遲或者中斷，最後結果都可能同現實有落差。
| 物聯網嘅核心唔係連線本身，而係建立一個可以感知、判斷、行動，再檢查結果嘅閉環。 |
筆者將一個最基本嘅物聯網或者 Physical AI 系統，理解成五個彼此分開、但需要配合嘅層次。咁樣拆開之後，出錯時先知道問題究竟來自感應器、網絡、模型定控制器。
1｜感知層：用感應器、鏡頭同咪高峰取得現實環境資料。
2｜邊緣控制層：由微控制器或者小型電腦讀取訊號、處理即時狀態，同埋執行基本規則。
3｜通訊與資料層：透過 Wi-Fi、藍牙或者其他連線，將需要保存或進一步分析嘅資料送到伺服器。
4｜判斷層：由固定程式、統計模型或者 AI 分析情況，產生候選動作。
5｜輸出與執行層：用屏幕、喇叭、燈、摩打、繼電器或者其他控制模組，將數碼決定變成使用者睇到、聽到或者真正發生嘅結果。
例如自動駕駛系統會由鏡頭、雷達、速度同定位資料取得環境狀態，再經過感知、定位、路徑同控制計算，最後將指令交俾方向、加速同制動系統。即使我做嘅只係一個簡單桌面裝置，基本原理都相似：先讀取，後判斷，再輸出，最後確認裝置有冇按預期反應。
感應器讀數唔等於現實真相
做軟件時，我哋容易將一個欄位當成確定事實；但感應器提供嘅通常只係某一個時間、某一個位置、某一種量度方法之下嘅估算。讀數會受安裝位置、環境噪音、電源、溫度、反射物、震動同元件差異影響。
例如一個溫度感應器如果放得太近處理器或者電源，可能量到裝置自己發出嘅熱，而唔係房間溫度；距離感應器遇上斜面、透明物件或者吸收訊號嘅材料，讀數亦可能突然跳動。即使感應器冇壞，單次讀數都未必足以代表環境真正狀態。
所以系統通常要處理校準、單位、取樣頻率、平滑、去抖動、合理範圍同缺失資料。重要判斷亦可以利用多次讀數、兩種不同感應方式或者狀態持續時間交叉確認。最危險嘅做法，係將「冇收到資料」自動解讀成「一切正常」；未知狀態應該保留為未知，而唔係默認為零。
唔係每一個判斷都需要 AI
當開始將 AI 同硬件放埋一齊，最容易出現嘅誤解係：既然有大型語言模型，就將所有判斷都交俾模型。但一盞燈喺指定時間開關、一個風扇超過某個溫度先啟動，或者摩打到達限位就停止，固定規則通常更快、更便宜、亦更容易驗證。
AI 比較適合處理固定規則難以完整描述嘅部分，例如理解自然語言指令、辨認影像或聲音、找出異常模式、綜合多種資料，或者喺多個候選方案之間提出建議。但模型輸出最好先變成有限、結構化嘅意圖，再由普通程式檢查範圍、權限同安全條件。
例如使用者講「房間有啲焗」，語言模型可以將意思理解成「查閱溫度同濕度，必要時建議開風扇」。真正執行時，控制器仍然要檢查設備狀態、最高運行時間、感應器是否正常，同埋有冇人手停機要求。唔應該由模型自由產生一段文字，就直接變成任意硬件指令。
邊緣運算同雲端，各自負責唔同工作
物聯網系統另一個重要選擇，係邊啲工作要喺裝置本身完成，邊啲工作可以送上伺服器或者雲端。裝置附近嘅處理通常稱為 edge computing，即係邊緣運算。
需要即時反應、涉及安全、網絡可能不穩，或者資料較敏感嘅部分，通常應該盡量留喺本地。例如按掣後立即停機、摩打去到限位、溫度超過硬性上限，唔應該先等網絡往返同模型回答。就算斷網，基本保護仍然要繼續運作。
語音辨識、大型語言模型、跨裝置資料分析同複雜內容生成，對運算同記憶要求較高，放喺伺服器會比較實際。常見做法係混合模式：本地負責讀取、緊急停止、簡單規則同狀態管理；雲端負責較重嘅理解、資料整合同長期記錄。
系統亦要預先定義斷網時點做。係保留最後設定、轉入安全模式、只提供本地功能，定直接停止？一部真正可靠嘅裝置，唔係假設連線永遠存在，而係喺連線消失時仍然有可預期行為。
低成本開發板令原型門檻大幅下降
以前要將屏幕、感應器、無線連線同控制程式放入一件小型裝置，成本同技術門檻都相當高。今日 ESP32、Arduino 生態同 Raspberry Pi 類型設備，已經令個人可以用幾十至幾百元開始試驗。
不過，呢幾類設備並唔完全相同。ESP32 同好多 Arduino 類開發板主要屬於微控制器，適合低耗電、快速啟動、讀取感應器、控制腳位同執行清楚而重複嘅任務。Raspberry Pi 類設備比較接近一部小型 Linux 電腦，較適合處理多個服務、較複雜介面、鏡頭、檔案同網絡應用。
選擇時唔係愈強愈好，而係睇任務需要幾多運算、記憶、儲存、連線、耗電同即時反應。只係每分鐘讀一次溫度，未必需要完整作業系統；但如果要同時顯示介面、處理鏡頭同執行本地服務，小型電腦會更方便。
呢啲開發板可以連接 Wi-Fi、藍牙、屏幕、咪高峰、喇叭、鏡頭、燈、摩打同各類感應器。真正令我覺得有意思嘅，係我可以先用現成模組建立一條完整流程，再慢慢決定邊啲部分值得做成更穩定嘅產品，而唔需要一開始就設計專用電路板。
試做一個可以對話嘅 AI 裝置
筆者其中一個實驗，係利用開發板製作一個類似 AI 助手嘅桌面裝置 (AI版 Alexa)。筆者可以直接同佢講嘢，裝置先收集聲音，再將音訊送到語音辨識服務，將文字交俾大型語言模型處理，最後把答案轉成語音播放出嚟。
同一個裝置亦可以由伺服器取得天氣、航班、巴士、電車或者其他公開數據，再顯示喺屏幕。表面睇，呢啲功能同手機或者網站相似；但當佢變成一件放喺枱面、可以即時聽到同睇到嘅物件，筆者先更清楚體會到軟件同實體互動嘅差別。
例如網頁等幾秒先顯示答案，使用者可能只覺得稍慢；但語音裝置講完一句之後長時間冇反應，就會令人懷疑佢有冇聽到、係咪斷線或者已經當機。因此，裝置要有清楚狀態：正在聆聽、處理中、連線失敗、資料過期，定係需要重新講。燈號、屏幕文字同短聲音，往往同模型能力一樣重要。
呢個項目亦筆者我明白，硬件原型唔只係接駁元件同寫程式。電源穩定、音量、咪高峰位置、網絡重連、重新開機後狀態、API 逾時同屏幕更新，都會直接影響成件產品係咪「好似真係識用」。
由一條最細、可以驗證嘅實體流程開始
建立硬件項目時，筆者覺得最有效嘅做法同網站嘅 vertical slice 相似：先揀一條最細但完整嘅流程，證明由感應到輸出全部接得通，再逐步增加功能。唔好一開始同時接十個感應器、鏡頭、摩打、語音同雲端服務，否則出錯時好難知道問題喺邊。
1｜先定義一個清楚任務，例如讀取溫度並顯示，或者接收一句語音再播放答案。
2｜逐件元件獨立測試，保存原始讀數同錯誤訊息，確認接線、電源同驅動程式正常。
3｜將「讀取、判斷、執行」分成不同模組，避免任何一層出錯就令成個裝置停住。
4｜模擬斷網、伺服器逾時、感應器拔走、電源重啟同資料超出範圍，觀察系統點樣退化。
5｜加入手動控制、狀態提示、日誌同安全停止，再考慮自動化同 AI 功能。
先做好可觀察性非常重要。裝置只係「冇反應」時，維修幾乎只能靠估；如果系統知道自己停喺錄音、上傳、模型、播放定顯示階段，問題就容易重現同修正。
由感應變成控制，風險會突然增加
只讀取溫度或者顯示巴士資料，出錯通常只係畫面唔準。但當系統開始控制摩打、發熱元件、門鎖、車輛、泵或者其他會影響人同環境嘅設備，錯誤就可能造成財物損失甚至人身風險。
因此，執行層需要硬性限制，而唔係只靠一句 prompt。常見原則包括最大速度、最高溫度、最長運行時間、允許移動範圍、每次操作上限、互鎖條件、看門狗、緊急停止同安全預設狀態。程式失控、模型回應異常或者網絡中斷時，裝置應該回到已知而安全嘅狀態。
筆者會將語言模型放喺較高層，用嚟理解「想做乜」；真正控制硬件嘅低層程式，只接受少量預先定義、通過驗證嘅指令。高風險動作仲要有人確認。模型可以建議「將裝置移到指定位置」，但唔應該可以跳過距離限制、碰撞檢查同停止條件。
保安同私隱唔可以等原型完成先處理
連網裝置通常長時間開著，可能放喺屋企、辦公室或者其他私人空間。如果佢有咪高峰、鏡頭、位置或者環境數據，資料敏感程度可能比普通網站表格更高。
基本設計應該包括最低權限、獨立裝置憑證、加密通訊、可更新韌體、撤銷失效金鑰、限制對外服務，同埋唔將密碼硬寫入公開程式。裝置亦唔應該因為方便，就同所有內部系統處於同一個無限制網絡。
使用者要知道裝置幾時正在錄音、邊啲資料會上傳、會保存幾耐，同埋點樣關閉或者刪除。對一件實體產品嚟講，一粒真正斷電或者關閉感應器嘅掣，有時比介面入面一個複雜設定更可信。
真正難嘅係處理失效，而唔係展示成功一次
一個原型成功運作一次，證明概念有可能；一件裝置每日運作，就要面對電源中斷、Wi-Fi 改密碼、API 轉格式、感應器老化、儲存空間用盡、時間不同步同使用者意外操作。實體系統嘅例外，比一個示範影片多得多。
所以會問：裝置重新開機後會返到邊個狀態？如果上一個指令只完成一半，會唔會重複執行？讀數長時間完全不變，係環境穩定定感應器卡死？伺服器回覆遲到，舊答案仲應唔應該播放？錯誤會唔會被記錄同通知？
呢啲問題未必有 AI 咁吸引，但先決定系統可唔可以長期使用。由軟件走入現實世界之後，可靠性唔再只係「結果大致合理」，而係要知道每一個狀態、每一個失敗，同埋失敗後嘅安全行為。
智能化唔代表每件物件都值得自動化
低成本開發板令人好容易為任何物件加感應器、連線同 AI，但技術上做到，仍然唔代表實際值得。好多情況用一個定時器、一粒掣或者簡單規則已經解決問題，加入雲端同模型只會增加耗電、延遲、私隱同維護成本。
筆者會用同之前自動化項目相似嘅問題判斷：呢個動作幾頻繁？現有做法有幾麻煩？需要幾快反應？斷網時有咩後果？出錯容易唔容易發現？裝置要維護幾耐？如果只係為咗節省幾秒，但多咗長期充電、更新同故障處理，未必係真正改善。
最有價值嘅物聯網應用，通常係能夠取得人手難以持續量度嘅狀態、及早發現異常、減少高頻重複工作，或者令設備喺清楚限制內更安全、更節能同更容易使用。
由物聯網走向 Physical AI
傳統物聯網比較強調「連接」：裝置將資料送上網絡，人可以遠端查看或者控制。當 AI 加入之後，系統開始可以理解更複雜嘅聲音、影像同環境模式，亦可以根據目標調整下一步。
筆者會將 Physical AI 理解成一個反覆循環：感知現實、建立狀態、判斷目標、規劃動作、執行，再觀察結果。感應器係眼耳，控制器係反射神經，模型負責部分理解同規劃，而摩打同其他執行器就係手腳。
當一件設備只有一個感應器同一盞燈，循環相對簡單；當佢同時有鏡頭、力感應、關節、平衡、導航、語音同多個摩打，系統就逐步接近機械人。每增加一個自由度，感知、控制、測試同安全要求都會急劇增加。
現實世界令 AI 嘅責任變得更具體
接觸物聯網之後，筆者對 AI 最大嘅新體會，係「有能力做」同「可以放心交俾佢做」之間嘅距離，在實體世界會更加明顯。Full Self-driving 就係最佳例子。文字寫錯可以修改，網站版本可以回復；摩打撞到物件、門鎖錯誤開啟或者設備過熱，就未必可以簡單 undo。
所以，實體 AI 系統需要更清楚區分探索、建議同控制。模型可以幫我設計方案、閱讀資料、理解指令同找出異常，但安全邊界、低層控制、監察、停止同最終責任，仍然要由確定程式同人建立。
低成本開發板最重要嘅價值，唔係令每個人立即製造一部完整機械人，而係令我哋可以用細規模、可觀察、可停止嘅方式，親手理解感知、連線、決策同控制點樣組成一個真正系統。
下一步：點解機械人會做成人形？
當感應器、控制器、AI 模型、摩打同電池組合得愈來愈完整，下一個自然問題就係機械人。技術上，機械人可以有輪、履帶、機械臂，甚至完全唔似人；針對單一任務，非人形設計往往更有效率。
但我哋今日生活嘅門、樓梯、枱櫈、工具、廚房、汽車同工作空間，大部分都係按人類身形同動作建立。如果一部通用機械人要進入現有環境，而唔係要求成個世界重新設計，人形就有一種實際兼容性。
下一篇｜由人形機械人到數碼分身：AI 最後會變成另一個自己？
最後一篇會由人形機械人轉到個人數碼分身：記憶、工作方法同決策規則可以外置，但價值判斷、風險承擔同最終責任仍然要由人保留。