はじめに
こんにちは、ティアフォーでオープンソースの自動運転システム「Autoware」の開発をしている三宅です。現在は主に開発環境周りを担当しており、効率的な開発プラットフォームを目指して日々改善を重ねています。
前回のブログ記事では、The Autoware Foundation (AWF) の概要、歴史、コミュニティへの参加方法、等について説明がありました。
今回はもう少し詳細として、Autowareのリポジトリ構成についてお話します。リポジトリ構成には、「常にこうしておけば完璧」という、いわゆる「銀の弾丸」はなく、目的に応じてトレードオフを考慮して設計する必要があります。
そこで、まずはAutowareのコンセプトを説明します。
Autowareのコンセプト
Autowareは、「世界初のオープンソース自動運転ソフトウェア」です。
競合システムと比較すると、例えばCruise、Tesla、Waymo、Zoox等のプロプライエタリなものに対しては、当然ですが、オープンソースであることが異なります。また、同じくオープンソースのApolloやopenpilotに対しては、それらはそれぞれBaiduやcomma.aiという一企業が開発していますが、Autowareは非営利団体であるAWFによって開発されます。
最も大きな違いは、それらの競合システムが特定の車両やユースケースに特化した「プロダクト」を開発しているのに対して、Autowareは幅広いユースケースに適応可能な（＝スケーラブルな）「プラットフォーム」を目指していることです。下図のように、幅広い機能コンポーネントを開発し、ユーザーの要求に応じて柔軟に組み替えることで、様々なプロダクトに対応できるプラットフォームを実現する、というイメージです。
Autoware（プラットフォーム）と他の自動運転システム（プロダクト）
これは、ティアフォーがビジョンとして掲げる「自動運転の民主化」とも一致しています。Autowareを中心とした、オープンソースでスケーラブルなプラットフォームをベースとしたエコシステムを構築することで、世界中の誰もが自動運転システムの恩恵を受けられるようにすることが、ティアフォーとAWFが目指すものです。それにより結果的に、ティアフォーやAWFメンバー企業のビジネスを拡大させられます。
スケーラブルな自動運転システム開発プラットフォームに求められる要件
では、スケーラブルなプラットフォームになるためには、何が必要でしょうか？
以前の記事でも説明されているように、まずは業界の様々なプレイヤーの参入障壁を下げることが重要です。例えば、以下のような多種多様なユースケースに、容易に対応可能であることが求められます。
- 自動運転システム開発者がAutowareのソフトウェア構成やハードウェア構成をカスタマイズして「自分たちの自動運転システム」を構築できる
- AI企業が「高性能なPerception/Planningコンポーネント」を開発して販売できる
- タクシー運行事業者が「AutowareのAPIを利用した自動運転タクシーの配車サービス」を提供できる
つまり、「AutowareのAPIやコンポーネント間のインタフェースが定義されており、低コストで自由に拡張やカスタマイズができる」ことが重要だと言えます。
また、自動運転システム開発で難しいのが、「走行環境の組み合わせが膨大すぎて、開発前に明確な要件を定義するのが現実的に不可能」ということです。特に「幅広いユースケースに適応可能なスケーラブルなプラットフォーム」を目指すAutowareの方針においては、終わり無くシステムを成長させ続ける必要があります。
この課題を解決するためには、DevOpsのように運用での知見を開発にフィードバックしつつ、インクリメンタルな開発によって段階的に機能拡張しつつ性能や品質を向上させて、徐々にシステムの適用範囲を拡大して対応するしかありません。そのためには、「様々なアルゴリズムを素早く実装して試し、有効なアルゴリズムを効率的に見極めて選択できる」ことが求められます。
さらに、最終的に自動運転システムを「ビジネスのためのプロダクト」として完成させるためには、システムが作動する前提となる走行環境条件、いわゆるOperational Design Domain (ODD) を定義して、その中でシステムの安全性を論証し、Dependableなシステムを構築する必要があります。
あらゆる可能性を考慮して100%事故が発生しないことを保証するのは困難ですが、安全上のリスクが許容範囲内であることは求められるため、ソフトウェア品質も一定以上の水準を達成し、ステークホルダーとの合意や社会受容性の課題をクリアしなければなりません。「バグがたくさん潜んでいるかもしれませんが、概ね動いているので多分大丈夫ですよ」では安心して自動運転車に乗れませんからね。
しかし、「オープンソースの多様性と高品質なソフトウェアを両立する」ことは非常にチャレンジングです。無限のリソースが与えられれば人海戦術で解決することも可能ですが、限られたリソースで問題を解決するためには、効率的な管理の仕組みが必要になります。
スケーラブルな自動運転システム開発プラットフォームを実現するリポジトリ構成
検討した要件を整理すると、以下のようになります。
- AutowareのAPIやコンポーネント間のインタフェースが定義されており、低コストで自由に拡張やカスタマイズができる
- 様々なアルゴリズムを素早く実装して試し、有効なアルゴリズムを効率的に見極めて選択できる
- オープンソースの多様性と高品質なソフトウェアを両立する
これらを実現するために、Autowareでは「Core/Universe」というコンセプトを掲げています。開発体制や品質基準の異なる2つの基準を併用することで、品質と機能を両立するのが狙いです。
Coreは、自動運転システムのインタフェースや基本機能を備えています。AWF主導で開発を行い、機能は最小限なものの、高品質を目指して厳格に品質管理されます。
Universeは、Coreに対する拡張という位置付けです。細かく分類すると「AWFやコアメンバーが行う拡張」と「任意の組織やユーザーが自由に行う拡張」の2種類があります。コミュニティ主導で開発を行い、品質は様々なものの、幅広いユースケースに対応できる高機能なコンポーネント群を、効率良く開発できます。
下図のように、安定したCoreが中心にあり、Universeの様々な拡張がその周りに広がっているイメージです。
Autoware Core/Universe
このCore/Universeにより、以下のようなユースケースに対応できます。
- Coreのベースコンポーネントを利用して、高品質な自動運転システムのプロダクトが開発できる
- Coreで定義されたAPIを利用して、MaaS等の外部サービスを連携できる
- Coreで定義されたコンポーネントインタフェースに適合するUniverseコンポーネントを開発して、Coreのベースコンポーネントを置き換えることで、Autowareを高機能化できる
- Universeでフィージビリティスタディを実施して有用性や安全性が確認できたものだけを、より堅牢な実装にしたり、性能改善したり、リファクタリングしたりしてCoreに取り込むことで、無駄な作り込みを削減できる
先ほど整理した要件と見比べてみると、あとはこれらのカスタマイズを効率良く実施できるのであれば、要件を満たせそうですね。
カスタマイズについて深堀りするため、Autowareの構成要素（＝カスタマイズ可能な要素）を考えてみると、以下のものがあります。
- 様々なプロダクトやODDで共通して利用したいもの
- コア機能（インタフェースや自律走行アルゴリズム）
- 汎用的な拡張機能（新機能のプロトタイプやツール類）
- 基本的にはプロダクトやODDごとに異なるもの
- 特定用途に特化した拡張機能（ハードウェア依存の強いHMIシステム等）
- センサ構成（個々のセンサのドライバ）
- センサキット構成（複数センサを組み合わせた時の配置関係や前処理ロジック）
- 車両構成（車両ECUのドライバや車両諸元）
- Launcher構成（ソフトウェアコンポーネント構成や起動順序）
- 車両1台ごとに異なるもの
- 個体差パラメータ（キャリブレーション値やハードウェアID）
これらの構成要素をどのような単位で管理すれば、Autowareによる自動運転システムのプロダクト開発を行う利用者にとって効率的なカスタマイズ性が実現できるでしょうか？
試しに全てを1リポジトリで管理することを考えてみると、以下のような様々な不都合が発生することが分かります。
- Pull requestの管理が複雑になり、メンテナンスコストが高くなる
- （例）「Coreはマージ前にこのテストが必須、Universeは必須ではない」等の基準を切り替える必要があるが、同一リポジトリで別の基準を設けることは一般的に難しい
- 一部のみをカスタマイズするためにForkした場合も、変更する必要のない部分も含めて全体が複製されてしまう
- （例）Planningアルゴリズムのパラメータを小変更するためにForkしたが、Autoware全体をコピーされてしまって無駄が多く、定期的に最新版に追従するための手間も増える
- アクセス権限を適切に管理できない
- （例）現場の運行管理者に車両パラメータ変更の権限を与えたい場合、ソフトウェア開発者以外にもソースコード変更の権限を渡す必要がある
したがって、関心の単位でリポジトリを分割して管理することが重要だと言えます。プログラミングの設計で重要な考え方と同じですね。
以上を考慮して、Autowareのリポジトリ構成は下図のようになっています。autowareというメタリポジトリの中に、リポジトリ定義ファイルの autoware.reposがあり、上で挙げた「Autowareの構成要素」と対応する様々なリポジトリを参照しています。
Autowareのリポジトリ構成
これをForkしてカスタマイズする際は、以下のような流れになります。
- autowareリポジトリをForkしてautoware.customを作成する
- 共通部分は変更しない
- Autoware CoreはAWFと同一のものを参照する
- AWFで利用している拡張機能が、もし不要であれば参照を削除しても良い
- ユーザー独自の拡張機能を追加する
- 必ずしもユーザー自身が開発する必要はなく、サードパーティのコンポーネントを再利用もできる
- ユーザーのシステム構成に合わせて、センサ/車両/ノード構成をカスタマイズする
- AWFのデフォルト構成をそのまま使用する際は、変更しなくても良い
- 個体差パラメータもカスタマイズに合わせて変更し、メンテナンスする
- 必要であれば、Git管理からWebシステム上での管理への置き換えをしても良い
AutowareをForkしてカスタマイズする際の構成
リポジトリを適切な単位で分割/分類して管理していることより、必要な場所だけを容易にカスタマイズでき、シンプルになりました。
実際のソースコードが気になる方は、Autowareのリポジトリをご覧ください。例えばこれらの行を見ると、車両を変更したい場合はautowarefoundation/sample_vehicle_launchをカスタマイズすれば良さそうだと分かります。また、これらの行を見ると、ティアフォーが先進機能のテスト用に独自の拡張メッセージを定義していることが読み取れます。これと同様に、reposファイルに任意のリポジトリを自由に追加することで、Autowareの機能を拡張して行くことができます。
今後の発展のために
今回、無事にリポジトリ構成は検討できましたが、実はこれで終わりではありません。何事もそうですが、管理方法を決めるだけでは不十分で、実際にそれが上手く運用されるまでサポートしていく必要があります。
特に、Autoware Core/Universeのコンセプトは昨年末に合意して採用された新しい考え方であり、まだ全てのAWFメンバー企業やコントリビューターに浸透しているとは言えません。
Autowareコミュニティの全員が協調することでAutowareの開発を加速させられるように、ティアフォーが積極的に開発やディスカッションリードして、コミュニティにビジョンを示していきます！
おわりに
本記事では、Autowareのコンセプト「スケーラブルな自動運転システム開発プラットフォーム」を実現するためのリポジトリ構成について紹介しました。
今回は実装面の詳細な話は省略しましたが、Autowareのリポジトリ管理ではメンテナンスコストを減らすための様々な自動化の工夫を取り入れていて面白いと思うので、そちらは後日また別の記事として公開したいと思います。お楽しみに！
ところで、Autowareの開発やメンテナンスは、メンバー企業や有志の善意によって支えられております。コントリビューター達の励みになりますので、リポジトリのスターも是非よろしくお願いします！
https://github.com/autowarefoundation/autowareを開き、Sign inボタンからご自身のGitHubアカウントにログイン後、Starボタンを押せばスター完了です。GitHubアカウントをお持ちでない方も、Sign upボタンから無料アカウントをすぐに作成できます。
オープンソースのソフトウェアを一緒に開発していきませんか？
ティアフォーでは、「自動運転の民主化」というビジョンに共感を持ち、自らそれを実現する意欲に満ち溢れた新しい仲間を募集しています。
Media Contact
pr@tier4.jp
Share the post
LinkedIn | X | Facebook | Instagram