自動運転開発したい！でもどこから始めれば良いの？

Ryohsuke Mitsudome

Published in

TIER IV MEDIA

18 min readSep 6, 2022

はじめに

こんにちは、TIER IV でオープンソースの自動運転システム「Autoware」の開発をしている満留です。

Autowareの活動に参加していると、初めてAutowareを触れた方や開発に参加しようとしている方と話す機会があるのですが、よく以下のことについて聞かれます。

Autowareは誰がどう運用しているか？
Autoware.AI, Autoware.Auto, Autoware Core/Universe, いろいろあるけどそれぞれどういう関係性があるか？
Autowareの活動参加するにはどうすればよいか？

Autowareの公式ページに簡単な記述はありますが、Autowareが2015年に初めて公開されてから様々な変遷をたどっていますし、Autowareのコミュニティの全体像はソースコードやウェブサイトを見るだけでは掴みづらいかと思います。そこでAutowareに興味がある人が参入しやすいように、上記の疑問についてもう少し踏み込んで文章化してみます。Autowareに興味があるものの参加方法がわからない人の助けになれば幸いです。

以下についても今後の記事で紹介していくので、楽しみにしていてください。

Autowareのリポジトリ構成
Autowareの動かし方

AutowareのCommunityの概要とその組織体制

Autoware Foundation とは

AutowareはオープンソースとしてGitHub上で公開されているので、誰でも新機能を提案して開発に貢献できるようになっています。しかし、オープンソースソフトウェア (OSS) として運用するためにはリポジトリを管理・メンテナンスするOwnerが必要です。それ以外にもAutowareの開発方針の舵取りをしたり、開発のロードマップを引いたりする必要もあります。その役割を担っているのが The Autoware Foundation（以下AWF）と呼ばれる非営利団体です。

Autowareは、TIER IVの創設者でもある加藤真平が名古屋大学在籍時に長崎大学や産総研との共同成果の一部として、2015年に自動運転の研究開発用途に無償で公開されました。TIER IVが創設されてからは、TIER IVがAutowareの開発・管理をリードしていました。そして、Autowareの初公開から3年後の2018年にTIER IVはLinaroとApex.AIと共にAWFを設立し、AutowareをAWFに譲渡します。

Autowareの運営をTIER IVという1企業から分離した主な理由は、TIER IV単独ではいずれ開発に限界が来ることが予想できたからです。自動運転のサービスを運営するためには、コアとなる自動運転ソフトはもちろん、センサーの開発、地図生成、MaaSなど、必要な要素技術は多岐に渡ります。

TIER IVのようなベンチャーではそれら全てを単独で提供するのは無理があるため、OSSであるAutowareを起点にこれらの要素技術を開発している他企業とエコシステムを形成することが必要でした。他の企業や団体の協力を仰ぐためには、エコシステムの根幹となるAutowareがTIER IV単体で所有しているソフトウェアのままだと、TIER IVの独断でAutowareを非公開にしてしまえたり、極論TIER IVの資金繰りが苦しくなるとAutowareの開発が止まってしまったりといったリスクがあります。そこで、より様々な個人や団体が安心してAutowareを利用できるためにAWFを設立し、Autowareの管理をAWFに移しました。AWFに譲渡後、Autowareの運営判断はAWFに加盟している企業それぞれの代表者による委員会方式で取り決められるようになり、より公平な運営を行えるようになりました。その具体的な運営方法については次の章で説明します。

AWFの組織体制

AWFは様々な研究機関や企業がメンバとして所属しています。メンバ間で上手く連携するために、下記の図のような委員会方式で運営しています。

Committee

上記の図の各CommitteeはAWFのPremiumメンバで構成され、Autowareの運用や技術Roadmapの決定など主要な方針を決定する役割を担っています。

Board of Directors (BoD): AWFの取締役会。AWFのPremium Memberの中から最大5人選挙で選出された代表者でAWFの全体方針を決定します。
Strategic Planning Committee (SPC): Autowareの戦略を練る委員会です。Premiumメンバの代表者から形成され、どういったエコシステムを形成すればAutowareが普及するのか、そのエコシステムをどう形成するのかを考えます。
Technical Steering Committee (TSC): Autowareの技術的な要素について議論します。どういった開発方針にするのか、Autowareのソフトウェアアーキテクチャをどうするか、リポジトリの運用改善などについて議論します。詳細なタスクは各Work Groupで行いますが、Work Group内で議論が割れたりした場合などもTSCに打ち上げて、メンバ企業の代表者で方針決定を行います。
Operations Committee (OC): AWFを運用するサポートを行います。例えば、AWFのメンバ企業・団体の契約手続きを行ったりします。

Work Group (WG)

Autowareの大まかな開発方針は上記の委員会で決定されますが、その決定方針に従ってAutowareを開発するのはWGで連携をとりながら行われます。開発はGitHubのIssueやDiscussionといった場でテキストベースに行われますが、議論が割れたりコアな開発メンバに共有したい事項がある場合は、WGの議題として挙げられ口頭での議論をすることになります。WGの会議にはFoundationのメンバに限らず誰でも参加できるようになっており、こちらのカレンダーのミーティングに自由に参加できるようになっています。

Autonomy Software (AS) WG
Autoware内部のアルゴリズムについて議論します。TSCで決まった開発Roadmapに合わせてLocalization/Perception/Planning/Controlなどの開発を行っていきます。その他、GitHubのIssueなどで上がってきたバグ報告や新機能要望などについても必要に応じて話し合われます。
Operational Design Domain (ODD) WG
TSCではRoadmapに合わせて1年毎に開発目標を立てるのですが、このWGはそのODDとユースケースを具体化する場になります。その開発目標を達成するためのユースケースのシナリオを定義し、ASWGではそれを使って機能検証することになります。
Simulation WG
このWGではその名の通りシミュレータについて議論します。ODDで作ったシナリオに沿ってシミュレーションを再現できるようにしたり、ログデータからAutowareの挙動を再現するシミュレーションツールなどを開発します。
Open AD Kit WG
Autowareを実際のサービスで運用するための支援フレームワークについて議論するWGです。例えば、運行管理するためのクラウドシステム、不具合の特定につながるログを吸い上げるツール、新しいAutowareのバージョンを車両に配信するためのOTAサービスといった、Autowareを使ってサービス提供するための土台となるフレームワークを提供します。
Racing WG
AWFは Indy Autonomous ChallengeやF1Tenthといった自動運転車両のレースイベントにも協力しており、それらに関することを議論するWGになります。これらレースイベントは主に、まだAutowareに詳しくない方向けのものとなっているため、そこにAutowareをベースシステムとして提供することで、より多くのエンジニアにAutowareを触ってもらいAutoware開発者の裾野を広げることが目的となっています。

Autowareのこれまで

Autowareは2015に公開されてから、いくつか違うバージョンがリリースされています。この章では、これまでAutowareがどのような進化をたどってきたか説明します。

Autoware.AI (2015~)

Autoware.AI は2015年にリリースされた最初のAutowareです。当時、他にOSSとして使える自動運転システムがなかったこともあり注目を集め、多くの研究者や企業によってSensing, Mapping, Localization, Perception, Planning, Controlと自動運転に必要なパッケージが数多く実装されてきました。しかし一方で、自動運転システム全体としてのアーキテクチャが明確に設計されないまま各開発者が自由に機能を開発したことで、実際にAutowareをつかって車両を動かそうとしても、似た機能を持つパッケージでも互換性を持っておらず、特定のパッケージの組み合わせでしか動かなくなってしまったりといった問題点もありました。他にも適切なドキュメンテーションがされていなかったり、コードの品質もパッケージごとにバラバラだったりといった課題がありました。そのため、企業がサービスで利用するにあたって求められる製品レベルの品質とは大きな隔たりがあり、Proof of Concept(PoC)など実証実験や研究用と以外で使いづらくなっていました。この問題を解決するために、後述するAutoware.Autoの開発が始まります。2020年以降は、AWFがAutoware.Autoへの開発に注力することを目的にAutoware.AIはメンテナンスモードに移行しています。2022年末に開発も完全に終了し新機能やバグの修正対応などは行われなくなりますが、コード自体はその後も公開はされ続けます。

Autoware.Auto (2019~)

AutowareはROSと呼ばれるロボット開発フレームワークをベースにパッケージが実装されているのですが、2019年にROS 2と呼ばれる新しいROSのLTSリリースが行われました。Autoware.AIはROS 1で実装されていたため、ROS 2のリリースに合わせてAWFではROS 2に移行する計画が議論されました。議論の結果、Autoware.AI開発時に直面した課題を解決するためにもAutoware.AIのパッケージを単純にROS 2に書き換えるのではなく、システム全体の設計を含めて一からやり直すことにしました。開発プロセスも見直され、1年毎にターゲットとなるODDとユースケースを定義し、そのODDで動作可能な自動運転システムのアーキテクチャを設計し、各機能を実装していくというサイクルで開発していました。新機能をマージする際のチェック項目も増え、Documentationやテストコードがないとリポジトリにマージされなくなり、パッケージごとのコード品質向上のための手順が必須となりました。

Autoware.Autoで開発プロセスも一新したことで、しばらくは上手く開発が進んでいきました。しかし、開発を続けていくうちに下記のような課題が浮かび上がってきました。

コードをマージするための要求が高くなってしまったことで、研究のためにプロトタイプ用にコードを変更するといった気軽な開発がしにくくなってしまった。
アーキテクチャレベルで大きな変更が必要なときに、常にコード品質を保った状態で大規模変更を加えるための開発コストが大きい。

自動運転はまだまだ研究が必要な要素技術も多く、学会等でも常に新しい論文が発表されています。それら最先端の技術をスムーズに取り入れていくためにも、ある程度の品質を担保しつつ実験的な機能でも取り入れやすい枠組みを考える必要に迫られました。

Autoware Core/Universe (2022〜）

Autoware.AIではコード品質の基準が緩すぎたためソフトウェアの信頼性に問題があり、Autoware.Autoでは逆にコード変更に対する基準が厳しくなったため品質担保のために開発スピードが落ちるという問題が起きてしまいました。これを解決するために、TIER IVからAutoware Core/Universeと呼ばれるコンセプトをAWFに向けて提案しました。この提案ではAutowareはCoreとUniverseの2つの異なる基準で管理される要素で構成されることになります。

Autoware Core と Autoware Universeのコンセプト図 (Autowareのウェブサイトより抜粋)

Autoware CoreはAutoware.Autoの理念を引き継いでおり、リポジトリへ新機能を追加する際にはAWFで設定した基準をパスする必要があります。AWFが基準を満たしていることを確認することで、機能保証と品質保証をした自動走行ソフトウェアを提供することができ、例えば企業が自社サービスにAutowareを使いたい場合にも、より少ない手間で導入できるようになります。

対してAutoware Universeは、Autoware Coreの一部のモジュールを置き換えたり機能追加したりできるような拡張、変更が簡単にできるパッケージ群になります。Autoware Universeは、Core よりも緩い基準でパッケージが管理され、学生や研究者が研究目的で開発した実験的な機能でもAWFのコミュニティに共有できるようになります。Autoware Core開発者にとっても、様々な実装を試すプロトタイプ開発の場としても利用できます。ただしAutoware.AIほど基準が緩いわけではなく、例えば他のユーザーが利用しやすいように最低限READMEなどは求められますし、あくまでAutoware UniverseはAutoware Coreの拡張という位置付けですので、Autoware Coreで定められたインタフェースに基づいてCoreのモジュールとの互換性を持っている必要があります。よって、ユーザーは例えば基礎的な機能はCoreのモジュールを使いつつ、例えば物体認識機能だけUniverseにある最新機能を試してみるといった構成でAutowareを動かすことができるようになります。Coreの機能をそのまま再利用できるため、必要な機能のみに集中できます。

Autoware UniverseはAutoware Coreのモジュールと互換性を持ち、任意に最新機能を試すことができる

以上のように、CoreとUniverseで異なる基準のもとコードを管理することで、自動運転の基礎的な機能は高品質で安定に動作する状態を保ちつつ、新機能も効率的に開発できるようになります。Autoware Core/Universeの構成は2022年3月からすでに正式に開発に取り入れられています。また、新しくAutoware Core/Universeとして再編成するにあたり、もともとあったAutoware.Autoのコードについても、Coreにそのまま入れてしまうのではなく改めてインタフェースやアーキテクチャをUniverseで検討してからCoreとして開発することになりました。なので現時点ではCoreは空の状態ですが、2022年後半で新しいアーキテクチャの検証を行った後、徐々にコードがマージされていく予定です。

具体的にAutoware Core/Universeがリポジトリとしてどのように構成・管理されているかの詳細は次回の記事で説明しようと思います。

Autowareの開発に参加するには

最後に「Autowareを使いたい」「Autowareの活動に参加したい」という方のために参考になるAutowareのドキュメンテーションやコミュニケーションツールについて紹介します。いきなりWork Groupに参加するのはハードルが高いという方は、ここで紹介するDiscussionやIssueでのやり取りから慣れていくのがおすすめです。

Autoware Documentation: Autowareのインストール方法やチュートリアルが書いてあります。手始めにAutowareを動かしてみたいという方はまずこちらをご参照ください。
GitHub Discussions: Autowareに関して、よりよい実装や運営方針の改善といったを話すための掲示板です。幅広いトピックを扱っていますので、なにかAutoware関連で困ったらここで質問すると良いかと思います。議題はカテゴリで分類分けされているので、よく使われるものについてここで簡単に説明します。
Q&A: 質問カテゴリです。Documentationの通り実行したけど動かないので助けてほしい、といったような場合はこちらで質問してください。
Design: Autowareの新機能の設計について意見交換したかったり、現在の設計変更したかったりする場合はこちらで相談してください。
Show and tell: Autowareを新しい車両で動かせるようになったり、新しい開発ツールを紹介したい場合はこのカテゴリで自慢してください。
AutowareリポジトリのIssue: Autowareのバグ報告などはこちらで行います。もし、Autowareが動かないけど前提となるミドルウェアやライブラリのバージョンが異なっていたりと、Autowareそのもののバグか特定できない場合は、DiscussionのQ&Aでまず質問することをおすすめします。
Autoware Discord: 開発者同士でインスタントメッセージを送るときに使います。WGの参加者同士のコミュニケーションのや特定の人やグループでちょっとしたい会話をするために使います。

多くの場合、誰か困りごとがある場合は別の人も同じように困っていることが多いので、気軽にこれらの環境や場を活用してください。みんなでコミュニティで意見を交わすこと自体がAutowareの資産になります！

まとめ

この記事ではAutowareとAutowareのコミュニティに関する概要について説明しました。Autowareに興味を持った皆様の導入の助けになっていれば幸いです。最初に述べたとおり、より具体的なAutowareの構成管理や使い方についてはも引き続きTech Blogで紹介していきますので楽しみにしていてください。

最後に、ここまで記事を呼んでくださった方にお願いです。AutowareのGitHubにスターをつけてもらえると開発の励みになりますので、ぜひお願いします！

AutowareのGitHubページを開き、Sign inボタンからご自身のGitHubアカウントにログイン後、Starボタンを押せばスター完了です。GitHubアカウントをお持ちでない方も、Sign upボタンから無料アカウントをすぐに作成できます。