BEV表現を1から — 複数カメラを俯瞰図に統合する

自動運転車が6台のカメラ映像を1枚の「上から見た地図」に変換する仕組みを、透視投影の復習から解説。深度を確率分布で押し出すLSSと、BEV側から問い合わせるTransformer系(BEVFormer)の設計思想の違いまで、前提知識ゼロから追う。

Lift

なぜ「上から見た地図」が要るのか

サッカー中継を思い浮かべてください。ピッチサイドのカメラ映像は迫力がありますが、「選手Aと選手Bの間が何メートル空いているか」は掴みにくい。だから監督は戦術ボード——ピッチを真上から見た図——で作戦を考えます。距離・位置関係・空きスペースは、上から見た平面図がいちばん素直に表せるからです。

自動運転車もまったく同じ問題を抱えています。車には前後左右を向いた複数のカメラ（例えば6台）が付いていて、それぞれが斜めから見た透視図を写します。しかし「隣の車線の車まで何メートルか」「この隙間に割り込めるか」という判断は、戦術ボードと同じ真上からの地図の上で行いたい。この上から見た表現を BEV（Bird's-Eye View、鳥瞰図） と呼び、複数カメラの透視図を1枚のBEVに統合する仕組みが今回の主題です。

一度BEVにしてしまえば、物体検出も経路計画も「地図上の2次元問題」になり、LiDAR（レーザー距離計）由来の情報とも同じ土俵で混ぜられます。カメラごとにバラバラに検出して後から統合する旧来の方式に対し、先に視点を統一してから考えるのがBEV表現の思想です。

透視投影 — 世界が写真になるとき、何が失われるか

まず「カメラに写る」とはどういう計算かを押さえます。最も単純なピンホールカメラのモデルでは、カメラから見た3次元の点 $(X, Y, Z)$（$Z$ が奥行き）は、画像上の位置 $(u, v)$ にこう写ります。

言い換えると、3次元の座標を奥行き $Z$ で割ったものが画像上の位置です。$f_x, f_y$ は焦点距離（ズームの度合いを表す定数）、$c_x, c_y$ は画像の中心位置で、これらをまとめてカメラの内部パラメータと呼びます。$Z$ で割るからこそ、遠くのもの（$Z$ が大きい）ほど画像上では小さく写る——これが透視投影です。

重要なのは、この計算が情報を捨てていることです。$Z$ で割った瞬間、奥行きの値そのものは画像から消えます。逆に画像の1ピクセルから世界を復元しようとすると、候補は「カメラからそのピクセルの方向へ伸びる光線上のすべての点」——手前1mの虫かもしれないし、50m先のトラックかもしれない。1枚の画像から奥行きは一意に決まらない。この逆問題の解けなさこそが、透視図→俯瞰図の変換を難しくしている根本原因です。

視点変換の直感 — 「失われた奥行きをどう埋めるか」で流派が分かれる

奥行きが消えているなら、何かで補うしかありません。古典的な答えはIPM（逆透視投影）です。「写っているものはすべて地面（高さ0の平面）にある」と仮定すれば、光線と地面の交点として奥行きが一意に決まります。駐車支援のアラウンドビューモニタはこの原理です。しかし車や歩行者のような高さのある物体では仮定が破れ、上のほうほど遠くへ引き伸ばされて歪みます。地面しか信じない変換なので、立体物だらけの走行シーンには足りません。

そこで深層学習ベースの手法は、大きく2つの流派に分かれました。

• 画像側から押し出す（push型）: 各ピクセルの奥行きをネットワークに確率分布として推測させ、その分布に従って特徴を3次元空間へ押し出す。代表がLSS（Lift-Splat-Shoot）。
• BEV側から引き寄せる（pull型）: 先に俯瞰図側にクエリ（質問係）を敷き詰め、「この地点に何が見えるか」を各カメラへ問い合わせる。代表がBEVFormerなどのTransformer系。

鍵になるのは「奥行きを1つの値に決めつけない」ことです。推測が自信ありなら分布は尖り、迷っているなら平らになる——この振る舞いは、softmax（合計1の確率分布に変換する関数）の温度と同じ構図です。