Vineyard Wildlife Guard on RPi Edge
- 프로젝트 한눈에 보기
- 문제 정의
- 왜 이 문제가 어려운가
- 프로젝트 목표
- 현재 기술적 판단
- 왜 이런 접근을 선택했는가
- 도입 기술별 예상 문제
- 기술 검토 요약
- 예상 파이프라인
- 진행 방향
- 기술 문서 모음
- 회고를 보는 기준
이 프로젝트는 포도밭에 침입하는 야생동물(노루·멧돼지·오소리·너구리·조류) 5종을 라즈베리파이 4에서 실시간으로 탐지하는 것을 목표로 하고 있습니다.
같은 도메인의 드론 포도송이 탐지와는 분리해서 보고 있습니다. 포도송이 탐지가 "데이터가 적은 환경에서 정확도를 짜내는" 트랙이라면, 이 프로젝트는 "충분한 데이터 + 엣지 디바이스 제약" 트랙이라 기술 스택과 의사결정 기준이 완전히 다릅니다.
처음에는 모델 학습만 끝내면 된다고 봤지만, 실제로는 변환 → 양자화 → 디바이스 운용 → 카메라 통합 전 과정에서 학습 자체보다 더 많은 의사결정이 필요했습니다. 그래서 이 페이지에서는 단계별 결과 숫자보다 "왜 이 길로 갔고, 어디서 안 됐고, 어떻게 우회했는가" 를 먼저 정리합니다.
위에서부터 노루·멧돼지·오소리·너구리·조류. 야간 IR 카메라트랩(상위 4종)부터 주간 일반 카메라(조류)까지 분포가 섞여 있는데, 한 모델로 모두 처리.
- 포도밭에 침입하는 야생동물을 카메라로 실시간 감지할 수 있어야 한다.
- 모델은 클라우드가 아닌 현장 엣지 디바이스(라즈베리파이 4) 에서 돌아가야 한다.
- 5종 multi-class 분류가 가능해야 하며, 종마다 대응 방식이 다를 수 있어야 한다.
- 5 FPS 이상의 실시간 처리가 필요하다.
- 라즈베리파이 4는 CPU-only이고 Cortex-A72 4코어로 GPU 가속이 없다.
- 일반적인 데스크톱 추론 백엔드(PyTorch, TensorRT)는 ARM에서 제대로 돌지 않는다.
- ARM에서 쓸 수 있는 백엔드(ncnn / onnxruntime / TFLite)마다 양자화 지원 수준이 다르다.
- INT8 양자화는 한 줄 옵션처럼 보이지만 실제로는 calibration 전처리·detection head·activation 분포까지 챙겨야 한다.
- 발열·재부팅·SSH 끊김·외부 접속 같은 운용 변수가 모델 정확도만큼이나 결과에 영향을 준다.
- 모델 정확도 자체보다 "엣지에서 1시간 동안 안 죽고 도는가" 가 더 큰 변수다.
- 양자화 도구의 성숙도가 추론 백엔드별로 천차만별이다.
- 학습 시점 mAP가 좋아도, 현장 카메라에서 false positive가 패턴화되면 운용에 문제가 된다.
- 종별로 충분한 데이터를 모아 multi-class fine-tune까지 끌고 간다.
- 종별 mAP 분포를 확인해 데모/운영에서 어떤 종이 약점인지 파악한다.
- 5 FPS 목표를 ARM 추론 백엔드 비교를 통해 달성한다.
- 정확도/속도/발열의 trade-off를 정량적으로 정리한다.
- 학습된 모델을 카메라 + 추론 + 텍스트 로그까지 묶어 한 흐름으로 동작하게 한다.
- 라이브 환경에서 false positive 패턴을 측정해 데모 전 보완 카드를 정리한다.
- 백엔드는 ncnn FP16 이 현 시점 베스트로 보고 있다.
- INT8 양자화는 onnxruntime ARM EP 한계로 일단 보류한다.
- imgsz는 320을 기본으로, 정밀 분석용으로 640을 옵션화한다.
- 변환·양자화는 dev에서, 엣지는 추론만 담당하는 것이 더 안정적이다.
- 5 FPS가 운영 기준이라, 정확도가 더 좋아도 FPS가 절반인 옵션은 받아들일 수 없었다.
- INT8 양자화는 속도 향상이 매력적이지만, 정확도 손실 30% 이상이면 의미가 없다고 봤다.
- 양자화·변환을 RPi에서 돌리다 OOM 의심 재부팅을 겪고 나서, dev에서 만들고 엣지엔 산출물만 보내는 분리 가 더 안정적임을 체감했다.
- 현장 카메라의 false positive는 모델 retrain 전이라도 confidence 임계값/클래스별 임계값/시간 일관성 필터로 1차 보완 가능하다고 판단했다.
- YOLO11n: 가벼워서 RPi에 적합하지만, 정확도 한계 도달 시 더 큰 모델로 교체가 필요할 수 있다.
- ncnn FP16: ARM에 잘 맞지만 INT8 사용 시 시스템 바이너리 컴파일이 추가로 필요하다.
- onnxruntime INT8: 큰 imgsz의 activation map에서 ARM EP 한계로 정확도가 무너질 수 있다.
- picamera2 + OpenCV: 카메라 학습 데이터 분포와 실내 데이터 분포 차이로 false positive가 발생할 수 있다.
| 백엔드 | RPi 4 가능? | FPS | mAP50-95 | 비고 |
|---|---|---|---|---|
torch CPU .pt
|
가능 | 3.09 | 0.691 | 베이스라인 |
| onnxruntime CPU FP32 | 가능 | 8.98 | 0.684 | 정확도 거의 동일 |
| ncnn FP16 | 가능 | 10.03 | 0.684 | 현재 권장 |
| onnxruntime INT8 | 가능 | 18.54 | 0.473 | 정확도 -31%p 망가짐 |
| TensorRT | 불가 | — | — | NVIDIA 전용 |
| TFLite INT8 | 불가 | — | — | tflite-runtime이 RPi Python 3.13 미지원 |
| imgsz | RPi 4 FPS | mAP50-95 | 용도 |
|---|---|---|---|
| 320 | 10.03 | 0.684 | 실시간 데모 |
| 640 | 2.34 | 0.787 | 오프라인 정밀 분석 |
현재는 "실시간 320 + 옵션 640" 조합이 가장 자연스럽다고 보고 있습니다.
- 5종 데이터 수집·통합 (자동 split 스크립트로 70/20/10)
- YOLO11n multi-class fine-tune (imgsz 320 + 640 병렬)
- 추론 백엔드 비교 (torch / onnxruntime / ncnn)
- 양자화 시도 및 진단 (INT8 망가짐 → FP16 유지)
- 카메라 실시간 검출 MVP (picamera2 + 추론 + 텍스트 로그)
- 라이브 환경 false positive 측정 → 임계값 튜닝
- 1시간 안정성 테스트 + 데모 환경 검증
이 구조는 추후 다른 종 추가나 디바이스 교체 시에도 각 단계를 독립적으로 업데이트하기 좋습니다.
- ncnn FP16 + imgsz 320을 데모 기본 조합으로 확정한다.
- 카메라 MVP의 false positive(특히 bird 클래스)를 임계값/시간 일관성으로 1차 보완한다.
- 발열·안정성을 1시간 연속 테스트로 검증한다.
- 추후 RPi 5 / Hailo-8L NPU / Jetson Orin Nano 비교 트랙은 별도 분기로 분리한다.
- INT8 양자화는 ncnn 시스템 바이너리 컴파일 또는 QAT 트랙으로 다시 검토 가능성을 열어둔다.
| 주제 | 왜 봤는가 | 문서 |
|---|---|---|
| 5종 multi-class fine-tune 변천사 | 단일 종 → 다종으로 확장하면서 어떤 의사결정이 필요했는지 정리하기 위해 | 야생동물 5종 multi-class 학습 변천사 |
| 주제 | 왜 봤는가 | 문서 |
|---|---|---|
| RPi 4에서 torch / ONNX / ncnn 비교 | ARM CPU-only 환경에서 어떤 백엔드가 진짜 맞는지 측정 근거가 필요했기 때문 | RPi 4 추론 백엔드 비교 |
| 주제 | 왜 봤는가 | 문서 |
|---|---|---|
| INT8 양자화 망가짐 진단 | 단순히 "안 됐다"가 아니라 어디서 무엇이 무너졌는지 4가지 원인으로 정리하기 위해 | INT8 양자화 진단 |
| 주제 | 왜 봤는가 | 문서 |
|---|---|---|
| picamera2 + ncnn 실시간 검출 MVP | 학습 시점 mAP와 현장 deploy 환경의 차이를 직접 측정하기 위해 | 카메라 실시간 검출 MVP |
- 1시간 연속 안정성 테스트 결과 (발열·메모리 추이)
- 모션 게이트 도입과 평균 부하 절감 측정
- RPi 5 / Hailo-8L NPU / Jetson Orin Nano 비교 실험
- ncnn INT8 시스템 바이너리 컴파일 트랙
- 양자화 인지 학습(QAT) 검토
- 단순 실험 로그보다 "왜 이 결정을 했는가" 를 먼저 적으려고 했습니다.
- 각 자료는 엣지 ML 배포의 한 단계가 다음 단계의 전제 조건이 되는 흐름으로 이어집니다.
- 즉, 학습 → 변환 → 양자화 → 운용 → 카메라는 분리된 작업이 아니라 한 흐름의 의사결정 사슬이라고 보고 있습니다.
- 정확도와 FPS 외에도 발열, 재부팅, SSH 끊김, false positive 패턴 같은 운용 변수까지 함께 기록하는 것을 기준으로 삼고 있습니다.