Embodied AI：なぜ私は家庭用ロボットに「空の目」を与えたのか

本記事は、VLM、RAGメモリ、マニホールド学習を用いて「訓練不要」のホームサービスロボットを構築するための一連の記事の一部です。この記事では、カメラアーキテクチャを扱います。具体的には、なぜ天井に固定したノードが、知覚システム全体の土台として採用されることになったのかを説明します。

正直に言うと、最初の直感はこうでした。なぜロボットの搭載カメラを使わないのですか？

それが最も明白な答えです。ロボットはすでに部屋の中にいます。つまりカメラもすでに付いています。天井の固定ノードを12個追加するのは、不要な複雑さに聞こえます――より多くのハードウェア、より多くのキャリブレーション、より多くの故障ポイントです。すでに十分複雑なシステムに対して。

私の指導教員の要件は明確で、揺るぎませんでした。AIパイプラインの視覚入力は、ロボット自身ではなく、固定されたグローバルカメラから取らなければならない。これについては交渉の余地なし。

そこで私はしばらく、その制約のもとで「ただ従う」のではなく、なぜそうなのか理解しようと考えました。この記事は、私が突き止めたことのまとめです。まず私が持っていた本音の疑問――そもそもなぜグローバルカメラなのか？――から始まり、答えを受け入れた後に行った工学的な意思決定で締めくくります。

ロボット視点に潜む問題

搭載カメラによるオンボード視覚を推すのは直感的です。ロボットは移動できるので、カメラは行動が起きている場所へ行きます。しかし「行動が起きている場所」が、まさに問題であることが分かりました。

地面から30cm〜100cmの範囲でどこにでも取り付けられるロボット搭載カメラには、本質的な2つの問題があります。

視野が狭いことと、常時発生する遮蔽。 ロボットは低く、移動する、一人称視点から世界を見ます。ソファが、その後ろに座っている人の視界を塞ぎます。キッチンの壁が、ダイニングテーブルで何が起きているかを隠します。ロボットの視点では、家の中は「部分的な情報の迷路」です。

移動中のモーションブラー。 ロボットが動いているとき――つまり多くの時間――搭載カメラは信頼できる静止フレームを生成できません。ブレていて安定しない動画からの活動認識は、固定視点からの認識よりもかなり難しくなります。

これらは「工学的な失敗」ではありません。移動する地上レベルのカメラという幾何学的制約に内在するものです。どれだけ良いハードウェアにしても、この基本的な制約は変えられません。

アーキテクチャ：固定ノード＋1台の移動カメラ

私の解決策は、グローバルな知覚とローカルな行動を分離することでした。ロボットは物理的なやり取りを担当します。シーン理解は、固定された位置のカメラノード群が担当します。

私のシステムでは、12個のCameraNodeオブジェクトを3つの部屋に分散配置します（部屋ごとに4個）。天井高――約2.3m――に置き、実際の家庭で取り付けるであろう固定IPカメラのアレイをシミュレートします。これらのノードは動きません。互いに遮りません。そして常に空間を真上から見下ろす安定した視点を持ちます。

しかし重要な工学的制約があります。シーン中の物理カメラは1台しかないという点です。12個の別々のカメラを立ち上げる（高価で冗長）代わりに、1台のカメラを使って、選択された各ノード位置へ「テレポート」し、フレームをレンダリングしてから次へ進めます。この処理を管理するのがVirtualCameraBrainコンポーネントです。

for each selected node (top-N by score):
    camera.transform ← node.position + node.rotation
    wait 2 frames                    // GPUレンダリングのフラッシュ
    capture 512×512 PNG → Base64

POST all images to /predict in one request

これにより、レンダリングのオーバーヘッドを最小限に抑えつつ、多視点のカバレッジを得られます。

難しい問題：どのノードを選ぶべきか？

ノードが12個あっても、間違ったものを選べば無意味です。ユーザの背後にあるノードや、視野の端にユーザが入ってしまうノードは、VLMが確実に解釈できない画像を生成します。

そこで私はスコア関数が必要でした。最終的に次の形に落ち着きました：

s_i = (v_i × 0.5 + α_i × 0.3 + d_i × 0.2) × m_i

ここで：

• v_i — 可視性：ノードからユーザの胸までのラインキャストで、家具に当たらず到達できるか？（0または1）
• α_i — 角度ファクタ：ノードの視野内でユーザがどれだけ中心にいるか？（ど真ん中で1、視野端で0）
• d_i — 距離ファクタ：0mから10mまでの線形減衰
• m_i — ノードごとの優先度乗数。Inspectorで設定

最も重要なルールは、重み付き和の前に来ます。ハードなFOVゲーティングです。ユーザがそのノードの視野円錐の外にいる場合、そのノードは距離やラインキャストの結果がどれほど良くても即座にスコア=0になります。そもそも、ターゲットを見られないカメラに対して重み付き計算をしても意味がないからです。

スコア付けの後、候補を降順に並べ、上位2ノードから撮影します（設定可能）。1つのノードがわずかに遮られるケースに対応するため、2つの視点を用意しています。

なぜこれがVLMにとって重要なのか

私が視点の品質にこだわる理由は、下流の精度に直結するからです。私のシステムでは、llava-phi3（Ollama経由）を使って、ユーザが何をしているかを認識します――飲む、座る、読む、タイプするなど――タスク固有の訓練なしで。

VLMは、訓練済みの分類器とは異なる形で、画像品質に敏感です。訓練済みの活動認識モデルは、訓練中に十分な「遮蔽された例」を見れば、部分的な遮蔽を補うことを学習できます。しかしゼロショットのVLMはできません。学習による補正なしに、見えているものを解釈する必要があります。

つまり、カメラ選択は認識精度を直接左右するということです。初期テストでは、スコアリングシステムが悪い視点を選んだエピソード（ユーザがフレーム端にいる、あるいは家具の背後に一部隠れている）で、VLMの出力が「壁の近くに立つ人」のようになり、「ボトルから飲んでいる人」になりませんでした。SBERTの正規化層がその一部を処理しましたが、より良い対策は、上流で視点選択を改善することでした。

シミュレーションと現実の間のギャップ

私の現在の実装がどこに位置しているかについて、正直に述べたいと思います。上で説明したものはすべてUnity 3Dのシミュレーション上で動作します。「ノード」は仮想のGameObjectです。「カメラ」はUnityのレンダリングエンジンです。座標ストリームは、深度センサやオブジェクト検出からではなくDynamicSyncManager.csから取得しています。

これは意図的です。物理ハードウェアにコミットする前に、フレームワークを検証するためにシミュレーションを使っています。しかし、その代わりに現実世界で未解決の2つの問題が残ります：

外部パラメータ（外部）キャリブレーション。 実運用では、固定ノードごとのすべてのピクセル（u, v）を、共有された3D座標系にマッピングする必要があります。これには、各カメラの位置と、部屋に対する向きの物理的キャリブレーションが必要です。これはセットアップに相当な時間を要し、カメラを動かすたびに再キャリブレーションが必要になります。

レイテンシ補償。 天井（壁）に設置したIPカメラから処理バックエンドへのネットワーク送信は、おおよそ50〜150msの遅延を生みます。移動するユーザの場合、このことは、受け取る位置データが「現在」ではなく「その人がいた場所」に対応することを意味します。補償には、予測が必要です――単純な線形外挿でも、カルマンフィルタでも。

私のシミュレーションは、Unityシーンから正解の座標を直接得られるため、この2つを回避しています。これは現実のギャップであり、論文中の制限として明示的に記録しています。

協調的なオフロード：この設計がロボットに可能にすること

この設計のアーキテクチャ上の利点は、ロボット自体が重い視覚推論を実行する必要がないことです。固定ノードの知覚パイプラインがシーン理解を行い、軽量なメタデータをロボットの意思決定層へ送信します：

{
  "user_id": "User_Mom",
  "action":  "Reading",
  "pos":     [-0.17, 8.62],
  "room":    "LivingRoom",
  "intent":  "Drink",
  "confidence": 0.74
}

ロボットは、生のピクセルではなく、事前処理された要約を受け取ります――誰がどこにいて、何をしていて、次に何を欲しがりそうか、です。これは「体に実装された知能（embodied intelligence）へと周辺の知能（ambient intelligence）をオフロードする」アーキテクチャの中核です。

電池駆動の物理ロボットにとって、これは非常に重要です。組み込みGPUでVLM推論パイプラインを継続的に動かすと、1時間以内にバッテリーが消耗します。壁給電のバックエンドでそれを実行し、メタデータをWi-Fiでロボットに送る場合、ロボット側のコストはほとんどありません。

Perception Mode Comparison

What's Next

このシリーズの次回投稿では、これらのキャプチャ画像を入力としてゼロショットVLMパイプラインに使う方法と、SBERTによるセマンティック正規化が、自由形式のVLM記述を、学習データなしで標準的な振る舞いラベルへマッピングする仕組みを説明します。

もしあなたが同様のものを作っている、または実運用で外部パラメータのキャリブレーション問題を扱ったことがあるなら、どのように取り組んだのかぜひ聞かせてください。

「Training-Free Home Robot」シリーズの一部です。全システムは、VLMによる知覚、行動シーン・グラフのメモリ層（FAISS + MongoDB）、および事前意図予測のためのUMAPマニフォールド学習を統合します。