[프로젝트 4]🤖 카메라 인식이 v7까지 걸린 이유 – 라즈베리파이 5 Edge AI 완성기

“컨테이너에 카메라 마운트하고 YOLOv8 돌리면 되겠지” 라고 생각했습니다. v1을 올리고 로그를 봤더니 exec format error. v2 올리니 Failed to read frame from camera. v3, v4, v5, v6 빌드 실패… 결국 v7에서야 화재 감지가 정상 동작했습니다. 이 포스팅은 그 7번의 시도 뒤에 발견한 라즈베리파이 5의 카메라 아키텍처에 관한 이야기입니다.

🔗 Edge AI 위키 상세 문서: GitHub Wiki — Edge AI | 모니터링 실증 🐳 Docker Hub 이미지: safe-edge-integrated-ai | safe-edge-audio

---

🌐 왜 Edge AI인가 — 클라우드 AI는 안 되는 이유

스마트 팩토리 현장은 인터넷이 불안정하거나 아예 차단된 폐쇄망 환경인 경우가 많습니다. 클라우드 서버에 영상을 보내서 추론하는 방식의 치명적인 문제가 있습니다.

❌ 클라우드 AI 방식
  현장 카메라 → 인터넷 → 클라우드 서버 추론 → 결과 반환
  문제: 네트워크 단절 시 감시 완전 불가 / 지연 시간 존재

✅ Edge AI 방식 (이 프로젝트)
  현장 카메라 → 라즈베리파이 직접 추론 → 즉시 결과 저장
  장점: 네트워크 독립 / 실시간 처리 / 폐쇄망 완전 동작

화재나 폭발이 일어나는 바로 그 순간, 네트워크도 함께 끊길 수 있습니다. 그 순간에 감지가 안 된다는 건 시스템의 존재 이유 자체를 부정하는 것입니다. 라즈베리파이에서 직접 추론하는 것이 유일한 답이었어요.

---

🧩 4종 AI 파드 구성

파드	감지 대상	모델	입력 장치
safe-edge-integrated-ai	🔥 화재 감지	YOLOv8	CSI 카메라
safe-edge-integrated-ai	🧍 자세 이상 (쓰러짐·굽힘)	YOLOv8 Pose	동일 카메라
safe-edge-audio	💥 이상 소음 (폭발·총성)	YAMNet	USB 마이크
bme280-sensor	🌡️ 온습도·기압	BME280 직접 읽기	I2C GPIO

모든 파드는 추론 결과를 InfluxDB safe_edge_db에 기록합니다. 화재 감지 결과는 0 또는 1의 이진값으로 저장됩니다.

---

💥 Episode 10-1. ARM 아키텍처 — “exec format error”

첫 번째 벽은 v1을 올리자마자 바로 왔습니다.

exec /hello-app: exec format error

PC(x86_64)에서 docker build를 하면 기본적으로 x86_64 아키텍처 이미지가 생성됩니다. 라즈베리파이는 ARM64 아키텍처입니다. 실행 자체가 불가능합니다.

해결: docker buildx로 ARM64 전용 이미지를 빌드합니다.

# --platform 옵션으로 아키텍처 명시
docker buildx build --platform linux/arm64 \
  -t minsoo0919/safe-edge-integrated-ai:v2 \
  --push .

💡 교훈: ARM 기반 노드에 배포할 때는 이미지 빌드 단계부터 --platform linux/arm64를 기본값으로 고정해야 합니다.

---

💥 Episode 10-2. Grafana → InfluxDB 연결 실패 — 내부/외부 DNS 경계

ArgoCD를 통해 InfluxDB를 K3s 클러스터 내부에 올리고, Grafana에서 연결하려 했습니다. Grafana 데이터 소스 설정에 K3s 내부 DNS 주소를 입력했더니 connection refused.

http://influxdb-svc.monitoring.svc.cluster.local:8086
→ connection refused ❌

원인: Grafana는 K3s 클러스터 외부 Host PC에 Docker 컨테이너로 떠 있습니다. K3s 내부 DNS는 클러스터 내부 파드끼리만 통신 가능합니다. 클러스터 밖에서 내부 DNS를 사용하는 건 구조적으로 불가능합니다.

해결: 마스터 노드 고정 IP + NodePort 조합으로 변경합니다.

# 변경 전 (불가)
http://influxdb-svc.monitoring.svc.cluster.local:8086

# 변경 후 (정상)
http://10.10.10.10:30086

추가로 DB명에 오타(sage_edge_db → safe_edge_db)도 있었습니다. 이것도 함께 수정하고 Save & Test 성공.

💡 교훈: 아키텍처를 설계할 때부터 클러스터 내부/외부 통신 경계를 명확히 구분해두면 이런 혼란을 예방할 수 있습니다.

---

💥 Episode 10-3. 카메라 인식 — v1에서 v7까지

가장 오래 걸렸고, 가장 많이 배운 트러블슈팅입니다.

증상: 화재 감지 파드를 배포했더니 로그에 계속 이런 메시지만 뜹니다.

Failed to read frame from camera
No working camera found

처음의 접근:

# USB 웹캠 기준의 일반적인 방식으로 시도
cap = cv2.VideoCapture(0)

v3, v4, v5를 계속 빌드하며 다양한 방식을 시도했습니다. v6에서는 아예 빌드 자체가 실패합니다.

Package 'libgl1-mesa-glx' has no installation candidate

Debian Trixie 베이스 이미지에서 libgl1-mesa-glx 패키지명이 libgl1로 통합 변경된 것이었습니다.

근본 원인을 발견: 라즈베리파이 5는 Pi 4와 달리 새로운 ISP 칩(RP1)을 사용하며, CSI 카메라가 구형 V4L2 드라이버가 아닌 libcamera 전용 아키텍처로 동작합니다.

# 카메라 확인
rpicam-hello --list-cameras
# → [0] : ov5647 [2592x1944] (/base/soc/i2c0mux/...)
#   Modes: 'SRGGB10_CSI2P' ...
# libcamera 방식으로 동작 확인 ✅

cv2.VideoCapture(0) + V4L2 방식으로는 이 카메라에 절대 접근할 수 없었습니다.

v7 해결: GStreamer 파이프라인(libcamerasrc)으로 전환

# 변경 전 (V4L2 방식 — 라즈베리파이 5 CSI 카메라에 동작 안 함)
cap = cv2.VideoCapture(0)

# 변경 후 (GStreamer + libcamerasrc — v7 최종 해결)
pipeline = (
    "libcamerasrc ! "
    "video/x-raw, width=640, height=480, framerate=30/1 ! "
    "videoconvert ! "
    "appsink drop=True max-buffers=1"
)
cap = cv2.VideoCapture(pipeline, cv2.CAP_GSTREAMER)

YAML의 볼륨 마운트도 /dev/video0 단일에서 /dev 디렉터리 전체로 변경했습니다.

# 변경 전: 특정 장치 번호만 마운트
volumes:
- name: camera-dev
  hostPath:
    path: /dev/video0

# 변경 후: /dev 전체 마운트 (실제 스트림 장치 번호 접근 허용)
volumes:
- name: dev
  hostPath:
    path: /dev

💡 교훈: 새로운 하드웨어를 사용할 때는 인터넷 예제 코드를 바로 적용하기 전에 공식 문서에서 드라이버 스택을 먼저 확인해야 합니다. 라즈베리파이 5의 카메라는 Pi 4와 근본적으로 다릅니다. 그리고 컨테이너에서 디버깅하기 전에 호스트 → Docker → Kubernetes 순서로 한 단계씩 검증하는 바텀업 방식이 시간을 가장 절약합니다.

---

📊 InfluxDB 데이터 스키마

Measurement	주요 Field	의미
fire_detection	is_fire (0/1), confidence	화재 감지 여부
pose_detection	is_fallen (0/1), is_bent (0/1)	작업자 자세 이상
acoustic_detection	is_danger (0/1), event_type	이상 소음 감지
environment_data	temperature, humidity, pressure	환경 센서

---

📈 Grafana 관제 대시보드 — mean()이 아니라 max()를 써야 하는 이유

처음에 Grafana 그래프에 이상한 값이 뜨기 시작했습니다.

화재 감지 데이터가 0 또는 1이어야 하는데
→ 0.200, 0.600 같은 소수점 값이 표시됨

원인: Grafana의 Time Series 패널은 기본적으로 mean()(평균) 집계로 데이터를 처리합니다. 0과 1만 있는 이진 데이터에 평균을 내면 구간 내 감지 비율로 계산되어 소수점이 나옵니다.

해결: max()로 변경합니다. 구간 안에서 단 한 번이라도 감지됐으면 1을 표시합니다. 관제 시스템에서 “한 번이라도 화재가 감지됐으면 경보”가 올바른 로직입니다.

-- 변경 전
SELECT mean(is_fire) FROM fire_detection WHERE time > now()-5m GROUP BY time(10s)

-- 변경 후
SELECT max(is_fire) FROM fire_detection WHERE time > now()-5m GROUP BY time(10s)

4개 패널 구성:

패널	측정값	0 (정상)	1 (감지)
🔥 화재 감지	max(is_fire)	✅ 초록 / SAFE	🚨 빨강 / FIRE
🚨 쓰러짐 감지	max(is_fallen)	✅ 초록 / SAFE	🚨 빨강 / FALLEN
⚠️ 굽힘 감지	max(is_bent)	✅ 초록 / SAFE	⚠️ 노랑 / BENT
🔊 이상 소음	max(is_danger)	✅ 초록 / SAFE	🚨 빨강 / DANGER

---

✅ Edge AI 완성 상태

항목	상태
YOLOv8 화재 감지 (libcamera + GStreamer)	✅
YOLOv8 자세 이상 감지	✅
YAMNet 이상 소음 분류	✅
BME280 환경 센서	✅
InfluxDB 데이터 저장	✅
Grafana 4패널 실시간 관제	✅

이제 AI 파드들이 현장을 24시간 감시하고 있습니다. 다음 문제는 이 데이터가 끝없이 쌓이는 것을 어떻게 처리하느냐입니다. 라즈베리파이 SSD는 무한하지 않으니까요.

🔗 다음 편: 5편 — 데이터 티어링: K3s CronJob이 CPU를 1291%까지 폭주시킨 날 🔗 Edge AI 위키 전체: GitHub Wiki — Edge AI Wiki