아래는 원문의 내용을 그대로 한국어로 번역한 결과입니다.

---

에이전트 이해 및 생성

에이전트를 정의하는 것은 navsim.agents.abstract_agent.AbstractAgent를 상속받는 새로운 클래스를 생성하는 것부터 시작합니다.

이 클래스를 좀 더 자세히 살펴보겠습니다. 다음 메서드들을 구현해야 합니다.

• __init__():
  에이전트의 생성자입니다.

• name():
  에이전트의 이름을 반환해야 합니다.
  이 이름은 평가 CSV 파일의 파일 이름을 정의하는 데 사용됩니다.
  임의의 값으로 설정할 수 있습니다.

• initialize():
  에이전트를 처음 추론하기 전에 호출됩니다.
  여러 워커를 사용하는 경우, 각 워커는 자신의 에이전트 인스턴스에 대해 이 메서드를 호출합니다.
  상태 dict 등을 로드해야 한다면, __init__ 대신 여기서 처리해야 합니다.

• get_sensor_config():
  각 프레임마다 에이전트에 대해 어떤 센서 모달리티가 로드되어야 하는지를 정의하는 SensorConfig(자세한 내용은 navsim.common.dataclasses.SensorConfig 참조)를 반환해야 합니다.
  SensorConfig는 각 센서에 대해 로드해야 할 과거 프레임의 인덱스 리스트를 저장하는 데이터 클래스입니다.
  또는, 모든 사용 가능한 프레임을 로드해야 한다면 각 센서에 대해 boolean 값을 사용할 수 있습니다.
  또한, 모든 사용 가능한 센서에 접근하고자 한다면 SensorConfig.build_all_sensors()를 반환할 수 있습니다.
  사용 가능한 센서에 대한 세부 정보는 아래에서 확인할 수 있습니다.

  센서 로딩은 실행 시간에 큰 영향을 미칩니다. 만약 필요하지 않은 센서가 있다면 해당 센서를 False로 설정하는 것을 고려하십시오.

• compute_trajectory():
  이것은 에이전트의 주요 함수입니다. 에이전트는 Ego 상태와 센서 모달리티를 포함하는 AgentInput을 입력으로 받아, 에이전트를 위한 미래 궤적(future trajectory)을 계산하여 반환해야 합니다.
  출력 형식에 대한 자세한 내용은 아래에서 확인할 수 있습니다.

  미래 궤적은 반드시 navsim.common.dataclasses.Trajectory 타입의 객체로 반환되어야 합니다. 예제는 constant velocity agent나 human agent를 참조하세요.

학습 기반 에이전트

대부분의 경우, 여러분의 에이전트는 학습 기반 컴포넌트를 포함할 것입니다.
Navsim은 학습을 위한 경량의 사용하기 쉬운 인터페이스를 제공합니다.
이를 사용하기 위해서는, 위에 언급된 메서드들 외에 추가적인 기능들을 구현해야 합니다.
예제로는 navsim.agents.ego_status_mlp_agent.EgoStatusMLPAgent를 참고하세요.

• get_feature_builders():
  navsim.planning.training.abstract_feature_target_builder.AbstractFeatureBuilder 타입의 feature builder 리스트를 반환해야 합니다.
  FeatureBuilder는 AgentInput 객체를 받아 에이전트 학습 및 추론에 사용되는 feature tensor들을 계산합니다.
  하나의 feature builder가 여러 feature tensor를 계산할 수 있으며, 이들은 딕셔너리 형태로 반환되어 forward pass 시 모델에 제공됩니다.
  현재, 다음과 같은 feature builder들이 제공됩니다:

  • EgoStatusFeatureBuilder
    (현재 속도, 가속도 및 주행 명령을 포함하는 텐서를 반환)
  • TransfuserFeatureBuilder
    (현재 전면 카메라 이미지, LiDAR BEV 맵 및 ego 상태를 포함하는 딕셔너리를 반환)

• get_target_builders():
  get_feature_builders()와 유사하게, 학습 시 사용되는 target builder들을 반환합니다.
  이들은 navsim.planning.training.abstract_feature_target_builder.AbstractTargetBuilder 타입이며,
  feature builder와 달리 에이전트 입력만 있는 것이 아니라, ground-truth 정보가 포함된 Scene 객체에 접근할 수 있습니다.

• forward():
  모델의 forward pass를 구현합니다.
  feature builder들이 생성한 feature들이 딕셔너리 형태로 제공되며, 모든 tensor는 이미 배치 처리되어 모델과 동일한 디바이스에 있습니다.
  forward pass는 "trajectory"라는 키를 포함하는 딕셔너리를 출력해야 하며, 이 키는 미래 궤적을 나타내는 tensor를 포함해야 합니다.
  이 tensor의 shape은 [B, T, 3] 이어야 하며, 여기서 B는 배치 사이즈, T는 미래 타임스텝 수, 3은 x, y, heading을 의미합니다.

• compute_loss():
  feature, target, 그리고 모델 예측값을 받아 학습에 사용되는 loss를 계산합니다.
  loss는 단일 Tensor로 반환되어야 합니다.

• get_optimizers():
  학습에 사용되는 optimizer들을 정의하기 위해 사용합니다.
  학습률 스케줄러 사용 여부에 따라, 이 함수는

  • 단순히 torch.optim.Optimizer 타입의 Optimizer를 반환하거나
  • Optimizer (키: "optimizer")와 torch.optim.lr_scheduler.LRScheduler 타입의 학습률 스케줄러 (키: "lr_scheduler")를 포함하는 딕셔너리를 반환해야 합니다.

• get_training_callbacks():
  이 함수에서는 학습 과정 중 모델의 모니터링이나 시각화를 위해 사용할 pl.Callback 리스트를 반환할 수 있습니다.
  예제로 TransFuser의 콜백인 navsim.agents.transfuser.transfuser_callback.TransfuserCallback을 참고할 수 있습니다.

• compute_trajectory():
  비학습 기반 에이전트와 달리, 학습 기반 에이전트에서는 이 함수를 구현할 필요가 없습니다.
  추론 시에는 feature builder들과 forward 메서드를 사용하여 자동으로 궤적이 계산됩니다.

입력

get_sensor_config()는 에이전트가 접근할 수 있는 센서를 결정하기 위해 오버라이드할 수 있습니다.

사용 가능한 센서는 데이터셋에 따라 다릅니다.
OpenScene의 경우, 9개의 센서 모달리티(8개의 카메라와 5개의 LiDAR에서 생성된 데이터를 병합한 merged point cloud)를 포함합니다.
각 모달리티는 과거 2초 동안 2Hz의 주기로(즉, 4 프레임) 제공되며, 테스트 프레임에는 이 데이터만 제공됩니다(학습 시에는 지도, 트랙, 점유 정보 등을 사용할 수 있으나, 리더보드 제출 시에는 접근할 수 없음).

navsim.common.dataclasses.SensorConfig 데이터 클래스를 사용하여 사용할 센서 모달리티와 각 프레임에 필요한 과거 데이터의 양을 구성할 수 있습니다.

왜 LiDAR인가요?
최근 오픈 루프(planning) 연구에서는 LiDAR 대신 주변 고해상도 카메라를 선호하는 경향이 있습니다.
이는 SoTA(planning) 모델의 학습 및 테스트를 위한 계산 자원 요구량에 큰 부담을 주게 됩니다.
우리는 LiDAR 모달리티의 사용이 더 적은(또는 저해상도의) 카메라 입력을 사용하는 계산 효율적인 제출물을 가능하게 하기를 기대합니다.

Ego 상태.
센서 데이터 외에도, 에이전트는 지역 좌표계에서의 ego pose, 속도 및 가속도 정보를 받습니다.
마지막으로, 운전자 의도를 명확히 하기 위해 좌, 직진, 우 방향의 주행 명령(이산값)이 제공됩니다.
중요한 점은, NAVSIM에서의 주행 명령은 오직 원하는 경로에 기반하며, 이전 벤치마크(nuScenes 등)에서처럼 장애물이나 교통 표지판 정보를 포함하지 않는다는 것입니다.
또한, 좌우 주행 명령은 회전, 차선 변경 및 급격한 커브를 포함합니다.

출력

이 입력들을 바탕으로, compute_trajectory() 메서드를 오버라이드하여 Trajectory를 출력해야 합니다.
이것은 BEV(새로운 시점) pose의 배열(지역 좌표계에서의 x, y, heading)과, 궤적의 지속 시간과 주기를 나타내는 TrajectorySampling 설정 객체를 포함합니다.
PDM 점수는 10Hz 주기로 4초의 시간 범위에 대해 평가됩니다.
TrajectorySampling 설정은 평가 시 사용되는 주기와 출력 주기가 다를 경우 보간(interpolation)을 용이하게 합니다.

에이전트 구현 예제는 baseline들을 참고하세요!

Baselines

NAVSIM은 새로운 end-to-end 주행 모델을 위한 비교 기준 또는 시작점으로 사용할 수 있는 여러 baseline을 제공합니다.
우리는 학습된 모든 baseline의 모델 가중치를 Hugging Face에서 제공합니다.

ConstantVelocityAgent:

ConstantVelocityAgent는 가장 단순한 주행 논리를 따르는 나이브 baseline입니다.
에이전트는 일정한 속도와 일정한 heading angle을 유지하여 직선 형태의 출력 궤적을 생성합니다.
이 에이전트를 사용하여 AbstractAgent 인터페이스에 익숙해지거나, 높은 PDM 점수를 쉽게 달성할 수 있는 단순 솔루션의 샘플을 분석할 수 있습니다.

구현 링크.

EgoStatusMLPAgent:

EgoStatusMLPAgent는 환경을 인지하는 센서를 모두 무시하는 블라인드 baseline입니다.
에이전트는 ego 차량의 상태(즉, 속도, 가속도, 주행 명령)에 대해 다층 퍼셉트론(MLP)을 적용합니다.
따라서, EgoStatusMLP는 단순히 ego 차량의 운동학적 상태를 외삽함으로써 달성할 수 있는 성능의 상한선을 나타냅니다.
EgoStatusMLP는 feature cache를 생성하고 NAVSIM에서 에이전트를 학습하는 절차를 보여주는 경량의 학습 예제입니다.

구현 링크.

TransfuserAgent:

Transfuser는 카메라와 LiDAR 입력을 모두 활용하는 센서 에이전트의 예제입니다.
Transfuser의 백본은 전면 카메라 이미지에 CNN을 적용하고, 이산화된 LiDAR BEV 그리드에 CNN을 적용합니다.
카메라와 LiDAR branch에서 추출된 feature들은 여러 컨볼루션 단계를 거쳐 Transformer를 통해 결합되어 하나의 통합 feature 표현으로 만들어집니다.
Transfuser 아키텍처는 여러 보조 작업(auxiliary tasks)과 모방 학습(imitation learning)을 결합하여 CARLA 시뮬레이터를 이용한 end-to-end 주행에서 강력한 closed-loop 성능을 보여줍니다.

NAVSIM에서는 CARLA Garage에서 Transfuser 백본을 구현하였으며,
보조 작업으로 BEV semantic segmentation과 DETR 스타일의 bounding-box detection을 사용합니다.
Transfuser는 넓은 시야의 카메라 입력을 지원하기 위해, 세 개의 전면 카메라의 패치를 이어붙입니다.
Transfuser는 센서 에이전트를 위한 좋은 시작점이며, 이미지 및 LiDAR 센서 전처리, 콜백을 통한 학습 시각화, 그리고 헝가리안 매칭(Hungarian matching)과 같은 보다 진보된 loss 함수를 제공합니다.

구현 링크.

---

위 내용은 에이전트의 정의, 학습 기반 에이전트 구현에 필요한 추가 기능, 입력 및 출력 데이터 구성, 그리고 몇 가지 baseline 예제에 대한 설명을 담고 있습니다.