CCTV Bike Idle Detection Project
- 프로젝트 한눈에 보기
- 문제 정의
- 왜 이 문제가 어려운가
- 프로젝트 목표
- 현재 기술적 판단
- 왜 이런 접근을 선택했는가
- 도입 기술별 예상 문제
- 예상 파이프라인
- 진행 방향
- 기술 문서 모음
- 회고를 보는 기준
이 프로젝트는 한동대학교 캠퍼스 CCTV 위에 두 가지 컴퓨터비전 시스템을 같은 파이프라인 백본으로 올리는 것을 목표로 합니다.
- 자전거 경로 추적 — 자전거에 부착된 커스텀 번호판을 CCTV 가 읽어, 어느 구간(A/B/C/D) 을 어떤 순서로 지났는지 경로를 복원
- 차량 공회전 탐지 — CCTV 로 정차 중인 차량이 시동을 켠 채 공회전하는지 탐지
기존의 야생동물 RPi 엣지 배포 가 "충분한 데이터 + 엣지 디바이스 제약" 트랙이었다면, 이 프로젝트는 "고정 CCTV 부감 시점 + 도메인 갭 + 합성 데이터 사전학습" 트랙입니다. 카메라가 실제로 설치되기 전 2주의 사전 준비기 동안 합성 데이터/공개 데이터로 베이스 모델을 만들고, 도착 후 소량(100~500장) 실데이터로 fine-tune 한 사이클 도는 전략을 택했습니다.
위 이미지는 사전 검증으로 돌린 Zone A (주차장) dry-run 결과로, 215대 차량 트랙이 동시에 잡힌 순간을 트랙별 고유 색 + #ID 라벨로 시각화한 것입니다. 한 모델이 차량·사람·자전거를 한 번에 검출 → ByteTrack 으로 시간축 유지 → 트랙별 시계열을 parquet 로 보관 → 도메인 로직(공회전·경로) 에 넘기는 구조.
- 카메라 4대(A·B·C·D 구간)를 통해 자전거 경로와 차량 공회전을 모니터링해야 한다.
- 자전거는 단순한 ID 추적이 아니라, 부착된 커스텀 번호판을 OCR 로 읽어 구간 통과 순서를 복원해야 한다.
- 차량 공회전은 단순 "정지" 만으로 판정할 수 없다. 시동 ON 상태로 정차 + 운전자 탑승 + 시간 임계값 ≥ 20초 의 다중 신호 조합이 필요하다.
- 카메라는 SD 카드 저장 후 회수 방식이라 실시간 RTSP 처리가 아니라 오프라인 batch 흐름이다.
- 카메라 도착 전이라 실데이터가 없다. 사전 2주 동안 합성/공개 데이터만으로 베이스 모델을 만들어 둬야 한다.
- CCTV 부감 시점은 COCO 가 학습한 분포와 다르다. 차량·사람 검출 자체는 COCO 가중치로 돌지만 정확도는 떨어질 수 있다.
- 차내 운전자가 안 보인다. 부감 30~40° 각도라 차량 안 운전자 박스가 매 프레임 안 잡혀서 단순 "이 프레임에 person 있냐" 만으론 0% 가 나온다. 시간축 상태 추정이 필요하다.
- 자전거 커스텀 번호판은 어떤 공개 데이터셋에도 없다. 합성 데이터를 직접 만들어야 한다.
- 후미등 분류기 학습 데이터는 블랙박스 정면 시점. 우리 CCTV 부감과 도메인 갭이 분명하다.
- 모델 정확도 자체보다 "4 카메라 영상이 모인 뒤 같은 자전거를 같은 세션으로 묶을 수 있느냐" 가 더 큰 변수다.
- 학습 시점 mAP 가 좋아도, 부감 시점에서 false positive 가 패턴화되면 운용에 문제가 된다.
- 시험 시나리오상 같은 자전거가 한 카메라에 여러 번 재등장한다. 세션을 어떻게 자르느냐가 결과의 의미를 좌우한다.
- COCO YOLO11 + ByteTrack 으로 차량·사람·자전거 검출/추적
- 트랙별 시계열을 parquet 로 보관 → 도메인 로직과 분리
- 시각화 mp4 자동 생성 (트랙별 고유 색 + #ID 라벨)
- 정지 + 탑승 + (보조) 후미등 신호의 다중 조합
- T_idle_sec = 20s / 30s 두 케이스 평가
- 부감 시점 운전자 가림에 대응하는 boarding 상태기계 도입
- 합성 번호판 생성기 → 5만 장 단독 + 3천 장 자전거 장면 합성
- CCPD 사전학습 → 합성 데이터 fine-tune (번호판 검출)
- 36-class 문자 분류기 또는 PARSeq fine-tune (OCR)
- 화이트리스트 매칭 (편집거리 1 이내 스냅)
- 4 카메라 영상 → 영상별 1패스 추론 (GPU 병렬) → 일괄 통합
- cameras.yaml offset_sec 으로 카메라 간 시각 동기
- 세션 분할 규칙: 같은 구간 재등장 → 직전 세션 종료 + TTL 5분 안전망
- 캘리브레이션 런으로 cameras.yaml offset 산출
- 실데이터 100~500장 fine-tune
- 자전거 라이더 2명 × 45 루트, 공회전 50회 + 미공회전 50회 평가
- 객체 탐지·추적은 COCO 가중치 그대로 출발. Ultralytics YOLO11 + ByteTrack 으로 충분하다. 학습 리소스는 번호판·OCR·후미등·로직에 집중.
- 후미등 분류기는 EfficientNet-B0. Roboflow Tail_Lamp_KLETECH 학습 결과 test 82.68% 로 3 모델 중 가장 일반화 잘됨. brake_on FN 가장 낮음.
-
운전자 탑승 신호는 시간축 상태기계. 부감에선 차내가 안 보이므로 person 박스가 차량 ROI 에 들어왔다가 사라지면 탑승으로 잠근다 (
boarding.py). - 세션 분리는 "같은 구간 재등장 → 직전 세션 종료" 규칙. 시험 시나리오가 한 방향 통과 후 다시 시작이라 자연스럽다.
- DB 미사용, Parquet/CSV 만. 운영·다중 사용자 단계가 아니므로 분석은 parquet 으로 충분. 필요 시 ETL 추가.
- 합성 데이터를 직접 만드는 길 — 자전거 커스텀 번호판은 어떤 데이터셋에도 없어 합성이 유일한 길. 다행히 디자인이 통제되어 있어 (알파벳 2 + 숫자 2, 색상 분리, 화이트리스트) 합성 난이도가 낮다.
- 3 모델 병렬 학습 — ResNet18 / MobileNetV3-Large / EfficientNet-B0 을 처음부터 같이 돌려 test 시점에 비교. 순차로 돌면 GPU 한 장이 노는 시간이 너무 길다.
- boarding 상태기계 추가 — 매 프레임 has_driver 만 보면 부감 시점에서 0% 가 나옴을 dry-run 으로 확인. 시간축으로 보면 "사람이 차에 다가가 → 사라짐" 패턴이 분명히 잡힌다.
- 오프라인 batch 흐름 — 카메라가 SD 저장 방식으로 결정되어 실시간 RTSP 처리는 일단 보류. 코드는 영상 파일을 입력으로 받는 구조로 통일.
- COCO YOLO ↔ 부감 CCTV 도메인 갭 — 정확도 측정 후 부족하면 AI-Hub 시내도로 CCTV 로 fine-tune. 신청 + 승인 며칠 소요라 지금부터 신청.
- 후미등 분류기 도메인 갭 — 블랙박스 정면 분포로 학습. 빨간 차체에 false positive 가 생길 수 있어 rolling 평균 + 정지·탑승과의 다중 신호 조합으로 보완.
- PARSeq 합성 데이터 fine-tune — 36-class 단일 문자 분류기로 대체 가능. 새 번호판 추가 시 재학습 안 해도 됨.
- 다중 카메라 시각 동기 — 캘리브레이션 런 영상으로 cameras.yaml 의 offset_sec 산출. 어긋나면 세션이 잘못 묶임.
[Phase 1] 카메라 → SD 회수 → NAS
bike_idle_original/recordings/{camA, camB, camC, camD}/
[Phase 2] 영상별 1패스 추론 (GPU 병렬)
GPU 0: camA → camA.parquet (트랙별 프레임 단위 raw)
GPU 1: camB → camB.parquet
...
[Phase 3] 영상별 후처리 (CPU)
① 트랙별 OCR 다수결 → 번호판 확정
② 화이트리스트 매칭 (편집거리 1 이내)
③ 카메라 단위 세션 후보 추출
[Phase 4] 다중 카메라 일괄 통합 (CPU, 1회)
① cameras.yaml offset 적용 → 시각 정규화
② 같은 번호판의 시간순 관측 정렬
③ 세션 분할 (재등장 → 종료, TTL 5분 안전망)
④ 세션별 경로 복원: ['A','B','C','D']
→ sessions.parquet
- Phase 1·2·4 의 코드 구조는 상세 페이지 에서 확인 가능. Zone A dry-run 까지 마쳤다.
- Phase 3 (자전거 OCR) 는 합성 번호판 생성기까지 끝나 있고, 검출·OCR 모델 학습이 남아 있다.
- Phase 5 는 카메라 도착 이후 단계. 현재 D-14 시점.
이 프로젝트는 "카메라 도착 전 2주 동안 무엇을 준비해 두느냐" 가 가장 큰 의사결정이었습니다. 단순히 "공개 데이터로 학습한다" 가 아니라:
- 어떤 부분이 COCO 가중치로 공짜로 해결되는지
- 어떤 부분이 합성 데이터가 유일한 길인지
- 어떤 부분이 도메인 갭으로 도착 후 fine-tune 이 필수인지
를 분리해서 학습 리소스를 배분한 것이 핵심입니다. 모델 자체보다 "학습 안 해도 되는 것을 학습 안 하기" 가 결과적으로 더 중요했습니다.