Autowareコミュニティからのインサイト：第一線メンバーの対話
連載企画「TIER IV PEOPLE」は、志をともにする個性豊かで魅力的なメンバー一人ひとりに焦点を当てて紹介します。
世界初の自動運転用オープンソースソフトウェア「Autoware」は、ティアフォーが開発をリードしています。持続可能なエコシステムを作り、より多くの人が自動運転のソリューションを享受できるようにするという揺るぎないコミットメントのもと、ティアフォーはThe Autoware Foundation（AWF）と協力し、自動運転技術の発展を加速させ、Autowareコミュニティ内のコラボレーションを促進しています。
最新のインタビューでは、AWFのTechnical Steering Committeeの委員長であるティアフォーの満留諒介と、AWFのアーキテクトであるLeo DriveのM. Fatih Ciritの対談をお届けします。このダイナミックなパートナーシップから、自動運転技術の卓越性の追求という両者共通の想いが見えてきます。
Ryohsuke Mitsudome | R&D Unit, Architect at TIER IV, Technical Steering Committee Chair of AWF
自己紹介
満留：ティアフォーのソフトウェアアーキテクトで、AWFのTechnical Steering Committeeの委員長を務めている満留諒介です。Fatihと密に協力しながら、AWFの技術面を統括しています。
M. Fatih Cırıt | Tech Lead at Leo Drive, Software Architect of AWF
Fatih：AWFでソフトウェアアーキテクトを担当しているFatihです。
満留：Leo Driveについての考えから始めましょう。せっかくティアフォーに来ていただいたので、Leo DriveとAWFのエンジニアとして、私たちやAWFと協力して業務を行った経験について聞かせください。その前に、ティアフォーでの経験はいかがでしたか？
Fatih：ティアフォーのオフィスに来たのは、開発プロセスやオフィス環境を知るためだけでなく、日本文化を思い切り楽しむためでもありました。
満留：浅草やスカイツリー、お花見にも行かれたんですよね。このようなことをすべて経験できたのはすごいです！
Leo Drive, The Autoware Foundation and TIER IV
ティアフォーのパートナーシップとコミットメント
満留：まず、ティアフォーがLeo Driveとのパートナーシップについてどう考えているか話ししましょう。AWFへの最初の加入メンバーではありませんが、Leo Driveは貢献をもたらしてくれる重要な企業となっています。重要なメンバーとなり、様々なワーキンググループに積極的に参加し、主導もしています。代表的な功績のひとつに、バスODD（Operational Design Domain）プロジェクトがあります。
Leo Drive、ITRI、いすゞが共同でAutoware.Universeをバスに組み込み、その性能を披露しました。2月に行われたデモでは、Autoware.Universeがバスにシームレスに統合され、アクセルやブレーキ、バスのドアの開放からバス停への到着まで、スムーズな運転を披露しました。
Fatih：多くのソフトウェア開発や統合プロジェクトと同様に、Autowareスタックへの統合には、限られたドキュメントや安定性の問題による課題がありました。しかし、最終的にはそのほとんどを克服できました。CI/CD（Continuous Integration and Deployment）パイプラインにおいても、ブレーキに変更が起こる可能性がありました。
満留：バスODDプロジェクトが完了した今、この内容はAutowareの最初のリリースに含まれ、他のユーザーにとってもスムーズな統合が可能になります。CI/CDについては、間違いなく改善が必要です。最初のCI/CDパイプラインには多くの開発がありましたが、もっと多くのエンジニアに取り組んでもらい、改善すべきだと思っています。
エンジニアリングとノードの課題
Fatih：現在、Autowareでノードがクラッシュした場合、その原因を正確に把握するのは困難です。また、どのノードがクラッシュしたのかを見つけることも難しいです。Autowareで何かがクラッシュした際、障害の発生源とクラッシュの理由を正確に把握できるようにするために、より優れた健全なモニタリングシステムが必要です。
満留：そうですね、診断ツールの改善は不可欠です。Leo Driveのエンジニアは、Autowareをよく理解しています。ROSだけでなく、Autowareとその仕組みについてもです。Leo Driveには特別なトレーニングプログラムがあるのですか？
Fatih：ROS 2のチュートリアルやドキュメントに沿って作業をしたり、オンラインコースに参加したり、ピアトレーニングを受けたりしています。これにより、先輩の開発者が後輩の開発者を指導し、プロセスの仕組みや開発全般に関する情報を得る方法をよく理解できるようにしています。
Leo Driveから見るTIER IV
満留：ティアフォーはどう見えますか？
Fatih：ティアフォーは素晴らしいです。オープンソース開発を強調するビジョンを持っています。ティアフォーが開発したツールやその開発への取り組みは、仕事をする上で本当に役に立ちます。職場や、特に自動運転車両、センサー、コンピューティング機器を備えた車庫は印象的です。リモートテストのために車両のセットアップをモニターする外部機器もあります。ティアフォーの自動運転車両の開発方法は感銘を受けます。中核となる開発とテストや統合を分けることで、よりスムーズなプロセスを実現しています。このアプローチに感心しています。
満留：当初は、ティアフォーのセットアップはLeo Driveと同じでした。中心となる開発者が開発と車両統合の両方を管理していました。コードの影響やアルゴリズムの改善方法を理解するためにこの方法を継続していますが、現在ではIntegrationチームに専門のチームがあります。
TIER IVとAWFの関係を築く
満留：ティアフォーとAWFとの関係について、どのように考えていますか？私としては、より多くのエンジニアにAWFのワーキンググループに参加するよう奨励することで、エンゲージメントを高めることができると思っています。GitHubでの文字ベースのディスカッションだけに頼るのではなく、実際に話し合うことでより影響を与えることができると思います。新しいワーキンググループが設立されましたが、どのように発展していくと思いますか？Leo DriveとAWFのエンジニアとして、これはコミュニティに利益をもたらすと思いますか？
Fatih：ソフトウェアワーキンググループとミーティングは継続的に行ってきました。特定の分野でさらに3つのワーキンググループを行うことは有益だと思います。ソフトウェアワーキンググループは範囲が広すぎたため、何かの議題に集中した議論をするのが困難でした。知覚センシング、プランニングとコントロール、ローカライゼーションとマッピングのワーキンググループが隔週で開催されるようになったことで、参加者が増えることを期待しています。これにより、エンジニアは自分たちの発見を推進し、一緒になってAutowareの改善を促進することができます。
満留：Leo Driveが提案した、ソフトウェアワーキンググループのサブワーキンググループのコンセプトは素晴らしいです。各ワーキンググループ内での専門的な議論が可能になりました。プランニングのワーキンググループのチームリーダーは、多くのエンジニアに参加して欲しいと思っています。AWFのメンバー間のコミュニケーション強化は、相互の成長に不可欠であると思っています。
Autowareコミュニティの未来を創る
満留：ティアフォーとLeo Driveに焦点を当ててきましたが、Autowareコミュニティをどのように変え、向上させることができるか、考えを教えてください。私たちがAWFの中で重要な役割を担っていることを考えると、その将来像や自動運転技術の発展における役割についてビジョンを持っていることは確かです。協力するメンバーとして、どのように考えていますか？
Fatih：Autowareの大きなビジョンは、世界中の誰もがアクセスできる標準的な自動運転用オープンソースソフトウェアとして確立することです。これは、他のAWFのメンバーの目標とも一致していると思います。正しい方向に向かっていますが、この目標を実現するためにはさらなるステップが必要です。
満留：おっしゃる通り、Autoware committeeをさらに拡大し、より使いやすいものにするために、ボードメンバーからの方向性をきちんと知っておきたいと思います。そうすることで、より多くのコミュニティーメンバーを惹きつけることができます。
しかし、Autowareのユーザーと貢献してくれるメンバーの数にはまだギャップがあります。新しい課題や議題を見つけていくことは重要ですが、コードレベルで貢献してくれるメンバーがもっと必要です。ユーザーにもっと積極的に貢献してもらうにはどうしたらいいでしょうか？
Fatih：その通りですね、Autowareプロジェクトの複雑さは大きな課題です。約250個のパッケージと多数のノードがランタイムにあるため、多種多様なシナリオを通して自動運転をするのは複雑です。これに対処するための最初のステップは、ドキュメントを改善し、各パッケージの包括的なガイドラインとチュートリアルを作ることです。明確な説明、詳細な図、簡略化された手順を作ることで、貢献してくれるメンバーが参加しやすくなるでしょう。
満留：まさにおっしゃる通りです。Autowareを実行するための基本的なコマンドラインのチュートリアルはありますが、内部構造やアーキテクチャ、ノードの機能性を説明する包括的なドキュメントが不足しています。ドキュメントを作るためにはより多くのエンジニアが必要ですが、ドキュメントがなければ貢献してくれる新しいメンバーを得ることが難しい、鶏と卵のような問題があります。このサイクルを断ち切るための第一歩を踏み出す必要があります。Autowareコミュニティで何か具体的な改善案は挙がりましたか？
Fatih：現在、Autowareプロジェクトのデバッグと安定性向上は優先事項です。これを改善するために、「Autoware Node」と呼ばれる必要不可欠なパッケージを含むAutowareコアを開発しています。このパッケージは、他のすべてのノードが中核モニタリングシステムと通信するためのベースとなるもので、「Autoware Control Center」などと呼ぶことができます。このシステムにより、デバッグの透明性が大いに高まると思っています。さらに、新しいノード用のテンプレートを作り、パッケージの作成と検証を簡素化する予定です。
満留：つまり、ROSのcreate packageのコマンドに似ているけれど、Autoware用の仕様に変更されているのですね。新しいパッケージの開発を簡易化するために、Autowareのノードの基本クラスと統合する必要があるかもしれないですね。
Fatih：また、リグレッションや失敗を防ぐために、テストと検証を優先すべきだと思います。
満留：そうですね、コードの安定性を確保し、混乱を防ぐためには、シナリオシミュレーターや強固な検証ツールを通じて、Autowareはより信頼性が高く、使い安いものへと進化していくでしょう。これらの取り組みがAuwatowareコミュニティの未来を輝かせる一歩となることを期待し、共に協力し続けましょう。
