01
로봇에서 동작하는 화재 탐지
화재를 놓치는 경우를 줄이기 위해 모델의 탐지 결과와 판정 기준을 비교하는 평가 도구를 만들었습니다. 모델 하나로만 탐지할 때와 결과를 한 번 더 판별할 때(Cascade), 이미지를 여러 형태로 바꿔 결과를 모을 때(TTA)를 비교했습니다. 실제 로봇에서는 탐지 기준을 조정하고, 주행 중 놓친 열원을 다시 찾는 로직을 수정했습니다.
Python · PyTorch · YOLO11n
← 프로젝트 목록
삐용 · 로봇 안전 모니터링
BBIYONG
화재·과열 감지 로봇과 실시간 관제
프로젝트 개요
사람이 계속 순찰하기 어려운 공간에서 로봇이 화재와 설비 과열을 감지하고, 사건 위치와 현장 영상을 관제에서 확인하는 서비스입니다.
- 기간
- 2026.07.06–08.10
- 팀
- 6명 / 전체 기여도 20%
- 담당
- 화재 탐지 평가 도구·탐지 기준·재포착 로직
사건·알림 백엔드 / 인프라·CI/CD - 수상
- 공통 프로젝트 우수상
2026.08.10
서비스 동작 · 팀 시연
01
화재 탐지와
사건 처리
02
사건 저장과 경보 재전송 처리
경보의 messageId와 DB unique 제약으로 중복 저장을 막았습니다. 저장한 사건 번호(eventId)를 로봇 회신, 관제 전달과 사건 영상에 공통으로 사용했습니다. 외부 알림은 대기 상태와 최대 3회 재시도를 따로 관리했습니다.
Spring Boot · MySQL · messageId / eventId
03
파트별 검증과 배포 자동화
GitLab MR에서는 임시 MySQL로 빌드·테스트하고, dev 병합 후에는 해당 파트만 배포하도록 나눴습니다. EC2, Nginx와 Docker Compose로 실행 환경을 구성하고, 서버 준비 상태를 확인한 뒤 배포 결과를 전달했습니다.
EC2 · Nginx · Docker Compose · Jenkins
02
모델 변환과
로봇 시험
학습 모델을 로봇 GPU에서 실행하도록 ONNX로 변환하고 TensorRT FP16으로 추론했습니다. 전열기를 시험용 열원으로 사용해 위험 감지부터 관제 경보까지 공동 시험했습니다.
-
팀원 담당
화재·연기 데이터
모델 학습 -
담당 작업
평가 도구
탐지·재포착 기준 -
공동 작업
ONNX 변환
TensorRT 실행 -
공동 시험
실제 로봇 시험
관제 전달
30.17 ms
발표 기록의 변환 전 추론시간
10.51 ms
공동 최적화 후 추론시간
03
중복 저장과
처리 순서 검증
같은 경보가 동시에 도착해도
저장은 한 번만
저장 전에 존재 여부를 조회해도 두 요청이 동시에 “없음”으로 판단하면 중복 저장을 시도할 수 있습니다. 경보 번호(messageId)의 DB unique 제약으로 중복 저장을 막고, 실제 MySQL에서 동시 저장을 시험했습니다.
24
동시 작업 수 / 총 3회 반복
1
매회 실제 DB에 저장된 사건 행
검증 조건과 확인 범위
24개 작업이 모두 존재 여부 조회를 마치도록 맞춘 뒤 동시에 저장하게 했습니다. 3회 모두 DB에는 1행만 남았고, 후속 처리(모의)도 회마다 한 번만 실행됐습니다.
실제 로컬 MySQL을 사용했으며 로봇 회신, 관제와 외부 알림은 모의 처리로 분리했습니다. 기존 중복 방어 로직을 사후 검증한 결과입니다. 운영 환경의 개선 전후 비교는 수행하지 않았습니다.
같은 로봇의 순서는 지키고,
다른 로봇은 함께 처리
대기열이 차면 일부 작업이 앞선 작업을 추월해 처리 순서가 바뀌었습니다. 대기열에 빈자리가 생길 때까지 기다리도록 바꿔 순서는 지켰지만, 시험용 작업 400건의 총 처리 시간은 약 4.7초에서 6.2초로 늘었습니다.
이후 로봇 번호를 기준으로 대기열을 네 개로 나눴습니다. 같은 로봇의 작업은 들어온 순서대로 처리하고, 서로 다른 로봇은 함께 처리하는 구조를 실제 DB 저장 200건으로 비교했습니다.
176.83 → 607.90
초당 배치 처리량 / 개인 로컬 MySQL 시험
1,118 → 319
처리시간 p99, ms / 작업 99%가 이 값 이하
수치와 시험 조건 자세히
| 항목 | 단일 경로 | 4분할 |
|---|---|---|
| 배치 처리량 | 176.83건/초 | 607.90건/초 |
| p99 | 1,118ms | 319ms |
| 저장 행 | 200/200 | 200/200 |
| 순서 위반 / 실패 | 0 / 0 | 0 / 0 |
네 로봇 번호에 각 50건, 구조별 3회 중앙값입니다. 후속 알림은 모의 처리이며, 시험용 작업 400건의 순서 시험과 실제 DB 200건의 처리량 시험은 서로 다른 실험입니다.
프로그램 종료와 새 작업 접수가 겹치는 경우가 남아 운영에는 반영하지 않았습니다. 특정 로봇에 요청이 몰리는 조건과 로봇 수신부터 화면 표시까지의 실제 부하 시험도 추가 과제입니다.
04
회고
모델 평가와 실기기 검증
실제 주행에서는 열원을 놓치거나 촬영 방향이 어긋나 탐지 기준과 재포착 방식을 조정했습니다. 다음에는 모델을 비교할 때부터 주행 조건과 경보 성공 기준을 정하고, 추론시간, 재포착 동작과 관제 경보를 함께 확인하려 합니다.
사건 처리 조건과 실패 상황의 설계
후속 부하 시험에서 대기열이 가득 차면 같은 로봇의 처리 순서가 바뀌는 문제를 확인했습니다. 다음에는 순서 유지와 중복 저장 방지를 처리량과 함께 검증하고, 대기열 포화와 종료 시 남은 작업의 처리 기준도 처음부터 정하려 합니다.
다른 프로젝트