FirePatrol - BIM 도면으로 소방 순찰 로봇 운용 가능성 진단하기

1. 개요

FirePatrol은 건물 BIM 모델(IFC)만으로 소방 순찰 로봇의 운용 가능성을 진단하는 Windows 프로그램입니다. 로봇이 어느 소방시설까지 갈 수 있는지, 화재 때 몇 초 만에 도착하는지, 몇 대가 필요한지를 현장 조사 전에 계산하고, ROS 2 시뮬레이션으로 검증합니다.

개발 배경과 해결하려는 문제

소방 순찰 로봇을 건물에 들이기 전에는 “이 건물에서 로봇이 제 역할을 할 수 있는가”를 먼저 따져야 합니다. 지금은 현장에서 문 폭과 턱을 재거나, 사람이 도면을 보고 판단합니다.

하지만 BIM 모델에는 벽, 문의 폭과 방화 등급, 바닥 단차, 가구 배치, 소방시설의 종류와 위치가 이미 들어 있습니다. 이 정보를 직접 계산하면 현장에 가지 않고도 다음 질문에 답할 수 있습니다.

• 로봇이 점검할 수 있는 시설은 몇 개이고, 못 가는 곳은 왜 못 가는가 (문 폭 · 좁은 통로 · 단차)
• 화재가 나면 몇 초 만에 도착하고, 평상시 순찰은 얼마나 막히는가
• 목표 대응 시간을 지키려면 로봇이 몇 대 필요하고 어디에 두어야 하는가
• 어느 문을 고치면 효과가 가장 큰가

주요 기능과 개발 범위

IFC 파일과 로봇 사양을 넣고 [전체 검사 → PDF]를 누르면 진단부터 보고서까지 이어서 계산합니다. 예제 모델(60×32m, 소방시설 151개) 기준 약 1분 30초가 걸립니다. 범위는 한 층 단위의 PoC입니다.

IFC 하나에서 진단, 화재, 배치, 개선안이 이어서 나온다

모든 분석은 점검 경로 · 진단 결과를 공통 바탕으로 합니다. ROS 2 시뮬레이션에서 잰 실제 주행 시간은 다시 로봇 대수 계산에 되돌아갑니다.

프로그램 전체 화면

사용한 AI도구와 기술 스택

2. 개발 과정

설계와 구현 방향 결정, 검증은 개발자가 주도하고, AI는 코드 작성과 반복 작업을 돕는 도구로 활용했습니다. 기능마다 요구사항과 판정 기준을 먼저 정한 뒤, AI와 함께 구현하고 직접 실행해 확인하는 순서로 진행했습니다.

개발 방식과 AI 활용

• 기능 단위 반복: 한 기능씩 요구사항 정리 → 구현 → 실행 확인 순서로 진행하고, 확인이 끝난 뒤 다음 기능으로 넘어갔습니다.
• 문서로 맥락 유지: 결정 사항 · 남은 문제 · 다음 할 일을 작업 기록으로 남겨, AI 작업 세션이 바뀌어도 같은 맥락에서 이어갔습니다. 기록은 저장소의 docs/개발기록.md에 있습니다.

검증 설계: 정답이 있는 시험 모델

구현 결과를 객관적으로 판단하기 위해, 기능 구현보다 먼저 정답이 정해진 시험 IFC를 설계했습니다.

• 24×14m 시험층에 소방시설 34개를 두고, 8개는 일부러 도달할 수 없게 설계했습니다: 0.40m 통로 안쪽 2개, 폭 0.45m 문 뒤 3개, 0.15m 문턱 뒤 3개.
• 진단 결과가 도달 수(26/34)뿐 아니라 원인까지 정답과 같아야 다음 단계로 넘어갔습니다.
• 사무실 · 2층 창고 모델도 같은 방식으로 만들어 회귀 시험에 썼습니다.
• 시뮬레이션 분석도 같은 방식입니다. 계수를 알고 만든 가짜 주행 기록 · 사진으로, 분석이 그 값을 되찾는지 먼저 확인했습니다.

개발 순서

1. 요구사항 정리, 시험 모델과 정답표
2. 도면 처리: 추출 → 주행 지도 → 점검 경로 → 리포트
3. ROS 2 · Gazebo 순찰 시뮬레이션 (C++ 순찰 노드)
4. Windows 진단 프로그램(exe)
5. 화재 시나리오 (FDS 연동)
6. 화재 위험 지도, 개선안 시험, 로봇 프리셋, PDF 보고서
7. 로봇 대수 · 배치, 화재 확산 시간 진행
8. 3D 디지털 트윈
9. 예제 모델과 대형 도면 성능 개선
10. 시뮬레이션 고도화: 실제 주행 시간 보정, 점검 카메라 · 가시성 판정

기능별 개발 내용

순찰 가능성 진단

소방시설마다 로봇이 점검 위치까지 갈 수 있는지 판정하고, 못 가면 원인을 문 폭 · 좁은 통로 · 단차 중 하나로 내놓습니다.

1. 도면 정보 추출: IFC에서 소방시설(스프링클러, 감지기, 소화기 등), 문(폭 · 방화 등급 · 문턱 높이), 공간, 벽 · 기둥 · 가구를 읽어 시설 목록과 점검 체크리스트를 만듭니다.
2. 주행 지도: 층 형상을 5cm 격자로 나눠 지날 수 있는 곳을 계산합니다. 로봇이 넘을 수 있는 높이보다 높은 턱 · 올림바닥은 경계를 막고, 통로는 ‘폭 + 양옆 여유’ 이상이어야 지납니다.
3. 점검 위치와 도달 판정: 천장 시설은 바로 아래, 벽 · 바닥 시설은 0.7m 앞을 점검 위치로 잡고, 대기 위치에서 최단 경로를 찾습니다. 못 가는 곳은 단차 → 문 폭 → 좁은 통로 순서로 원인을 확인해 수치와 함께 표시합니다.
4. 점검 경로: 갈 수 있는 점검 위치를 한 번에 도는 순서(최근접 + 2-opt)를 정하고, Nav2 웨이포인트 미션 파일(nav2_waypoints.yaml)로 내보냅니다.

로봇 사양은 프리셋(바퀴형 · 4족 보행 · 소형 실내형)으로 고르거나 실제 제품 사양을 저장해 씁니다.

진단 지도 - 도달 / 못 감 시설과 원인 점검 경로

화재 시나리오와 확산 시간 진행

화재가 난 상황에서 로봇이 몇 초 만에 현장에 도착하는지, 평상시 순찰이 얼마나 막히는지, 사람의 대피 경로가 안전한지를 계산합니다.

• 화원 입력: FDS 입력 파일에서 화원 위치 · 발열량(HRR) · 성장 곡선(RAMP)을 읽습니다. IFC와 FDS는 원점이 다를 수 있어 범위를 비교해 자동으로 맞추고, 필요하면 수동 보정합니다.
• 세 가지 분석: 로봇 출동(위험 구역 가장자리까지 경로 · 시간), 화재 중 순찰(위험 구역을 막고 다시 계획), 대피(출구까지 1.2m/s 보행, 정상 / 우회 / 위험 구역 통과 / 출구 없음).
• 위험 구역: 직선이 아니라 벽을 돌아가는 거리로 계산해, 벽 너머 방은 가깝더라도 포함하지 않습니다.
• 시간 진행: 발열량은 FDS 곡선 또는 NFPA 72의 t² 성장 모델을 쓰고, 위험 반경은 발열량에 따라 커집니다. 연기는 50kW 이후 벽을 따라 0.3m/s로 퍼지고, 감지(30초)에 로봇 출동과 대피가 시작됩니다. 슬라이더 · 배속 재생, MP4 저장을 지원합니다.

화재 시간 진행

로봇 대기 위치와 대수 계획

화재는 어느 방에서든 날 수 있으므로, 건물 전체를 기준으로 위치와 대수를 정합니다.

• 화재 위험 지도: 모든 공간에 가상 화원을 두고 방별 출동 시간 · 막히는 점검 위치 · 대피 위험을 비교해, 최악 출동 시간이 가장 짧은 대기 위치를 추천합니다.
• 필요 대수: 목표(최대 출동 초 · 순찰 한 바퀴 분 · 포인트당 점검 초 · 최대 대수)를 넣으면 만족하는 최소 대수를 찾습니다. 대기 위치는 0.5m 간격 후보 중 k-center로 고르고, 점검 위치를 가까운 로봇에 배정한 뒤 순찰 시간을 고르게 조정합니다.
• 시간 계산: 기본은 ‘거리 ÷ 속도’입니다. ROS 2 시뮬레이션을 한 번 돌리면 실제 주행 시간 보정을 반영하고, 보정 전 기준 대수도 함께 보여 줍니다(아래 ROS 2 절).

화재 위험 지도 로봇 배치 (실제 주행 시간 반영)

개선안 시험

“이 문을 넓히면 몇 개를 더 점검할 수 있나”를 건물을 고치기 전에 확인합니다. 문마다 새 폭이나 경사로를 넣거나, [문제 문 자동 채우기]로 진단에서 원인이 된 문을 한 번에 채웁니다. 원본은 그대로 두고 사본으로 다시 진단해, 문마다 늘어나는 시설 수를 보여 줍니다. 개선 공사의 우선순위를 정하는 근거가 됩니다.

개선안 전후 비교

3D 디지털 트윈과 보고서

• 3D 디지털 트윈: 프로그램 안 3D 탭에서 IFC의 벽 · 문 · 가구 · 소방시설 위에 분석 결과를 겹쳐 봅니다. 진단(판정 색, 순찰 로봇 애니메이션) · 화재 시간 진행(불 · 연기 · 출동 · 대피) · 위험 지도 · 로봇 배치 · 개선안 보기를 고르고, 시설이나 문을 누르면 판정 근거가 나옵니다. HTML 파일 하나로 내보내 인터넷 없이 공유할 수 있습니다.
• 보고서: [전체 검사 → PDF]가 진단 → 화재 위험 지도 → 화재 시나리오 → 로봇 배치 → 개선안을 차례로 돌려 A4 PDF 한 편으로 정리합니다. 시뮬레이션 결과가 있으면 ‘시뮬레이션 검증’ 절이 더해집니다.

3D 디지털 트윈

ROS 2 시뮬레이션: 도면 계산으로는 알 수 없는 것

도면 계산은 “갈 수 있나”를 빠르게 답하지만, 로봇이 실제로 얼마나 걸리는지, 도착해서 시설이 보이는지는 알 수 없습니다. 같은 미션 파일로 Gazebo에서 로봇을 달려 이 두 가지를 측정합니다.

• 가상 환경: IFC에서 벽 · 기둥 · 올림바닥 · 가구를 3D 형상으로 만들어 Gazebo 월드를 자동 생성하고, 같은 IFC로 Nav2 지도를 만듭니다.
• 순찰 노드 (C++): 점검 위치마다 경로 계획을 먼저 확인한 뒤 주행하고, 문은 양쪽 정렬 위치를 거쳐 정면으로 통과합니다. 실패하면 코스트맵 초기화 → 후진 → 재시도합니다.
• 실제 주행 시간 보정: 포인트마다 경로 계획 · 주행 · 촬영 시간을 따로 기록하고, 구간별 예측 시간(격자 거리 ÷ 속도)과 비교해 아래 식의 계수를 최소제곱(계수 0 이상)으로 구합니다. k는 가감속 · 경로 굴곡, d는 문 앞 정렬, c는 출발 · 정지 · 제자리 회전 시간입니다.
  식 : 실제 시간 ≈ k × (거리 ÷ 속도) + d × 문 수 + c
• 보정값 활용: 로봇 대수 계산은 이 식으로 출동 · 순찰 시간을 다시 계산합니다. 보정값은 건물보다 로봇(가감속 · 회전 · 문 정렬)에 따른 값이라 로봇 사양 · 속도별로 저장하고, 시뮬레이션하지 않은 건물에도 같은 로봇이면 재사용합니다.
• 점검 카메라 · 가시성 판정: 로봇 모델에 RGB-D 카메라 2대(전방: 높이 0.45m · 18° 위 · 화각 120°, 상향: 천장 방향 · 화각 100°)를 넣고, 점검 위치에 멈춘 뒤 사진과 깊이 영상을 저장합니다. 시설의 3D 위치를 카메라에 투영해, 그 자리 깊이가 시설까지 거리보다 확실히 짧으면 가려짐(가구 · 벽 등), 사진 밖이면 화각 밖, 아니면 보임으로 판정합니다. 사진에는 시설 위치와 판정을 표시합니다.

3. 구현 결과

위 기능은 모두 Windows 프로그램(exe)에서 동작하고, 검증용 모델 4개 층에서 판정이 정답과 일치했습니다. 시뮬레이션에서는 실제 순찰 시간이 도면 예측의 약 2.3배라는 것을 확인했습니다.

적용 예시: 연구동 1층

기능 시연을 위해 만든 가상 건물입니다 (60×32m, 공간 14개, 문 21개, 소방시설 151개, 실험실 · 창고 화재 FDS 2종).

시뮬레이션으로 확인한 것

시험 도면(소방시설 34개)의 실제 시뮬레이션 기록(0.3m/s, 도달 구간 24개)으로 계산한 값입니다.

보정식은 실제 ≈ 1.49 × 예측 + 문당 7.5초 + 포인트당 8.8초 (R² 0.96)입니다. 거리만으로는 로봇 한 대가 출동 목표(30초)를 거의 지키는 것처럼 보이지만, 실제로는 두 배 가까이 걸립니다. 로봇 대수를 거리만으로 정하면 적게 잡을 수 있다는 뜻입니다.

구간별 예측 vs 실제 주행 시간

4. 문제 해결 및 개선사항

문제가 생기면 로그와 결과 파일로 원인 후보를 직접 좁히고, AI와 함께 검토해 수정한 뒤 다시 실행해 확인했습니다.

사례 1. 시뮬레이션 로봇이 문을 통과하지 못함

현상 — 도면 진단은 26/34인데 Gazebo 시뮬레이션은 17~19/34에서 멈췄습니다.

분석과 해결 — 포인트별 로봇 위치와 오류를 기록한 결과 파일과 Nav2 로그로 원인을 하나씩 좁혔습니다.

1. 올림바닥 방을 지도에서 통째로 막아, 위치 추정(AMCL)이 로봇을 그 안에 있다고 착각 → 테두리만 막도록 수정
2. 전역 코스트맵에 라이다 장애물이 쌓여 가짜 벽이 생김 → 전역 경로는 IFC 지도만 사용
3. 주행 제어기(MPPI)가 문으로 꺾어 들어갈 때 모서리를 깎아 차체가 문틀에 붙고 이후 경로 계획이 모두 실패 → Regulated Pure Pursuit로 교체하고, 문 양쪽 정렬 위치를 거쳐 정면으로 통과

결과 — 26/34. 갈 수 있는 포인트는 재시도 없이 모두 도달했습니다. 이 문 앞 정렬 시간은 나중에 실제 주행 시간 보정에서 ‘문 1개당 +7.5초’로 측정됩니다.

사례 2. 점검 카메라가 바닥 소화기를 못 봄

현상 — 처음에는 전방 카메라를 벽 설비에 맞춰 25° 위로 두었는데, 가짜 영상 시험에서 바닥 소화기(높이 0.25m, 0.55m 앞)가 사진 아래로 벗어났습니다.

해결 — 바닥 소화기부터 벽 발신기(높이 1.3m)까지 한 화면에 담도록 화각을 120°로 넓히고 18°로 낮췄습니다. 가림 판정 여유도 거리 비례(0.18m + 거리의 10%)로 바꿔, 0.55m 앞 시설 앞의 0.3m 물체는 가려짐으로, 벽 설비의 두께(0.15m)는 보임으로 판정하게 했습니다. 실제 환경에 넣기 전에 가짜 데이터로 먼저 시험한 덕분에 발견한 문제입니다.

한계와 개선 방향

• 검증은 가상 모델로만 했고, 실제 건물 IFC로는 아직 확인하지 않았습니다.
• 로봇 프리셋의 4족 · 소형 사양은 예시 값입니다.
• 5cm 격자로 판정하므로, 필요 폭과 5cm 이내로 차이 나는 곳은 보수적으로 ‘못 감’이 될 수 있습니다.
• 화재 확산은 발열량 곡선 기반의 단순 모델이며, FDS 해석 결과(온도 · 연기 농도)를 직접 쓰지는 않습니다.
• 실제 주행 시간 보정은 측정한 속도에서만 씁니다. 속도를 바꾸면 다시 측정해야 합니다.
• 가림 판정은 IFC에 있는 가구 · 벽만 반영합니다. 실제 현장의 짐 · 닫힌 문은 모릅니다.
• 층별로 진단하며, 여러 대 시뮬레이션은 한 대씩 실행합니다.

5. 개발 경험 및 향후 계획

반복적인 구현을 AI가 도와 준 덕분에, 설계와 검증에 더 많은 시간을 쓸 수 있었습니다.

AI 활용이 효과적이었던 부분

• 새 기술 영역 진입: ROS 2 · Nav2 · Gazebo, PySide6, three.js처럼 기존 업무(C++ CAD/BIM 엔진)에서 쓰지 않던 기술을 짧은 기간에 동작하는 수준까지 올렸습니다.
• 기능 확장 속도: 진단 파이프라인 위에 화재 시나리오, 대수 계획, 개선안, 3D, 시뮬레이션 분석을 기능 단위로 빠르게 쌓을 수 있었습니다.
• 로그 · 데이터 분석: 수천 줄의 Nav2 로그에서 원인을 찾거나, 주행 기록에서 보정식을 뽑는 일을 빠르게 처리했습니다.
• 시험 데이터 생성: 정답표가 있는 시험 IFC, 예제 모델, 가짜 주행 기록 · 사진을 코드로 만들어 실제 데이터 없이도 검증할 수 있었습니다.

부족했던 부분과 주의할 점

• 실제 환경 차이: AI 쪽 시험을 통과해도 Windows · WSL 실제 환경에서는 다르게 동작한 경우가 있었습니다. 마지막 확인은 항상 실제 환경에서 해야 합니다.
• 검증 기준이 필요: 기준 없이 결과만 보면 맞는지 판단하기 어렵습니다. 정답표를 먼저 만든 것이 가장 효과가 컸습니다.
• 코드 이해는 필수: AI가 작성한 코드도 구조와 핵심 알고리즘은 직접 이해하고 검토해야 유지보수할 수 있습니다.
• 작업 관리: 세션이 바뀌거나 여러 세션을 동시에 쓸 때는 인계 기록과 파일 전달 규칙이 없으면 같은 실수가 반복됩니다.

기존 개발 방식과의 차이

향후 계획

• 실제 로봇 제품 사양(크기, 승월 단차, 속도)으로 프리셋과 주행 시간 보정값 만들기
• 실제 건물 IFC로 현장 검증
• SoonBuilder에서 바로 진단하는 연동
• FDS 해석 결과(온도 · 연기 농도)를 반영한 화재 확산
• 여러 대 동시 시뮬레이션(복도 · 문에서 서로 막히는지)과 층간 이동