연구/논문리뷰

[논문리뷰] R-TOD: Real-Time Object Detector with Minimized End-to-End Delay for Autonomous Driving 요약1

윤창이 2021. 1. 8. 03:38
728x90

[주의] 개인 공부를 위해 쓴 글이기 때문에 주관적인 내용은 물론, 쓰여진 정보가 틀린 것일 수도 있습니다!

피드백 부탁드립니다. (- -)(_ _) 꾸벅


https://arxiv.org/abs/2011.06372

 

 

R-TOD: Real-Time Object Detector with Minimized End-to-End Delay for Autonomous Driving

For realizing safe autonomous driving, the end-to-end delays of real-time object detection systems should be thoroughly analyzed and minimized. However, despite recent development of neural networks with minimized inference delays, surprisingly little atte

arxiv.org


[들어가며]

 R-TOD는 Real-time Computing System에서 종단 간 Delay를 어떻게 분석하고 최적화할 것인지에 대해 적어놓은 논문이다. 2020년 10월에 발표됐으니 비교적 최근에 발표된 논문이라고 볼 수 있겠다..! 자율주행에서 사용되는 Object Detector의 종단 간 Delay를 줄이는 방법을 분석적이고 합리적으로 제안했다. 국민대학교에서 발표한 논문인 것 같은데, 역시 자동차와 유서 깊은 학교인 것 같다. 들어가기 앞서 학부생 입장에서 본 논문이므로 사실상 그냥 겉핡기 수준에 불가능하다는 것을 밝히고 시작한다 ㅎㅎ..


[자율주행에서의 Delay?]

 

 자율주행에서는 자동차의 제어가 초단위가 아닌 밀리초(ms) 단위일 정도로 짧은 시간안에 이루어져야 한다. 운전자의 안전을 위해서 어떻게 보면 당연한 얘기일 수도 있겠다. 그에 따르는 Camera-based Object Detection도 당연히 End-to-End 지연이 최소화되어야한다. 이를 위해 최근에 이루어지는 많은 연구들은 Neural Network의 모델을 가볍게 만든다던가, 하드웨어를 가속하는 데에 초점이 맞춰져있다고 한다. 그에 반면에 이 논문에서는 Delay를 철저하게 Analysis(분석)하고, Optimization(최적화)에 중점을 두었다.

 

 먼저 End-to-End delay를 나타내는 지표로 Frame rate가 가장 대표적일 수 있겠다. 말그대로 1초에 몇 장을 처리할 것인지에 대한 지표인데, 이 논문에서는 특별히 Cycle time이라는 것을 쓴다. Frame rate의 Inverse(역수)로 1장을 처리하는데 몇 초가 걸리는지에 대한 지표로 생각하면 될 것 같다. 

 

세 가지의 Nvidia hardware platforms에서의 평균 종단 간 delay 및 cycle time

 위의 표에서는 성능이 각기 다른 Nvidia hardware platforms에서 YOLO 버전별로 상이한 퍼포먼스를 내는 것을 보여주고있다. 예를 들어 설명하자면, Jetson AGX Xavier에서 YOLO v3를 사용하였을 때 163ms밖에 Cycle time이 걸리지 않은 반면에, 최종적인 End-to-End Delay는 1070ms로 약 6배나 느린 지연을 보였다. 즉 충분한 Frequency로 detection이 가능해도, 실제 세계에서 처리하는 데에는 Time lags이 발생한다는 게 핵심 문제.

 

 정리하자면 이 논문에서 던지는 질문을 크게 두 가지이다.

1.  What is the reason for the serious time lags compared with the cycle times of object detection systems?

2.  How can we minimize the end-to-end delays of object detection systems, and by how much?

[Darknet YOLO Architecture의 내부]

 이 논문에서는 Object Detector로 Darknet Framework의 YOLO를 사용한다. 당연하겠지만, 분석하기 위해서는 Darknet YOLO의 내부에 대해 살펴봐야겠지..? 먼저 YOLO는 Image frame Buffer되는 Queue 관리를 위해 OpenCV 라이브러리에 의존한다고 한다. 또한 세 단계의 Multithread Pipeline을 사용한다고 하는데, 그 종류에는 Queue에서 이미지 프레임을 갖고 오는 Fetch 단계, YOLO를 통해 추론하는 Inference 단계, 화면에 결과를 표시하는 Display 단계가 있다. 그런데 이 Queue를 사용하고 Multithread Pipeline을 사용하여 병렬 처리하는 데에 불필요한 Delay가 생긴다고 한다.

 

  • Camera와 Object detector의 Frame rate가 달라 생기는 불필요한 Queuing delay

  • 3개의 Pipeline stage의 길이가 각기 다르기 때문에 짧은 곳에서 Idle time(유휴시간) 발생

  • 동시에 실행되는 GPU 커널과 CPU 스레드 간의 공유 메모리 band-width에 대해 Contention(경합)을 일으켜 실행시간 증가

이에 대한 Delay의 해결법을 결론적으로 말하자면, (Nvidia Jetson AGX Xavier, Yolov3 기준)

 

Queuing delay   =>  On-demand capture

Queue를 사용하지 않고 On-demand로 처리 (1070ms에서 383ms64% 감소)

(On-demand : 요구할 때 마다)

 

Idle time   =>   Zero-slack pipeline

First pipeline stage 종료 직후 다음 주기가 시작되도록 First pipeline stage 지연 (383ms에서 73ms를 감소하여 310ms)

 

Contention(경합)   =>   Contention-free pipeline

Synchronized execution으로 CPU workload로부터 GPU kernel 독립 (delay 좀 더 감소시켜 총 261ms 감소)

 

1070ms  ->  261ms로 총 76% reduction 
Detection Quality 저하없이 End-to-End delay를 76% 감소

 정말 띠용이 아닐 수 없다.. 모델을 가볍게 만든 것도 아니고, 하드웨어를 가속화한 것도 아닌데 단순히 Delay를 최적화하는 것만으로 76%나 감소하였다.


[전반적인 Hardware-Software 구성]

 

 

 Camera Subsystem과 Detector Subsystem으로 구성된다고 볼 수 있겠다. CameraUSB 커넥터로 연결되고, CPU, GPU 이기종 컴퓨팅 플랫폼을 사용한다. 리눅스에서 CPU 스레드, GPU 커널 관리를 위해 CUDA 프레임워크와 Pthread 라이브러리를 사용하며, 그 위에서 Darknet Framework가 돌아간다. 사전에 훈련 된 YOLO DNN을 구동하고, subsystem간에 인터페이스로 Video For Linux Two라는 V4L2 장치 드라이버를 사용한다. 탐지결과는 OpenCV 라이브러리로 시각화!

 

이 Architecture에서 다음 두 문제를 이끌어 낼 수 있다.

 

  • Analysis : Darknet YOLO의 내부 아키텍처 분석을 통해 timing model 도출

  • Optimization : 종단 간 지연을 최소화하는 관점에서 Object detection systems를 위한 최적의 애플리케이션 아키텍처를 제시 


[전반적인 처리 흐름]

 

End-to-End Delay를 한눈에 보기 딱 좋은 그림이다. 여기서 종단 간 delay를 요약할 수 있었다.

 

  1. Camera subsystem : Capture 이후 Queue 되기까지의 delay, Queue의 Arrival interval을 확률분포 A로 정의
  2. Detector subsystem : Queue에서부터 온 이미지가 detect되어 Display 되기까지의 delay, Queue의 Service interval을 확률분포 S로 정의
  3. Queue : Stack size Q에 대해 주어진 A와 S의 차이로부터 생기는 delay

 

 세 가지 종류로 나눌 수 있겠다. 이 논문에서는 세 가지에 대해서 철저한 Analysis를 진행하였다. 먼저 Camera subsystem에서는 카메라 usb의 전송속도에 관해 분석을 한 것 같고, Detector subsystem에서는 다양한 해상도나 object 수에 따른 fetch, inference, display에서의 delay를 경험적인 차원에서 확률분포로 나타내었고, 그에 따른 분포 A와 S의 경우에 따른 Queue의 delay를 분석하는 것 같다.

 

자세한 이야기는 다음에 하도록 하자...^^ㅎㅎ

728x90