졸작을 끝낸지 1주일이 넘었는데, 여러가지 문제로 정신이없어후기를 이제야 올린다. 지난 2달 동안 준비한 졸업작품 전시회를 무사히 마쳤다.비록 수상은 하지 못해 아쉬움이 남지만, 그동안의 노력이 의미 없진 않았다.이번 프로젝트는 AI 모델을 활용한 차량 과속 탐지 및 알림 제공 서비스였다.주제는 퀄컴(QUALCOMM) 측에서 직접 정해줬다. https://github.com/Qualcom-Capstone Qualcom-CapstoneQualcom-Capstone has 5 repositories available. Follow their code on GitHub.github.comhttps://www.youtube.com/watch?v=FDzbjOeika8 내가 담당한 파트는 YOLO 기반 객..

속도 측정 알고리즘 개선기존에는 객체의 프레임당 중심 좌표 이동 거리를 이용해 속도를 계산했지만,이 방식은 실제 차량의 속도를 정확히 반영하지 못했다.카메라의 위치, 각도, 해상도, 거리 왜곡 등 다양한 요소가 영향을 미치기 때문에,단순한 픽셀 거리 기반 계산만으로는 신뢰할 수 있는 속도 추정이 어려웠다.새로운 방식: 선 통과 기반 시간 측정이에 따라, 속도 측정 방식을 다음과 같이 변경했다:화면에 가상의 두 선을 설정하고, 객체(차량)가첫 번째 선을 통과한 시점두 번째 선을 통과한 시점이 두 시점 사이의 시간 차를 측정하여 속도를 계산하는 방식이다.이를 통해 실제 움직인 거리를 고정된 기준으로 환산할 수 있게 되었고,특정 픽셀 간 거리를 미터 단위로 환산할 수 있다면 훨씬 정확한 속도 계산이 가능해졌다..

YOLO 모델을 활용한 객체 탐지 시스템을 구현하던 중, 프레임 드랍과 프로그램 종료라는 심각한 문제가 발생했다.초기에는 원활히 작동했지만, 감지되는 객체 수가 1~2개를 초과하면 프레임이 급격히 떨어지기 시작했고,이후에는 프로그램이 강제 종료되기도 했다. 문제 원인 : 후처리 병목처음에는 객체 탐지 이후 수행되는 후처리 과정에서 병목이 발생한다고 판단했다.매 프레임마다 수행되는 작업은 다음과 같다:객체의 좌표 처리객체 트래킹속도 계산 및 과속 여부 판단이러한 연산을 단일 스레드에서 처리하다 보니, 프레임당 처리 시간도 점차 증가했고, 이는 곧 시스템의 전체 성능 저하로 이어졌다. 구조 개선 시도 : 멀티스레드 도입병목 현상을 해소하기 위해 시스템 구조를 멀티스레드 방식으로 리팩토링했다.작업을 아래처럼 ..

Rubik Pi 3 보드에서 YOLO기반의 객체 탐지 및 속도 측정 시스템을 개발하고 있다.어느정도 핵심 기능이 구현되어 중간 경과를 간단히 적어본다.YOLO 모델 구동Rubik Pi 보드 환경 세팅GStreamer 기반 객체 탐지 + Bounding Box + 기타 시각화appsink를 통한 메타데이터 파싱 및 후처리IoU기반 객체 트래킹중심 좌표 기반 속도 측정과속 시 스크린샷 촬영 기능가장 어려웠던 부분환경 구성과 메타데이터 처리qtimlsnpe, qtimlvdetection 이후의 text/x-raw 포맷을 appsink로 받아오는 과정바운딩 박스 좌표, 기타 정보 파싱 과정GPU 메모리 포맷 (NV12, GBM, RGB) 호환 문제이 모든 과정은 커뮤니티에서도 사례가 없었기 때문에,직접 파이프라..

이번에는카메라 영상출력, YOLO-NAS 객체 탐지, 바운딩 박스 오버레이, 메타데이터 추출까지겪었던 모든 과정을 공유하려고 한다. Rubik Pi 보드 기반으로 이 작업을 시도한 사례는한국은 물론, 해외 커뮤니티에서도 찾기 힘들다.그만큼 의미있는 도전이라고 생각한다.목표(Rubikl Pi 보드 위에서)YOLO-NAS모델을 돌려 객체를 실시간으로 탐지카메라 영상 디스플레이 출력탐지된 객체 바운딩 박스 화면에 overlay메타데이터(라벨, 좌표 정보)를 별도로 추출초기 과정처음에는 비교적 단순해 보였다. GStreamer 하나만으로 메타데이터를 받아오고, 오버레이까지 처리할 생각이었다.하지만 곧 문제가 발생했다.이전 글에서도 다뤘듯이, GStreamer만으로 메타데이터를 받아오는 시도는 실패했고, 대..