ティフフォーのエンジニアである近藤が、9月25日に開催されたROSCon JP 2024にて「マルチコンテナ開発と運用の知見公開と自動運転AIチャレンジへの応用」というテーマで、世界初のオープンソースソフトウェアである「Autoware」のマルチコンテナ開発について講演を行いました。今回は、その講演を振り返ります。
ティアフォーが開発を主導する「Autoware」は、LinuxとROS 2をベースとした自動運転オープンソースソフトウェアです。世界20か国以上、30種類以上の車両に展開され、約500社の企業が自動運転の実現のために活用しています。「Autoware」の所有権は非営利団体の「The Autoware Foundation」に移管し、オープンソースコミュニティに提供しています。現在「Autoware」のGitHubリポジトリは、9000以上のスターを獲得しています。今年中に1万スターの獲得を目指していますので、Starを付けていただけると嬉しいです。
小松駅前を走るMinibus
「Autoware」を活用した、自動運転車両の実際の運用も始まっています。ティアフォーはパートナー企業との連携の下、JR小松駅・小松空港間での自動運転バスの通年運行を行っています。2024年3月9日の運行開始から、すでに利用者1万人を達成しており、地域を支える交通手段となっています。
「Autoware」は様々なROS 2パッケージで構成されており、これらのパッケージをひとかたまりのコンポーネントにし、切り替えながら動く仕組みになっています。これをオートノミーアーキテクチャといいます。「Autoware」は10万行以上のソースコードと400以上のROS 2パッケージを含め、コンテナ化を考えていく必要があります。AMD64やX86アーキテクチャ、ARM64（AArch64）アーキテクチャでコンパイルする必要があり、さらにはCUDAのドライバーの有無など、多くのコンフィグレーションを加味してビルドを効率的に行う必要があります。
さらに、ソフトウェアのライセンスはApache 2なので、GitHubの無償サービスを使うことができます。GitHubホステッドランナーを使えば、無料でCI/CDを実行し、テストが可能になります。今回は、そのようなノウハウを共有します。
シングルステージからマルチステージビルドへ
「Autoware」のマルチコンテナ化の今までの取り組みについて紹介します。半年ほど前はシングルステージビルド、つまり一気通貫のビルドしかありませんでした。「devel」と書いてある開発コンテナのステージから、runtimeにコピーして実行コンテナを作っており、シングルコンテナに近い状態でした。
そこから、rosdepインストールの依存パッケージリストのみを生成するステージを独立して作成し、ビルドステージを分割して効率的にコンパイルできるようにしました。さらに分割して効率的にした後、LiDARやカメラといったセンシングを行う部分と物体認識などを行うAIビジョンの部分を分離した開発コンテナを作成しました。そして、その最終成果物をコピーした実行コンテナとして提供することで、マルチコンテナ化の第一歩が実現しました。
センシング／認識処理用開発コンテナの分離
現在ではさらにプランニングとローカライゼーションのコンテナも用意しており、どちらにも開発コンテナと実行コンテナがあります。
自動運転車両を開発する際、すべてのソフトウェアやセンサーを車両にセットすることは困難です。しかし、シミュレータとrosbagファイル、そして自分が開発したいパッケージを用意すれば、それをボリュームマウントし開発コンテナでビルドしてデバッグできるため、パソコン1台で自動運転ソフトウェアの開発が可能です。
一方、実行コンテナは実車両を使って「Autoware」を動かすため、環境設定などすべての要素が含まれています。現状、「Autoware」の最新版でも動くようになってきています。
コンテナビルド時間の削減
シングルステージビルドからマルチステージビルドに移行していく過程で様々な改善を行っています。その結果、数ヶ月前まで2時間半掛かっていたコンテナのビルドが、現在はおよそ40分程度、早い場合は5分程度にまで短縮されました。これはおよそ数十倍速に達しています。
Runner GitHub Actionsでのコンテナビルド時間
コンテナのサイズも、docker pullやdocker pushの際に通信データサイズやディスク消費量に影響を及ぼします。それが現在、9.3 GBあったものが4.2 GB と半分以下になり、CUDAドライバーが無い場合はさらにその半分程度になっています。
Autowareコンテナイメージサイズ
このように工夫することで、CPU計算リソースの低いGitHubホステッドランナーでも効率的に開発を行うことができます。
GitHub Actionsを使ったコンテナビルドの手法
ビルド時間の削減のために実施した手法を紹介します。まずROSに関係のない部分から解説します。GitHub ActionsというCI/CDを回す仕組みにおいて、Docker build cacheを有効にしない場合、コンテナビルドのレイヤーキャッシュの部分がキャッシュできません。今回、レジストリにきちんとキャッシュするようにしました。これをすることで、そのレイヤーのキャッシュが効いている部分はきちんとGitHub Container Registry（GHCR）から持ってきて、再利用することができます。
また、cache-fromでメインブランチとPull requestのためのブランチの両方を指定した場合、Pull requestが肥大化し、その中でビルドが多く必要になっていても、キャッシュが効くようになっています。しかもメインブランチの分も反映可能です。cache-toでキャッシュを保存する際も、全てのステージをキャッシュすることで、ビルド結果が最大限キャッシュされます。
しかし、「Autoware」などの大規模なROSパッケージ開発の場合、シングルステップの実行でcolcon buildする際に数百個のパッケージをビルドすると、1〜2時間かかることがあります。このような場合、buildkit-cache-danceというGitHubアクションがとても便利です。イメージ内のファイルを抽出し、復元してキャッシュしてくれます。これを使い、C++のコンパイルのキャッシュをCcacheで作成し、復元しています。これにより、1個のパッケージの修正なら、キャッシュを約90%以上効かせることもできます。
もう一点、こちらはROS特有ですが、rosdepでのキャッシュの保持力の向上を行います。package.xmlを変えず、ソースコードのみ変更した場合、再度rosdepインストールが開始してしまうことがあります。それを避けるため、まず独立したステージでソースコードの必要な部分だけをコピーし、rosdepインストールに必要なパッケージリストをあらかじめ作成しておきます。そのファイルを作り、ビルドステージの直前にインストールします。これをすることで、依存パッケージのリストに変化がなければ、依存パッケージのインストールをスキップすることが可能です。こちらはとても有効です。また、先ほどのCcacheと同様、APTのダウンロード済みのパッケージをGitHub Actionsのキャッシュに保存しておくことでダウンロード時間を最小化することが可能です。
ソースコードをバインドマウントする際、各ステージで必要な分（例えば、センシングと物体認識（perception）する部分のみ）をマウントし、インストール先もカレントディレクトリにインストールするのではなく、インストール先を/opt/autowareに変えるようにしてあげれば、この/opt/autowareという最終成果物だけを実行コンテナや、次のステージにコピーするだけで十分になります。カレントディレクトリの中間生成物であるbuildディレクトリもその場で削除すれば、コンテナのイメージサイズに悪影響を与えないので、軽量化につながります。
最後に、実行コンテナの最小化ですが、前述のやり方を組み合わせ、rosdepをインストールするときに、きちんとexec_dependだけをインストールするよう--dependency-types=execと設定することが重要です。
さらに、rootディレクトリから不要なヘッダファイルや開発用のファイルを根こそぎ削除し、開発コンテナからは最終成果物のみをコピーするようにすると、最小サイズのROSコンテナが生成できます。
開発コンテナを使った「Autoware」のパッケージの作成手順は以下の通りです。
- Autowareリポジトリをクローン
- サブモジュールをvcs import
- 必要なパッケージだけをボリュームマウントして開発コンテナをdocker run
- colcon build実行（debugオプション付与）
これにより、自分が開発したいものだけを、GNU Debugger（GDB）をアタッチしながらビルド可能です。また、ローカルの環境がMac、Linux、Windowsのいずれであっても可能です。
現在、Visual Studio Codeを使った方法を整備中なので、別途ご紹介したいと思います。
AutowareからPilot.Autoへ
ティアフォーでは、「Autoware」をベースとした、拡張可能な自動運転システムを実現できるプラットフォームである「Pilot.Auto」への道筋を整えていく予定です。まずは「Autoware」のデモの機能を取り除いたコンテナ部分を次の「Pilot.Auto」につなげ、「Pilot.Auto」はその製品用のフィーチャーを別のコンテナとして受け継ぐというストリームラインを作ります。
そして、デバッグ用シミュレーターや評価用ツールを取り除いてマルチコンテナを形成します。例えば物流ロボット用だったら物流ロボット用のフィーチャー、シャトルバスだったらシャトルバス用のフィーチャーを足して、最終的なPilot.Auto製品群にしていくということを目指しています。
OSSからプロダクトへ
レースカー用のプロダクトに関しても、今後「Autoware」の一部のコンテナを取り出し、レースカー用の競技システムをインテグレーションし、レースカーのソフトウェアにするという取り組みも行う予定です。
自動運転AIチャレンジ2024
レースカーとはつまり自動運転AIチャレンジのことです。もう一つの本題である自動運転AIチャレンジについてもご紹介します。本大会は、CASE（Connected/Autonomous/Sharing & Services/Electric）やMaaS（Mobility as a Service）といった新しい技術領域において、これからの自動車業界を牽引する技術者の発掘と育成のための新たな取り組みとして実施しています。決勝大会では自動走行モビリティに開発したプログラムを搭載させる走行競技を行います。コンピューターサイエンス、AI、ソフトウェアや情報処理に関わる技術者・研究者・学生等のチャレンジの場、また学習および機会を提供し、有機的な繋がりを実現する場を目指します。
今年のAIチャレンジは、お台場のシティサーキット東京ベイにて半年間にわたって開催されています。EVレーシングカートを使っており、手動運転もできるので、どんな方でも楽しめる場所となっております。
予選は9月に終わりましたが、デジタルツイン指向のコースを用意し、シミュレーションを実施いたしました。準決勝と決勝は11月に開催されますので、ぜひ遊びに来てください。
Yutaka Kondo | 近藤豊
Autoware Engineeringチーム
2024年4月入社。前職では産業ロボメーカー、AIスタートアップ、家庭用ロボットメーカーにて自律型ロボットの開発に従事。現在はAutowareのバージョン管理やマルチコンテナ化、CI/CDパイプライン、コンポーネント再設計などAutowareの全体最適化を担当。ROSConプログラム委員とROSCon JP実行委員を務める。著書である「改訂新版 ROS 2ではじめよう 次世代ロボットプログラミング」が2024年9月に発売。
ティアフォーでは、「自動運転の民主化」というビジョンに共感を持ち、自らそれを実現する意欲に満ち溢れた新しい仲間を募集しています。
多くの職種で採用をしています。詳細は、ティアフォーの「求人ページ」をご覧ください。カジュアル面談をご希望の方は、応募する際に「カジュアル面談希望」と記載してください。
「どの職種で自分の経験を活かせるかが分からない」「希望する職種が見つからない」などの場合は、ぜひ「キャリア登録」をお願いします。
お問い合わせ先
- メディア取材やイベント登壇のご依頼：pr@tier4.jp
- ビジネスや協業のご相談：sales@tier4.jp
ソーシャルメディア
X (Japan/Global) | LinkedIn | Facebook | Instagram | YouTube
関連リンク