【2025年度も継続中！誰でも自由に追記OK】自動運転AI+その他関連してそうならなんでもOK Advent Calendar 2024

ちゅらデータ株式会社

VLMで自動運転やってみた #2

自動運転AIチャレンジ

Last updated at 2025-11-23Posted at 2025-11-22

はじめに

Vision-Language Model (VLM) を活用した自動運転システムの開発は、個人的に注目している技術領域のひとつです。

以前、自動運転AIチャレンジ環境を使用して、入力画像から車両制御指令値を直接生成するVLM Controllerの構築に挑戦していました。

今回は視点を変え、VLM Planner に挑戦してみます。
このPlannerは自動運転でいうところの「認知〜判断」を担うモジュールで、画像や指示をもとに「次に取るべき軌跡 (Trajectory)」を出力する役割を担当します。

まず手始めに、今年の自動運転AIチャレンジで提供された「AI教材」のVLM Plannerを動かしつつ、Gemini Roboticsの最新モデルや俯瞰画像 (Bird’s Eye View, BEV) 変換を組み合わせて既存モデルと比較してみました。

先に結論を書いておきます。

gemini-robotics-er-1.5-preview + BEV変換で画像上は妥当なTrajectoryが引けそうですが、安定した走行までは実現できていません。
コードはすべて公開しています。課題山積ですので、Let's チャレンジ。

自動運転AIチャレンジにおける「AI教材」の再構築

今年の自動運転AIチャレンジで提供された「AI教材」は、VLM PlannerとAutowareのControllerが連携し、シミュレーション環境で動作する仕組みとなっており、非常に素晴らしい構成でした。天才！すごい！去年私が諦めたやつ！

しかしながら、公式教材はファイルダウンロードや依存関係が少し煩雑に感じられたため、今回は自動運転AIチャレンジ2025開発環境に統合し、より簡単にまとめて動かせるように再構築しました。

※ 公式教材のように、最新のAutoware docker imageを使うことで autoware_tensorrt_vad (VAD for trajectory planning) を始めとする最新パッケージを使えるため、AIチャレンジ開発環境と分離している意図は非常に理解できました。ただ今回は使いやすいようにVLM Plannerだけまとめてしまいました。Yablocも「AI教材」の構成で動かせた可能性があるな…と思いました。

まとめたコードは、以下のGitHubブランチに置いてあります。

【ブランチ全体】

【vlm_planner】

【vlm_trajectory_selector】

開発環境のセットアップ手順

簡単に使用手順をまとめます。

① リポジトリのクローンとブランチの切り替え

Terminal 1

git clone https://github.com/soyaoki/aichallenge-2025
cd aichallenge-2025
git switch e2e-test/feat/gemini-robotics-er-1.5

Terminal 1

git clone -b e2e-test/feat/gemini-robotics-er-1.5 https://github.com/soyaoki/aichallenge-2025
cd aichallenge-2025

② 開発環境コンテナの起動 (ターミナルを2つ用意)

Terminal 1

./docker_run.sh dev gpu

Terminal 2

./docker_run.sh dev gpu

③ Terminal 1でAWSIM / Autowareを起動

Terminal 1 (AIC_DEV)

./build_autoware.bash
./run_evaluation.bash

④ Terminal 2でAPIキーを設定

Terminal 2 (AIC_DEV)

cd /aichallenge/workspace/src/aichallenge_submit/vlm_planner
cp .env.sample .env
# .envファイルを開き、GEMINI_API_KEYを編集してAPIキーを追加します。

⑤ Terminal 2でVLM Plannerを起動

Terminal 2 (AIC_DEV)

source setup_vlm_planner.bash
source run_vlm_planner.bash

※ きちんとROSのパッケージにして、rosdep / launch / params.yamlあたりを導入したいですね…すみませんできてないです…

README.mdを更新してありますので併せてご確認いただけますと幸いです。なお不要な依存関係やイメージダウンロードは削除して各種セットアップは数分で終わるようにしています。

※ 最近はaptでもAutowareのROSメッセージなどがインストールできるようになり、非常に便利になりました。

sudo apt install ros-humble-autoware-internal-planning-msgs

VLMモデルの変更

上記の「AI教材」ではgemini-2.5-flash-liteが採用されていますが完走は難しいようです。そこで、最近登場したロボティクス向けの特化モデルである Gemini Robotics (gemini-robotics-er-1.5-preview) へ切り替えて走行に挑戦します。

Gemini Roboticsとは？

2025年3月に発表された、ロボット工学向けに設計されたGemini 2.0ベースのモデルです。

Gemini Robotics models allow robots of any shape and size to perceive, reason, use tools and interact with humans. They can solve a wide range of complex real-world tasks – even those they haven’t been trained to complete.

このGemini Roboticsの推論能力を強化したものが、Gemini Robotics-ERです。

ERは "Embodied Reasoning" の略です

Vision-Language-Action Model (VLA) の側面を持ちながらも公式ドキュメントでは、VLM (Vision-Language Model) と定義されています

Gemini Robotics-ER 1.5 is a vision-language model (VLM) that brings Gemini's agentic capabilities to robotics.

今回試したgemini-robotics-er-1.5-previewには、ロボットの動作経路を時系列データとして出力する Trajectory出力例がドキュメントで公開されており、このTrajectory生成能力を自動運転に応用するという発想です

利用条件

ERはFreeプランでも使うことができます。

項目	詳細
モデル名	gemini-robotics-er-1.5-preview
料金	Freeプランでも利用可能
レートリミット	10 リクエスト/分, 250 リクエスト/日 (やや厳しめ)

参考

日本語記事はこちら。

VLMモデルの比較実験

早速 gemini-robotics-er-1.5-preview を試してみます。

.envファイル内のGEMINI_MODEL_NAMEを以下のように変更するだけで、既存のAI教材のコード (古いSDK google-generativeaiを使用) でも動作することが確認できました。

.env

-) GEMINI_MODEL_NAME=gemini-2.5-flash-lite
+) GEMINI_MODEL_NAME=gemini-robotics-er-1.5-preview

※ ちなみに古いSDKgoogle-generativeaiは2025年11月31日でサポートが終了するため、将来的にはgoogle-genaiへの移行が必要です。

前方画像 → Trajectory(自車座標系のXY)

AI教材は、前方画像に加えて、トラック知識、過去の履歴、セクター、車速などをインプットとして、自車座標系のXYで構成されるTrajectory Pointsを出力するE2Eの仕組みです。まずはこのやり方でモデルを比較します。

gemini-2.5-flash-lite

初期速度velocity = 5.0が継続され、すぐに壁に激突してしまいました。推論時間は約5秒でした。

※ 現在Rviz上でMapが描画されておらず、Trajectoryの妥当性を定性的に判断できない状態です。（今後のTODO）

gemini-robotics-er-1.5-preview

期待のGemini Roboticsですが、こちらはvelocity = 0.5のままで、そもそも発進できませんでした。

velocityを2倍に調整すると発進はしましたが、カーブを曲がりきれずに壁に激突してしまいます。また、1回の推論に約20秒かかりました。Reasoning系なので推論時間は増加します。

前方画像 → Trajectory(画像上のXY)

前方画像から直接、深度情報が必要な自車座標系XYを出力するのはハードルが高い可能性があるため、まずは画像上でTrajectoryを出力できるかを確認しました。
※ ただ画像上でTrajectoryが引けても、自車座標系XYへの変換が必要なので注意。

gemini-2.5-flash-lite

期待通りの出力が得られませんでした。明らかに不自然なTrajectoryであり、画像の渡し方や後処理に問題があるかもしれません。

gemini-robotics-er-1.5-preview

こちらも不自然な結果となりました。画像内で大きく上下する、意図しないTrajectoryが出力されています。

BEV変換した前方画像 → Trajectory(画像上のXY)

gemini-robotics-er-1.5-previewのドキュメント例には俯瞰画像が多く見られたため、「入力は、モデルが学習しているデータの分布に合わせるべきではないか？」という仮説のもと、BEV (Bird's Eye View) 変換の前処理を試しました。

gemini-2.5-flash-lite

BEV画像を与えても、Trajectoryは引き続き不自然なままでした。

gemini-robotics-er-1.5-preview

お？

画像上で車線に沿った、比較的妥当性の高いTrajectoryが出力されました。
この結果から、「モデルが学習しているデータ分布」に合わせた入力 (俯瞰画像) が重要であるという示唆が得られました。
ただし、俯瞰画像上でTrajectoryが引けたとしても、それを実際の走行に利用するためには自車座標系XYへの正確な変換が必要であり、この点も今後の大きな課題となります。

おわりに

ロボティクス向けのGeminiである gemini-robotics-er-1.5-preview のVLM Planner適用を試みました。

前方カメラ画像そのままの入力では走行が困難でしたが、画像を俯瞰画像に変換して入力することで、モデルからのTrajectory出力が比較的妥当になることが確認できました (E2Eではなくなってしまいましたが…) 。

今後のTODO

まだまだ課題がたくさんあります、Let's チャレンジ。

Rviz連携の強化: Rviz上でmapとTrajectoryの表示を実装し、出力の妥当性を定性的に確認可能にする
座標変換の実装: VLM PlannerのNodeに、(1)BEV変換と(2)画像上のTrajectory → 自車座標系Trajectoryへの変換ロジックを実装する
各種調整: システムプロンプトや入力データの調整を行い、安定した走行を可能にする
コード見直し: 出力が不自然なケースがあるため、画像入力や各種処理を見直す

この記事は、AI文章校正ツール「ちゅらいと」で校正されています。

おまけ