はじめに

前回、生成AIを用いて自動運転の論文「Bench2Drive: Towards Multi-Ability Benchmarking of Closed-Loop End-To-End Autonomous Driving (2024)」の内容(本文)を(なるべく)把握してみました。
同論文の末尾にあるAppendixについても、前回と同様の方法で、把握してみます。

以降で、ChatGPTに聞いてみた例を記載します。

前回の記事: (本文の内容)

対象の論文

論文: (自動運転に関する論文)

[2406.03877] Bench2Drive: Towards Multi-Ability Benchmarking of Closed-Loop End-To-End Autonomous Driving
https://arxiv.org/abs/2406.03877
(PDF: https://arxiv.org/pdf/2406.03877)

質問時の各章節の区切り部分

論文の中にある各章節を、下記のように区切って、部分毎に生成AIに内容を質問していきます。

Checklist
---
A Details of Data Collecting
---
A Details of Data Collecting (続き)
---
B Distribution of Scenarios, Towns and Weathers
---
C Implementation Details of Baselines
---
D Training and Evaluation Resource Requirements
---
E Behavior Model of NPC Agents
---
F Details about Infraction Score
---
G Description of Scenarios
---
G Description of Scenarios (続き1)
---
G Description of Scenarios (続き2)
---
G Description of Scenarios (続き3)
---
H Author Statement (省略)
---
I License (省略)
---
J Datasheet

生成AIへの質問方法

生成AIを活用して、知りたい記事・論文の1節分(適度な長さ)のテキストをコピー＆ペーストして、その下に質問内容を「①～ ②～ …」と番号付きで書いて、生成AIに渡せば、全質問に一発で的確に回答してくれるので、非常に良好でした。記事全体を読む必要なく、知りたい点の情報だけを収集できます。

生成AIへの質問例:

(論文・記事の各章節を貼り付け)

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、回答量は長くなってもOK)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載)

※各章節に応じて、適宜下記の質問を追加。

続けて下記の質問に追加で回答下さい:
②具体的な処理方法の記載があれば説明下さい。(簡略化せずに全て記載、既存手法があれば引用元を記載)
③改良点・工夫点・テクニック等の記載があれば説明下さい。
④メカニズムの解明・なぜそうなるのか等の記載があれば説明下さい。(記載がなければ回答不要)
⑤性能が向上した記載があれば説明下さい。(具体値があれば記載、対応する図/表番号があれば各文末に記載)
⑥比較の記載があれば違いを表でまとめて下さい。(下に解説を記載、対応する図/表番号があれば明記)
⑦上記⑥以外で表に出来そうな部分があれば表でまとめて下さい。(下に解説を記載、対応する図/表番号があれば記載)
⑧具体的な数値の記載を全て列挙して、表にまとめて下さい。(必ず正しく数値を抜き取る事、|数値|説明|の表へ)
⑨具体的な変数名(数式用の記号)の記載を全て列挙して、表にまとめて下さい。(|変数名|説明|次元・型|の表へ)
⑩図/表があれば、各図/表は何を主張するためのものかを説明下さい。(掲載理由・注目ポイント等)
⑪関連研究の参照番号を全て列挙して、表にまとめて下さい。(元文にある内容のみ記載・類推して付け足しは不要、|参照番号|概要説明|の表へ、関連するもの同士でまとめて並べ替え)
⑫難解用語を全て列挙して、表にまとめて下さい。(必ず正しく抜き取る事、|用語|説明|の表へ)

※回答が長くなりそうな場合は、適宜、分けて質問: ②③④⑤、⑥⑦⑧⑨、⑩⑪⑫
※各章節に応じて、その章節内で明らかに不要な質問は、適宜除外。

※その他、不明点があれば、適宜、ピンポイントで質問。

質問内容は、始めに「①要旨は何か」に絞って1つだけを質問し、得られた回答内容に応じて、適宜質問を追加するようにしました。また、表で表した方が素早く把握できるので、必要であれば、記事を表に変換するような質問を追加しています。

論文・記事を貼り付けるテキストの長さは、1節分程度の量にとどめた方が、良い回答が得られました。生成AIの回答の文量が多くなってくると、回答が長くなり過ぎないように、生成AIが勝手に(適度に)端折り始めてしまい、重要な点が回答から抜けてしまう可能性が高くなります。

事前知識

機械学習についてある程度知っていないと、生成AIに質問しても、その回答内容だけでは理解できないと思います。生成AIの回答は、論文の内容をあまり変えずに、要点をそのまま掻い摘んで回答するような形になっています。

自動運転の論文についての分かりやすい解説記事(下記)等を事前にチェックして、中核部分の内容をあらかじめ分かっていると、理解しやすいと思います。生成AIは実際の細かい処理方法自体を分かりやすく説明してはくれない傾向があります。

注意点

論文のテキスト内容だけを貼り付けて、生成AIに質問しています。論文の中の図・表の部分は貼り付けていません。図・表の内容は生成AIの回答には含まれず、別途論文を見る必要があります。

以降で、生成AIの回答内容が読みにくい・分かりづらい場合は、論文の本文でも同じように書かれてあり、論文の本文を読んでも同じように分かりづらいことが多くあります。論文では、既存研究等があるため、多くの説明を省略・一言だけサラッと書かれてある等、同種の研究に取り組む人でなければ、なかなか全容の理解に辿りつくのは難しい側面があります。この点は、生成AIの回答性能が悪いのではなく、論文という性質上、生じるものと考えています。

生成AIに質問

以降で、ChatGPTに実際に聞いてみた例を記載します。

生成AIへの質問＆回答の全容

生成AIへの質問＆回答の全容・詳細:

Checklist

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) Checklist The checklist follows the references. Please read the checklist guidelines carefully for information on how to answer these questions. For each question, change the default [TODO] to [Yes] , [No] , or [N/A] . You are strongly encouraged to include a justification to your answer, either by referencing the appropriate section of your paper or providing a brief inline description. For example: • Did you include the license to the code and datasets? [Yes] See Section 3. Please do not modify the questions and only use the provided macros for your answers. Note that the Checklist section does not count towards the page limit. In your paper, please delete this instructions block and only keep the Checklist section heading above along with the questions/answers below. 1. For all authors... (a) Do the main claims made in the abstract and introduction accurately reflect the paper’s contributions and scope? [Yes] (b) Did you describe the limitations of your work? [Yes] (c) Did you discuss any potential negative societal impacts of your work? [Yes] (d) Have you read the ethics review guidelines and ensured that your paper conforms to them? [Yes] 2. If you are including theoretical results... (a) Did you state the full set of assumptions of all theoretical results? [N/A] (b) Did you include complete proofs of all theoretical results? [N/A] 3. If you ran experiments (e.g. for benchmarks)... (a) Did you include the code, data, and instructions needed to reproduce the main experimental results (either in the supplemental material or as a URL)? [Yes] (b) Did you specify all the training details (e.g., data splits, hyperparameters, how they were chosen)? [Yes] (c) Did you report error bars (e.g., with respect to the random seed after running experiments multiple times)? [No] (d) Did you include the total amount of compute and the type of resources used (e.g., type of GPUs, internal cluster, or cloud provider)? [Yes] 4. If you are using existing assets (e.g., code, data, models) or curating/releasing new assets... (a) If your work uses existing assets, did you cite the creators? [Yes] (b) Did you mention the license of the assets? [Yes] (c) Did you include any new assets either in the supplemental material or as a URL? [Yes] (d) Did you discuss whether and how consent was obtained from people whose data you’re using/curating? [N/A] (e) Did you discuss whether the data you are using/curating contains personally identifiable information or offensive content? [N/A] 5. If you used crowdsourcing or conducted research with human subjects... (a) Did you include the full text of instructions given to participants and screenshots, if applicable? [N/A] (b) Did you describe any potential participant risks, with links to Institutional Review Board (IRB) approvals, if applicable? [N/A] (c) Did you include the estimated hourly wage paid to participants and the total amount spent on participant compensation? [N/A]

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本項目は、論文や研究記事のチェックリストに関する記載である。このチェックリストは、論文投稿者が研究の透明性、再現性、倫理性を確保し、記載内容が適切であることを確認するための質問集である。質問への回答は、[Yes]、[No]、または[N/A]（該当なし）で行い、それに加えて適切な根拠を記載することが推奨されている。

要旨

主張と範囲の一致性
論文の要旨や導入部分が、研究の貢献や範囲を正確に反映しているかを確認することを求めている。
制約の明示
研究の限界について言及しているかどうかを問うている。
社会的影響の議論
本研究が社会に与える可能性のある負の影響について議論しているかどうかを確認している。
倫理ガイドラインの遵守
論文が倫理的基準に適合していることを確認している。
理論的結果の完全性
理論的な仮定や証明が完全に提示されているかを問うている（該当する場合のみ）。
実験の再現性
実験の再現性を確保するためのコードやデータ、手順の提供について確認している。また、誤差範囲や計算リソースの記載も求められている。
既存のリソースや新規資産の取り扱い
使用した既存資産の引用やライセンス、データの内容に関する説明、新たに公開する資産の取り扱いに関する質問が含まれている。
クラウドソーシングや人間被験者の研究
人間被験者を用いた研究やクラウドソーシングが行われた場合、その詳細な手順やリスク、報酬についての記載があるかを問うている。

このチェックリストは、透明性や再現性の向上を目的として設けられており、読者や査読者が論文の品質や倫理性を評価する際に活用される重要な要素である。

A Details of Data Collecting

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) A Details of Data Collecting The collection of data is a mix of automatic pipelines and manual checking. We give details below: Route: We use the expert model Think2Drive to run on the predefined route files and only keep those without infractions. We design a traversal algorithm over all maps to determine whether a scenario could be triggered, aiming to cover towns as much as possible. The balance of weather, towns, and scenarios are ensured by manually checking. The behaviors and rendering of CARLA sometimes could be buggy as shown in Fig. 7 and we manually filter those bad clips. Annotations: We utilize CARLA’s official APIs to collect annotations. Notably, there are several bugs within the APIs: (I) All pedestrians’ speed value are 0 from the API. We manually calculate their speed by differentiating during training of baseline methods. (II) The returned value of Speedometer and IMU could be None. We pad these values with 0 during training. (III) Some stop signs in CARLA are on the ground and thus there is no bounding box. To compensate this, We record all stop signs with rectangles to denote their trigger volume. (IV) Some static vehicles’ rotation and location are wrong by API. Thus, we use the correct center and extent to obtain their 3D bounding boxes. Object Class: Considering different attributes of different objects, we categorize all objects into four main types and store them group by group: Vehicle, Traffic Sign, Traffic Light, and Pedestrian. Vehicles are further subdivided into static and dynamic vehicles. Static vehicles remain stationary throughout the entire scenario and are distinguished by a unique actor identifier obtained from "static.prop.mesh". For Traffic Signs, they consist of speed_limit_sign, stop_sign, yield_sign, warning_sign (including warning construction, traffic warning, and warning accident), dirt_debris, and cone. Notably, signs involving trigger_volume, such as speed_limit_sign, stop_sign, and yield_sign, has trigger volume where we store the rectangle as well. The coordinates for warning signs and cones are obtained from the center and extent of their actor class, while dirt_debris requires additional conversion due to inaccurate coordinates. For Traffic Lights, the trigger volume coordinates for traffic signs and lights are relative to the actor, which requires extra transformation. Each traffic sign/light consists of two parts: the pole and the light/sign itself while the bounding boxes from API is only the lights/signs.

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本章は、データ収集の詳細について述べたものである。自動化されたパイプラインと手動での確認を組み合わせたデータ収集プロセスを説明し、具体的な収集ルート、注釈の作成、オブジェクト分類に関する詳細が記載されている。また、使用したシミュレーター「CARLA」の挙動やAPIのバグに対処する方法についても具体的に言及されている。

要旨

データ収集ルートの設計
- CARLAシミュレーター内の事前定義されたルートで、Think2Driveという専門モデルを用いて走行シミュレーションを実施している。
- シナリオの触発可能性を確保するためにマップ全体を網羅するトラバーサルアルゴリズムを設計している。
- 天候、町、シナリオのバランスは手動でチェックし、問題のあるクリップをフィルタリングしている（Fig. 7を参照）。
注釈の収集方法
- CARLAの公式APIを使用して注釈を収集しているが、APIには以下のようなバグが存在するため対処している：
  - (I) 歩行者の速度がAPIでは常に0と表示されるため、速度はトレーニング中に差分計算で求めている。
  - (II) スピードメーターとIMUの値がNoneの場合があり、トレーニング時に0で補完している。
  - (III) 地面に配置された停止標識にはバウンディングボックスがないため、矩形でトリガーボリュームを記録している。
  - (IV) 静止車両の位置や回転情報が不正確な場合があり、中心座標と範囲を使用して正しい3Dバウンディングボックスを作成している。
オブジェクト分類
- オブジェクトを以下の4つの主要タイプに分類し、それぞれをグループ化して保存している：
  1. Vehicle（静的車両と動的車両に細分化）
  2. Traffic Sign（速度制限標識、停止標識、譲歩標識、警告標識、土砂、コーンなど）
  3. Traffic Light
  4. Pedestrian
- 静的車両は「static.prop.mesh」識別子で区別される。
- 標識のトリガーボリューム（例：速度制限標識、停止標識、譲歩標識）は矩形として保存している。
- 交通標識や信号のトリガーボリューム座標はアクターに相対的であり、追加の変換が必要である。
CARLAにおける課題と対処法
- CARLAの挙動やAPIにはバグが含まれており、手動での確認や計算、補正による対処が行われている。

本章の記載は、データ収集および注釈作成の具体的な手順と、それに伴うシミュレーション環境やAPIの課題への対処法を詳細に説明することで、データの品質と信頼性を確保するための努力を示している。

▼質問(人間)
上記の「CARLAの挙動やAPIにはバグが含まれており、手動での確認や計算、補正による対処が行われている。」が記載された元文を抜き出して下さい。

▼生成AIの回答(ChatGPT-4o)
該当箇所は以下である。

元文
- "The behaviors and rendering of CARLA sometimes could be buggy as shown in Fig. 7 and we manually filter those bad clips."
元文
- "Notably, there are several bugs within the APIs:
  (I) All pedestrians’ speed value are 0 from the API. We manually calculate their speed by differentiating during training of baseline methods.
  (II) The returned value of Speedometer and IMU could be None. We pad these values with 0 during training.
  (III) Some stop signs in CARLA are on the ground and thus there is no bounding box. To compensate this, We record all stop signs with rectangles to denote their trigger volume.
  (IV) Some static vehicles’ rotation and location are wrong by API. Thus, we use the correct center and extent to obtain their 3D bounding boxes."

元文の抜き出しは完全に正しい。

A Details of Data Collecting (続き)

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) Coordinate System: Unlike the Y-down right-hand system used by Nuscenes, CARLA employs the Unreal Engine coordinate system, which is a Z-up left-hand coordinate system. In Compass, orientation with regard to the North ([0.0, -1.0, 0.0] in Unreal Engine) means the standard yaw angle in the left-hand system is theta in the compass minus 1/2 pi. In rare cases, this may result in NaN values, which need to be manually filtered. Map Information: The HD-Map is organized into road_ids with lane_index. Each lane includes the world coordinates and orientations of points, lane type, color identifiers and adjacent road_ids-lane_ids (left, right and connected road ids and lane ids), as well as topological structures (e.g., ’Junction’, ’Normal’, ’EnterNormal’, ’EnterJunction’, ’PassNormal’, ’PassJunction’, ’StartJunctionMultiChange’, or ’StartNormalMultiChange’). The Trigger_Volumes represent the trigger areas for signs, where ’Points’ specify the vertices’ locations of the trigger volume, ’Type’ can be ’StopSign’ or ’TrafficLight’, and ’ParentActor_Location’ provides details on the location of the parent actor associated with the trigger volume. Data Compression To reduce file size, following [ 19], we adopted compressed data format. Images are compressed using JPG with the quality= 20. To avoid train-val gap during closed-loop evaluation, we also use in-memory JPG compression and decompression during inference. Semantic segmentation and depth data are stored as PNG files. We use a specialized algorithm called laszip to compress our LiDAR point clouds. JSON files are compressed using GZIP.

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本章では、データ処理に関連する3つの重要な要素について説明している。具体的には、座標系、マップ情報、およびデータ圧縮手法が含まれており、それぞれの仕様や使用方法、目的が記載されている。

要旨

座標系 (Coordinate System)
- CARLAはUnreal EngineのZ-up左手系座標系を使用している。これはNuscenesのY-down右手系座標系と異なる。
- 北方向を基準とした方位を計算する際、Unreal Engineにおける標準的なヨー角はコンパスでの方位θから(-\frac{\pi}{2})を差し引いた値となる。
- 稀にNaN値が発生する場合があり、これらは手動でフィルタリングする必要がある。
マップ情報 (Map Information)
- 高精度マップ（HD-Map）は、road_idsとlane_indexに基づいて構造化されている。各車線は次の情報を含む：
  - ワールド座標と点の向き
  - 車線タイプ、色識別子
  - 左右および接続されたroad_ids-lane_ids
  - トポロジ構造（例：’Junction’, ’Normal’, ’EnterNormal’, ’PassJunction’など）。
- トリガーボリュームは標識のトリガー領域を示し、次の情報を含む：
  - ’Points’：トリガーボリュームの頂点の位置
  - ’Type’：’StopSign’または’TrafficLight’
  - ’ParentActor_Location’：トリガーボリュームに関連付けられた親アクターの位置。
データ圧縮 (Data Compression)
- ファイルサイズを削減するために[19]を参照し、圧縮データ形式を採用している：
  - 画像データはJPG形式で圧縮（品質=20）。推論時に訓練データと評価データ間のギャップを防ぐため、メモリ内でのJPG圧縮と解凍を実行している。
  - セマンティックセグメンテーションおよび深度データはPNG形式で保存している。
  - LiDAR点群データはlaszipアルゴリズムで圧縮している。
  - JSONファイルはGZIP形式で圧縮している。

本章の内容は、データ収集や処理における正確な座標系の使用、詳細な地図情報の管理、効率的なデータ圧縮方法の適用により、データ品質と計算効率を両立する取り組みを示している。

B Distribution of Scenarios, Towns and Weathers

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) B Distribution of Scenarios, Towns and Weathers As shown in Fig. 8, the distribution of weathers are nearly uniform while the distribution of town is dominated by Town12 and Town13. The imbalance comes from two perspectives: (I) New towns, like Town12 and Town13, are designed on purpose by CARLA team to be much larger than old towns so that the community could explore applications in city-level scene. Thus, we collect more data in larger towns for more diverse landscapes. (II) Lots of new scenarios in Leaderboard v2 are designed recently and thus old towns do not support the layouts required by new scenarios. For example, parting exit requires the existence of other parked vehicles. As a result, we have to collect more data in new towns to ensure the balance of scenario types.

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本章では、収集されたデータにおけるシナリオ、町、天候の分布について述べている。特に新しい町（Town12およびTown13）のデータ量が多い理由と、それに関連する背景が説明されている。

要旨

天候の分布
- 天候の分布はほぼ均一である（Fig. 8参照）。
- 特定の天候に偏らず、バランスよくデータが収集されていることを示している。
町の分布
- データはTown12およびTown13に大きく偏っている（Fig. 8参照）。
- 偏りの理由は以下の2つである：
  - (I) Town12およびTown13はCARLAチームによって設計され、旧町に比べて大規模かつ多様な都市レベルのシーンを提供することを目的としている。
  - (II) Leaderboard v2の新しいシナリオは最近設計されたものであり、旧町では新しいシナリオに必要なレイアウトをサポートできない場合がある。
シナリオと町の関係
- 新しいシナリオ（例：駐車場からの退出など）は、他の駐車車両の存在を前提とするため、新町でデータを多く収集する必要がある。
- より多様なシナリオタイプを網羅するために、新町でのデータ収集が重視されている。

これらの説明から、新しい町とシナリオが収集データの分布に大きな影響を与えていることが示されている。また、シナリオや天候のバランスを保ちながらも、町の規模や設計目的がデータ分布に反映されていることが分かる。

C Implementation Details of Baselines

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) C Implementation Details of Baselines For all baseline E2E-AD methods, we strictly follow their official open-sourced code, environments, and configs. There are a few modifications: (I) For methods with object detection module, we change the detection classes according to CARLA3. (II) Data collection of Bench2Drive is in 10Hz while nuScenes with bounding boxes is in 2Hz. Due to Bench2Drive’s longer clips, Bench2Drive-base has approximately 10x frames compared to nuScenes yet with higher redundancy. For computationally demanding methods like UniAD/VAD/ThinkTwice/DriveAdapter, we train 1 10 epochs compared to the original version. We observe similar level of loss due to similar number of training steps. (III) Since ThinkTwice and DriveAdapter require expert’s BEV features, we use Think2Drive expert to regenerate those expert feature. Additionally, for fair comparison with other methods, we modify both of them into 6 cameras without LiDAR

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本章では、各種エンドツーエンド自動運転（E2E-AD）手法におけるベースラインの実装詳細について述べている。公式のコードや設定を基にしつつ、特定の状況に応じた修正やデータ収集の特徴が記載されている。

要旨

公式コードと設定の遵守
- すべてのベースライン手法（E2E-AD）は、公式に公開されたコード、環境、および設定を厳密に遵守して実装されている。
修正点
- (I) 物体検出モジュールのクラス修正
  - CARLA3に基づき、物体検出モジュールのクラス設定を変更している。
- (II) データ収集頻度の違いとフレーム数の比較
  - Bench2Driveのデータ収集頻度は10Hzであり、nuScenesの2Hzよりも高頻度で収集されている。
  - Bench2DriveはnuScenesに比べ約10倍のフレーム数を持つが、冗長性が高い。
- (III) 計算コストが高い手法への対応
  - UniAD、VAD、ThinkTwice、DriveAdapterのような計算コストが高い手法においては、元の設定の10分の1のエポック数でトレーニングを実施している。
  - トレーニングステップ数が類似しているため、損失レベルも同様であることが観測されている。
- (IV) ThinkTwiceとDriveAdapterの特徴生成
  - ThinkTwiceおよびDriveAdapterは専門家（expert）のBEV特徴量を必要とするため、Think2Driveを用いてそれらの特徴量を再生成している。
  - 他手法との公平な比較のため、両手法をLiDARを使用せず6台のカメラ構成に変更している。

これにより、データの冗長性や計算負荷を軽減しつつも、元の設定に忠実なベースライン比較が可能になっていることが説明されている。また、公平性を保つための修正が随所に加えられている。

D Training and Evaluation Resource Requirements

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) D Training and Evaluation Resource Requirements We report resource requirements of training and evaluating baselines. Note that the evaluation time could be linearly speed up with more GPUs to parallely evaluate on more routes.

Table 5: Resource requirements for training on base set and evaluation on 220 routes. The
training of UniAD consists of BEVFormer, stage1, and stage2.
Training Evaluation
AD-MLP 1 A600 * 1 day 4 A6000 * 6 hours
TCP 1 A600 * 1 day 4 A6000 * 6 hours
VAD 8 H800 * 5 days 8 H800 * 2 days
UniAD-base 8 H800 * (3+3+3)=9 days 8 H800 * 2 days

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本節は、各ベースライン手法のトレーニングおよび評価に必要なリソース要件について説明している。特に、トレーニング時間と評価時間におけるGPUの使用量と時間の違いが詳細に記載されている。

要旨

リソース要件の概要
- 各手法のトレーニングおよび評価に必要な計算リソース（GPU種別、台数、時間）が示されている。
- 評価プロセスは、複数のGPUを用いて並列処理することで線形的に高速化できる点が明記されている。
表5の要点
- 表5では、ベースセットでのトレーニングおよび220ルートでの評価に要するリソース要件が記載されている。
- 特に、UniADのトレーニングプロセスは、BEVFormer、ステージ1、ステージ2の3段階から構成され、それぞれに必要な日数が分けて記載されている。
手法ごとのリソース要件（表5の詳細）
- AD-MLP
  - トレーニング：1台のA600 GPUを用いて1日。
  - 評価：4台のA6000 GPUを用いて6時間。
- TCP
  - トレーニング：1台のA600 GPUを用いて1日。
  - 評価：4台のA6000 GPUを用いて6時間。
- VAD
  - トレーニング：8台のH800 GPUを用いて5日間。
  - 評価：8台のH800 GPUを用いて2日間。
- UniAD-base
  - トレーニング：8台のH800 GPUを用い、BEVFormerに3日間、ステージ1に3日間、ステージ2に3日間、合計9日間。
  - 評価：8台のH800 GPUを用いて2日間。
リソース効率化の可能性
- 評価時間については、複数のGPUを使用することで並列処理が可能となり、直線的な高速化が実現可能である点が強調されている。

表5の参照：
表5は、各手法におけるリソース要件を具体的にまとめたものであり、トレーニングや評価における計算コストの違いを明確に示している。

E Behavior Model of NPC Agents

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) E Behavior Model of NPC Agents In CARLA, three behavior types are preset in CARLA Agent: cautious, normal and aggressive. These behavior types govern the driving actions of NPCs, influencing factors such as speed, responses to other vehicles, and safety protocols. The key parameters for each behavior mode include: • max_speed: Sets the maximum speed(km/h) that an NPC vehicle can reach. • speed_lim_dist: Value in km/h that defines how far your vehicle’s target speed will be from the current speed limit • speed_decrease: Controls the deceleration of the NPC when approaching a slower vehicle ahead. • safety_time: Estimates the time to a collision if the vehicle in front suddenly brakes. • min_proximity_threshold: Defines the minimum distance before the NPC takes actions such as evasive maneuvers or tailgating. • braking_distance: The distance at which the NPC performs an emergency stop to avoid a collision. • tailgate_counter: A counter that prevents the NPC from initiating a new tailgating action too soon after the last one. These behavior designs interact with the ego (self-driving) vehicle, ensuring that NPCs respond to the presence and actions of the ego vehicle in the simulation. The parameters for different behavior styles are as follows,

Table 6: Comparison of Cautious, Normal, and Aggressive behavior parameters.
Parameter Cautious Normal Aggressive
max_speed (km/h) 40 50 70
speed_lim_dist (km/h) 6 3 1
speed_decrease (km/h) 12 10 8
safety_time (seconds) 3 3 3
min_proximity_threshold (meters) 12 10 8
braking_distance (meters) 6 5 4
tailgate_counter (times) 0 0 -1

The rule-based behavior decision algorithm in behavior_agent.py for non-player character (NPC)
vehicles is shown below:
The behavior of walkers/pedestrians is characterized by their consistent adherence to the route line at
a constant speed, with the inability to walk backward. In autonomous driving scenarios, pedestrian
safety is of utmost importance. Pedestrians have the highest priority when autonomous vehicles
interact with humans, and autonomous vehicles should learn to give way to pedestrians regardless of
traffic conditions.

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本節は、CARLAシミュレーションにおけるNPC（Non-Player Character）エージェントの行動モデルについて記載している。具体的には、NPCの運転行動を決定する3つのプリセットの行動タイプ（慎重、通常、攻撃的）の特徴と、それに関連する主要なパラメータの説明、およびそれらがシミュレーションでの自動運転車（Ego車両）とのインタラクションに与える影響について説明している。

要旨

CARLAのNPCエージェントの行動タイプ
- NPCエージェントには、以下の3つの行動タイプが設定されている：
  - 慎重 (Cautious)
  - 通常 (Normal)
  - 攻撃的 (Aggressive)
- 各行動タイプは、車両の速度、他車両への応答、安全プロトコルなどに影響を与える。
主要なパラメータ
- 行動タイプごとに設定される主要なパラメータがリストアップされている：
  - max_speed：NPC車両の最大速度（km/h）。
  - speed_lim_dist：現在の速度制限からNPC車両の目標速度がどの程度離れているかを定義する値（km/h）。
  - speed_decrease：前方に遅い車両がいる場合の減速量を制御。
  - safety_time：前方車両が急ブレーキを行った場合の衝突までの時間を推定。
  - min_proximity_threshold：NPCが回避行動や追尾を開始する際の最小距離を定義（m）。
  - braking_distance：衝突を回避するために緊急停止を行う距離（m）。
  - tailgate_counter：NPCが前回の追尾行動から新たな追尾行動を開始するまでのカウント。
行動タイプ間のパラメータ比較（表6参照）
- 表6では、慎重、通常、攻撃的の3つの行動タイプごとの各パラメータ値が比較されている。具体的には以下の点が記載されている：
  - 慎重な行動タイプは、低速かつ安全な距離を維持する傾向が強い。
  - 通常の行動タイプは、適度な速度と安全距離を保つ。
  - 攻撃的な行動タイプは、高速での運転や、より短い距離での回避行動が特徴的。
歩行者の行動モデル
- 歩行者は一貫してルートラインに沿った一定速度で移動し、後退ができない。
- 歩行者の安全が最優先事項とされており、自動運転車は交通状況にかかわらず歩行者に道を譲る必要がある。

表6の参照

主張内容：表6は、各行動タイプにおける主要パラメータの具体的な値を示し、それぞれの行動特性を明確に比較している。特に速度や距離に関連するパラメータの違いが、慎重から攻撃的までの行動タイプの特性を反映している。

F Details about Infraction Score

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) F Details about Infraction Score In Table 7, we gives the penalty score of each infraction designed by Leaderboard v2.

Algorithm 1 Non-Player Character (NPC) Vehicles Behavior Decision
1: Update vehicle’s surrounding information
2: if red light or stop sign detected then
3: return emergency_stop()
4: end if
5: if pedestrian detected and within braking distance then
6: return emergency_stop()
7: end if
8: if other vehicle nearby then
9: if within braking distance then
10: return emergency_stop()
11: else
12: return car_following()
13: end if
14: else if ego vehicle at intersection and (turn left or turn right) then
15: adjust_speed_limit()
16: return PID_Control
17: else if in normal driving conditions then
18: maintain_speed_limit()
19: return PID_Control
20: end if

Table 7: Infraction Types & Penalty. Following https://leaderboard.carla.org/.
Infraction Penalty Note
Pedestrian Collision 0.50 Punished every infraction.
Vehicles Collision 0.60 Punished every infraction.
Other Collision 0.65 Punished every infraction.
Running Red Light 0.70 Punished every infraction.
Scenario Timeout 0.70 Fail to pass certain scenarios in 4 minutes.
Too Slow 0.70 Fail to maintain a suitable speed with surrounding vehicle.
No Give Way 0.70 Failure to yield to emergency vehicle.
Off-road - Not considered in route completion.
Route Deviation - Deviates more than 30 meters. Shutdown immediately.
Agent Blocked - No action for 180 seconds. Shutdown immediately.
Route Timeout - Exceed the maximum time limit. Shutdown immediately.

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本節は、CARLA Leaderboard v2に基づいた違反スコアの詳細について記載している。具体的には、NPC（Non-Player Character）車両の行動決定アルゴリズム（Algorithm 1）と、違反ごとのペナルティスコア（表7）を示している。これにより、シミュレーション環境における安全性やパフォーマンスの評価基準が明確にされている。

要旨

NPC車両の行動決定アルゴリズム（Algorithm 1）
- NPC車両は周囲の情報を更新し、以下の条件に基づいて行動を決定する：
  - 赤信号または停止標識の検知
    - emergency_stop()を呼び出して緊急停止。
  - 歩行者の検知
    - 歩行者がブレーキ距離内にいる場合はemergency_stop()を呼び出して緊急停止。
  - 他車両の存在
    - 他車両がブレーキ距離内にいる場合はemergency_stop()を呼び出して緊急停止。
    - それ以外の場合はcar_following()で追従走行を実行。
  - 交差点でのEgo車両の動作
    - 左右折時に速度制限を調整し、PID_Controlで動作を制御。
  - 通常走行条件下
    - 速度制限を維持し、PID_Controlで動作を制御。
違反スコア（表7）
- 表7は、CARLA Leaderboard v2の仕様に基づき、各違反タイプに対するペナルティスコアを示している：
  - 歩行者衝突：ペナルティスコア0.50。
  - 車両衝突：ペナルティスコア0.60。
  - その他の衝突：ペナルティスコア0.65。
  - 赤信号無視：ペナルティスコア0.70。
  - シナリオタイムアウト：4分以内にシナリオをクリアできない場合に適用、ペナルティスコア0.70。
  - 低速運転：周囲車両と適切な速度を維持できない場合に適用、ペナルティスコア0.70。
  - 進路譲らず：緊急車両への道譲りに失敗した場合に適用、ペナルティスコア0.70。
  - オフロード：ルート完了には考慮されない。
  - ルート逸脱：30メートル以上ルートを逸脱すると即座に終了。
  - エージェント停止：180秒間行動を停止した場合に即座に終了。
  - ルートタイムアウト：最大時間を超過すると即座に終了。
表7の参照
- 主張内容：表7は、シミュレーション内のパフォーマンスや安全性を評価する際の具体的な基準を提供している。特に、ペナルティスコアが各違反の重要性を定量化し、システムが安全性と効率性を高めるための指標として機能する。

G Description of Scenarios

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) G Description of Scenarios Bench2Drive provides 44 corner scenarios, extended from CARLA Leaderboard V2. We give details about them below: 1. ControlLoss The ego vehicle loses control due to bad conditions on the road and it must recover, coming back to its original lane. 2. ParkingExit The ego vehicle must exit a parallel parking bay into a flow of traffic. 3. ParkingCutIn The ego vehicle must slow down or brake to allow a parked vehicle exiting a parallel parking bay to cut in front. 4. StaticCutIn The ego vehicle must slow down or brake to allow a vehicle of the slow traffic flow in the adjacent lane to cut in front. Compared to ParkingCutIn, there are more cars in the adjacent lane and any one of them may cut in. 5. ParkedObstacle The ego vehicle encounters a parked vehicle blocking part of the lane and must perform a lane change into traffic moving in the same direction to avoid it. 6. ParkedObstacleTwoWays The ’TwoWays’ version of ParkedObstacle. The ego vehicle encoun- ters a parked vehicle blocking the lane and must perform a lane change into traffic moving in the opposite direction to avoid it. 7. Construction The ego vehicle encounters a construction site blocking and must perform a lane change into traffic moving in the same direction to avoid it. Compared to ParkedObstacle, the construction occupies more width of the lane. The ego vehicle has to completely deviate from its task route temporarily to bypass the construction zone. 8. ConstructionTwoWays The ’TwoWays’ version of Construction. 9. Accident The ego vehicle encounters multiple accident cars blocking part of the lane and must perform a lane change into traffic moving in the same direction to avoid it. Compared to ParkedObstacle and Construction, these accident cars occupy more length along the lane. The ego vehicle has to completely deviate from its task route for a longer time to bypass the accident zone. 10. AccidentTwoWays The ’TwoWays’ version of Accident. Compared to ParkedObsta- cleTwoWays and ConstructionTwoWays, there is a much shorter time window for the ego vehicle to bypass the route obstacles (i.g. accident cars).

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本節では、Bench2Driveが提供する44のシナリオのうち、代表的な10のコーナーケース（corner scenarios）について記載している。これらのシナリオは、CARLA Leaderboard V2を拡張したものであり、各シナリオは自律走行車（ego vehicle）の性能や安全性を評価するために設計されている。具体的な状況やego車両がとるべき行動が詳細に説明されている。

要旨

ControlLoss
- Ego車両が路面状態の悪化により制御を失い、元の車線に戻る必要があるシナリオ。
ParkingExit
- Ego車両が並列駐車帯から交通の流れに出るシナリオ。
ParkingCutIn
- 並列駐車帯から出る車両が前方に割り込むため、ego車両が減速または停止する必要があるシナリオ。
StaticCutIn
- 隣接車線の遅い車両が前方に割り込むため、ego車両が減速または停止する必要があるシナリオ。ParkingCutInより隣接車線の車両が多く、どの車両も割り込む可能性がある。
ParkedObstacle
- Ego車両が停車している車両によって車線が部分的に塞がれた状況に遭遇し、同方向に進む交通に合わせて車線変更を行うシナリオ。
ParkedObstacleTwoWays
- ParkedObstacleの二方向バージョン。Ego車両は反対車線の交通を考慮しながら車線変更を行う必要があるシナリオ。
Construction
- Ego車両が工事現場により車線が塞がれた状況に遭遇し、同方向に進む交通に合わせて車線変更を行うシナリオ。工事はより広い車線幅を占有し、タスクルートから完全に逸脱する必要がある。
ConstructionTwoWays
- Constructionの二方向バージョン。
Accident
- Ego車両が複数の事故車両により車線が塞がれた状況に遭遇し、同方向に進む交通に合わせて車線変更を行うシナリオ。ParkedObstacleやConstructionよりも占有される車線の長さが大きく、長時間タスクルートから逸脱する必要がある。
AccidentTwoWays
- Accidentの二方向バージョン。他のTwoWaysシナリオ（ParkedObstacleTwoWaysやConstructionTwoWays）と比較して、ルート障害物を回避するための時間的余裕がさらに短いシナリオ。

特記事項

各シナリオは現実の複雑な交通状況を模倣して設計されており、自律走行車の対応能力を評価するためのテストケースとして機能する。これらのシナリオは、車両制御、路線復帰、緊急対応、周囲車両との相互作用など、多様な運転条件を含む。

G Description of Scenarios (続き1)

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) 11. HazardAtSideLane The ego vehicle encounters a slow-moving hazard blocking part of the lane. The ego vehicle must brake or maneuver next to a lane of traffic moving in the same direction to avoid it. 12. HazardAtSideLaneTwoWays The ego vehicle encounters a slow-moving hazard blocking part of the lane. The ego vehicle must brake or maneuver to avoid it next to a lane of traffic moving in the opposite direction. 13. VehiclesDooropenTwoWays The ego vehicle encounters a parked vehicle opening a door into its lane and must maneuver to avoid it. 14. DynamicObjectCrossing A walker or bicycle behind a static prop crosses the road suddenly when the ego vehicle is close to the prop. The ego vehicle must make a hard brake promptly. 15. ParkingCrossingPedestrian The ego vehicle encounters a pedestrian emerging from behind a parked vehicle and advancing into the lane. The ego vehicle must brake or maneuver to avoid it. Compared to DynamicObjectCrossing, the pedestrian is closer to the road and the ego vehicle has to act more timely. 16. HardBrake The leading vehicle decelerates suddenly and the ego vehicle must perform an emergency brake or an avoidance maneuver. 17. YieldToEmergencyVehicle The ego vehicle is approached by an emergency vehicle coming from behind. The ego vehicle must maneuver to allow the emergency vehicle to pass. 18. InvadingTurn When the ego vehicle is about to turn right, a vehicle coming from the opposite lane invades the ego’s lane, forcing the ego to move right to avoid a possible collision. 19. PedestrainCrossing While the ego vehicle is entering a junction, a group of natural pedestrians suddenly cross the road and ignore the traffic light. The ego vehicle must stop and wait for all pedestrians to pass even though there is a green traffic light or a clear junction. 20. VehicleTurningRoutePedestrian While performing a maneuver, the ego vehicle encounters a pedes- trian crossing the road and must perform an emergency brake or an avoidance maneuver.

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本節では、Bench2Driveにおける44のコーナーシナリオのうち、11から20番目のシナリオについて説明している。これらのシナリオは、CARLA Leaderboard V2を拡張したものであり、さまざまな状況下で自律走行車（ego vehicle）が直面する可能性のある挑戦的なケースを提示している。これらのシナリオは、安全性、適応力、危険回避能力を評価するためのテストとして機能している。

要旨

HazardAtSideLane
- Ego車両が、同じ方向に進む車線の一部を塞いでいる低速移動の障害物に遭遇するシナリオ。Ego車両はブレーキをかけるか、他車線との位置関係を考慮しながら回避行動を取る必要がある。
HazardAtSideLaneTwoWays
- HazardAtSideLaneの二方向バージョン。Ego車両は反対車線の交通を考慮しつつ障害物を回避する必要がある。
VehiclesDooropenTwoWays
- 停車中の車両がドアを開けて車線に侵入している状況に遭遇するシナリオ。Ego車両は適切な回避行動を取る必要がある。
DynamicObjectCrossing
- 静止している障害物（プロップ）の背後から、歩行者または自転車が突然道路を横切るシナリオ。Ego車両は素早く急ブレーキをかける必要がある。
ParkingCrossingPedestrian
- 停車中の車両の背後から歩行者が現れ、車線に進入するシナリオ。DynamicObjectCrossingよりも歩行者が道路に近い状況であり、Ego車両はより迅速に行動を取る必要がある。
HardBrake
- 前方の車両が突然減速し、Ego車両は緊急ブレーキまたは回避行動を取る必要があるシナリオ。
YieldToEmergencyVehicle
- 緊急車両が後方から接近し、Ego車両が進路を譲るための行動を取る必要があるシナリオ。
InvadingTurn
- Ego車両が右折を試みている際に、対向車線から来る車両がEgo車両の車線に侵入するシナリオ。Ego車両は右に動いて回避行動を取る必要がある。
PedestrianCrossing
- Ego車両が交差点に進入する際に、信号を無視して複数の歩行者が道路を横切るシナリオ。Ego車両は信号が青でも、すべての歩行者が通過するまで停止して待つ必要がある。
VehicleTurningRoutePedestrian
- Ego車両が運転操作を行う際に、歩行者が道路を横断するシナリオ。Ego車両は緊急ブレーキまたは回避行動を取る必要がある。

特記事項
これらのシナリオは現実的な運転状況をシミュレートしており、急な障害物の出現、歩行者や緊急車両との相互作用、対向車との接触回避など、多岐にわたるケースが含まれている。これらは、Ego車両がどの程度迅速かつ安全に対応できるかを評価するために設計されている。

G Description of Scenarios (続き2)

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) 21. VehicleTurningRoute While performing a maneuver, the ego vehicle encounters a bicycle crossing the road and must perform an emergency brake or an avoidance maneuver. Compared to VehicleTurningRoutePedestrian, the bicycle moves faster and the ego has to brake earlier. 22. BlockedIntersection While performing a maneuver, the ego vehicle encounters a stopped vehicle on the road and must perform an emergency brake or an avoidance maneuver. 23. SignalizedJunctionLeftTurn The ego vehicle is performing an unprotected left turn at an intersec- tion, yielding to oncoming traffic. 24. SignalizedJunctionLeftTurnEnterFlow The ego vehicle is performing an unprotected left turn at an intersection, merging into opposite traffic. 25. NonSignalizedJunctionLeftTurn Non-signalized version of SignalizedJunctionLeftTurn. The ego has to negotiate with the opposite vehicles without traffic lights. 26. NonSignalizedJunctionLeftTurnEnterFlow Non-signalized version of SignalizedJunctionLeftTurnEnterFlow. 27. SignalizedJunctionRightTurn The ego vehicle is turning right at an intersection and has to safely merge into the traffic flow coming from its left. 28. NonSignalizedJunctionRightTurn Non-signalized version of SignalizedJunctionRightTurn. The ego has to negotiate with the traffic flow without traffic lights. 29. EnterActorFlows A flow of cars runs a red light in front of the ego when it enters the junction, forcing it to react (interrupting the flow or merging into the flow). These vehicles are ’special’ ones such as police cars, ambulances, or firetrucks. 30. HighwayExit The ego vehicle must cross a lane of moving traffic to exit the highway at an off-ramp.

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本節では、Bench2Driveにおける44のコーナーシナリオのうち、21から30番目のシナリオについて説明している。これらのシナリオは、Ego車両が道路上で直面する複雑な交通状況を再現したものであり、自律走行車が安全にタスクを遂行するための性能評価のために設計されている。

要旨

VehicleTurningRoute
- Ego車両が運転操作を行う際に、自転車が道路を横断するシナリオ。
- 自転車は歩行者よりも速く移動するため、Ego車両はより早いタイミングで緊急ブレーキまたは回避行動を取る必要がある。
BlockedIntersection
- Ego車両が運転操作中に、停止している車両に遭遇するシナリオ。
- 緊急ブレーキまたは回避行動が求められる。
SignalizedJunctionLeftTurn
- 信号のある交差点で、Ego車両が保護されていない左折を行い、対向車両に譲る必要があるシナリオ。
SignalizedJunctionLeftTurnEnterFlow
- 信号のある交差点で、Ego車両が保護されていない左折を行い、反対方向の交通に合流するシナリオ。
NonSignalizedJunctionLeftTurn
- SignalizedJunctionLeftTurnの信号なしバージョン。
- Ego車両は信号の助けなしに対向車と交渉する必要がある。
NonSignalizedJunctionLeftTurnEnterFlow
- SignalizedJunctionLeftTurnEnterFlowの信号なしバージョン。
SignalizedJunctionRightTurn
- 信号のある交差点で、Ego車両が右折を行い、左側から来る交通の流れに安全に合流するシナリオ。
NonSignalizedJunctionRightTurn
- SignalizedJunctionRightTurnの信号なしバージョン。
- Ego車両は信号なしで交通の流れと交渉しながら右折する必要がある。
EnterActorFlows
- Ego車両が交差点に進入する際、赤信号を無視して走行する車両群（警察車両、救急車、消防車など）に遭遇するシナリオ。
- Ego車両はその流れを中断するか、流れに合流する必要がある。
HighwayExit
- Ego車両が高速道路の出口で車線を横切り、移動中の交通を回避しながら出口ランプに到達するシナリオ。

特記事項
これらのシナリオは、交差点での複雑な動き、信号の有無に応じた異なる状況対応、緊急車両への反応、また高速道路の出口での安全な運転行動を含む。各シナリオはEgo車両がどのように迅速かつ安全に適切な判断を行えるかを評価するために設計されている。

G Description of Scenarios (続き3)

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) 31. MergerIntoSlowTraffic The ego vehicle must merge into a slow traffic flow on the off-ramp when exiting the highway. 32. MergerIntoSlowTrafficV2 The ego vehicle must merge into a slow traffic flow coming from the on-ramp when driving on highway roads. 33. InterurbanActorFlow The ego vehicle leaves the interurban road by turning left, crossing a fast traffic flow. 34. InterurbanAdvancedActorFlow The ego vehicle incorporates into the interurban road by turning left, first crossing a fast traffic flow, and then merging into another one. 35. HighwayCutIn The ego vehicle encounters a vehicle merging into its lane from a highway on-ramp. The ego vehicle must decelerate, brake, or change lanes to avoid a collision. 36. CrossingBicycleFlow The ego vehicle needs to perform a turn at an intersection yielding to bicycles crossing from either the left. 37. OppositeVehicleRunningRedLight The ego vehicle is going straight at an intersection but a crossing vehicle runs a red light, forcing the ego vehicle to avoid the collision. 38. OppositeVehicleTakingPriority Non-signalized version of OppositeVehicleTakingPriority. 39. VinillaNonSignalizedTurn A basic scenario for the ego vehicle to learn to pass through a non-signalized junction (without traffic signs and traffic lights). 40. VinillaNonSignalizedTurnEncounterStopsign A basic scenario for the ego vehicle to learn to stop and start at stop signs. 41. VinillaSignalizedTurnEncounterGreenLight A basic scenario for the ego vehicle to learn to pass through the signalized junction. 42. VinillaSignalizedTurnEncounterRedLight A basic scenario for the ego vehicle to learn to pass through the signalized junction when the traffic light changes from red to green. 43. LaneChange A basic scenario for the ego vehicle to learn to change lanes and avoid collision. 44. TJunction A basic scenario for the ego vehicle to learn to pass through a T-junction.

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本節では、Bench2Driveにおける44のコーナーシナリオのうち、31から44番目のシナリオについて説明している。これらのシナリオは、高速道路での合流や交差点での複雑な状況、信号や標識の対応、および基本的な運転動作の学習を目的として設計されている。

要旨

MergerIntoSlowTraffic
- Ego車両が高速道路出口ランプにおいて、低速の交通流に合流するシナリオ。
MergerIntoSlowTrafficV2
- Ego車両が高速道路走行中に入口ランプから合流してくる低速交通流に合流するシナリオ。
InterurbanActorFlow
- Ego車両が郊外道路を左折して高速交通流を横断し、道路を離れるシナリオ。
InterurbanAdvancedActorFlow
- Ego車両が郊外道路に左折で合流する際、最初に高速交通流を横断し、続いて別の交通流に合流するシナリオ。
HighwayCutIn
- 高速道路入口ランプからEgo車両の車線に合流してくる車両に遭遇するシナリオ。Ego車両は減速、ブレーキ、または車線変更で衝突を回避する必要がある。
CrossingBicycleFlow
- Ego車両が交差点で左側から横断してくる自転車に譲る必要があるシナリオ。
OppositeVehicleRunningRedLight
- Ego車両が交差点を直進中に、赤信号を無視して横切る車両に遭遇するシナリオ。衝突を避けるために回避行動を取る必要がある。
OppositeVehicleTakingPriority
- OppositeVehicleRunningRedLightの信号なしバージョン。
VinillaNonSignalizedTurn
- 信号や標識のない交差点を通過する基本的なシナリオ。Ego車両が非信号交差点の通行を学ぶためのもの。
VinillaNonSignalizedTurnEncounterStopsign
- Stopサインがある交差点で停止・発進する動作を学ぶための基本シナリオ。
VinillaSignalizedTurnEncounterGreenLight
- 信号のある交差点で青信号時に通過する動作を学ぶための基本シナリオ。
VinillaSignalizedTurnEncounterRedLight
- 信号のある交差点で赤信号から青信号に変わるタイミングで通過する動作を学ぶための基本シナリオ。
LaneChange
- Ego車両が車線変更を学び、衝突を回避するための基本シナリオ。
TJunction
- Ego車両がT字路を通過する動作を学ぶための基本シナリオ。

特記事項
これらのシナリオは、Ego車両が郊外道路や高速道路での合流動作や複雑な交差点の状況に対処する能力を評価するものである。また、基本的な運転技術（車線変更やT字路の通過）を学習し、信号や標識への対応能力を強化するために設計されている。

H Author Statement (省略)

1文のみのため、省略。

I License (省略)

1文のみのため、省略。

J Datasheet

▼質問(人間)

質問内容全体はここをクリック

(論文・記事の各章節を貼り付け) J Datasheet J.1 Motivation For what purpose was the dataset created? Was there a specific task in mind? Was there a specific gap that needed to be filled? Please provide a description. We build the benchmark to fulfill the need of comprehensive and realistic testing environments for Full Self-Driving (FSD). The primary task is end-to-end autonomous driving. Existing benchmarks failed to provide a closed-loop granular assessment of driving skills for E2E-AD methods. Who created the dataset (e.g., which team, research group) and on behalf of which entity (e.g., company, institution, organization)? This dataset is curated by Xiaosong Jia, Zhenjie Yang, Qifeng Li, Zhiyuan Zhang, Junchi Yan from ReThinkLab with School of AI and Department of CSE, Shanghai Jiao Tong University. J.2 Distribution Will the dataset be distributed to third parties outside of the entity (e.g., company, institution, organization) on behalf of which the dataset was created? Yes. How will the dataset be distributed (e.g., tarball on website, API, GitHub)? All data, codes, and checkpoints are in GitHub (https://github.com/Thinklab-SJTU/Bench2Drive) and Huggingface (https://huggingface.co/datasets/rethinlab/Bench2Drive). J.3 Maintenance Who will be supporting/hosting/maintaining the dataset? All authors and potentially new members of ReThinLab in Shanghai Jiao Tong University led by Prof. Junchi Yan. How can the owner/curator/manager of the dataset be contacted (e.g., email address)? Please contact Xiasong Jia (jiaxiaosong@sjtu.edu.cn) and Junchi Yan (yanjunchi@sjtu.edu.cn) Is there an erratum? No erratum as of submission. Will the dataset be updated (e.g., to correct labeling errors, add new instances, delete instances)? Yes, we will maintain the dataset. Will older versions of the dataset continue to be supported/hosted/maintained? Yes. If others want to extend/augment/build on/contribute to the dataset, is there a mechanism for them to do so? Yes, they could follow the guide in https://github.com/Thinklab-SJTU/ Bench2Drive. J.4 Composition What do the instances that comprise the dataset represent? One basic instance is one clip. Each clip contains hundreds or thousands of frames in 10 Hz with raw sensor information and annotations.. How many instances are there in total (of each type, if appropriate)? There are 13638 clips in Bench2Drive. Are relationships between individual instances made explicit? Yes. Each clip is annotated with scenario types and locations. Clips could have the same scenario type or nearby location. Are there recommended data splits (e.g., training, development/validation, testing)? Yes. In the github repo. Is the dataset self-contained, or does it link to or otherwise rely on external resources? Self-contained. J.5 Collection Process Who was involved in the data collection process (e.g., students, crowdworkers, contractors) and how were they compensated (e.g., how much were crowdworkers paid)? All data is collected in CARLA automatically The collection code is written by authors. J.6 Use What (other) tasks could the dataset be used for? With existing annotations, the dataset could also be used to conduct 3D object detection, semantic segmentation, instance segmentation, point cloud segmentation, depth estimation, tracking, motion prediction.

上記の内容に関して下記の質問に回答下さい: (である調で記載、一般的な推測を回答に混入しない事、元文の記載内容に基づいて忠実に回答、元文量に合わせて回答量は十分長くする事)
①何についての記載か? + 要旨は何? (要旨は箇条書きで記載、既存手法があれば引用元を記載、図・表の参照があれば記載)

▼生成AIの回答(ChatGPT-4o)
①何についての記載か? + 要旨は何?

本節では、Bench2Driveデータセットに関するデータシートの概要を記載している。このデータセットは、フルセルフドライビング（Full Self-Driving, FSD）のための包括的かつ現実的なテスト環境を提供する目的で作成されている。以下に各項目の要旨を示す。

要旨

J.1 Motivation
- データセット作成の目的は、エンドツーエンド自動運転（E2E-AD）手法向けに、既存ベンチマークでは不十分であった「クローズドループ」かつ詳細な運転スキル評価を可能にする包括的なテスト環境を提供すること。
- データセットは上海交通大学のReThinkLabの研究者たち（Xiaosong Jia、Zhenjie Yang、Qifeng Li、Zhiyuan Zhang、Junchi Yan）により作成された。
J.2 Distribution
- データセットは第三者に対しても公開されており、GitHub（https://github.com/Thinklab-SJTU/Bench2Drive）およびHuggingface（https://huggingface.co/datasets/rethinlab/Bench2Drive）で配布されている。
J.3 Maintenance
- データセットの維持管理は、ReThinkLab（上海交通大学）とその新メンバーによって行われ、Prof. Junchi Yanが主導している。
- 問い合わせ先は以下の通りである：
  - Xiasong Jia: jiaxiaosong@sjtu.edu.cn
  - Junchi Yan: yanjunchi@sjtu.edu.cn
- データセットには現在のところ正誤表（erratum）はなく、今後もアップデートが行われる予定である。
- 過去バージョンも引き続きサポートされる。また、拡張や貢献はGitHubリポジトリのガイドラインに従うことで可能である。
J.4 Composition
- データセットの基本単位は「クリップ」であり、各クリップには10Hzの生センサー情報およびアノテーション付きの数百から数千のフレームが含まれる。
- 合計で13,638クリップが存在する。
- 各クリップにはシナリオタイプや位置情報が付与されており、同一シナリオや近接する位置のクリップが存在する。
- トレーニング、バリデーション、テスト用のデータ分割が推奨されており、GitHubリポジトリで提供されている。
- データセットは自己完結型であり、外部リソースには依存していない。
J.5 Collection Process
- データ収集はCARLAシミュレーターを用いて自動的に行われ、収集コードは作成者によって記述された。
J.6 Use
- 本データセットは、E2E自動運転以外にも以下のタスクで利用可能である：
  - 3D物体検出
  - セマンティックセグメンテーション
  - インスタンスセグメンテーション
  - 点群セグメンテーション
  - 深度推定
  - トラッキング
  - モーション予測

あとがき

所感

機械学習についてある程度知っていないと、生成AIに質問しても、その回答内容だけでは理解できないと思います。生成AIの回答は、論文の内容をあまり変えずに、要点をそのまま掻い摘んで回答するような形になっています。(良い意味で論文の要点をそのまま抜き出した形)

分かったこと

分かったこと・注目した点を列挙すると:

Checklist

このチェックリストは、論文投稿者が研究の透明性、再現性、倫理性を確保し、記載内容が適切であることを確認するための質問集である。

A Details of Data Collecting

本章は、データ収集の詳細について述べたものである。

自動化されたパイプラインと手動での確認を組み合わせたデータ収集プロセス

天候、町、シナリオのバランスは手動でチェックし、問題のあるクリップをフィルタリングしている（Fig. 7を参照）。

CARLAの公式APIを使用して注釈を収集しているが、APIには以下のようなバグが存在するため対処している：
(I) 歩行者の速度がAPIでは常に0と表示されるため、速度はトレーニング中に差分計算で求めている。
(II) スピードメーターとIMUの値がNoneの場合があり、トレーニング時に0で補完している。
(III) 地面に配置された停止標識にはバウンディングボックスがないため、矩形でトリガーボリュームを記録している。
(IV) 静止車両の位置や回転情報が不正確な場合があり、中心座標と範囲を使用して正しい3Dバウンディングボックスを作成している。

CARLAの挙動やAPIにはバグが含まれており、手動での確認や計算、補正による対処が行われている。

画像データはJPG形式で圧縮（品質=20）。

B Distribution of Scenarios, Towns and Weathers

Town12およびTown13はCARLAチームによって設計され、旧町に比べて大規模かつ多様な都市レベルのシーンを提供することを目的としている。

C Implementation Details of Baselines

Bench2Driveのデータ収集頻度は10Hzであり、nuScenesの2Hzよりも高頻度で収集されている。

Bench2DriveはnuScenesに比べ約10倍のフレーム数を持つが、冗長性が高い。

UniAD、VAD、ThinkTwice、DriveAdapterのような計算コストが高い手法においては、元の設定の10分の1のエポック数でトレーニングを実施している。

ThinkTwiceおよびDriveAdapterは専門家（expert）のBEV特徴量を必要とするため、Think2Driveを用いてそれらの特徴量を再生成している。

D Training and Evaluation Resource Requirements

各手法のトレーニングおよび評価に必要な計算リソース（GPU種別、台数、時間）が示されている。

AD-MLP
トレーニング：1台のA600 GPUを用いて1日。
評価：4台のA6000 GPUを用いて6時間。

TCP
トレーニング：1台のA600 GPUを用いて1日。
評価：4台のA6000 GPUを用いて6時間。

VAD
トレーニング：8台のH800 GPUを用いて5日間。
評価：8台のH800 GPUを用いて2日間。

UniAD-base
トレーニング：8台のH800 GPUを用い、BEVFormerに3日間、ステージ1に3日間、ステージ2に3日間、合計9日間。
評価：8台のH800 GPUを用いて2日間。

E Behavior Model of NPC Agents

CARLAシミュレーションにおけるNPC（Non-Player Character）エージェントの行動モデル
NPCの運転行動を決定する3つのプリセットの行動タイプ（慎重、通常、攻撃的）
慎重な行動タイプは、低速かつ安全な距離を維持する傾向が強い。
通常の行動タイプは、適度な速度と安全距離を保つ。
攻撃的な行動タイプは、高速での運転や、より短い距離での回避行動が特徴的。

歩行者は一貫してルートラインに沿った一定速度で移動し、後退ができない。

F Details about Infraction Score

CARLA Leaderboard v2に基づいた違反スコアの詳細について

歩行者衝突：ペナルティスコア0.50。
車両衝突：ペナルティスコア0.60。
その他の衝突：ペナルティスコア0.65。
赤信号無視：ペナルティスコア0.70。
シナリオタイムアウト：4分以内にシナリオをクリアできない場合に適用、ペナルティスコア0.70。
低速運転：周囲車両と適切な速度を維持できない場合に適用、ペナルティスコア0.70。
進路譲らず：緊急車両への道譲りに失敗した場合に適用、ペナルティスコア0.70。
オフロード：ルート完了には考慮されない。
ルート逸脱：30メートル以上ルートを逸脱すると即座に終了。
エージェント停止：180秒間行動を停止した場合に即座に終了。
ルートタイムアウト：最大時間を超過すると即座に終了。

G Description of Scenarios

Bench2Driveが提供する44のシナリオ
CARLA Leaderboard V2を拡張したもの

J Datasheet

Bench2Driveデータセットに関するデータシートの概要
データセットは、フルセルフドライビング（Full Self-Driving, FSD）のための包括的かつ現実的なテスト環境を提供する目的で作成されている。

データセット作成の目的は、エンドツーエンド自動運転（E2E-AD）手法向けに、既存ベンチマークでは不十分であった「クローズドループ」かつ詳細な運転スキル評価を可能にする包括的なテスト環境を提供すること。

データセットは上海交通大学のReThinkLabの研究者たち（Xiaosong Jia、Zhenjie Yang、Qifeng Li、Zhiyuan Zhang、Junchi Yan）により作成された。

データセットの維持管理は、ReThinkLab（上海交通大学）とその新メンバーによって行われ、Prof. Junchi Yanが主導している。

データセットの基本単位は「クリップ」であり、各クリップには10Hzの生センサー情報およびアノテーション付きの数百から数千のフレームが含まれる。

合計で13,638クリップが存在する。

データ収集はCARLAシミュレーターを用いて自動的に行われ、収集コードは作成者によって記述された。