RuView は ruvnet が公開している WiFi 空間センシングプラットフォームです。
狙いはかなり野心的です。カメラもウェアラブルも使わず、通常の WiFi 信号と低コストな ESP32-S3 センサーノードだけで、Channel State Information、つまり CSI から、人の存在、移動、呼吸、心拍、活動パターン、部屋の状態、姿勢推定の情報を取り出そうとします。
プロジェクト:https://github.com/ruvnet/RuView
まず結論
RuView は注目に値します。ただし、冷静に見る必要があります。
これは普通の Web アプリではなく、Docker を起動すればすぐに「壁の向こうが見える」完成品の監視システムでもありません。より正確には、WiFi CSI、ESP32-S3、エッジ推論、空間センシング、マルチモーダル融合を扱う研究向けのオープンソース基盤です。
向いている用途は次の通りです。
- WiFi CSI センシングと無線信号処理の学習。
- ESP32-S3 による存在検知、動作検知、バイタルサイン検知のプロトタイプ。
- カメラを使わない空間センシング方式の研究。
- 介護、医療、スマートビル、店舗の客流、防犯、ロボット安全などのエッジセンシング探索。
- プライバシーに敏感な場所で「非映像センシング」を試すこと。
一方で、現時点では次の期待には向きません。
- ボードを買うだけで医療機器を安定して置き換える。
- 1 個の ESP32 ノードで高精度な屋内 3D 測位を行う。
- 任意の部屋で調整や校正なしに個人を正確に識別する。
- 通常の RSSI だけの WiFi ノート PC で完全な CSI 能力を得る。
- beta プロジェクトを高リスクな本番環境へ直接投入する。
README でも、RuView は beta ソフトウェアであり、API やファームウェアは変わる可能性があること、ESP32-C3 と初代 ESP32 は非対応であること、単一 ESP32 配置では空間分解能が限られること、カメラなし姿勢推定の精度にも限界があることが明記されています。
RuView とは
RuView の中心的な考え方は、WiFi 信号を空間センサーとして扱うことです。
WiFi ルーターは空間に電波を出し続けています。人が動く、呼吸する、座る、立つといった動きは、その信号に微細な変化を起こします。従来の WiFi は主に「つながるか」と「信号が強いか」を見ますが、RuView はより低レイヤーの Channel State Information を見ます。
CSI は、異なるサブキャリアや時刻における無線リンクの細かな状態と考えるとわかりやすいです。通常の RSSI より情報量が多く、次の分析に使えます。
- 部屋に人がいるか。
- 人がだいたいどのあたりにいるか。
- 歩行、着席、転倒が起きたか。
- 呼吸周波数に異常がありそうか。
- 心拍信号を推定できるか。
- 部屋の RF 指紋が変化したか。
- 複数ノードの空間関係でより細かい定位ができるか。
RuView は、こうした生の無線信号を利用可能な空間インテリジェンスへ変換しようとしています。
何を感知できるか
README によると、RuView が対象にする能力は次の通りです。
- Presence and occupancy:人の有無、人数変化、入退室の検知。
- Vital signs:非接触の呼吸数と心拍数推定。
- Activity recognition:歩行、着席、ジェスチャー、転倒などの活動認識。
- Environment mapping:部屋の RF 指紋、家具移動、新しい物体の変化。
- Sleep quality:夜間監視、睡眠段階、睡眠時無呼吸のスクリーニング方向。
- Pose estimation:WiFi CSI による人体キーポイント推定。
現実的に導入しやすいのは、存在検知、活動変化、粗い占有判断です。呼吸、心拍、姿勢推定は、ハードウェア配置、環境、信号品質、モデル、校正への要求が高くなります。
研究パイプラインが動くことと、家庭、病院、ホテル、倉庫で長期安定運用できることの間には、まだ大きな工程差があります。
なぜ ESP32-S3 なのか
RuView は低コストな CSI 収集ノードとして ESP32-S3 を推奨しています。
README では次の点が示されています。
- ESP32-C3 は非対応。
- 初代 ESP32 は非対応。
- 単一コアで計算力が不足し、CSI DSP 要件に合わない。
- 単一 ESP32 配置では空間分解能が限られる。
- より良い結果には 2 個以上のノード、または Cognitum Seed との組み合わせが必要。
これは重要です。「WiFi センシング」と聞くと、普通の PC、普通のルーター、任意の ESP32 で実現できると思いがちです。実際には、完全な CSI 能力はハードウェア、ファームウェア、収集方式に依存します。
プロジェクトは複数のハードウェア経路も示しています。
- Docker の模擬データ:ハードウェア不要で、処理パイプライン評価向き。
- ESP32-S3 ノード:低コストなリアルタイム収集で、プロトタイプ向き。
- ESP32 mesh:複数ノードで空間分解能を改善。
- ESP32-S3 + Cognitum Seed:永続記憶、kNN、witness chain、AI 統合向き。
- Intel 5300 / Atheros AR9580 などの研究用 NIC:より本格的な CSI 研究向き。
- 通常の WiFi ノート PC:多くは RSSI のみで能力は限定的。
すばやく試す
UI と模擬データを見るだけなら Docker から始められます。
|
|
その後、次を開きます。
|
|
実際の ESP32-S3 ハードウェアを使う場合は、ファームウェアを書き込み、WiFi を設定します。
|
|
ネットワークと送信先を設定します。
|
|
リアルタイム処理スクリプトも用意されています。
|
|
これらは 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 センシングでも、部屋に人がいるか、入退室時刻、睡眠・呼吸・活動パターン、転倒や長時間静止、空間内の行動規則性を推定できます。これらも敏感なデータです。
導入時には、明示的な通知、権限管理、データ保持方針、暗号化保存、最小限の収集、アクセス監査が必要です。
カメラ、PIR、ミリ波レーダーとの違い
カメラは情報量が多く、直感的で説明しやすい一方、プライバシー負荷が最大で、照明と視線に依存します。
PIR センサーは安価で設置しやすいですが、熱変化を主に見ます。人が静止すると検知しにくく、空間分解能も限られます。
ミリ波レーダーは非接触のバイタルサインや存在検知に向き、精度と安定性も比較的高いですが、追加ハードウェアが必要で、既存 WiFi の再利用よりコストが上がりがちです。
WiFi センシングの利点は、既存の WiFi インフラが多いこと、一部の壁や遮蔽を通ること、画像を収集しないこと、ESP32-S3 ノードが安価なこと、既存ネットワークと組み合わせやすいことです。
弱点は、環境影響が大きいこと、配置やノード数や壁材で結果が変わること、多人数シーンが難しいこと、高精度姿勢・バイタル推定がまだ難しいこと、カメラ方式より工学的検証が難しいことです。
現在の制限
README にある主な制限は次の通りです。
- まだ beta ソフトウェアである。
- API とファームウェアは変わる可能性がある。
- ESP32-C3 と初代 ESP32 は非対応。
- 単一 ESP32 配置では空間分解能が限られる。
- 2 個以上のノードまたは Cognitum Seed が推奨される。
- カメラなし姿勢推定の現精度には限界がある。
- カメラ監督の学習パイプラインはあるが、データ収集と評価は進行中。
- Docker 例は模擬データであり、実ハードウェアの性能を示すものではない。
WiFi センシングには強い可能性がありますが、実際の効果はハードウェア、環境、配置密度、モデル、校正、用途の許容誤差に依存します。
プロトタイプでは、まず存在検知と簡単な活動認識から始めるのが現実的です。最初から高精度姿勢、心拍、多人数 3D トラッキングを求めるべきではありません。
入門方法
堅実な学習順序は次の通りです。
- Docker の模擬データを動かし、UI と処理パイプラインを理解する。
- README と docs のアーキテクチャ説明を読む。
- ESP32-C3 や初代 ESP32 ではなく ESP32-S3 を用意する。
- 単一ノードの CSI 収集から始め、データフローの安定性を確認する。
- 2 から 4 ノードに増やし、空間分解能の変化を見る。
- presence、movement、breathing など基礎能力を先に検証する。
- 最後に pose estimation、edge modules、マルチモーダル融合を試す。
製品化を考えるなら、設置位置、ネットワーク安全、暗号化と保持期間、誤報率、利用者への通知と同意、ハードウェア保守、ネットワーク断や停電時の挙動、OTA 更新、ファームウェアロールバックも必要です。
まとめ
RuView は非常に野心的な WiFi CSI 空間センシングプロジェクトです。低コストの ESP32-S3、無線信号処理、エッジ AI、バイタルサイン推定、姿勢認識、カメラなし空間監視を 1 つの基盤にまとめようとしています。
最も価値があるのは、「WiFi はネットワーク手段であるだけでなく、空間センサーにもなり得る」という考えを、実行可能なオープンソース工程にした点です。
ただし、まだ beta です。README の機能一覧をそのまま安定した製品能力と見なすべきではありません。RuView は WiFi センシング実験基盤として扱い、模擬データと基本的な存在検知から始め、具体的な空間で段階的に検証するのが現実的です。
参考リンク: