[CV勉強会@関東 ICCV2025] WoTE: End-to-End Driving with Online Trajectory Evaluation via BEV World Model

2025/11/16 関東CV勉強会の資料です。
End-to-end自動運転modelの出力を、走りながら世界モデルで評価する論文です。

参考link
- code: https://github.com/liyingyanUCAS/WoTE
- arxiv: https://arxiv.org/abs/2504.01941
- 関東CV勉強会: https://kantocv.connpass.com/event/373217/

Transcript

1. End-to-End Driving with Online Trajectory Evaluation via BEV World Model ICCV2025 code: https://github.com/liyingyanUCAS/WoTE arxiv: https://arxiv.org/abs/2504.01941 ※資料中の図表は断りのない限り上記論文から引用
2. 自己紹介 Shin • 趣味で自動運転関連技術を追っています • 自動運転用VLM Plannerの分野に興味があり， 自分なりの「こうすべきでは」という仮説作りが 最近のマイブームです ◦ この分野がどの程度有望そうなのか？・自分の仮説は正しそうなのか？ を調べている状態です • 自動運転に興味のある方は， 自動運転AIチャレンジが盛り上がっているので覗いてみてください！ ◦ 初学者向け資料などもあるので趣味でやりやすいかも？ Twitter: @AquaRobot0202
3. WoTE • World model to predict future BEV states for Trajectory Evaluation ◦ ML PlannerがTrajectoryを複数出力 ◦ Trajectoryに応じてWorld Modelで未来を予測 ◦ Rewardを予測し、Trajectoryを選択 今日紹介する論文: E2E自動運転モデルをWorld Modelで評価
4. [背景] E2E自動運転が注目され、目覚ましい発展を遂げている • Sensor data(e.g.画像)，ego status(過去のtrajectory), Commandからtrajectoryを直接生成する model • データから，交通ルールを遵守した行動，衝突回避のための行動を学習させる • 2023,2024年から, 学習ベースの Plannerを開発して公道走行する企業が増えてきている ◦ Tesla FSD v12 ◦ Turing TD-1 ◦ Wayve ICCV2023で発表されたVADもE2Eと呼ばれるモデルの一種 https://github.com/hustvl/VAD/blob/70bb364aa3f33316960da06053c0d168628f b15f/projects/mmdet3d_plugin/VAD/VAD.py#L380C49-L380C62
5. [背景] E2E自動運転が注目され、目覚ましい発展を遂げている https://x.com/Tesla/status/1989427425508561398?s=20 例: Tesla FSD v14 • 犬が飛び出してくるのを予測してSlow down • バイクが飛び出してくるのを予測してSlow down
6. [背景] しかし、ML based plannerを仕上げるのはそう簡単ではない • MLあるあるだが、データ量が少ない状態では、適切な挙動の実現が難しい ◦ データが少ない状態では、「横断歩道で減速」「横断歩道で待つ」といった挙動ができない場合がある • 学習できていない状況では適切な出力が出ないかもしれない ◦ 論文ではSoTA合戦だが...本気で製品化用ML Plannerをやっている企業では、こう した泥臭い問題に取組んでいる: 「横断歩道で止まる」 ▲ 日本の自動運転企業(Turingさん)の取り組み例 • 横断歩行者が稀な横断歩道では歩行者に反応しづらくなる ◦ 学習していない状況になると適切に対応できない https://www.youtube.com/watch?v=ZPQhv-QK_UQ https://www.youtube.com/watch?v=enXdOkxAVq • エキストラを追加してデータ増強 ◦ 学習データに充分に含まれた状況下だと適切に 対応できる
7. [背景] 未学習の状況では適切な出力が出ないかも: 対処方法-軌道生成後に適切さを判定 • 学習できていない状況では適切な出力が出ないかもしれない • 出力をいつでも信用できるわけではないので、 軌道生成後に軌道が適切かを判定するという対処方法が存在 https://github.com/orgs/autowarefoundation/discussions/5033 ◀ autowareにおける generator(経路生成) -selector(軌道評価・選択) のアーキテクチャ
8. https://arxiv.org/abs/2109.13602 どうやって判定？ • SafetyNet(ICRA 2022), woven ◦ Transformer based plannerでtrajectory生成 ◦ Trajectory Checkを行い、 fail判定ならnon ML basedにFallbackする • 判定方法 : ルールベース + prediction model使用 ◦ Dynamic feasibility ▪ 速度・加速度・ジャークが快適な範囲に収まっているか ◦ Legality ▪ 交通ルールを守っていなければ Infeasibleと判定 • Stop signの前で止まらない • right of way(通行権)のルールに違反 • 赤信号で進む • 走行可能エリア逸脱 ◦ Collision likelihood ▪ 他agentとの衝突可能性を検証 • prediction module使用 • overlap, longitudinal distance, time-to-collisionにより判定 [背景] ML based plannerには課題も存在: 対処方法-軌道生成後に適切さを判定
9. 本論文: World ModelでE2E自動運転モデルの出力軌道を評価・選択 WoTE: World model to predict future BEV states for Trajectory Evaluation • ML PlannerがTrajectoryを複数出力 • Trajectoryに応じて World Modelで未来予測 • 未来予測に応じてRewardを推定し、 Trajectoryを選択
10. WoTE: 手法の概要 • Trajectory生成 • World Modelで未来予測 • 未来予測に応じてReward を推定 • Rewardが最も高い Trajectoryを選択
11. Method: Trajectory Prediction 画像とLiDARから特徴抽出 • TransFuser based Encoder使用 • 画像は前方3枚使用 • BEV State取得 ◦ B (h, w, c) ◦ h=w=8程度 Trajectory Anchors • NAVSIMのtraining datasetをk-means • N個の軌道を取得 ◦ N=256 Trajectory Refinement • Trajectory Anchorsのoffsetを BEV Stateから推定 • Trajectory Encoder(MLP)で Anchorをembedding • N個から一番近い軌道を選び L1 loss使用(winner-take-all) Trajectory Encoder • N本のRefined Trajectoriesを MLPに入力 • N個のAction embedding取得
12. Method: Trajectory Prediction 画像とLiDARから特徴抽出 • TransFuser based Encoder使用 • 画像は前方3枚使用 • BEV State取得 ◦ B (h, w, c) https://arxiv.org/abs/2104.09224
13. Method: World Model 将来のBEV Stateとaction embeddingをWorld Modelで予測 • 再帰的に推論を行うことで複数step予測 ◦ 論文中では、4 sec先まで予測 ◦ 4 secを直接予測 / 0 -> 2 -> 4と2 secずつ予測で比較を実施 ▪ 0 -> 2 -> 4の方が性能が良かった
14. Method: World Modelの学習 • World Modelには教師が必要 ◦ しかし、datasetには単一の未来しか含まれていない • Simulatorを用いて学習 ◦ BEV空間のSemantic Map(HxWxL: Lはclass数)を教師とする • FocalLoss(CrossEntropyに1-confidenceをかけたもの)使用 ◦ 難しいpixelほど損失が大きくなる BEV State を • Upsampling • Transposed Conv により BEV Semantic Mapへdecode 教師データとのFocalLoss計算
15. Method: Reward Simulation reward シミュレータが定義した評価基準に基づいて評価 • No Collision ◦ 走行時dynamic objectに衝突したら0 ◦ static objectなら0.5 • Driving Area Compliance ◦ 走路から逸脱したら0 • Time-To-Collision ◦ 自車両が一定の速度と進行方向で前進した場合の 衝突までの時間が閾値を下回ると 0 Imitation reward Predicted trajectoryとexpertの差分で評価 • Comformatable ◦ acceleration, jerkが閾値以下なら1 • Ego Progress ◦ ルート中心線に沿った進行度
16. Method: Reward Model • 現在のBEV State, action • 予測した将来のBEV State, action から6種類のrewardを推定 Simulation reward • BCEを使用 Imitation reward • 距離に応じてGT reward計算, CE使用 ◦ 人の軌道に近いtrajectoryはreward大 と推定したい
17. WoTE: 手法の概要 • Trajectory生成 • World Modelで未来予測 • 未来予測に応じてReward を推定 • Rewardが最も高い Trajectoryを選択
18. WoTE: 評価結果
19. 評価(Closed-loop) UniAD, VADなどより走破率(Success Rate), Driving Scoreどちらも高い
20. 定性評価 上: 横断歩行者に危険が及ぶ trajectoryの抑制 • WoTE: 歩行者の進行方向と交差する trajectoryなし • TransFuser: 歩行者の進行方向と交差 するtrajectory生成 下: 道路を逸脱する trajectoryの抑制 • WoTE: 道路逸脱なし • TransFuser: 道路を逸脱する trajectory を生成 従来手法(TransFuser)より 安全なtrajectoryを生成 (個人的な感想) 高度な予測がいるほどの long-tailなケースではないような ...
21. Latency評価 Trajectory Anchorsの数を増やしてlatencyを評価
22. (補足) NVIDIA L20のスペック • 275W • CUDA core: 11,776 • VRAM: 48 GB • Base Clock: 1440 MHz (個人的な感想) サーバー用のGPUであり、 量産車両に挿せるかというと微妙。 実験車両なら使えそう
23. 結論: E2E Plannerを評価しながら走るやり方が増えるかも？long-tailへの対応もできるか？は未検証 • E2E Plannerの出力を走りながらWMで評価するという手法 • UniAD, VADなどより走破率(Success Rate), Driving Scoreどちらも高い • しかしながら評価結果の例は，特にlong-tail scenarioというわけではなかった • 走りながら評価するための推論速度評価も実施 ◦ 19ms @ NVIDIA L20
24. 結論: E2E Plannerを評価しながら走るやり方が増えるかも？long-tailへの対応もできるか？は未検証 • E2E Plannerの出力を走りながらWMで評価するという手法 • UniAD, VADなどより走破率(Success Rate), Driving Scoreどちらも高い • しかしながら評価結果の例は，特にlong-tail scenarioというわけではなかった • 走りながら評価するための推論速度評価も実施 ◦ 19ms @ NVIDIA L20 (個人的な感想) ML Plannerの出力は走りながら validationが必要, validationには予測が必要, 予測ならWMを 使うと良いのではという主張は素直だと思う (個人的な感想) ただし，Open Datasetにそこまでlong-tailを含むものがないという事情もありそう 後続手法は，以下のような datasetを使って評価できるかも Waymo-E2E: https://arxiv.org/abs/2510.26125 Nexar Dashcam Collision Prediction Dataset: https://arxiv.org/abs/2503.03848 (個人的な感想) 19msという時間自体は高速 . しかし、実験に使った GPU(NVIDIA L20)は車載には厳しそう
25. 補足slide
26. Anchors: k-means https://github.com/liyingyanUCAS/WoTE/blob/main/scripts/miscs/k_means_trajs.py trajectoryは4秒の長さ (個人的な感想) 4秒先の先読みで十分なのか？
27. 自動運転システムの評価方法 • Open-loop: 車両の行動に依存して次frameの自車両の状態が変化しない．log-replay. • Closed-loop: 車両の行動に依存して次frameの自車両の状態が変化 ◦ Agent non-reactive: 周囲の車が自車両に反応しない ◦ Agent reactive: 周囲の車が自車両に反応 こっちが右折してても 対向車は無視して突っ込んでくる ミスって急操舵になっても 次フレームではリセットできる ミスって急操舵になったら 次フレームにも影響 こっちの動きに相手が反応
28. 評価(Closed-loop, Non-Reactive)
29. NAVSIM: Data-Driven Non-Reactive Autonomous Vehicle Simulation and Benchmarking https://arxiv.org/abs/2406.15349 • nuPlanを使用した、Non-ReactiveなClosed-loop評価手法 • 4秒, 10Hzという短い期間で評価 ◦ nuPlan planning challenge 2023で一位になったPDMが 4秒のHorizonを採用しているため • LQRを使用して、steeringとaccelerationを計算 • kinematic bicycle modelにより自車両の状態を更新
30. NAVSIM: Data-Driven Non-Reactive Autonomous Vehicle Simulation and Benchmarking https://arxiv.org/abs/2406.15349 nuPlan planning challenge 2023で一位になったPDMが 4秒のHorizonを採用しているため
31. PDMでは計算負荷のため4 secondsとなっている https://arxiv.org/pdf/2306.07962 To circumvent computational demands in subsequent stages, the proposals have a reduced horizon of H steps, which corresponds to 4 seconds at a 10Hz. 後続の段階における計算負荷を回避するため、各 proposalの予測期間（ホ ライゾン）はHステップに短縮されており、これは 10Hzで4秒間に相当しま す。 (個人的な感想) PDMでは計算負荷の都合上 4秒のHorizonを使用。 これを踏まえて決まった NAVSIMの4秒間評価って本 当に妥当なのか？
32. https://arxiv.org/abs/2406.15349 NAVSIM: Data-Driven Non-Reactive Autonomous Vehicle Simulation and Benchmarking • nuPlanを2HzでsamplingしたOpenSceneを使用 ◦ 120hの運転データ • navtrain: 103k samples • navtest: 12k samples
33. PDMS: Predictive Driver Model Score NAVSIM: https://arxiv.org/pdf/2406.15349 • スコア同士の掛け算，足し算を行う ◦ 「penalty * scoreの和」という形式 • どれだけscoreが高くてもpenaltyが0ならだめ penality • No Collision ◦ 走行時dynamic objectに衝突したら0 ◦ static objectなら0.5 • Driving Area Compliance ◦ 走路から逸脱したら 0 weighted average • ego progress ◦ ルート中心線に沿った進 行度 • time-to-collision ◦ 自車両が一定の速度と進 行方向で前進した場合の 衝突までの時間が閾値を 下回ると0 • comfort ◦ ジャーク
34. https://arxiv.org/abs/2406.15349 NAVSIM: Data-Driven Non-Reactive Autonomous Vehicle Simulation and Benchmarking • 等速で走り続ける(Constant Vel)だ けで、PDMSは79%になる • 静止・等速のデータがDatasetには たくさん含まれる Filtering • 等速agentがPDMSは0.8を達成す るシーンは除去 • 人のtrajectoryがPDMS 0.8未満と なるシーンも除去
35. NAVSIM: LQR https://github.com/autonomousvisi on/navsim/blob/main/navsim/plan ning/simulation/planner/pdm_plan ner/simulation/batch_lqr.py
36. https://arxiv.org/abs/2406.03877 • シミュレータ(CARLA)を用いて，シナリオを実行して評価 • 成功率などを評価 Bench2Drive: Reactiveなclosed-loop評価 https://arxiv.org/abs/2406.03877
37. Bench2Drive: Reactiveなclosed-loop評価 https://arxiv.org/abs/2406.03877 • シミュレータ(CARLA)を用いて，シナリオを実行して評価 ◦ 全220 routes (各route 150m) • Success Rate ◦ 決められた時間内に、ルール違反なくゴールに到達したらsuccess • Driving Score ◦ ルート走破率(Route-Completion): 走破できた距離の% ◦ penalty: 違反に対応した罰則。重い違反ほど減少率も大きい
38. Bench2Drive: Reactiveなclosed-loop評価 https://arxiv.org/abs/2406.03877
39. Bench2DriveZoo https://github.com/Thinklab-SJTU/Bench2Drive Zoo/tree/uniad/vad/team_code https://github.com/Thinklab-SJTU/Bench2DriveZoo/t ree/tcp/admlp/team_code
40. TCP: Trajectory-guided Control Prediction for End-to-end Autonomous Driving: A Simple yet Strong Baseline https://arxiv.org/abs/2206.08129