【編集後記】Apolloオープンプラットフォームの業界における影響力は、開発者の使いやすさの問題とは対照的に、影響力ベースのコミュニティ価値とユーザーエクスペリエンスベースの製品価値との間にギャップがあることが本質です。では、オープンソースの自動運転プラットフォームにおける開発者の技術開発エクスペリエンスを向上させるにはどうすればよいでしょうか? この記事の著者は、Apollo オープンプラットフォームをベースにした長期的な実践を通じて、その答えを導き出しました。
著者 | Hu Kuang、Wang Fanghao 編集者 | Yang Yang
制作｜『新人プログラマ』編集部
現在、自動車産業は科学技術革命と産業変革の新たな段階に入り、自動運転は新たな技術の頂点となり、国内外の伝統的な自動車会社やテクノロジー企業が次々と導入を進めている。百度は10年前、自動運転関連の研究開発への投資を開始した。2017年にアポロ計画が正式に発表されました。
6 年間の構築を経て、Apollo オープンソース プロジェクトは GitHub で 23,000 を超えるスターを獲得し、コミュニティでも非常に人気があります。ただし、自動操縦システム自体の複雑さと、Apollo のオープンソース コードの巨大なプロジェクトにより、Apollo を使用するには敷居が高くなります。基本的な開発者にとって、基本的なインストールから使用、開発、デバッグに至るまで、開発者はさまざまな問題に遭遇する可能性があります。上級開発者にとって、Apollo システムと Robotaxis シーンは深く結合しているため、開発者が他のシーンで直接再利用することを期待している場合、敷居も非常に高くなります。多くの場合、開発者は Apollo エンジニアリング アルゴリズムの実装を参照するだけで、それを独自のシステムに移植します。
ユーザビリティの問題をより体系的に分解して定量化するために、私たちはこれまでの技術モジュールに焦点を当てていたのから、さまざまな種類の技術開発者の使用シナリオに焦点を当てて製品を再構築し、社内外の優れたオープンな開発者の経験を参照することに移行しました。ソースコミュニティにおいては、NPS（Net Promoter Score、ネットプロモータースコア）や開発者徹底インタビュー、ツールチェーンの利用状況などを採用し、体系的に開発者のフィードバックを取得し、使いやすさを測る参考指標として活用しています。
開発者の使用シナリオ
さまざまな種類の技術の開発者の違いに応じて、開発者の使用シナリオは、コンピュータシミュレーション開発とデバッグに基づく計画制御シミュレーション開発とデバッグシナリオ、知覚シミュレーション開発とデバッグシナリオ、車両適応と統合ベースのシナリオに大別できます。車両のデバッグ、実車の路上テストとデバッグのシーンについて。シーン分類を通じて、開発者のニーズをより深く理解し、共通のニーズを見つけたり、さまざまなニーズを理解したりすることができます。
開発者調査
2022 年前半から、コミュニティ初の NPS 調査を実施し、すべての開発者を対象とした半年ごとの定期的なフィードバック メカニズムを形成しました。表1は、2022年上半期の第1回NPS調査のデータです。Apollo全体のNPSは非常に高いのですが、知覚とPnC（計画と制御）の開発経験のNPSは非常に低いです。これは、Apollo コミュニティの価値と製品の価値との間のギャップについての私たちの理解をさらに裏付けています。
表 1 2022 年上半期の NPS データ
同時に、各リリースの前に、アルファ社内テストとベータ公開テストを実施し、図 1 の認識に示すように、さまざまな使用シナリオの開発者向けに SIG (Special Interest Group、特別関心グループ) を形成して、的を絞ったフィードバックを取得します。シナリオ開発者のインタビュー記録。
図 1. 知覚シミュレーション開発およびデバッグ シナリオに関する SIG 調査のフィードバック
さらに、意見や提案をさらに収集するために、コミュニティ エバンジェリストとの詳細なインタビューを定期的に実施しています。これらの方法を通じて、開発者の悩みのポイントに深く切り込み、開発者の使用におけるさまざまな問題を効果的に解決し、初心者の開発者が入門から熟練に到達できるように、上級開発者が迅速に 0 から 1 に改善できるよう支援したいと考えています。効率。
シナリオベースの分類と開発者のフィードバックの多面的な収集により、4 種類の中核的な問題を整理しました。まず、エンジニアリング能力を効率的に再利用するにはどうすればよいでしょうか? Apollo プロジェクトは複雑で、Robotaxi シナリオと深く結びついていますが、Apollo のコア機能に基づいて、どのようにして迅速に拡張し、他のシナリオに適用できるでしょうか? それをサポートするには、より柔軟で便利なリリースメカニズムが必要です。第 2 に、アルゴリズム モデルのさまざまな差別化されたアプリケーション シナリオのニーズを満たすため、または科学研究分野での新しいアルゴリズムの探索に対応するために、新しいアルゴリズム モデルを迅速に検証する方法です。 、開発とデバッグの効率を向上させるにはどうすればよいですか? 作業者が良い仕事をしたい場合は、まずツールを磨く必要があります。現在、Apollo ツールは個人の開発やデバッグのシナリオではなく、車両アプリケーションのシナリオに偏っています。個々の開発者のニーズとのギャップを埋めるために、個々の開発者ツールを開発することも重要です。最後に、学習曲線を短縮するにはどうすればよいでしょうか? 開発者の学習習慣に合ったコンテンツや製品を提供し、開発者の学習プロセスを短縮することは、製品価値を高めるために不可欠です。
次に、上記の 4 つのポイントを踏まえて、新しくリリースされた Apollo Open Platform 8.0 が開発者にもたらす価値のあるアプリケーションを、エンジニアリング技術、アルゴリズム モデル、開発ツール、知識学習の観点から詳しく紹介します。
プラットフォーム機能の効率的な再利用 - パッケージ管理のアップグレード
Apollo ソフトウェア パッケージ管理の主な目的は、自動運転システムのコンパイル出力を「モジュール」の粒度に従って標準化および整理することですが、一方では、出力パッケージを直接使用する形でコンポーネントの使用をサポートします。一方で、コンポーネントの依存関係やコンポーネントの粒度を標準化することで、コンポーネントの利用・再利用の難しさを軽減し、自動運転システムの研究開発効率を向上させます。
Apollo のソースコードは Bazel をベースに構築されており、その長所と短所は明らかですが、Bazel の高度な並列コンパイル速度のおかげで、70W 以上のソースコードを 1 時間でコンパイルできます。一方、Bazel の単一ソース ツリーの制限により、Apollo モジュールはバイナリの依存関係に依存できません。Bazel パッケージはネストされた依存関係をサポートしているため、Apollo モジュール間の依存関係が非常に複雑になり、1 つまたは複数のモジュールを単独で使用することが困難になります。
したがって、Apollo パッケージ管理は Bazel に基づいて拡張され、主にコンストラクション出力 (およびソース コードの一部) の内容を標準化し、Apollo モジュールをバイナリ形式で導入および再利用できるように関連ツールをサポートします。この記事で紹介されている概念と用語は、主に Apollo に対するビルド出力です。
さらに、Apollo パッケージは現在、CMake プロジェクトに先立って Bazel プロジェクトをサポートしていますが、Apollo パッケージは最終的には標準 DEB パッケージになり、Ubuntu オペレーティング システムにインストールしたり、CMake プロジェクトで通常のシステム パッケージとして使用したりできるようになります。
パッケージ管理の全体的なフレームワークの概要
Apollo のパッケージ管理は、図 2 に示すように、パッケージ全体のライフサイクル全体をカバーするツールのコレクションです。
図 2 Apollo パッケージ管理フレームワーク
これには次のモジュールが含まれています。
RepoServer は、ソフトウェア パッケージ用のクラウド ウェアハウスであり、パッケージ エンティティ (つまり、deb パッケージ) とパッケージ インデックスを保存します。具体的な実装としては、静的 Web サイト サービスと CDN アクセラレーション テクノロジを組み合わせて使用し、高速かつ高可用性のファイル ダウンロード サービスを実現します。
LocalRepo はソフトウェア パッケージのローカル ウェアハウスです。これは基本的なローカル ファイル システムです。標準のファイル システム仕様に従ってパッケージの内容が保存されます。これには、リモート ウェアハウスからダウンロードしてインストールされた deb パッケージと、ローカル プロジェクト構築によって作成されたローカル バージョン ソフトウェア。ローカル ウェアハウスに格納されるコンテンツには 2 つの機能があり、1 つは Apollo システムの実行時にダイナミック リンク ライブラリを提供すること、もう 1 つは Apollo コンポーネントのコンパイル時に依存関係ライブラリを提供することです。
Buildtool は、ソフトウェア パッケージを拡張コンポーネントの依存関係として使用する場合のサポート ビルド ツールです。Apollo はビルド システムとして Bazel を使用するため、拡張コンポーネントのビルドには Bazel を使用することをお勧めします。Bazel は、クラウド コンパイルやキャッシュなどのテクノロジにおいて大きな利点があります。Buildtool の現在の最下層も Bazel に基づいています (将来的には、CMake などの複数のコンパイル システムのサポートが検討されます)。
Buildtool の中心的な機能は、Apollo のソフトウェア パッケージをコンパイルの依存関係として Bazel ビルド システムに追加し、使用の複雑さを可能な限り単純化することです。ご存知のように、Bazel の依存関係システムにダイナミック ライブラリを追加するのは面倒です。まず、ダイナミック ライブラリをインストールする必要があります。Bazel は http_archive を使用してパッケージをダウンロードできますが、通常は次のようなツールを使用してオペレーティング システムにインストールされます。適切なダイナミックライブラリ。次に、new_local_repository にリポジトリを作成させ、cc_library を含む BUILD ファイルを提供する必要があります。
依存パッケージ間に相互依存がある場合、依存関係の競合を防ぐために、バージョン自体を整理する必要があります。Buildtool は、依存関係のバージョン分析、依存パッケージの自動取得、リポジトリ構成の自動生成、カスケード依存関係の自動処理などを通じて、パッケージ記述ファイル (cyberfile.xml) と連携します。これにより、上記の面倒なプロセスをユーザーのみに透過的に行うことができます。パッケージの説明に含める必要があります。依存関係を宣言するだけです。Buildtool の 2 番目の役割は、ソース コードでの Apollo のソフトウェア パッケージの使用をサポートすることです。C++ はバイナリを依存関係として使用しており、解決が難しい ABI などの問題が常に存在します。そのため、ソース コードは Apollo ソフトウェア パッケージの標準コンテンツとしても使用されます。Buildtool は、パッケージのソース コードを同時に、Buildtool は複数のソース パッケージのコンパイル シーケンスも管理します。
構築中に Buildtool を使用してダウンロードしてインストールすることに加えて、Apt などのツールを使用してインストールして直接使用することもできます。たとえば、Dreamview を使用してレコード ファイルを再生するシナリオでは、Apollo プロジェクトをコンパイルする必要はありません最初から、apt installapollo-neo-dreamview-dev を使用して、dreamview とその依存関係をローカルに置き、データ パッケージを再生してデータを確認します。
パッケージ管理のさまざまなコンポーネントが導入されました。そのすべての機能は無人運転システム自体とは何の関係もないことがわかりますが、それはアポロの開発にどのような影響を与えるのでしょうか? アポロのオープンソースプロジェクトは無人運転システムの完全なセットですが、ビジネスシナリオが異なるため、開発者はプロジェクトの完全なセットを特定のシナリオに直接展開するのではなく、自分たちに適した機能やアルゴリズムなどを選択して実装します。独自のプロジェクトで使用されます。
しかし、モノリシック リポジトリの現在の組織構造では、さまざまな機能コンポーネント間に結合があり、それらを分離して個別に使用するには多大なコストがかかるため、多くの開発者が自分でコードを再実装することになります。しかし、これでは開発者の時間とコストが無駄になるだけでなく、開発者の拡張コンテンツも貢献できなくなります。
ソフトウェアパッケージ管理では、開発者が機能モジュールの粒度に応じたバイナリライブラリ（またはソースコード）の形で高度なテクノロジーを直接利用できる一方で、より軽量で巨大なモノリシックバージョンも開発者に提供します。ソース コードを分離して独自の拡張機能を共有する方法、つまり、Apollo ソフトウェア パッケージの仕様に従って独自のソフトウェア パッケージを開発/公開する方法は、Apollo オートパイロットの健全な開発の基礎を築きました。システムエコロジー。
新しいモデルを迅速に検証 - 認識フレームワークのリファクタリングから開始
ディープラーニング技術の継続的な開発により、自動運転知覚の分野は近年目覚ましい進歩を遂げています。ディープラーニングモデルの更新速度が非常に速いため、毎年新しいモデルが登場するため、モデルをいかに迅速にリリースして検証するかが自動運転認識における重要な課題となっています。同時に、ほとんどのコミュニティ開発者がモデル自体により多くの注意を払っていることにも気づきました。フルスタックの認識フレームワークである Apollo には、モデル自体 (つまり、アルゴリズム部分) だけでなく、タスク フレームワークも含まれています。現在、一般的なタスクには、信号機検出、車線境界線検出、物体検出が含まれます。アルゴリズム開発者をフレームワークから解放し、アルゴリズム自体にもっと集中するために、私たちは Apollo 認識フレームワークをアップグレードし、アルゴリズムとフレームワークの分離を実現しました (図 3 および図 4 を参照)。
図 3 アップグレード前の Apollo 認識フレームワーク
図 4 アップグレードされた Apollo 認識フレームワーク
トレーニングされたモデルには、大量のコードを開発することなく、必要に応じて柔軟にアクセスできます。同時に、エンドツーエンドのモデル検証をサポートするテスト検証ツール チェーンも導入され、それによって認識アルゴリズムの実装が大幅に高速化されます。フレームワーク部分については、さまざまなタスク パイプラインに従って構成することで、提供されたモジュールを再利用できます。このようにして、ユーザーは設定に従ってのみ認識タスクの開発要件を満たすことができます。
上記 2 つのアップグレードにより、認識モジュールのアルゴリズム開発とタスク パイプラインを分離することに成功しました。これにより、認識モジュールの検証と反復速度が高速化され、開発効率が大幅に向上しました。現在では、モデルの立ち上げまでに最速で 1 ～ 2 日しかかかりません。
モデル
Paddle3D を導入することで、より多くのモデルをサポートできるだけでなく、トレーニング ツールの完全なセットも提供できます。同時に、当社は定期的に Paddle3D と協力して自動運転知覚の方向に向けたコンテストを開催し、最新モデルをフォローアップし、Apollo 知覚アルゴリズムの主導的地位を確保しています。
Paddle3D との緊密な連携を通じて、自動運転認識タスクのベンチマークを確立し、モデルのトレーニングおよび展開コードをリリースしました。開発者はコミュニティで最新モデルを見つけて比較利用したり、自社で二次開発を行ったりすることができます。
フレーム
2 番目の比較的大きな変化は、フレームのアップグレードです。以前の認識モジュールでは、タスクとモジュールの区別はあまり高くなく、ディレクトリ ファイルは主にセンサーを通じて整理されていました。その結果、ユーザーは特定の部分の機能を理解するためにモジュール全体を深く掘り下げる必要があり、パイプライン全体の構成は比較的分散しており、ユーザーがパイプラインを変更する場合は、別の構成ファイルから変更する必要があります。ユーザーにとって良くありません。
フレームワークのアップグレード後、タスク パイプラインに応じてさまざまなコンポーネントを作成し、コンポーネントの概念を導入しました。さまざまな前処理、後処理、その他のコンポーネントを通じて、ユーザーは構成ファイルを通じてさまざまなコンポーネントを選択するだけで新しいパイプラインの導入と開発を実現できるため、モデルの導入がよりスムーズになります。
開発とデバッグの効率を向上 - 完璧なツールチェーン
自動運転は従来のインターネットによるソフトウェア開発とは異なり、第一に実車テストのコストが高く、第二にデータ量が膨大です。自動運転開発プロセスのニーズを満たし、研究開発の効率を向上させる一連の研究開発インフラは非常に重要です。Apollo はバージョン 1.0 以来、「車 + クラウド」自動運転研究開発の反復モデルを先駆けて開発し、Apollo データ プラットフォームを外部にリリースしました。クラウドを通じてデータ利用効率の問題を解決し、シミュレーションと組み合わせることで実車試験のコストを削減し、アポロベースの自動運転研究開発の効率を大幅に向上させることができます（図5参照）。
図5 「クルマ＋クラウド」の自動運転研究開発の反復モデル
「自動車+クラウド」自動運転研究開発反復モデルは、Apolloベースのオンボード統合デバッグのための技術的反復インフラストラクチャ保証を提供し、自動運転技術の路上テストを効率的にサポートすることで、オンボード閉ループ検証を実現します。同時に、車載検証前のローカル開発と開発者のデバッグも、自動運転の研究開発の反復ライフサイクル全体において同様に重要な部分ですが、この部分の需要は、以前の Apollo バージョンでは十分に満たされていませんでした。開発者のローカル開発とデバッグの効率をどのように改善するか、また自動運転の研究開発反復のライフサイクル全体の観点から研究開発の効率を改善する方法は、開発者の使いやすさの観点から、Apollo オープン プラットフォームのもう 1 つの重要なタスクです。
フローチャート (図 6) からわかるように、自動運転の研究開発プロセスには実際には 2 つの反復サイクルが含まれます。1 つはモデルの反復、もう 1 つはコードの反復であり、どちらもデータによって駆動されます。データ駆動型のモデル構成の反復。主に自動運転車の統合 (車両のキャリブレーション、センサーのキャリブレーション、制御評価など) とモデルのトレーニングのための研究開発クラウド サービスが含まれます。車両側のインテリジェント データ コレクターを通じてデータを収集し、クラウド ツール サービスを駆動して車両モデル構成を生成し、車両側への OTA により反復閉ループを完了します。データ駆動型のコード反復。主に、開発、デバッグ、回帰テストのための Apollo シミュレーション クラウド サービスが含まれます。Apollo シミュレーション クラウド サービスは、カスタマイズしてローカルの開発マシンにダウンロードできるシミュレーション デバッグ シナリオと、クラウドでの大規模クラスターの同時テスト機能を提供します。車両側の継続的なデータ収集を通じてシミュレーション シナリオを強化し、運転コードは継続的に改善および検証され、最終的に車両側への OTA によってコード反復の閉ループが実現されます。
図6 自動運転の研究開発ライフサイクル
開発者のデバッグ効率の点では、バージョン 8.0 では主に次の新機能が追加されており、PnC のデバッグ効率は 2 倍以上になっています。
ローカル シミュレーション デバッグのサポート: Dreamview に基づくローカル シミュレーション コンテナを提供し、ローカル PnC シミュレーション デバッグをサポートします。開発者は、Dreamview エミュレータを使用して車両の運転をシミュレートし、さまざまなシナリオをローカルで再現できます。
便利なシミュレーション シーン管理:シミュレーション シーンのクラウドベースのカスタム作成、編集、グループ管理を提供し、ワンクリックでシーン、動的モデル、データ パッケージをクラウドからローカルの Dreamview にダウンロードします。シミュレーション シーンの同期は、クラウド シミュレーションの評価とローカル デバッグの 2 つのシナリオをサポートします (図 7 を参照)。
図 7 Dreamview に基づくローカル シミュレーションのデバッグ
学習曲線を短縮する - Apollo Studio の新しい学習コミュニティ
これは、技術エンジニアリングおよびツール製品のユーザビリティの問題を解決するものであり、開発者の学習曲線を短縮するために学習リソース サービスをサポートする必要もあります。氷山モデル理論に基づいて、個人の能力は、まず知識とスキルから能力に変換されます。開発者の学習習慣に合わせたナレッジコンテンツや製品機能を提供し、開発者の学習プロセスを短縮することは、Apolloオープンプラットフォームの製品価値を高めるために不可欠です。そこで、昨年 8 月に、Apollo オープン プラットフォーム テクノロジー コミュニティの公式 Web サイトである新しい Apollo Studio を立ち上げました。Apollo Studio コミュニティは、最新の Apollo オープンソース プロジェクトとツール チェーンに基づいており、開発者がコースの内容を浅いものから深いものまでを通じて自動運転の知識を学び、コースの内容に合わせた実験を通じてスキルを鍛え、最終的にソリューションを改善するのに役立ちます。競争クイズを通して、問題を解く能力を養います。
現在、Apollo Studio では、Apollo Newcomer Tour、Apollo Autopilot Basic Course、Apollo PnC Special Course など、エントリーから基礎、特別コースまでの段階的なコースを提供しています。総授業時間は200時間近くに達し、5か月でコースの再生回数は100万回を超えました。コースに付随する実験も開発者に好評で、使用回数は 100,000 近くあります。この競技テスト システムは、2022 年の Apollo Urban Road 自動運転シミュレーション コンテストを効果的にサポートし、全国の約 200 の大学から 500 以上のチームから 2,000 名以上の参加者を集めました。
Apollo Studio は、開発者の成長を支援するコース、実践的なトレーニング、コンテストを統合した自動運転学習実践コミュニティを開発者に提供します。
要約する
自動運転機能から開発者の使いやすさに至るまで、Apollo オープン プラットフォームは多次元で革新を続けています。
Apollo Open Platform 8.0 は、パッケージ管理の導入により、リリースプロセスにおけるモジュール間の依存関係を完全に分離するための基盤を築き、さまざまなニーズを持つ開発者に Apollo の機能を直接再利用および拡張するための柔軟なスペースを提供します。
認識フレームワークを再構築し、モデルのトレーニング プロセスをオープンにすることで、新しいモデルを拡張する際のトレーニング、展開、検証のコストが大幅に削減され、開発者は新しいモデルの機能により集中できるようになります。
Dreamviewベースのローカルシミュレーションデバッグの導入とクラウドシミュレーションとの連携により、開発者の計画、制御、開発、デバッグの効率が大幅に向上します。
新しく立ち上げられた Apollo Studio コミュニティを通じて、学習習慣に合わせたコース、実験、能力テストツールを開発者に提供し、開発者の学習と成長を支援します。
今年上半期の NPS 調査では、開発者からも肯定的なフィードバックをいただき、パーセプション開発とデバッグ、PnC 開発とデバッグ、コミュニティの NPS がすべて大幅に増加しました (表 2 を参照)。
表 2 2023 年上半期の NPS 結果
バージョン 8.0 以降、私たちは Apollo オープン プラットフォームの開発者エクスペリエンスの強化を続けます。コア層認識モジュールと計画モジュールのパッケージ ロジック分割を最適化して、開発者の二次拡張開発ニーズをより適切に満たし、オリジナルのその他のオプション シーンにも対応します。 Robotaxi シーンでは、シーン アプリケーション層の柔軟な選択を実現するためのサポートが提供されています (図 8 を参照)。
図 8: Apollo オープンソース コード アーキテクチャ
ツールチェーンでは、Dreamview ベースのローカル開発とデバッグのエクスペリエンスをさらに最適化し、Dreamview を Apollo 開発者ツールのエントリ ポイントにします。知覚シミュレーションの開発とデバッグ、計画と制御シミュレーションの開発とデバッグ、車両の適応と統合、実車の路上テストとデバッグのシナリオをカバーし、さまざまなビジュアル デバッグ ツール、診断情報ツール、カスタム ビュー機能を提供します。コミュニティでは、サイバー RT、知覚関連の特別コース、実験や評価の質問をサポートする、より多くの技術モジュールを提供します。
著者について
胡光、アポロ伝道者。中国科学院ソフトウェア研究所コンピュータサイエンス修士、清華大学MBA。IBM で技術研究開発とイノベーション管理を担当し、国内外で 20 件を超える特許を取得しています。2014年にBaiduに技術管理職として入社し、現在はApolloオープンプラットフォームの製品・運用責任者として、Apolloオープンプラットフォームの全体的なアーキテクチャ設計と実装を担当している。
Apollo エバンジェリストの Wang Fanghao 氏は、武漢大学で電子情報を専攻し、現在は主に L4 レベルの自動運転の開発に従事しており、技術を研究し、ソースコードを分析し、質問に答えることが好きです。
