このアルゴリズムにより、オンラインで高精度の地図を構築できます。私たちの手法である MapTracker は、センサー ストリームを 2 つのディスプレイのメモリ バッファーに蓄積します。1) 鳥瞰図 (BEV) 空間のラスター 潜在、2) 道路要素 (横断歩道、車線、道路境界線) 上のベクトル 潜在。この方法は、オブジェクト追跡におけるクエリ伝播パラダイムを利用し、前のフレームの追跡された道路要素を現在のフレームに明示的に関連付けながら、メモリ潜在のサブセットを距離ストライドと融合して、より良い結果を実現します。オープンソース リンク: https:/。 /map-tracker.github.io/
要約すると、この記事の主な貢献は次のとおりです: 
HD マッピングを追跡タスクとして定式化する新しいベクトル HD マッピング アルゴリズム、および潜在メモリの履歴を活用する時間的な一貫性を実現するための両方の表現。
時間一貫性のある GT と一貫性を意識した mAP メトリクスを備えた改良されたベクトル HD マッピング ベンチマーク。従来のメトリクスと新しいメトリクスに関して、現在の最良の方法に比べて大幅に改善されました。
自動運転におけるメモリ設計
。シングルフレームの自動運転システムは、オクルージョン、センサーの故障、または複雑な環境に対処することが困難です。メモリを使用した時間モデリングは、有望な追加機能を提供します。ほとんどの自動運転タスクの基礎を形成する BEV 機能をグレーティングするために、多くのメモリ設計が存在します。 BEVDet4D および BEVFormerv2 は、過去の複数のフレームの特徴をメモリに重ね合わせますが、計算は履歴の長さに応じて線形に拡大するため、長期的な情報を取得することが困難になります。 VideoBEV は、BEV ラスター クエリをフレーム全体に伝播して、ループ内に情報を蓄積します。ベクトル ドメインでは、Sparse4Dv2 はターゲット クエリに同様の RNN スタイルのメモリを使用しますが、Sparse4Dv3 はさらに堅牢な時間学習のために時間ノイズ除去を使用します。これらのアイデアは、ベクトル HD マッピング手法に部分的に組み込まれています。この論文は、格子 BEV 待ち時間と道路要素のベクトル待ち時間のための新しいメモリ設計を提案します。ベクトル HD マッピング
。従来、高精度マップは SLAM ベースの方法を使用してオフラインで再構築され、その後手動で管理されていたため、高額なメンテナンス コストが必要でした。精度と効率の向上により、オフライン地図アルゴリズムよりもオンラインベクトル高精度地図アルゴリズムが注目を集めており、生産プロセスが簡素化され、地図の変更に対応できます。 HDMapNet は、後処理を通じてラスター イメージ セグメンテーションをベクター イメージ インスタンスに変換し、最初のベクター HD マッピング ベンチマークを確立しました。 VectorMapNet と MapTR は両方とも、エンドツーエンドの予測に DETR ベースのトランスフォーマーを利用します。前者は検出された各曲線の頂点を自己回帰的に予測しますが、後者は階層クエリとマッチング損失を使用してすべての頂点を同時に予測します。 MapTRv2 は、補助タスクとネットワーク変更によって MapTR をさらに補完します。曲線表現、ネットワーク設計、トレーニング パラダイムは他の研究の焦点です。 StreamMapNet は、BEV 認識におけるフローのアイデアを活用することで、一貫したマッピングに向けた一歩を踏み出しました。そのアイデアは、過去の情報を潜在メモリに蓄積し、それらを条件として渡すことです (つまり、条件検出フレームワーク)。 SQD MapNet は DN-DETR を模倣し、時間学習を促進する時間曲線ノイズ除去を提案します。MapTracker
2 つのシンプルなアイデアとメモリ メカニズムにより、一貫したマッピングが実現されます。最初のアイデアは、現在のフレームに単一のメモリの代わりに履歴メモリ バッファを使用することです。単一のメモリには履歴全体の情報が含まれているはずですが、特に多数の車両が道路構造物をふさいでいる乱雑な環境では、記憶が失われやすくなります。具体的には、効率と適用範囲を考慮して、車両の動きに基づいて各フレームで融合する過去の潜在記憶のサブセットを選択します。 2 番目のアイデアは、オンライン HD マップを追跡タスクとして定式化することです。 VEC メモリ メカニズムは、各道路要素の潜在メモリのシーケンスを維持し、追跡文献からクエリ伝播パラダイムを借用することでこの定式化を簡素化します。このセクションの残りの部分では、BEV および VEC メモリ バッファーとそれらに対応するネットワーク モジュールを含むニューラル アーキテクチャ (図 2 および 3 を参照) について説明し、その後トレーニングの詳細を紹介します。
BEV メモリは、BEV 座標系に潜在する 2D であり、車両を中心とし、t 番目のフレームの方向を向いています。空間寸法 (つまり、50×100) は、左右 15 メートル、前後 30 メートルの長方形エリアをカバーします。各メモリ レイテンシには過去の情報全体が蓄積され、バッファはそのようなメモリ レイテンシを最後の 20 フレームに維持するため、メモリ メカニズムは冗長ですが堅牢になります。
VECmemory はベクトル レイテンシのセットであり、各ベクトル レイテンシはフレーム t までアクティブな道路要素の情報を蓄積します。アクティブな要素の数はフレームごとに変化します。バッファには、過去 20 フレームの潜在ベクトルとフレーム間の対応関係 (つまり、同じ道路要素に対応する潜在ベクトルのシーケンス) が保持されます。
入力は、1) 航空機サラウンド画像の CNN 特徴と画像バックボーンによって処理されるそのカメラ パラメーター、2) BEV メモリ バッファー、および 3) 車両の動きです。以下では、BEV モジュール アーキテクチャの 4 つのコンポーネントとその出力について説明します。
出力は、1) バッファーに保存され、VEC モジュールに渡される最終メモリ MBEV(t)、および 2) セグメンテーション ヘッドによって推論され、損失計算に使用されるラスター化された道路要素ジオメトリ S(t) です。セグメンテーション ヘッドは、メモリ内の潜在的な各ピクセルを 2×2 セグメンテーション マスクに投影し、100×200 のマスクを生成する線形投影モジュールです。
入力は、BEV メモリ MBEV(t) とベクトル メモリ バッファおよび車両の動きです。
出力は、1) MVEC(t) からの単一の完全に接続された層からの分類によってテストされた「正の」道路要素の最終記憶、および 2) MVEC(t) ベクトル道路ジオメトリから 3 層 MLP によって回帰されました。ポジティブな道路要素を備えています。
BEV損失:
VEC損失。マルチオブジェクト追跡用のエンドツーエンド変換器である MOTR からインスピレーションを得て、GT 追跡を明示的に考慮するためにマッチングベースの損失を拡張しました。新しい要素に対する最適なインスタンス レベルのラベル割り当ては次のように定義されます:
次に、すべての出力と GT の間のラベル割り当て ω(t) が帰納的に定義されます:
ベクトル出力の追跡スタイル損失は次のとおりです。
コンバージョンロス。 PropMLP をトレーニングするために StreamMapNet から変換損失 Ltrans を借用し、潜在空間でのクエリ変換を強制してベクトル ジオメトリとクラス型を保持します。最後のトレーニング損失は次のとおりです:
MapTR は、nuScenes と Agroverse2 データセットからベクトル HD マッピング ベンチマークを作成し、その後の多くの研究で採用されました。ただし、横断歩道は単純に結合されており、フレーム間で一貫性がありません。この分割線は、(Argoverse2 の) グラフ追跡プロセスの失敗とも一致しません。
StreamMapNet は VectorMapNet のコードを継承し、ワークショップ チャレンジで使用されたより現実的なベンチマークを作成します。ただし、いくつかの問題が残っています。 Argoverse2 では、ディバイダが短いセグメントに分割されることがあります。 nuScenes では、大きな横断歩道によって小さなループが分割される場合があり、その不一致が各フレームでランダムに現れ、一時的に不一致な表現が発生します。付録では、既存のベンチマーク問題の視覚化を提供します。
既存のベースラインの処理コードを改善して、(1) 各フレームの GT ジオメトリを強化し、(2) フレーム間の対応関係を計算して GT の「軌道」を形成します。
(1) すべてのフレームのジオメトリを強化します。コミュニティで人気のある MapTR コードベースを継承し、改良しましたが、2 つの変更を加えました。1 つはウォーキング エリアの処理を StreamMapNet での処理に置き換え、より幾何学的制約を増やして品質を向上させ、グラフ トラッキング アルゴリズムを強化して元の注釈からのノイズを処理し、時間的一貫性を強化しました。除算処理 (Argoverse2 のみ)。
(2) トラックを形成します。各フレーム内の道路要素の形状を考慮して、隣接するフレームの各ペア間の最適な 2 部マッチング問題を解き、道路要素間の対応を確立します。対応関係のペアがリンクされて、道路要素の軌道が形成されます。道路要素のペア間のマッチングスコアは次のように定義されます。道路要素のジオメトリは、多角形の曲線またはループです。車両の動きに基づいて要素ジオメトリを古いフレームから新しいフレームに変換し、一定の厚さを持つ 2 つのカーブ/ループをインスタンス マスクにラスタライズします。和集合上のそれらの交点が一致スコアとなります。
mAP メトリクスは、一時的に矛盾した再構築にペナルティを与えません。標準の mAP 手順と同様に、再構成された道路要素と各フレームのグラウンド トゥルースを面取り距離と個別に照合し、次のチェックによって一時的に矛盾する一致を排除します。まず、追跡情報を予測しないベースライン手法については、GT の時間的対応を取得するために使用したのと同じアルゴリズムを使用して、再構築された道路要素の軌道を形成します (また、アルゴリズムを拡張して、速度をトレードオフすることで欠落している要素を再識別します。詳細については、を参照してください)。詳細は付録）。次に、前のフレームで同じ軌道に属する道路要素を「祖先」とします。シーケンスの先頭から、祖先のいずれかが一致しない場合は、すべてのフレーム一致 (再構築された要素とグラウンド トゥルース要素) を一時的に不一致として削除します。残りの時間的に一貫した一致は、標準 mAP の計算に使用されます。
私たちは、8 つの NVIDIA RTX A5000 GPU を使用して、nuScenes で 72 エポック、Argoverse2 で 35 エポックでモデルをトレーニングしながら、StreamMapNet コードベースに基づいてシステムを構築しました。 3 つのトレーニング ステージのバッチ サイズはそれぞれ 16、48、16 です。トレーニングには約 3 日かかり、推論速度は約 10 FPS です。データセット、メトリクス、ベースライン手法について説明した後、このセクションでは実験結果を示します。
私たちの貢献の 1 つは、2 つの既存の対応物、つまり MapTR と StreamMapNet 上で時間的に一貫したグラウンド トゥルース (GT) を実装したことです。表 1 と表 2 は、3 つの GT (最初の列に表示) の 1 つでシステムをトレーニングおよびテストした結果を示しています。私たちのコードベースは StreamMapNet に基づいているため、StreamMapNet GT およびアドホック コンシステント GT でシステムを評価します。
nuシーンの結果。表 1 は、MapTRv2 と StreamMapNet の両方が GT を使用してより優れた mAP を実現していることを示しています。これは、元の GT の不一致を修正するときに予想されることです。 StreamMapNet には時間モデリングがあり (MapTR にはありません)、データの時間的一貫性が活用されているため、StreamMapNet の改善はわずかに高くなります。 MapTracker は、特に一貫した GT が生の mAP スコアと一貫性を意識した mAP スコアでそれぞれ 8% と 22% 以上向上しているため、競合する手法よりも大幅に優れています。 MapTracker は、一貫性領域 mAP に必要な明示的な追跡情報 (つまり、フレーム間の要素の対応関係の再構築) を生成する唯一のシステムであることに注意してください。シンプルなマッチング アルゴリズムにより、ベースライン メソッドの軌跡が作成されます。
Argoverse2 の結果。表 2 は、MapTRv2 と StreamMapNet の両方が、一貫した GT を使用してより良い mAP スコアを達成していることを示しています。これは、時間的に一貫していることに加えて、より高品質の GT (横断歩道と分離帯用) も備えており、すべての方法でメリットが得られます。 MapTracker は、すべての設定で他のすべてのベースラインを大幅に上回っています (つまり、それぞれ 11% または 8%)。一貫性認識スコア (C-mAP) は、StreamMapNet よりも 18% 以上向上しており、当社の優れた一貫性を示しています。
nuScenes と Agroverse2 データセットの公式のトレーニング/テスト分割には地理的な重複があり (つまり、同じ道路がトレーニング/テストに表示されます)、これにより過剰適合が可能になります。表 3 は、地理的に重複しないセグメンテーションに基づいて、StreamMapNet と MapTracker によって提案される最良のベースライン手法を比較しています。 MapTracker は一貫して大幅な差を付けて良好なパフォーマンスを示し、強力なクロスシナリオ汎化機能を実証しています。どちらの方法でも、nuScenes データセットのパフォーマンスが低下することに注意してください。注意深く検査した結果、道路要素の検出は成功しましたが、回帰の座標誤差が大きく、パフォーマンスが低下しました。付録では追加の分析を提供します。
表 4 のアブレーション研究は、MapTracker の主要な設計要素の寄与を示しています。最初の「ベースライン」エントリは StreamMapNet で、これには時間推論機能がありません (つまり、BEV およびベクトル フロー メモリとモジュールがありません)。 2 番目のエントリは StreamMapNet です。どちらのメソッドも、完全に収束するまで 110 エポックにわたってトレーニングされました。最後の 3 つのエントリは、主要な設計要素の有無にかかわらず、MapTracker のバリエーションです。最初のバリアントは、BEV/VEC モジュールのメモリ フュージョン コンポーネントを破棄します。このバリアントは追跡式を利用しますが、過去の情報を保持するために単一の BEV/VEC メモリに依存します。 2 番目のバリアントでは、メモリ バッファとメモリ フュージョン コンポーネントが追加されますが、ストライドはありません。つまり、フュージョンに最新の 4 フレームが使用されます。このバリアントはパフォーマンスを向上させ、メモリ メカニズムの有効性を実証します。最後のバリアントではメモリ ストライドが追加され、メモリ メカニズムがより効率的に使用され、パフォーマンスが向上します。
図 4 は、nuScenes および Argoverse2 データセットにおける MapTracker とベースライン手法の定性的な比較を示しています。視覚化を向上させるために、単純なアルゴリズムを使用して、各フレーム ベクトル HD マップをグローバル ベクトル HD マップにマージします。マージ アルゴリズムと各フレーム再構成の視覚化の詳細については、付録を参照してください。 MapTracker はより正確でクリーンな結果を生成し、優れた全体的な品質と時間的一貫性を示しました。車両が旋回しているか、わずかに前に進んでいないシナリオ (図 1 の 2 つの例を含む) では、StreamMapNet と MapTRv2 は不安定な結果を生成し、壊れたノイズの多いマージ結果が生成される可能性があります。これは主に、検出ベースの定式化では、複雑な車両の動きの下で時間的にコヒーレントな再構成を維持するのが難しいためです。
このペーパーでは、オンライン HD マッピングを追跡タスクとして定式化し、ラスターとベクターの潜在履歴を活用して時間的一貫性を維持する MapTracker を紹介します。クエリ伝播メカニズムを使用して、追跡された道路要素をフレーム間で関連付け、メモリ エントリの選択されたサブセットを距離ストライドと融合して一貫性を高めます。また、追跡ラベルを使用して一貫した GT を生成し、タイミング一貫性チェックで生の mAP メトリクスを強化することで、既存のベースラインも改善します。 MapTracker は、従来のメトリクスを使用して評価した場合、nuScenes および Agroverse2 データセットに対する既存の手法を大幅に上回り、一貫性を意識したメトリクスを使用して評価した場合、優れた時間的一貫性を示します。
制限事項: MapTracker の 2 つの制限事項を確認しました。まず、現在の追跡公式は、道路要素の結合と分割を処理できません (たとえば、U 字型の境界は将来のフレームで 2 つの直線に分割され、その逆も同様です)。また、基本的な事実がそれらを適切に表しているわけでもありません。第 2 に、システムはまだ 10 FPS であり、リアルタイム パフォーマンスが少し不足しており、特に重大なクラッシュ イベントが発生した場合に顕著です。効率を最適化し、より複雑な現実世界の道路構造を処理することは、今後の課題です。
以上がオンライン地図はまだこのままでしょうか? MapTracker: 追跡を使用してオンライン マップの新しい SOTA を実現します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
