[E2EAD] UniAD (CVPR, 2023) (1) - Perception

[신민서]

Planning-oriented Autonomous Driving

---

https://arxiv.org/pdf/2212.10156

https://github.com/OpenDriveLab/UniAD

---

1. Background - 왜 UniAD인지

딥러닝 기반 AD Framework는 4가지로 분류할 수 있다.

(a) Standalone Models

독립적인 task modules을 가지고 있다. 모델끼리 서로의 존재를 모르는 독립된 신경망이다.

Perception + Localization -> Prediction -> Planning -> Control 순서대로 이어지는 형태가 표준이다.

(이런 식으로 구조를 짜게 되면 분할 업무를 하기 쉽고 module을 갈아끼우기 쉽다.)

핵심적으로는 Isolated optimization objectives 그림인데, 세 가지 Task가 다른 지표로 평가되는 걸 보여준다.

이게 왜 문제가 되냐 짚어보면, segmentation model은 IoU 지표에 대해 최적화만 한다.

결과물이 나중에 Planning 단계에서 실질적으로 의미가 있는지가 model train 시 목표에 없다.

따라서 앞 단계에서 자기 지표만 올리다 보니 계획에 필요한 정보가 유실되는 문제점이 있다.

(분류하는 것에만 초점을 두고 학습 -> 다음 단계에서 이를 최적화하지 않음)

결국에는 Error accumulation and Information loss across modules

즉 앞 단계의 오차를 독립된 신경망은 알 수 없기에 점점 오차가 누적, 전파되는 문제점이 생기게 된다.

(b) Multi-task Framework

하나의 feature에서 여러 개의 Head가 갈라져 나와 각각 Task를 수행한다.

앞서 본 model과 다른 점은 input을 처리하는 backbone이 하나로 통합되어 있다는 점이다.

따라서 feature를 한 번만 뽑고, 그 결과를 여러 목적으로 재사용하는 구조이다.

이렇게 되면 backbone 연산을 한 번만 하기 때문에 효율적이고, 새로운 Task가 필요하면 그 Task에 맞는 Head만 붙이면 된다.

또한 하나의 feature로 모든 Task를 수행하기 때문에 이전에 있었던 오차 누적 문제도 줄어들게 된다.

문제는 공유된 feature가 모든 Task에 다 잘 맞추려 한다는 점이다.

Object Detection이 원하는 feature 방향과 Lane Prediction이 원하는 방향이 다르면,

학습(역전파) 도중 gradient 충돌이 일어나 한쪽을 개선하면 다른 한쪽이 나빠지는 negative transfer가 일어난다.

(c.1) End-to-end Framework (Vanilla design)

중간 Task가 전혀 없는 형태, Input Data를 넣으면 곧바로 주행 명령이 나오는 구조이다.

TransFuser(CVPR' 21)도 이에 해당하는 구조이다. https://cafe.daum.net/SmartRobot/RoVa/2581

사람이 일일이 중간 Task를 정의하고 라벨링 할 필요가 없다.

즉, Image - LiDAR를 어떻게 fusion할 지, 언제 얼마나 이동할지를 전부 하나의 네트워크가 Data로부터 학습을 한다.

중간에 이건 보행자인지 차선인지 같은 명시적 개념이 전혀 없는 구조이다.

마찬가지로 TCP(NeurlPS' 22)도 중간 인식 결과에 대한 명시적 개념이 없는 구조이다.

(PAMI' 23 / TransFuser는 이를 Auxiliary Task로 개선했다.)

이러한 구조는 왜 그러한 결정을 내렸는지에 대한 설명을 할 방법이 없고,

인간의 운전을 모방하여 학습한 구조라 낯선 상황에서의 성능도 매우 떨어지는 편이다.

(c.2) End-to-end Framework (Explicit design)

위와 같은 구조는 input -> module1 -> module2 -> planner와 같이 중간에 명시적인 module 구조가 있다.

필요한 만큼만 module을 설계해서 쓸 수 있고 왜 이러한 결과를 내놓았는지 시각적으로 확인이 가능하다.

문제점으로는 모델들(PnPNet, MP3)이 필요로 하는 5가지의 Task(Track, Map, Motion, Occ, Plan)가 충족되지 못한다는 점이다.

(c.3) Planning-oriented Design (Ours)

따라서 논문에서 제시한 구조는 5가지의 Task를 충족하면서 Query 기반 설계로

오차 누적 문제와 negative transfer를 동시에 완화하겠다고 소개한다. (Table 1.)

전체 구조로 들어가기 전에 Query, Key/Value 개념을 제대로 알아야 한다.

Query가 Key들과의 유사도를 재서, 그 유사도(가중치)로 Value들을 가중평균하는 형태가 Attention이다.

가중평균: 각 데이터의 값에 중요도나 비중을 나타내는 가중치를 곱한 뒤 그 값을 모두 더하고,
전체 가중치의 합으로 나누어 구하는 평균값. 각 데이터의 영향력이 다를 때 사용

Q와 K는 얼마나 관련이 있는가를 재는 용도로만 쓰고, 실제 출력에 담기는 내용은 V라는 점이 중요하다.

Self-Attention = Q, K, V 전부 같은 곳에서 나옴 (자기 자신을 참조)

Cross-Attention = Q는 A / K, V는 B (서로 다른 두 소스끼리 참조)

따라서 쉽게 말하자면 무언가의 목적에 맞는 정보를 찾기 위해 학습된 vector가 Query가 되고,

정보를 갖고 있는 원천이 Key/Value가 된다.

Q가 K, V를 참조한다 = vector가 정보에게 물어봐서 필요한 걸 가져온다.

Attention 구조의 학습은 Query가 K, V를 맞게 참조하도록 학습하는 과정이기도 하고,

K, V가 Query에 맞는 정보를 주도록 학습하는 과정이기도 하다. 

2. Pipeline 전체 구조

Multi-view Vision-only Input -> B(BEV feature)가 Perception, Prediction, Planning 모두 다시 들어간다.

앞 모듈의 정보만 믿는 게 아니라, 각 단계가 원본 장면 특징을 항상 재참조한다. (information loss 방지)

또한 Ego-vehicle Query가 TrackFormer부터 Planner까지 계속 이어지는데,

ego vehicle이 처음부터 하나의 agent로 인지되어 다른 agent들과 같은 연산을 받는다.

(Agent: 차량, 보행자 등 다른 객체들을 의미) (Map: 신호등, 차선 등을 의미)

3. Perception - TrackFormer

기반: MOTR (https://arxiv.org/pdf/2105.03247)

Track Q - TrackFormer의 입력 Query / 아래에서 B(BEV feature)가 K, V로 TrackFormer로 들어간다.

이렇게 생긴 구조는 다시 말하자면,

Track Query = Q (Agent를 찾기 위해 학습된 vector) / B = K, V (정보를 가진 원천)

따라서 Track Query는 B(BEV feature)에 어떤 Agent가 있는지, 그에 따른 정보들을 채워넣는 과정이다.

입력 전과 후의 테두리 색이 다른 이유는 TrackFormer를 통과하며 Query가 실제 정보(V)로 채워졌다는 의미다.

중앙의 그림을 보면 세 가지의 input을 따로 받게 되는데, 

K, V인 BEV Feature와 Query인 Detect / Track을 Decoder에 넣는 형식이다.

BEV feature에서 검출된 Agent에 대한 정보가 채워진 vector(hidden state)가 생성된다.

(가중치를 뽑고 그것으로 가중합한 결과물 = V, Agent의 위치/형태 정보를 담은 vector)

hidden state에서 별도의 classification head + bbox regression head를 거쳐야 실제 bbox-class 나온다.

이후 시간에 흐름에 따라 집중해야 할 Agent가 달라지는 듯한 그림이 보이는데

이는 QIM(Query Interaction Module)에서 하는 역할이다.

Decoder가 한 Frame을 처리하고 나면 hidden state와 confidence score가 나온다. (=output)

(confidence score = 해당 클래스에 얼마나 확신이 있는지) 

confidence score가 높은 agent를 갱신할 Query에 추가하고 낮은 건 삭제한다.

이러한 과정을 다음 Frame이 들어왔을 때도 반복하여 계속해서 Query에 갱신하는 역할이다.

(= 이렇게 작동하면 시간순에 따라 집중적으로 봐야할 Agent가 달라진다.)

4. Perception - MapFormer

기반: Panoptic SegFormer (https://arxiv.org/pdf/2109.03814)

Map Q - MapFormer의 입력 Query / 위에서 B(BEV feature)가 K, V로 MapFormer로 들어간다.

위의 TrackFormer와 마찬가지로 Map Query = Q ( Map 구성 요소를 찾기 위해 학습된 vector )이다.

중앙의 그림을 보면 세 가지의 input을 따로 받게 되는데, 

K, V인 BEV Feature와 Query인 Thing / Stuff를 Decoder에 넣는 형식이다.

Thing queries: 셀 수 있는 개별 도로 요소 (Lanes, Crossings...)

Stuff queries: 셀 수 없는 영역 (Drivable areas)

(https://www.ultralytics.com/glossary/panoptic-segmentation#the-core-concept-stuff-vs-things)

Agent 제외 Map 요소 기준으로 역할이 대상의 성질 기준으로 나뉜다 (셀 수 있는지 / 없는지)

사각형 박스 / hidden state

원 / segmentation head를 붙여 나온 결과물 = Map segments