RuView：用 WiFi 訊號做無攝影機空間感知的開源平台

Sun, 17 May 2026 17:34:08 +0800

RuView 是 ruvnet 開源的 WiFi 空間感知平台。

它的目標很有想像力：不用攝影機、不用穿戴式裝置，只依賴普通 WiFi 訊號和低成本 ESP32-S3 感測節點，從 Channel State Information，也就是 CSI，提取人體存在、移動、呼吸、心率、活動模式、房間狀態和姿態估計資訊。

專案地址：https://github.com/ruvnet/RuView

先說結論

RuView 值得關注，但也要冷靜看待。

它不是普通 Web 應用，也不是裝上 Docker 就能直接「看穿牆」的成品監控系統。更準確地說，RuView 是一個圍繞 WiFi CSI、ESP32-S3、邊緣推理、空間感知和多模態融合的研究型開源平台。

它適合這些場景：

學習 WiFi CSI 感知和無線訊號處理。
用 ESP32-S3 做存在偵測、動作偵測和生命體徵原型。
研究無攝影機空間感知方案。
探索養老、醫療、智慧建築、零售客流、安防、機器人安全等邊緣感知應用。
在隱私敏感場景測試「非視訊感知」的可能性。

它暫時不適合這些期待：

買一塊板子就穩定替代醫療設備。
單個 ESP32 節點實現高精度室內三維定位。
在任意房間裡不調參、不校準就精準識別每個人。
用 RSSI 普通 WiFi 筆電取得完整 CSI 能力。
把 beta 專案直接部署到高風險生產場景。

README 也提醒：RuView 仍是 beta 軟體，API 和韌體可能變動；ESP32-C3 和原版 ESP32 不支援；單 ESP32 部署的空間解析度有限；無攝影機姿態估計精度也有明顯限制。

RuView 是什麼

RuView 的核心思路，是把 WiFi 訊號當成空間感測器。

WiFi 路由器會在空間裡持續發射無線電波。人體移動、呼吸、坐下、起身，都會讓這些訊號產生細微變化。傳統 WiFi 主要關心「能不能連線」和「訊號強不強」，RuView 關注的是更底層的 Channel State Information。

CSI 可以理解為無線鏈路在不同子載波、不同時間點上的細粒度狀態。相比普通 RSSI，CSI 資訊量更大，可以用來分析：

房間裡有沒有人。
人大概在什麼區域。
是否有人走動、坐下、跌倒。
呼吸頻率是否異常。
心率訊號是否可估計。
房間的無線指紋是否變化。
多節點之間的空間關係是否支援更細定位。

RuView 試圖把這些原始無線訊號處理成可用的空間智慧資料。

它能感知什麼

依照 README，RuView 關注的能力包括：

Presence and occupancy：偵測是否有人、人數變化、進入和離開。
Vital signs：非接觸式呼吸率和心率估計。
Activity recognition：行走、坐下、手勢、跌倒等活動識別。
Environment mapping：房間 RF 指紋、家具移動、新物體變化。
Sleep quality：夜間監測、睡眠階段和呼吸暫停篩查方向。
Pose estimation：基於 WiFi CSI 的人體關鍵點估計。

最容易落地的是存在偵測、活動變化和粗粒度占用判斷。呼吸、心率和姿態估計對硬體部署、環境、訊號品質、模型和校準要求更高。

所以不要把所有功能看成同等成熟。一個專案能跑通研究管線，和在真實家庭、醫院、酒店、倉庫裡長期穩定運行，中間仍有很長工程距離。

為什麼是 ESP32-S3

RuView 推薦使用 ESP32-S3 作為低成本 CSI 採集節點。

README 明確提到：

ESP32-C3 不支援。
原版 ESP32 不支援。
原因是單核和算力不足，不適合 CSI DSP 需求。
單 ESP32 部署空間解析度有限。
更好的效果需要 2 個以上節點，或搭配 Cognitum Seed。

這點很重要。很多人看到「WiFi 感知」會誤以為普通電腦、普通路由器、任意 ESP32 都能完整實現。實際上，完整 CSI 能力依賴硬體、韌體和採集方式。

專案也給出不同硬體路徑：

Docker 模擬資料：不需要硬體，適合評估處理管線。
ESP32-S3 節點：低成本即時採集，適合原型。
ESP32 mesh：多個節點提升空間解析度。
ESP32-S3 + Cognitum Seed：用於持久記憶、kNN、見證鏈和 AI 整合。
研究網卡：如 Intel 5300 / Atheros AR9580，用於更完整 CSI 研究。
普通 WiFi 筆電：通常只有 RSSI，能力很有限。

快速體驗

如果只是想看系統介面和模擬資料，可以先用 Docker：

1
2

docker pull ruvnet/wifi-densepose:latest
docker run -p 3000:3000 ruvnet/wifi-densepose:latest

然後打開：

`1`	`http://localhost:3000`

如果要接真實 ESP32-S3 硬體，就要刷寫韌體並設定 WiFi：

1
2
3

python -m esptool --chip esp32s3 --port COM9 --baud 460800 \
  write_flash 0x0 bootloader.bin 0x8000 partition-table.bin \
  0xf000 ota_data_initial.bin 0x20000 esp32-csi-node.bin

設定網路和目標地址：

1
2

python firmware/esp32-csi-node/provision.py --port COM9 \
  --ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20

專案也提供多個即時處理腳本，例如：

1
2
3

node scripts/rf-scan.js --port 5006
node scripts/snn-csi-processor.js --port 5006
node scripts/mincut-person-counter.js --port 5006

這些命令適合開發者依照 README 逐步驗證管線。普通使用者如果沒有無線訊號處理或嵌入式經驗，直接上手會有門檻。

它的處理管線

RuView 的基本處理鏈路可以理解為：

WiFi 訊號穿過房間。
人體和物體改變無線傳播路徑。
ESP32-S3 mesh 採集 CSI。
多頻段、多子載波、多節點鏈路融合。
訊號清理和特徵提取。
RuVector / AI Backbone 做表示、壓縮、檢索和建模。
神經網路輸出人體關鍵點、生命體徵和房間模型。
上層應用用於告警、統計、視覺化或自動化控制。

這裡涉及 CSI 子載波幅度和相位、多徑傳播、Fresnel zone 幾何、呼吸和心率頻段濾波、Hampel filter、SpotFi、BVP、spectrogram、圖演算法、attention、spiking neural networks、多節點 mesh 和跨視角融合。

這也是為什麼 RuView 更像研究平台，而不是普通 IoT 小工具。

可以用在哪些場景

README 列了很多應用場景，可以大致分成幾類。

第一類是養老和醫療輔助：

老人房間存在偵測。
跌倒偵測。
夜間活動監測。
睡眠時呼吸率觀察。
非關鍵病床的呼吸和心率輔助監測。

這類場景最吸引人，因為它不需要攝影機，也不要求使用者一直佩戴設備。但醫療相關用途必須非常謹慎，不能把研究專案直接當醫療設備使用。

第二類是智慧建築和商業空間：

辦公室工位和會議室占用。
HVAC 按真實存在狀態調節。
酒店房間空置和節能。
餐廳排隊和桌台周轉。
零售客流、停留時間和區域熱度。

這類應用更接近「空間占用和行為統計」，對隱私友善性要求高，對厘米級姿態精度要求相對低，可能更容易先落地。

第三類是安全和工業：

周界入侵偵測。
倉庫人員安全區域。
叉車接近提醒。
封閉空間人員存在。
施工現場跌倒和人員計數。

這些場景需要低延遲和可靠告警，也必須處理誤報、漏報和責任邊界。

第四類是機器人和複雜環境：

機器人在攝影機受限場景下感知人類。
煙塵、霧、遮擋、貨架背後的人體存在。
災害搜救中的呼吸訊號探測。
地下、礦井、船舶等光學感測器困難場景。

這類場景很有研究價值，但工程化難度也更高。

隱私優勢和新風險

RuView 的一個重要賣點是無攝影機。

在養老、醫院、學校、辦公室、酒店、餐廳、公共衛生間等場景裡，攝影機會帶來明顯隱私壓力。WiFi 感知不記錄影像，也不需要穿戴式裝置，從設計上減少了很多視覺隱私問題。

但「沒有攝影機」不等於「沒有隱私風險」。

WiFi 感知仍然可能推斷：

房間裡有沒有人。
人什麼時候進入和離開。
睡眠、呼吸和活動模式。
是否跌倒或長時間靜止。
某些空間裡的行為規律。

這些同樣屬於敏感資料。部署 RuView 這類系統時，仍然需要明確告知、權限控制、資料保留策略、加密儲存、最小化採集和存取審計。

和攝影機、PIR、毫米波雷達的差別

攝影機的優勢是資訊豐富、直觀、可解釋，但隱私壓力最大，也依賴光照和視線。

PIR 感測器成本低、部署簡單，但只能感知熱釋電變化，容易出現「人靜止就偵測不到」的問題，空間解析度也有限。

毫米波雷達適合非接觸生命體徵和存在偵測，精度和穩定性較好，但通常需要額外硬體，部署成本高於複用現有 WiFi。

WiFi 感知的優勢是：

WiFi 基礎設施普遍存在。
能穿過部分牆體和遮擋。
不採集影像。
ESP32-S3 節點成本低。
可以和現有網路環境結合。

短板是：

訊號受環境影響大。
部署位置、節點數量、牆體材料都會影響效果。
多人場景更複雜。
高精度姿態和生命體徵估計仍然困難。
工程化驗證比普通攝影機方案更難。

目前限制

README 已列出幾個關鍵限制：

專案仍是 beta 軟體。
API 和韌體可能變化。
ESP32-C3 和原版 ESP32 不支援。
單 ESP32 部署空間解析度有限。
建議使用 2 個以上節點或 Cognitum Seed。
無攝影機姿態估計目前精度有限。
攝影機監督訓練管線已實現，但資料採集和評估仍在推進。
Docker 範例使用模擬資料，不代表真實硬體效果。

這類專案最容易被標題帶偏。WiFi 感知確實有很強的技術潛力，但實際效果取決於硬體、環境、部署密度、模型、校準和應用容錯。

如果要做原型驗證，建議先從存在偵測和簡單活動識別開始，不要一開始就要求高精度姿態、心率和多人三維追蹤。

適合怎麼入門

比較穩妥的學習路徑是：

先跑 Docker 模擬資料，理解 UI 和處理管線。
閱讀 README 和 docs 裡的架構說明。
準備 ESP32-S3，而不是 ESP32-C3 或原版 ESP32。
從單節點 CSI 採集開始，確認資料流穩定。
再增加到 2 到 4 個節點，觀察空間解析度變化。
先驗證 presence、movement、breathing 這類基礎能力。
最後再嘗試 pose estimation、edge modules 和多模態融合。

如果目標是產品化，還要額外考慮設備安裝位置、網路安全、資料加密和保留週期、告警誤報率、使用者告知和授權、硬體批量維護、斷網和斷電行為、OTA 升級和韌體回滾。

總結

RuView 是一個很有野心的 WiFi CSI 空間感知專案。它嘗試把低成本 ESP32-S3、無線訊號處理、邊緣 AI、生命體徵估計、姿態識別和無攝影機空間監測放到同一套平台裡。

它最有價值的地方，是把「WiFi 不只是聯網工具，也可以成為空間感測器」這件事做成了可運行的開源工程。對研究者、硬體開發者、智慧建築團隊、隱私敏感場景的產品原型來說，它值得研究。

但它仍處於 beta 階段，不能把 README 裡的所有能力直接等同於穩定產品能力。單節點效果有限，硬體有要求，真實環境會帶來噪聲，多人和高精度姿態估計仍然困難。更合理的態度是：把 RuView 當成 WiFi 感知實驗平台，從模擬資料和基礎存在偵測開始，逐步驗證它在具體空間裡的可用性。

參考連結：

邊緣運算 on KnightLi的博客