Rubik Pi 3 프레임 드랍 문제 해결, 멀티스레딩

YOLO 모델을 활용한 객체 탐지 시스템을 구현하던 중, 프레임 드랍과 프로그램 종료라는 심각한 문제가 발생했다.

초기에는 원활히 작동했지만, 감지되는 객체 수가 1~2개를 초과하면 프레임이 급격히 떨어지기 시작했고,

이후에는 프로그램이 강제 종료되기도 했다.

 문제 원인 : 후처리 병목

처음에는 객체 탐지 이후 수행되는 후처리 과정에서 병목이 발생한다고 판단했다.
매 프레임마다 수행되는 작업은 다음과 같다:

• 객체의 좌표 처리
• 객체 트래킹
• 속도 계산 및 과속 여부 판단
• 프레임 캡처 및 클라우드에 전송

이러한 연산을 단일 스레드에서 처리하다 보니, 프레임당 처리 시간도 점차 증가했고, 이는 곧 시스템의 전체 성능 저하로 이어졌다.

(나는 그렇게 추측해본다..)

 구조 개선 시도 : 멀티스레드 도입

병목 현상을 해소하기 위해 시스템 구조를 멀티스레드 방식으로 리팩토링했다.
작업을 아래처럼 병렬 처리로 분리했다:

• 객체 탐지 메인 스레드
  YOLO 모델을 통해 실시간으로 객체 탐지 수행
• 후처리 스레드
  트래킹, 속도 계산 등의 연산 처리
• 스크린샷 및 서버 전송 스레드
  과속 차량 발생 시 이미지 저장 및 서버 업로드

이 구조는 일정 부분 성능을 향상시켰지만, 여전히 객체 수가 많아지면 프레임 드랍이 발생했고,

시스템 안정성을 완전히 확보하기는 어려웠다.

최종 해결 : 모델 경량화

결국 병목의 근본 원인을 모델의 연산 부하라고 판단하여,

YOLO NAS에서 보다 가벼운 YOLOv5m으로 모델을 변경했다.

YOLOv5m은 연산량이 적어 실시간 처리에 적합하며, 탐지 정확도도 목적에 충분히 부합했다.
모델 변경 이후, 프레임 드랍 문제는 완전히 해소되었고 시스템도 안정적으로 작동하게 되었다.

야외 테스트 : 실제 상황에서의 평가

이후 실제 야외 환경에서 테스트를 진행했다.

차량을 대상으로 한 테스트 결과, 시스템은 예상한 대로 정상적으로 작동했으며,

감지 및 트래킹, 과속 판단, 스크린샷 전송까지 전체 흐름이 잘 연결되었다.

 

다만, 속도 측정의 정확도는 낮은 편이었다.
현재는 픽셀 단위의 중심 좌표 이동량만으로 속도를 계산하고 있는데,

이는 카메라 보정이나 실제 거리 정보 없이 계산되기 때문이다.

실제 테스트 결과, 차량의 실제 속도와 측정값 간의 오차가 많이 발생했다.

https://www.youtube.com/watch?v=tIWNcrL4li8