はじめに
自動運転AIチャレンジ2023(インテグレーション大会)で実施した、Autowareパラメータ自動調整の取り組みを共有します。内容は、(1)取り組みの背景、(2)仕組みの概要、(3)実際の結果例と気づきのまとめです。
本大会のコンセプトである「今後の自動車業界を牽引する技術者の発掘育成」、「自動車産業のさらなる発展に寄与」の一助となれば幸甚の思いです。また本体会の運営の皆様、参加者の皆様、ありがとうございました。とても有意義で楽しい大会でした。
発言は個人の見解に基づくものであり、所属組織を代表するものではありません。
書いてあること（要約）
- AI(広義)を応用した、Autowareパラメータを自動で調整する仕組みを構築。
- シミュレータ×AIで、開発効率化が期待。
- 成果物は、GitHubで公開中。
書いてないこと
- AutowareおよびAIチャレンジ(概要,競技内容等)の説明は、他の方に譲ります。
- 背景にある数学的な原理には触れません。
目次
- 背景・目的
-
自動調整の先行例・本取り組み概要
2.1. 先行例調査
2.2. 本取り組み概要 -
調整結果の例・気づき
3.1. 関係しそうなパラメータすべて → 距離スコア: 0m
3.2. Planningのみ → 距離スコア: 70m
3.3. Controlのみ → 距離スコア: 115m, 145m - 結論・まとめ・感想
- 参考文献
1. 背景・目的
Autowareは様々なユースケースに対応できる柔軟な設計である反面、障害物回避プランナー等の一部モジュールには調整パラメータが70以上も存在し、その調整作業は複雑で手間がかかる場合がある。増加し続けるyamlファイルのコピー、どのパラメータでどのスコアだったかの把握・追跡、特定のパラメータ変更がもたらす影響の理解が困難となり、頭の中もディレクトリ内もカオスな状態に陥ることがしばしば。あくまで私は…ですが、AIチャレンジに参加した/している方々の中には、この経験に共感してくれる方がいることでしょう…。
上記の状況を踏まえ、実験計画を立てきちんと管理することは一つの正当な解決手段ではあるものの、より簡便で効率的なパラメータ調整方法が欲しい！、と思ったことが本取り組みのきっかけ。同時に、私自身がベイズ最適化による適応的実験計画に興味を持っていたこともあって、「スクリプトを1つ実行すれば、AI(広義)がパラメータ提案とシミュレーションを行い、最終的に良好な走行が可能なパラメータを発見してくれる」ような仕組みを構築して、開発の効率化を目指した。
2. 自動調整の先行例・本取り組み概要
先行例を調査し、Autowareへの応用を行った。
2.1. 先行例調査
私のような凡人の考えつくことは先人がすでに実行していることが多い。まずは、先行例を調査した。おいしいコーヒーの淹れ方探索など興味深い取り組みは見つかったものの、Autowareへの応用例そのものは存在しなかった。一方で、先行例を参考にすれば、大きな課題はないと思えたため、自力で実装した。
2.2. 本取り組み概要
目的関数を「シミュレーションでの距離スコア(result.json の "distanceScore")」とし、この距離スコアが最大となるような、Autowareパラメータの組み合わせを自動で探索する仕組みを構築した。具体的には、OptunaにAutowareパラメータとその探索範囲を渡し、最大スコアが期待できるパラメータの組合わせを提案してもらいシミュレーション、その結果を踏まえて提案 → シミュレーション…を、自動で指定イテレーション分だけ繰り返す。
詳細は、こちらをご確認ください。
3. 調整結果の例・気づき
以下に、いくつかの例と気づきを紹介する。なお画像は、最適化結果を手軽に確認できるWebダッシュボードのoptuna-dashboard。Optunaは、各最適化Studyをデータベース(SQLite)として保存が可能で、あとからdashboardで以下のように結果の見直しができる。もちろんStudyの途中経過も確認出来る。さらに、過去実施分からイテレーションを増やして最適化を再開することもできる。かなり便利。とても便利。好き。ラブ。
3.1. 関係しそうなパラメータすべて → 距離スコア: 0m
今回の競技内容では、PlanningとConrtolが重要と判断し、関係しそうなパラメータ全部盛りで自動調整を実行。結果、MPCのパラメータが不適切になるようで、そもそもPlannigが不可となり、走行できなかった。
※上図の中央横長のグラフにおいて、縦軸の"Objective 0"が距離スコア[m]、横軸の"Trial"がイテレーション数を表す。Objective 0はずっと綺麗にゼロ。つまり走っていない。
※150イテレーション分の電気代と時間、どうなるかな〜ワクワク〜、の純粋な気持ちを返してくれ。やはりドメインの知識はとても大事。
3.2. Planningのみ → 距離スコア: 70m
ControlはデフォルトのMPCパラメータで固定し、Planning(障害物回避)の調整を実施。
結果は以下。少し賢くなり、障害物を回避可能となった。
※上図の左下にある"Hyperparameter Importance"を見ると、"Max Lateral Jark"が距離スコアに効くことがわかる。
3.3. Controlのみ → 距離スコア: 115m, 145m
Planningで引いた経路を追従するControl、特に横方向(Lateral)の調整を実施。
MPCは一部パラメータであれば調整可能であった。結果は以下。
Pure Pursuitでもやってみた。結果は以下。意外にもMPCよりも高スコアとなった。
※普通に考えたらMPCのほうが性能が出そう。MPCよりもシンプルなPure Pursuitは、少ないイテレーションでうまいこと調整できるのかもしれない。MPCもイテレーション数を増やせば同等の性能が出る可能性はある、あとは対象パラメータを増やす、探索範囲を変更する等も。
4. 結論・まとめ・感想
-
Autowareパラメータを自動調整する仕組みを構築。
-
定量的な評価はできていないが、開発効率は大幅に向上した。目的は達成。
- 朝イチにスクリプトを実行 → 1日中、AIがシミュレーション → 夜に結果を見る、が可能に。
- Optunaがデータベースとして結果を残してくれるので、管理も簡単に。
-
Optunaがとても便利、Optunaがとても便利、Optunaがとても便利。大事なことなので。
-
ランダムサーチの方が良いのでは説もあるが、どうなんでしょうね。比較もやってみたい。
-
ツールとしてはまだまだ未熟。モジュール切り替えも自動で調整、パラメータの事前分布に経験則を反映、yamlファイルを汚さない…など、改善の余地あり。
-
AIとE2Eシミュレータ(AWSIM)の相性が良い。シミュレータとテストシナリオ、パラメータリストを用意してあとは全部AIにお任せ、もできる。
-
パラメータ調整、「もうAIだけで良くないですか」。