Abstract
문제
오랫동안 객체가 가려지거나, detection 결과가 좋지 않은 경우 ID-switching이 발생하게 된다.
해결
존재하는 과거정보와 미래 정보를 예측해서 활용하자.
- Past Reasoning
- 과거정보를 활용하여 추적중인 객체의 feature를 refine
- Future Reasoning
- 과거정보와 현재 정보를 활용하여 추적중인 객체의 미래 위치를 예측
- 문제 해결의 핵심
Introduction
3D multi-object tracking에서 LiDAR 기반의 접근들은 많지만, 비용이나 센서의 신뢰도로 인해 적용이 어렵다.
카메라의 경우에도 여러 접근들이 있지만, 대부분 detection이나 tracking이 독립적으로 연구되는 경우가 많다.
물론 몇몇 접근들이 detection과 tracking을 같이 다루지만, 인접한 여러 frame들을 사용하면서 시공간적인 특징을 결합하지 못했다.
이 논문에서는 카메라 기반에서 detection과 tracking을 같이 최적화하는 것이 성능을 극적으로 향상시키는 방법들을 제안한다.
PF-Track은 tracking-by-attention 방식을 사용하며, 다른 framework와 비교했을때 명시적으로 과거 및 미래 정보를 사용한다.
- 3D object query가 frame들 사이에서 객체의 시공간적인 정보를 전달하고, 관련된 bounding box 및 미래의 궤적을 생성한다.
- 간단한 attention 연산으로 객체의 동적인 특징과 상호작용을 알아내고, 추적중인 객체 특징의 refine 및 장기적인 객체의 이동을 예측한다.
- 예측된 객체의 이동을 활용하여 가려지는 것과 같이 객체를 놓치는 것을 해결한다.
- 따라서 제안하는 framework의 이름을 "Past-and-Future reasoning of Tracking", 즉 "PF-Track"이라 이름 지었다.
Method
[Pipeline] 개요
Multi-view, multi-object, 3D tracking을 해결하기 위해 object query들을 반복해서 사용.
목표는 다음과 같다.
- 어느 카메라(view)에서든 같은 객체는 같은 ID로 일관되게 잡아내야한다.
[Pipeline] 3D Object Queries
시작은 t-1시점에서 만들어진 object query들을 가져오는 것이다.
- 여기서 설명한 object query는 tracking중인 instance의 identity를 의미한다.
추가적으로 t시점에 만들어진 고정된 크기의 detection query를 가져온다.
- Tracking중인 instance가 아닌 새로운 instance를 찾기 위해.
- 500개의 learnable embedding으로 구현. [코드]
시점에 상관없이 query는 다음과 같이 구성된다.
1. Feature vector
2. 3D location
[Pipeline] Decoder
Decoder에서는 입력으로 다음이 사용된다.
1. T-1 시점에 만들어진 object query feature + T시점에 만들어진 detection query feature
2. Image feature
3. Query들의 position을 positional embedding으로 사용
세부적인 특징은 다음과 같다.
- Decoder로는 deformable transformer를 사용.
- Positional embedding으로 객체가 존재하는 위치 주변의 image feature를 더 집중하도록 함
[Pipeline] Past and Future Reasoning for Refinement and Propagation
Past 및 future reasoning의 목적은 다음과 같다.
1. Query와 3D bounding box의 refinement
2. 다음 timestamp로 예측된 motion과 함께 query를 전달(propagate)
"Past Reasoning"은 과거 정보(이전 frame들)로부터 현재 얻은 query와 box 정보를 refine하는 것
- 구현에서는 query queue에 historical query라는 이름으로 이전 frame들의 query를 저장
"Future Reasoning"은 query를 다음 timestamp로 전달하는 관점에서 객체들의 위치가 일관될 수 있게 해준다.
먼저 앞서 설명한 historical query와 past reasoning으로 얻은 refine된 query를 통해 다음 두가지를 생성한다.
1. T+1 시점에 대한 query
2. (T ~ T+$T_f$) 까지 객체의 움직임(motion) 예측 정보
이때 움직임 예측은 다음과 같이 활용된다.
1. (T ~ T+1)에 대한 움직임 정보는 다음 timestamp로 현재 query를 전파하는데 사용
2. (T+1 ~ T+$T_f$)은 객체가 가려지는 상황(occlusions)을 해결하기 위해 사용된다.
[Past Reasoning] 개요
3D localization을 기반으로 다음 두 관점에 맞춰 제안하는 것이 past reasoning 이다.
1. Historical embedding을 사용해서 query feature를 강화하는것
2. 강화된 query feature를 사용하여 조정한 bounding box를 통해 track들을 refine하는 것
[Past Reasoning] Query Refinement
Query refinement는 두가지 단계로 구성된다.
1. Cross-frame attention : 시간에 따라 쌓인 정보로 query 강화 [코드]
2. Cross-object attention : 탐지된 객체의 공간 정보로 query 강화 [코드]
Cross-frame attention의 경우 입력은 다음과 같다.
- Query : t시점에 구해진 query feature
- Key, Value : $\tau_{h}$ 개의 저장된 query(Historical Query)
Positional embedding으로 timestamp를 변환하여 사용한다.
- 시간에 따른 객체의 변화를 활용하여 query를 강화하겠다는 의도
Cross-object attention의 경우 입력은 다음과 같다.
- Query, Key, Value : cross-frame attention의 output
Positional embedding으로 객체들의 3차원 위치정보에 대한 embedding을 사용한다.
- 객체의 위치를 활용하여 query를 강화하겠다는 의도
- 객체끼리의 구별을 더 강화
시간과 공간에 따라 query를 따로 강화시켰는데 이를 decoupling한다고 한다.
이런 decoupling은 두가지 이점을 갖는다.
1. 공간과 시간에 따른 positional embedding을 각각 구성해서 사용할 수 있게 된다.
2. Computational complexity가 낮아진다.
Complexity 부분에 대해 설명을 더 해보자면 다음과 같다.
참고로 frame들을 약 0.5초를 기준으로 다른 시간대에 수집된 데이터이며, 구체적으로는 이미지들이다.
Decoupling을 하지 않는 경우, 저장된 frame끼리 서로 비교(attention)을 수행해야한다.
- Frame의 개수는 $\tau_h$ 개이므로 frame 끼리의 비교는 $O(\tau_{h}^{2})$ 만큼의 복잡도를 가진다.
- Frame끼리의 비교 한번에는 frame 내부 객체끼리 비교가 필요하다.
- 객체의 개수를 $N_t$ 개라고 할때, 객체끼리의 비교 한번에는 $O(N_{t}^{2})$ 만큼의 복잡도를 가진다.
- 최종적으로 decoupling을 하지 않는 경우의 복잡도는 시간끼리의 비교와 객체끼리의 비교를 곱한 $O(N_{t}^{2} \cdot \tau_{h}^{2})$ 이다.
Decoupling이 일어나는 경우, 시간에 따른 비교와 객체의 따른 비교가 분리된다.
- Cross-frame attention은 객체 하나하나마다 시간에 따른 비교(frame 끼리의 비교)가 들어가므로 복잡도는 $O(N_t \cdot \tau_{h}^{2})$ 이다.
- Cross-object attention은 객체끼리의 비교와 같으므로 복잡도는 $O(N_{t}^{2})$ 이다.
- 최종적으로 decoupling을 했을 경우의 복잡도는 위의 두 복잡도를 더한 $O(N_{t}^{2} + N_t \cdot \tau_{h}^{2})$ 이다.
따라서 computational complexity가 낮아진다는 것을 알 수 있다.
[Past Reasoning] Track Refinement
Track refinement는 query refinement로 강화된 query를 통해 tracking중인 객체의 3D bounding box를 강화한다.
두가지 branch로 나눠서 강화시킨다.
1. Classification branch : 강화된 query에 MLP를 적용하여 score를 다시 구함 [코드]
2. Localization branch : 강화된 query에 MLP를 적용하여 bounding box의 3D 위치를 조정함 [코드]
강화된 bounding box 정보는 최종적인 model output이 된다.
[Future Reasoning] 개요
Future reasoning은 가려지는 상황이나 객체가 잘 잡히지 않는 상황(이미지가 흐린 경우)을 해결하기 위해 제안됐다.
1. 객체들이 어떻게 움직일지 경로를 예측(motion prediction)하고
2. 예측된 경로를 활용하여 가려지거나(occlusion) noisy한 track을 구별하고 유지시킨다.
[Future Reasoning] Motion Prediction
Motion prediction의 경우, cross-frame attention과 같은 구조를 사용한다.
입력은 다음과 같다.
- Query : 길이가 $\tau_f$ 인 $N_t$ 개의 객체에 대한 embedding, 값은 0으로 설정 [코드]
- Key, Value : 과거 $\tau_h$ 개의 historical query들
Positional embedding으로 timestamp를 변환해서 사용한다.
- 대신 변환할때 $\tau_h + \tau_f$ 만큼의 길이로 생성한다.
- 앞의 $\tau_h$ 개는 key, value의 positional embedding으로 사용한다.
- 나머지 $\tau_f$ 개는 query의 positional embedding으로 사용한다.
Query가 0으로 설정되지만, positional embedding이 더해지기 때문에 계산에 사용되는 첫 query는 0이 아닌것에 주의하자.
결과로 나온 값에 MLP를 한번 더 적용하여 최종적인 motion 예측을 생성한다. [코드]
이후 미래 $\tau_f$ 개 frame 각각에 대해 예측된 motion정보로 위치를 업데이트 해준다. [코드]
이런 motion예측은 velocity를 사용하는 것과 필수적으로 비교될 수밖에 없다.
- Table 5를 보면 ADE (Average Displacement Error), FDE (Final Displacement Error)가 velocity와 비교해서 더 낮게 나온것을 알 수 있다.
[Future Reasoning] Track Extension
지금까지의 연구들은 객체가 사라지거나(missing), confidence가 낮은 객체를 다음과 같이 다뤘다.
- 추적중인 대상을 더이상 추적하지 않거나(terminate)
- Kalman filter같은 heuristic한 motion model을 사용했다.
그러나, 이런 방식들을 다음과 같은 이유로 ID-switching을 발생시킬 수 있다.
- Early ermination
- False association
반면, PF-track은 track extension을 통해 이를 해결한다.
Track extension은 예측된 미래 정보(motion prediction)의 활용을 다룬다.
- 앞에서 $\tau_{f}$ 개의 motion을 예측하기 때문에 현재 정보를 기준으로 track의 길이를 $\tau_f$ 개만큼 추가할 수 있다.
- 그래서 track "extension"이다.
따라서 무슨 이유가 됐던, 몇 frame 추적중인 객체를 찾지 못해도 상관이 없어진다.
어디로 이동할지 예측해놨기 때문에 $\tau_f$ frame 안에만 다시 찾을 수 있으면 된다.
물론 "절대"란 없듯, motion 예측의 부정확함이나, $\tau_f$ 보다 길게 객체를 놓칠 수 있기 때문에 id switching은 일어날 수 있다.
Track Extension Algorithm
구현된 코드는 supplementary에 작성된 알고리즘으로 정확하게 동작한다.
그러나 occlusion이나, low confidence같은 상황에서 어떻게 동작하는지 코드에서 찾기가 힘들다. [issue]
전체적인 흐름은 track_instance.reference_point 가 어떻게 이용되는지 추적하면 이해가 편하기 때문에 이를 이 부분에 정리한다.
reference_point과 가장 크게 엮이는 변수들은 다음과 같다.
- cache_reference_points : t시점에 다뤄지는 reference point
- hist_xyz : 추적중인 객체의 과거 위치
- fut_xyz : 추적중인 객체의 미래 위치
위 변수들을 염두하고 아래 흐름을 따라오는 것을 추천한다.
- 흐름들의 순서는 모델 train시의 순서임을 참고하자.
[Cam3DTracker.init_params_and_layers]
0. reference_points의 초기화 [코드]
[Cam3DTracker.generate_empty_instance]
0. track_instance의 초기화
- cache_reference_points = reference_points.weight, [코드]
- hist_xyz = 0, [코드]
- fut_xyz = 0, [코드]
[PETRCamTrackingHead.forward]
1. outs["reference_points"] = 업데이트된 reference_points, [코드]
- 첫 프레임인 경우 : 업데이트에 사용되는 reference_points는 0번째 단계에서 초기화된 값
- 그 외의 경우 : 업데이트에 사용되는 reference_points는 10번째 단계에서 구해진 값
[Cam3DTracker.load_detection_output_into_cache]
2. cache_reference_points = outs["reference_points"], [코드]
[SpatialTemporalReasoner.frame_shift]
3. hist_xyz 맨 뒤 = cache_reference_points, [코드]
4. reference_points = fut_xyz 의 첫번째, [코드]
- 첫 프레임인 경우 : fut_xyz는 0번째 단계에서의 초기화 값
- 그 외의 경우 : fut_xyz는 8번째 단계에서 구해진 값
5. fuz_xyz = fuz_xyz[1:], [코드]
6. cache_reference_points = 업데이트 된 cache_reference_points, [코드]
- 업데이트는 reference_points가 아니라 cache_reference_points에 된다는 것을 주의하자
[Cam3DTracker.frame_summarization]
여기서 active_mask가 나온다.
- Confidence값이 특정 threshold를 넘긴 객체를 의미한다.
- Training시 threshold값은 0으로 추적중인 모든 객체가 active상태가 된다.
- Inference시 threshold값은 [0.4]이다.
- 7번째 단계부터 마지막 단계까지 다뤄지는 track_instance는 모두 active 상태이다.
7. reference_points = cache_reference_points, [코드]
- 여기가 핵심인데, active상태가 아니면 4번째 단계의 reference_points로 고정이다.
- 따라서 tracking extension이 4번째 단계에서 이루어진다는 것을 알 수 있다.
8. fut_xyz = reference_points + motion, [코드]
[SpatialTemporalReasoner.update_reference_points]
9. reference_points = fut_xyz의 첫번째, [코드]
[SpatialTemporalReasoner.update_ego]
10. Ego 기준(촬영중인 자동차)으로 좌표를 조정한다. [코드]
- reference_points, hist_xyz, fut_xyz 모두 좌표가 조정된다.
'논문 정리 > 3D Multi Object Tracking' 카테고리의 다른 글
[논문 정리] OneTrack: Demystifying the Conflict Between Detection and Tracking in End-to-End 3D Trackers (0) | 2024.10.20 |
---|---|
[논문 정리] End-to-end 3D Tracking with Decoupled Queries (1) | 2024.09.02 |