Zenn
🦔

UniAD（Unified Autonomous Driving）について調べてみた。

に公開
transformer
自動運転
uniad
bird’seyeview
bev空間
tech

1.はじめに

1.1 自動運転の現状と課題

  • 自動運転システムでは、3D物体検出・セマンティクマップ推定・行動予測・経路計画など多くのタスクが必要。
  • 従来は各タスクごとに別々のネットワークが存在し、開発・保守が複雑化。

1.2 UniADの概要と特徴

  • UniAD (Unified Autonomous Driving) は、こうした多タスクを1つのネットワークで統合的に扱うフレームワーク。
  • 特徴：Bird’s Eye View (BEV) 表現を軸に、過去フレーム含めた時系列情報を考慮しながらマルチタスク学習を実現。

1.3 本記事のゴール・構成

  • 本記事ではUniADのアーキテクチャを分かりやすく解説し、導入メリットや実験結果をまとめる。
補足：BEV空間とは？

「Bird’s Eye View」とは、日本語で言うと“鳥の目線”という意味です。まさに鳥が空から地上を見下ろしたような視点をイメージすると分かりやすいでしょう。通常のカメラは正面や斜め方向から景色を映しますが、BEVでは「真上から見た」状態で風景を捉えます。地図アプリの俯瞰モードを思い浮かべると理解しやすいと思います。
BEV空間を使う最大のメリットは、道路や建物、障害物、車などが平面上に一目瞭然で表示される点です。横から見た映像や斜めからの映像とは違い、上下や左右の位置関係が直感的に捉えやすくなります。特に自動運転のようなシステムでは「この車線はどこにあるか？」「あの車はどのエリアにいるか？」「どこが通行できるか？」などを簡潔に把握できるため、衝突回避や経路選択などにとても役立ちます。

1.4 比較表：UniADと他の主要手法の位置付け

  • 従来のモジュール型は 2010年代初頭にかけて、大手自動運転企業が少しずつ構築。
  • CenterNet / CenterPoint が 2019～2021年あたりに学術的に広まる。
  • BEVFormer / BEVerse / BEVFusion / UniAD は 2022年前後以降、BEV への転換とマルチタスク統合が急速に進む流れの中で登場。
比較表
手法 / 比較軸 登場時期 (会議等) 発表元 タスク統合性 使用センサー パイプライン構成 時系列情報 BEV中心 主な特徴 / 例
従来のモジュール型パイプライン 2010年代前半～ 多様 (Waymo, GM, Uber, etc.) △ (各タスク別) カメラ / LiDAR / etc 多数の個別モジュールを連結 △ (別モジュールで対応) × / △ 例: 2D物体検出→3D変換→トラッキング→マップ認識→計画を個別ネットワークで行う。開発が複雑でモジュール間誤差が蓄積。
CenterNet / CenterPoint - CenterNet: 2019 ICCV
- CenterPoint: 2021 (arXiv,実装公開)		 - CenterNet: UT Austin
- CenterPoint: Waymo 等		 × (単タスク中心) LiDAR (CenterPoint), カメラ版もあり 単一目的 (3D検出用) △ (拡張版でトラッキング) × CenterNet は 2D/3D検出フレームワーク。CenterPoint は LiDARベース 3D検出 + Tracking で高精度。タスク統合度は低いが検出性能がSOTA級。
BEVFormer 2022 (ECCV) SenseTime / Shanghai AI Lab など △ (検出+地図) カメラのみ 比較的統合度高 (BEVに一体化) ○ (Transformer) ○ マルチカメラ→BEV変換 + 時系列統合。3D物体検出やBEVセグが可能。将来予測要素も拡張しやすく、Camera OnlyでLiDAR級精度を目指す。
BEVerse 2022 (arXiv) Shanghai AI Lab / HKUST 等 ○ (検出+セグ+予測) カメラのみ 統合度高 (BEV特化) △ (将来予測が主) ○ BEVFormerをさらに発展し、3D検出・BEVセグ・将来予測をワンフレームワークに統合。Camera Onlyで多タスクに対応する上位手法として注目。
BEVFusion 2022 (arXiv) HKUST 等 △ (検出+セグ) カメラ + LiDAR 「カメラBEV」と「LiDARBEV」を融合 △ (静的;時系列も拡張可) ○ シンプルに BEV 空間でチャンネル結合するセンサーフュージョン。カメラ情報 + LiDAR距離精度を両立し、多タスク（検出・マップ）精度を向上。
UniAD (本記事の対象) 2022～2023 (arXiv) SenseTime / Shanghai AI Lab など ◎ (多タスク) カメラのみ (現状) 統合度最大 (Backbone→各モジュール) ◎ (時系列必須) ○ 検出・マップ・将来予測・経路計画まで自動運転に必要な全要素を1つのモデルに統合する先進的フレームワーク。Camera Onlyながらフルスタックに近いパイプラインを実現。
Waymo / Cruise等社内実装 随時 (2018～2023など) Waymo, Cruise, Tesla 等 各社内 ○～◎ (多タスク) カメラ + LiDAR + Radar など 社内最適化・モジュール化 ○ (システム依存) △ / ○ 実車向けに大規模最適化。複数センサーをフル活用し、プランニングや制御まで含める。ただしクローズドソースが多く詳細不明点もある。

2.UniADが解決しようとしている問題

2.1 従来のパイプライン型アプローチの課題

  • タスクごとに個別のモデルを用意 → 設計・学習・推論時の膨大なリソース。
  • タスク間の知識共有不足 → 相互に助け合う情報を活かしきれていない。

2.2 マルチタスク学習のメリット

  • タスク間の相乗効果: 例）地図セグメンテーションが物体検出に役立つ。
  • 処理効率: 単一フレームワークで推論 → リアルタイム化に向けた可能性。

2.3 BEV表現の重要性

  • 真上から見下ろす視点で空間を捉えることで、周囲のオブジェクトや道路構造を統一的に扱いやすい。
  • カメラ座標からの投影や、LiDAR点群の投影などで、時系列変化も統合可能。

3.UniADの全体アーキテクチャ

3.1 モジュール構成図の紹介


引用元：GitHub:UniAD

3.2 全体フロー概観

図の左側「Backbone」では、マルチビューのカメラ画像（Vision-only Input）からBird’s Eye View（BEV）特徴 𝐵が生成されます。このBEV特徴を共通の土台として、「Perception（認識）」「Prediction（予測）」「Planning（経路計画）」の3つのフェーズを順次処理しているのがUniADの特徴です。

  • Backbone
    • 入力：複数視点のカメラ画像
    • 出力：BEV表現の特徴マップB

以降のステージでは、Transformerベースのモジュール（～Former）を用いて、オブジェクトや地図、将来予測に関連する クエリ (Query) を投げかけ、それに対するキー・バリュー (Key, Value) を𝐵他モジュールから受け取りながら、それぞれのタスクに最適化された表現を学習します。

3.3 Perception（認識）ステージ

図中央の「Perception」部分には TrackFormer と MapFormer の2つが並んでいます。

① TrackFormer

  • Track Q（動的物体を検出・追跡するためのクエリ）を用いて、BEV特徴 𝐵 からエージェント（車両・歩行者等）の位置や動きを推定します。
  • 出力として、各オブジェクト（エージェント）の特徴ベクトル (𝐾,𝑉) を得るほか、「Ego-vehicle Query」（自車の状態を把握するためのクエリ）も活用します。

② MapFormer

  • Map Q（地図情報を抽出するためのクエリ）を用いて、道路構造や車線情報など静的なマップ要素をBEV空間上でセグメンテーションします。
  • 出力として、地図（道路・交差点・車線等）のトポロジーを表す特徴ベクトル (𝐾,𝑉) を得ます。

このように、動的要素（物体検出） と 静的要素（マップ情報） を同じBEV特徴 𝐵 上で抽出することで、タスク間の情報共有がスムーズになり、互いに助け合う形で精度向上が期待できます。

3.4 Prediction（予測）ステージ

最終的なステージが「Planner」で、Predictionフェーズから受け取ったシーン情報（エージェントの将来姿勢、車線・交差点の形状変化など）を総合的に判断し、自車の経路（Trajectory） を出力します。

  • Planner
    • 「自車がどのルートをどのような加減速・ハンドル操作で走るか」を高次意思決定レベルで決定。
    • MotionFormer / OccFormer から得られる推定結果を参照し、衝突のない安全かつスムーズな軌道計画を実行する。

3.5 まとめとポイント

① 共通のBEV特徴 𝐵

  • マルチカメラ画像からまず BEV 特徴を抽出し、あらゆるモジュールがこの特徴を Key/Value として利用。
  • 2D画像座標系からの煩雑な変換を一度にまとめ、俯瞰視点での処理を標準化。

② Transformerモジュールの連携

  • TrackFormer / MapFormer / MotionFormer / OccFormer それぞれでクエリを発行し、動的物体・静的マップ・将来予測・シーン占有の多様な情報を段階的に取得。
  • モジュール間の情報（Queryと出力された Key, Value）は相互に参照可能。

③ マルチタスク一体型のフレームワーク

  • 従来は別々だった「検出」「地図」「将来予測」「計画」を一貫して扱う設計。
  • タスク同士が補完し合い、総合的な精度・効率の向上が期待できる。

UniAD は以上のように、Backbone → Perception → Prediction → Planning と段階を踏みながら、BEV ベース・クエリ駆動の Transformer モジュール群で多面的な情報を統合し、最終的に自車の経路決定までを包括的に行う革新的なアーキテクチャです。
このように、UniADはマルチタスクかつ時系列情報を活かしたフレームワークとして、自動運転の複雑なパイプラインを一元化しようとしています。

(補足)

  • 図の中で示されている「𝐵」「Track Q」「Map Q」「Motion Q」「Occ Q)」などは、それぞれが異なるレベルや目的のクエリ／特徴をやり取りしているイメージです。
  • 「Ego-vehicle Query」は自車の位置・状態を捉えるための特別なクエリを指し、最終的なプランニングにつながる重要要素です。

4.各モジュールの詳細

改めて図を記載。

引用元：GitHub:UniAD

4.1 カメラ画像の BEV 変換（Backbone 部分）

UniAD の入力は基本的に複数カメラ（マルチビュー）の画像のみです（LiDAR 等は想定していないケースが多い） 。これら 2D 画像をBird’s Eye View (BEV) に投影する段階を「Backbone」と呼んでいます。

① BEV 特徴マップ 𝐵 の生成

  • マルチカメラ画像から深度推定や Transformer 機構などを駆使して、真上視点での 2D 特徴マップ（BEV 空間）を構築します。
  • 具体的には、「Lift-Splat-Shoot」系統の手法や、BEVFormer のように視点変換を行う Transformer、あるいはBEVDepth における画素単位の深度スーパービジョンなどの発想が取り入れられており、それらの要素を組み合わせて精度を高めています。

② 他の類似手法 (BEVFormer / BEVerse) との比較

  • BEVFormer: カメラ特徴から BEV を生成する際に「視点変換用のクエリ」を設計し、時系列フレームの情報も含めて Transformer で統合する。
  • BEVerse: BEVFormer にさらに地図セグメンテーションや将来予測を組み合わせ、マルチタスクを実現したフレームワーク。
  • UniAD: BEVFormer/BEVerse などのバックボーン要素を取り込みつつ、その後段に「TrackFormer」「MapFormer」「MotionFormer」「OccFormer」「Planner」というモジュールを連ねることで、一層多面的なタスク（検出・マップ推定・将来予測・経路計画）をカバーしている。

ここまでで得られる BEV 特徴マップ 𝐵 は、以降の全モジュールで共通の「Key/Value 情報源」として利用されます。1回の変換で済ませることで、3D空間処理を効率化できるのが大きな利点です。

4.2 TrackFormer（Perception: 動的オブジェクト認識）

図中の “Perception” 領域のうち、水色の枠で示された「TrackFormer」は、動的オブジェクト（他車両や歩行者）を検出・追跡するモジュールです。

① Track Q（クエリ）

  • 物体検出用に、クエリとして {Track Q} を定義し、BEV 特徴 𝐵 から該当領域の Key / Value を取得。
  • Transformer の自己注意・相互注意機構によって、どのグリッドが車両・歩行者などの動的エージェントを含むかを学習します。

② Ego-vehicle Query（自車クエリ）

  • 自車の状態（姿勢や動き）を把握する専用のクエリ。自車を明示的に捉えることで、将来予測や経路計画の土台になる座標系を安定させる役割も担います。

③ モジュール出力

  • 検出された物体ごとに特徴ベクトル (K,V) が生成されるほか、位置や速度推定等を内部で保持。
  • 追跡 (Tracking) の要素：フレーム間で同じオブジェクトを紐づけ、動きの連続を捉える。
BEVFormer / BEVerse との比較
  • BEVFormer も 3D 物体検出を扱いますが、追跡 (Tracking) は主目的に含まれていません。
  • BEVerse は同じく物体検出 + BEV セグメンテーションを同時に行いますが、こちらもトラッキングを明確には扱わない場合があります。
  • UniAD の TrackFormer は、検出 + トラッキング を一貫して BEV 空間で行う点が一つの特徴です。

4.3 MapFormer（Perception: 静的マップ認識）

同じく “Perception” 領域のうち、紫色の枠で示された「MapFormer」は、地図情報（道路形状、レーン、交差点などのセマンティック情報） を推定するためのモジュールです。

① Map Q（クエリ）

  • BEV 空間上で「どこが道路で、どこが歩道か」などを区別するためのクエリ。
  • BEV 特徴 𝐵 に注意 (Attention) を適用し、セマンティクマップを構築します。

② モジュール出力

  • 車線境界や交差点形状などをピクセル単位、あるいはベクトル形式で推定。
  • 結果として、マップ要素ごとの Key / Value ベクトル (K,V) を生成し、後段モジュール（MotionFormer / OccFormer など）に地図コンテキストを提供。
BEVFormer / BEVerse との比較
  • BEVerse は車線やドライブ可能領域の BEV セグメンテーションを実装しており、MapFormer と同様のタスク（静的マップ予測）をカバー。
  • UniAD ではそれをさらに独立した Transformer モジュールとして明確に分け、後段の将来予測や経路計画と絡めやすい設計になっています。

4.4 MotionFormer（Prediction: エージェント別の将来予測）

図の「Prediction」フェーズの緑色枠「MotionFormer」は、検出・追跡された各エージェント（車両・歩行者など）の将来軌道を予測するモジュールです。

① Motion Q（クエリ）

  • 「オブジェクトが将来的にどのように動くか」を尋ねるためのクエリ。
  • TrackFormer から得たエージェント特徴と BEV 特徴 𝐵 を組み合わせ、時系列情報を考慮しながら各物体の未来位置や速度を推定。

② エージェントレベル特徴

  • 出力として、車両Aは2秒後にこの辺りへ進む…といった軌道情報を保持し、ベクトル化して提供。
  • 自動運転においては、他車の進路を予測することで衝突回避や優先制御などに繋がる。
BEVFormer / BEVerse との比較
  • BEVFormer 単独では将来予測の機能はオプション的で、メインは検出とトラッキング。
  • BEVerse は将来予測（Future Prediction）も扱いますが、MotionFormer のように明確な専用モジュールで区切られてはいない。
  • UniAD は「物体検出 + トラッキング + 予測」を完全に一連のフローとしてデザインしている点で、より総合的。

4.5 OccFormer（Prediction: シーン全体の占有予測）

同じ「Prediction」フェーズには、茶色枠の「OccFormer」が存在します。これはScene-level Feature を扱い、交差点や道路全体の占有状況（Occupancy）を把握する役割を担います。

① Occ Q（クエリ）

  • シーン全体の空間配置や混雑状況を尋ねるクエリ。
  • MapFormer や MotionFormer の結果、ならびに BEV 特徴 𝐵 を参照し、道路上の空き具合や潜在的な衝突領域などを広域に判断します。

② モジュール出力

  • シーン全体を俯瞰した上で「この交差点のこの車線は、将来的に混雑する / 通行困難になる」などの推定を行い、結果をPlannerにフィード。
  • 「Agent-level ではなく、Scene-level で将来を見通す」機能を強化しているのが特徴です。
他の手法との差別化
  • 多くの BEV ベース手法で行われるのは物体検出 or 地図推定 or 予測が中心で、シーン全体を Occupancy Map として予測する機能は別途モジュール化されることが多い。
  • UniAD の OccFormer は、それらを同一フレームワークで完結させる点で、より広域な理解を目指しているといえます。

4.6 Planner（Planning: 自車の経路決定）

図の最右端「Planner」は、自車がどのように走行するかを最終的に決定するステージです。

  • Planner
    • MotionFormer / OccFormer からの情報（他車の将来軌道やシーンレベルの占有予測）を参考にしながら、自車クエリ（Ego-vehicle Query）の状態を更新し、衝突回避や目的地へ向かう進路を計画。
    • ユニファイドモデルで計画まで含める手法は比較的珍しく、実自動運転システムにおいてはここが大きなアドバンテージになると期待されています。
BEVFormer / BEVerse 等との比較
  • 多くの BEV 手法は**知覚（Perception）や予測（Prediction）**までで止まり、**経路計画（Planning）**は別の制御モジュールに任せることが多い。
  • UniAD は「検出・地図・予測・プランニング」を一貫して行うため、従来のパイプラインのように複数モデルを組み合わせる必要がない。
  • ただし、実際に物理的な制御（アクセル・ブレーキ・ステアリング指令）に落とし込むにはさらに外部モジュールが必要な場合もあり、UniAD は高レベルの経路計画までを主に担当すると見るべきでしょう。

4.6 まとめとポイント

  1. TrackFormer (動的オブジェクト) と MapFormer (静的マップ) は Perception ステージで、物体検出＋トラッキング および 道路地図の推定 を担当。
  2. MotionFormer (エージェント別予測) と OccFormer (シーン全体予測) は Prediction ステージで、局所的・広域的な将来予測を担う。
  3. Planner は最終的に自車の経路を算出し、Unified Autonomous Driving を完成させる。

他の BEV ベース手法（BEVFormer/BEVerse 等）と比較すると、UniAD は最初から最後までワンパイプラインでつなげている点が最大の違いです。各モジュールが Transformer ベースで Key/Value をやり取りする形を取るため、タスク間の情報交換がスムーズで、マルチタスク学習による相乗効果を狙いやすい構造となっています。

5.主要な数式・損失関数

改めて図を記載。

引用元：GitHub:UniAD

UniADは大きく「Backbone（BEVEncoder）→Perception（TrackFormer、MapFormer）→Prediction（MotionFormer、OccFormer）→Planner」の流れを取りつつ、最終的なタスク（マルチオブジェクト追跡、マップ予測、将来軌道予測、シーン占有予測、経路計画）をすべて一貫して学習させます。

5.1 総合的な学習フロー

学習は2段階で行います。

  1. Step 1: TrackFormer + MapFormer のみ学習

    • ここではBackbone（BEVFormer）の重みの一部（image backboneやBEV encoder）を固定しつつ、オブジェクト検出・追跡とマップ推定を最適化。
    • 損失関数は主に「TrackFormer損失 + MapFormer損失の合算」。

  2. Step 2: すべてのモジュール（TrackFormer + MapFormer + MotionFormer + OccFormer + Planner）を合わせて学習

    • Step 1で学習したTrackFormerやMapFormerを初期化として使い、さらにMotion / Occ / Plannerを含めた多タスク損失で全体を最適化。
    • ただしBackboneの一部重み（BEV encoderなど）は引き続き固定する設定。

このように、段階的に学習することで安定性を確保しながらエンド・ツー・エンドの統合モデルに到達します。

5.2 TrackFormerの損失: \mathcal{L}_{\text{track}}

TrackFormer は複数物体の検出およびトラッキング (MOTRなどを踏襲) を行うモジュールです。

  • ハンガリアンマッチング (DETR系) により「クエリ」と「GTオブジェクト」を最適対応付け。
\mathcal{L}_{\mathrm{track}} = \lambda_{\mathrm{cls}} \,\mathcal{L}_{\mathrm{cls}} + \lambda_{\mathrm{box}} \,\mathcal{L}_{\mathrm{box}} \quad (\text{Hungarian Loss})

​

  • 分類損失(\mathcal{L}_{\text{cls}}): Focal Loss, あるいは Cross Entropy
  • バウンディングボックス損失(\mathcal{L}_{\text{box}}): L1 or Smooth L1 or IoU/GIoU
  • 実装例: \mathcal{λ}_{\text{cls}} =0.25, \mathcal{λ}_{\text{box}} =2.0 など

トラッキングに関しては、MOTRの仕組みにより「前フレームとマッチングしたクエリ」を次フレームに継承する形でIDを維持するため、追跡用のID損失が明示的に加わるというより、検出クエリと追跡クエリのハンガリアンマッチですべてを一貫して処理します。

5.3 MapFormerの損失: \mathcal{L}_{\text{map}}

MapFormer はBEV上の地図要素（車線、横断歩道、分離帯、走行可能領域など）を推定し、「things」と「stuff」に分割されたPanoptic Segmentationのようなタスクを実行します。

  • 分類損失: Focal Loss など（インスタンス存在判定）
  • 位置回帰損失: L1 や IoU、GIoUなど（インスタンス形状 or バウンディングボックス表現）
  • セグメンテーション損失: GIoU Loss、Dice Lossなど

最終的に、MapFormerの総損失は複数の要素を加重和で合算:

\mathcal{L}_{\mathrm{map}} = \lambda_{\mathrm{cls}} \,\mathcal{L}_{\mathrm{cls}} + \lambda_{\mathrm{seg}} \,\mathcal{L}_{\mathrm{seg}} + \cdots

5.4 MotionFormerの損失: \mathcal{L}_{\text{motion}}

MotionFormer はエージェントごとの将来軌道 (Trajectory) をマルチモーダルに予測するモジュールです。

  • Multipath / Multipath++ 系の確率的アプローチを踏襲し、複数の将来軌道（モード）を混合ガウスモデルなどで表現。
  • スピーカーデックでは「classification score loss + negative log-likelihood loss」というMultipath Lossを採用。
  1. モード選択の分類損失
    • 複数の候補軌道 (K=6 等) のうち、どのモードが正解に近いかを学習
  2. 確率的分布に対するNLL
    • それぞれのモードが2次元正規分布(\mu_x, \mu_y, \sigma_x, \sigma_y, \rho)を持ち、それがGT軌道をどれだけ尤度高く生成できるかを評価
\mathcal{L}_{\mathrm{motion}} = \underbrace{\mathcal{L}_{\mathrm{cls}}}_{\text{候補モードのスコア}} + \underbrace{\mathcal{L}_{\mathrm{nll}}}_{\text{ガウス分布による軌道尤度}}

また、GTの軌跡はトレーラーなど急カーブでも物理的に矛盾がないよう、非線形最適化でスムージングした上で学習に用いる。

5.5 OccFormerの損失: \mathcal{L}_{\text{occ}}

OccFormer はシーン全体の占有 (Occupancy) を時系列で推定するモジュールです。

  • 「Binary Cross Entropy (BCE) + Dice Loss」を組み合わせる手法が紹介します。
  • インスタンス単位で「どのグリッドがいつ占有されるか」を予測し、将来の交差点混雑や障害物分布を把握する。

たとえば、

\mathcal{L}_{\mathrm{occ}} = \lambda_{\mathrm{bce}} \,\mathcal{L}_{\mathrm{BCE}} + \lambda_{\mathrm{dice}} \,\mathcal{L}_{\mathrm{dice}}

占有フラグと実際の占有状況を比較しつつ、Dice Lossでクラス不均衡への対処も行います。

5.6 Plannerの損失: \mathcal{L}_{\text{plan}}

Planner は最終的に自車の将来軌道 (WayPoints) を出力し、衝突回避などを考慮します。
次の2成分を紹介します。

  1. Imitation Loss
    • 教師データ（模倣対象）となる自車軌跡 \tau_{\mathrm{expert}} と、モデルが出力する軌跡 \hat{\tau}との L2 誤差
\mathcal{L}_{\mathrm{imit}} = \sum_{t} \left\| \hat{\tau}_t - \tau_{t}^{\mathrm{expert}} \right\|^2
  1. Collision Loss
  • OccFormerが予測した他車や障害物の占有領域と、自車Boxの干渉を抑制する項
  • \hat{\tau} が衝突領域（占有セル）に近づかないようペナルティを与える

$、
\mathcal{L}{\mathrm{collision}} = \omega \cdot \sum{\text{near } (x, y)} \mathcal{F}\bigl(\mathrm{IoU}(\hat{\tau}, \mathrm{Occ}_t)\bigr)
\quad (\text{IoU等を用いた衝突距離の評価})
$$

以上をまとめると、

\mathcal{L}_{\mathrm{plan}} = \mathcal{L}_{\mathrm{imit}} + \lambda_{\mathrm{coll}} \, \mathcal{L}_{\mathrm{collision}}

ここで \mathcal{λ}_{\text{coll}} は衝突回避をどれほど重視するかを決定する重みです。

5.7 総合的なマルチタスク損失

最終的に、UniADは下記のような形で全タスクの損失を合算し、2段階学習を経てモデルを最適化します。

\mathcal{L}_{\mathrm{total}} = \lambda_{\mathrm{track}}\,\mathcal{L}_{\mathrm{track}} + \lambda_{\mathrm{map}}\,\mathcal{L}_{\mathrm{map}} + \lambda_{\mathrm{motion}}\,\mathcal{L}_{\mathrm{motion}} + \lambda_{\mathrm{occ}}\,\mathcal{L}_{\mathrm{occ}} + \lambda_{\mathrm{plan}}\,\mathcal{L}_{\mathrm{plan}}
  • Step 1 では \mathcal{L}_{\text{track}} と \mathcal{L}_{\text{map}} だけを主に使い、Backboneを凍結しつつオブジェクト検出/トラッキングとマップ予測を学習。
  • Step 2 では \mathcal{L}_{\text{motion}}、\mathcal{L}_{\text{occ}}、\mathcal{L}_{\text{plan}} も加わり、さらに追加のFine-tuningを行う。

このように各モジュールの出力を相互利用しながら、自動運転に必要なPerception + Prediction + Planningを一貫して最適化するのがUniADの要点です。各タスクの出力（例: TrackFormerの検出結果、OccFormerの占有マップなど）が誤差を減らし合い、最終的にPlannerの精度・安全性を高める設計になっています。

5.8 まとめ

  1. TrackFormer: ハンガリアンマッチングを利用した物体検出・追跡損失 (Focal + BBox など)。
  2. MapFormer: Panoptic Segmentation的な損失 (Focal + GIoU + Dice など) でBEVマップを推定。
  3. MotionFormer: Multipath系の確率的予測 (分類 + NLL) による多モード軌道学習。
  4. OccFormer: Occupancy予測のBCE + Dice損失により周囲のシーン占有を推定。
  5. Planner: 模倣学習 (L2) + 衝突回避 (Collision Loss) を組み合わせて自車経路を計画。

これらを段階的学習しながら最後はエンド・ツー・エンドでチューニングすることで、UniADは「統合された自動運転モデル」として多様なタスクを高精度にこなせるようにデザインされています。

6.実験・評価方法

6.1 評価対象データセット：nuScenes

  • UniADの性能評価は nuScenes ベンチマークに基づいて行われています。
  • nuScenesは、複数センサ（カメラ、LiDAR、GPS/IMU）と高密度なアノテーションを持つ大規模な自動運転用データセットであり、Perception・Prediction・Planning 各タスクに対して総合的な評価が可能です。

6.2 評価項目とモジュール別指標

モジュール 評価タスク 評価指標例
TrackFormer 多物体トラッキング sAMOTA, MOTA, MOTARなど
MapFormer 高精度なBEV地図推定 IoU, panoptic qualityなど
MotionFormer 将来軌道予測（多モーダル） minADE (平均誤差), minFDE (最終点誤差)
OccFormer Occupancy（占有）予測 IoU（インスタンス単位、時刻tごと）
Planner Waypoint計画の精度および安全性 imitation loss, collision rate, goal success rate

6.3 学習設定

  • 段階的学習（2ステージ）：
    • Step 1：TrackFormer + MapFormer のみを6エポック学習
      • Backbone（BEVFormer）の Image Encoder は固定
    • Step 2：MotionFormer / OccFormer / Planner を加えて20エポック学習
      • BEV Encoder も固定のまま

6.4 評価結果のサマリ

  • 全体結果の比較：NaiveなE2E法や別々のMulti-taskヘッドよりも、UniADの統合アーキテクチャが優れていると報告​
  • 特に次のような相乗効果が確認されています
    • Perception（検出・地図）とPrediction（将来予測）の相互補完
      • TrackingとMappingの両方を組み合わせることで将来軌道予測の精度が向上
    • Prediction（Motion & Occupancy）の両立による改善
      • 単独予測よりも、両者を組み合わせた予測の方がPlanningに有利

6.5 Ablation Study（アブレーション分析）

UniADの性能改善に寄与する要素を分析するため、以下のアブレーションが行われました。

評価観点 結果・効果
Collision Loss の有無 模倣学習（L2誤差）のみではなく、衝突回避項を加えることで安全性が向上
Occupancy Guided Attention Mask 特に近傍の精度が向上。マスク特徴を使った方がagent featureよりも良好
Scene-level Anchor の導入 Scene-centered な予測が効果的。エージェント中心よりも安定した予測が得られる
非線形最適化の有無 曲率や加速度制約を加えることで、より現実的な軌跡に近づけられる

6.6 可視化による定性的評価

  • クリティカルな場面（カットイン、障害物回避など） における軌道選択が直感的に「賢い」動作に見える。
  • OccupancyやMotionの予測が失敗しても、後段のPlannerで補正可能な構造となっており、モジュール間の冗長性と回復力がある。

6.7 まとめ：UniAD評価のポイント

  • UniADは「各モジュールの精度最大化」よりも、「最終的なPlanning品質の最適化」を目的に設計されています。
  • その結果、モジュール単体のスコアがSOTAより低くても、Planning全体ではより優れた性能を達成している点が特筆されます。
  • LiDARベースの手法すら上回るケースもあり、カメラ中心のアプローチの可能性を示す成果となっています

7.今後の展望まとめ

7.1 UniADの成果の総括

UniADは、従来の自動運転フレームワークとは一線を画す、Planning志向のE2E統合アーキテクチャを実現しました。
Perception、Prediction、Planning の各モジュールを単に接続するのではなく、最終出力である行動計画の質を最大化するためにモジュール間の相互最適化を目指した点が新規性です。

  • nuScenesベンチマークでは、一貫性のある優れた性能を記録。
  • Perception単体の精度を追うのではなく、行動計画の妥当性・安全性に主眼を置く。
  • Camera-only構成でありながら、LiDARベース手法を一部上回る性能を実現。

7.2 現時点での限界と課題

  • 非自明な学習の難しさ

    • 多数のモジュールを同時に最適化することは non-trivial（容易ではない） であり、
      • 学習が不安定になる可能性あり。
      • 収束までに 大規模な計算資源が必要になる。

  • モデルの計算コスト・軽量化

    • 現時点のUniADは高精度だが、
      • 実際の自動運転車へのリアルタイムデプロイには重量すぎる可能性がある。
      • TransformerベースのDecoder群による遅延が課題。

  • タスク拡張性

    • 現在は Tracking・Mapping・Motion Prediction・Occupancy・Planning に特化。
    • 今後は以下のようなタスク拡張が想定される
      • 深度推定（Depth Estimation）
      • 行動予測（Intention Prediction）
      • V2X通信との統合、外部ナビゲーション信号の活用　など

7.3 今後の研究方向性

課題領域 展望
軽量化・高速化 Transformer構造の改良（例：Performer系、低解像度処理との組み合わせ）
センサーフュージョン BEVFusionなどの知見を取り入れ、LiDAR + Cameraの統合へ拡張
自己教師あり学習 ラベル不足問題の解消、事前学習の強化によるデータ効率の改善
シナリオ対応力強化 夜間・悪天候・障害物の多いシーンにおける頑健性評価・強化
アブレーション分析の深化 モジュール間の依存度や相互補完性を理論的に解析・定量化するフレーム設計

Discussion