はじめに
今年も自動運転AIチャレンジに参加させていただいております。
弊チームは一般クラス予選を5位で突破し、なんとか今年も決勝へ進出できました。私はほぼ活動できずでしたが、他チームメンバーがかなり頑張ってくれました…圧倒的感謝です。目下決勝に向けて最終調整を行っています。
※ 決勝は2025年10月25日-26日に開催されます、是非お越しください！
さて、私はほぼ活動できていないとはいえ、予選(7/1-9/1)期間中、今年から使用可能となった“前方カメラ”を使った施策を少しだけ検討していたので、取り組み内容をまとめておきます。
本記事はAutowareのビジョンベース自己位置推定手法YabLocを使ってみたい方向けの記事となります。
注意事項です。
- 実行には「自動運転AIチャレンジ2025 GPU環境有り開発環境」が必要
- 高精度な自己位置推定を実現するためには本記事内容に追加の調整が必要
- 2025年大会予選(シミュレータ)向けの内容で、決勝(実車)ではカメラ未整備で適用不可
昨年大会の課題、解決施策としての“YabLoc”
昨年の自動運転AIチャレンジ2024では、GNSS+IMUによる自己位置推定が課題の1つでした。各センサの遅延や精度不足により安定した走行が難しく、苦しんだチームもあったのではないでしょうか。はい、弊チームもそうでした。
そんな中、今年から前方カメラが使用可能となりました。GNSS+IMU “+Camera” による自己位置推定が実現できれば安定した自己位置推定が可能になるのではと考え(使える情報は全部使おう的な脳筋思考)、YabLocと呼ばれるAutowareに実装されているビジョンベースの自己位置推定手法を試してみました。
YabLocとは
YabLocは、Autowareで実装されている、ベクターマップ+ビジョンベースの自己位置推定手法です。以下が公式ドキュメントです。
画像から抽出した路面標示とベクターマップを照合することで位置を推定します。点群マップやLiDARは必要ありません。YabLocは、LiDARを搭載していない車両や点群マップが利用できない環境でも、位置特定を可能にします。
といったことが書かれています、アツいですね。
2025年開発環境における使用方法
2025年開発環境で使おうと思うと、そもそもYabLocが含まれていなかったため、以下を行いました。
- 最新AutowareバージョンからYabLocをマージ
- YabLocのインプットmsg型に合わせるための変換部を作成
最低限YabLocが動作可能なセッティングが以下となりますので、こちらをお使いください。
実行手順
実際の使い方ですが、2025年の環境構築がすべて完了した状態を前提として、以下を実行します。
git clone https://github.com/soyaoki/aichallenge-2025
cd ~/aichallenge-2025
git switch feat/yabloc
./docker_build.sh dev
./docker_run.sh dev gpu
開発環境に入ったのち、以下シェルスクリプトを実行すればセットアップが完了します。
(なお、ここで依存関係のインストールやモデルファイルのダウンロードを行うので、採点環境などオフライン環境ではエラーになる可能性があります、ご注意ください)
bash workspace/src/aichallenge_submit/yabloc/setup.bash
cd /aichallenge
./build_autoware.bash
./run_evaluation.bash
以下の画面になったらAWSIM右上「Use Image」ボタンをクリックし、カメラモードをONにします。
Optional: 処理の途中結果(画像)をモニタしたい場合は、rqt viewerもインストール・起動しておきましょう。
cd ~/aichallenge-2025
./docker_run.sh dev gpu
sudo apt update
sudo apt install ros-humble-rqt-image-view -y
ros2 run rqt_image_view rqt_image_view
or
sudo apt update
sudo apt install ros-humble-rqt-image-view -y
rqt
実行結果
以下2パターンでまとめます。
- YabLocでの自己位置推定のみ (車両制御は他信号でのEKF自己位置推定を使用)
- YabLocでの自己位置推定 → 車両制御
※ なお以下のmoyashiiさんの記事にもあるように、/vehicle/status/velocity_statusのlongitudinal_velocityが停止時でも+0.5 [m/s]ほどオフセットしているためこれを除去しています。オフセットがあるとパーティクルが前方へオフセットしてしまい、自己位置推定結果にズレが発生してしまいました。
1. YabLocでの自己位置推定のみ
以下に自己位置推定をまとめます。
画面左は、YabLocの途中画像処理結果です。
画面右は、主に上記画像処理による自己位置推定結果を表示しており、点々が自己位置推定結果(パーティクル)と、色が信頼度を表しています。まれに表示される赤線分は画像で検出した道路エッジとなり、赤線分とベクターマップ(白線)のマッチングを行って自己位置を補完してくれると理解しています(若干そのような結果にはなっていなさそうなのですが…)。
※ ここでは車両制御側でYabLocによる自己位置推定を使用していません。
走行開始
パーティクルが収束せず、徐々に分散していってしまっています。
ヘアピン
カーブを曲がるとパーティクルが収束する挙動が見て取れます(画像↔ベクターマップのマッチングはあまり考慮されていなさそうですが…)。
くねくね
こちらもヘアピンと同様です。
2. YabLocでの自己位置推定 → 車両制御
上記はあくまでYabLocによる自己位置推定のみで、その結果を使用した車両制御とはなっていません。
もし車両制御まで実行したい場合は以下を変更し、EKFローカライザへYabLocで推定したpose_with_covarianceを渡します。
試しに動かしてみると、コースイン時点で壁にぶつかってしまいました…
各種設定見直しやパラメータ調整等が必要そうです…
考察など
定量的には評価できていませんが、YabLocによる自己位置推定精度の向上は確認できませんでした。
考えられる原因としては、そもそもパラメータやインプットトピックなどの設定が不適切である、想定ユースケース(公道)と異なりサーキットは白線などの道路境界が明確でない、特に安全ブロック(青白)のエッジが検出されやすくマップとのマッチング時のノイズになりやすい、あたりが思いつきます。
[パーティクルフィルタ]
パラメータをもう少し見直し・調整したいです。
[画像処理]
こちらも各種パラメータ見直しと併せて、不要な安全ブロック(青白)の垂直方向エッジを除去する(特定の角度のエッジは除去する)後処理等も必要かもしれません。
[セマンティックセグメンテーション]
セマンティックセグメンテーションによる道路検出は一定うまく機能していそうです。現状は初期位置設定にしか利用していない理解なので、こちらをマップマッチング時にも活用するなどもよさそうです。リアルタイムで動くか問題はありますが。
おわりに
Autowareのビジョンベース自己位置推定手法 YabLocを動かすことができました。しかしパーティクルをうまく収束させることができず、定性的な評価に留まりますが、自己位置推定精度の向上は確認できませんでした。設定やパラメータ調整、アルゴリズム変更などを行えば精度向上は達成可能かもしれません。
ただ、どうやら2025年決勝(実車)からGNSSの精度が格段に向上したようで、もはや自己位置推定は大きな課題ではなくなってしまったようです。以降の自動運転AIチャレンジでは、YabLocや他ビジョンベースの自己位置推定等、自己位置推定をより高精度にする手法は不要かもしれません。
一方で、以下記事のようにGNSSが高精度で取得できない走行環境 (高架下やトンネル内等) など、現実的な自動運転技術開発においてはビジョンベースの自己位置推定手法は課題解決の1手段として俎上に上がると思います。その観点から、本コンペティションの目的である「技術者の発掘育成」としてまとめておく価値はあると考え、作成しました。
色々と中途半端なため役立つ部分があるか怪しいですが、どなたかのお役に立てば幸いです。
この記事は、AI文章校正ツール「ちゅらいと」で校正されています。