Open-RMF 구조: 서로 다른 로봇과 문·엘리베이터를 하나의 작업 흐름으로 묶는 방법

Open-RMF는 모든 로봇을 하나의 제조사 명령으로 바꾸는 장치가 아닙니다. 작업 디스패처, 플릿 어댑터, 교통 스케줄과 문·엘리베이터 어댑터가 각 시스템의 책임을 연결합니다. 구성요소별 데이터 경계와 실패 소유권을 알아야 통합이 운영 가능한 형태가 됩니다.

아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.

Open-RMF는 로봇 한 대의 내비게이션보다 여러 플릿과 건물 자원을 조정한다

Open-RMF 공식 저장소는 이 플랫폼을 상호운용 가능한 로봇 플릿과 공유 인프라를 통합하는 모듈 집합으로 제공합니다. 각 로봇의 SLAM과 모터 제어를 대신하기보다 작업, 교통 일정과 건물 설비 사이의 경계를 연결합니다.

개별 로봇의 경로 계획은 글로벌·로컬 플래너 글의 영역입니다. Open-RMF는 플릿 어댑터가 보고한 경로와 진행 상태를 바탕으로 다른 참여자와의 시간축 충돌과 작업 흐름을 조정합니다.

작업 요청은 디스패처에서 입찰과 낙찰을 거쳐 플릿으로 간다

공식 rmf_demos는 디스패처가 BidNotice를 발행하고 플릿 어댑터가 비용이 담긴 BidProposal을 보내며 선택된 제안에 낙찰을 주는 흐름을 설명합니다. 운송이나 순회 같은 작업 요청이 특정 제조사 API에 바로 묶이지 않는 이유입니다.

입찰 비용은 예상 완료 시간과 배터리 상태처럼 플릿이 실제로 계산할 수 있는 근거에서 나와야 합니다. 디스패처는 숫자를 비교하지만 그 비용의 단위, 만료와 거절 사유는 통합 계약에서 통일해야 합니다.

플릿 어댑터는 Open-RMF 상태와 제조사 플릿 API 사이의 책임 경계다

플릿 어댑터는 로봇의 위치, 배터리, 경로 진행과 작업 상태를 RMF에 갱신하고 낙찰된 작업을 제조사 시스템이 이해하는 이동·행동 명령으로 바꿉니다. 로봇마다 직접 중앙 제어를 붙이는 대신 기존 플릿 매니저를 하나의 참여자로 연결할 수 있습니다.

공식 free_fleet 저장소는 플릿 어댑터 구현을 살펴볼 수 있는 예시입니다. 실제 적용에서는 상태 갱신 주기, 경로 인덱스, 명령 취소, 재접속과 배터리 모델을 제조사 API에 맞춰 검증해야 합니다.

교통 스케줄은 지도 좌표만이 아니라 시간축 궤적을 공유한다

같은 복도를 쓰는 두 로봇도 통과 시각이 다르면 충돌하지 않습니다. 각 참여자는 예상 궤적을 스케줄 데이터베이스에 등록하고 지연이나 경로 변경이 생기면 갱신해 다른 참여자의 계획과 비교합니다.

스케줄은 로봇의 실제 안전 정지를 대신하지 않습니다. 로컬 센서와 제어기가 사람과 돌발 장애물에 대응하고, 지연을 플릿 어댑터가 RMF에 알려 이후 궤적과 인프라 예약이 현실과 맞게 바뀌어야 합니다.

구성요소주요 입력책임 범위
Dispatcher작업 요청·BidProposal낙찰·작업 상태
Fleet Adapter로봇 상태·제조사 API명령 변환·진행 갱신
Schedule시간축 경로·지연충돌 탐지·협상 데이터
Door·Lift Adapter설비 상태·요청문 개방·엘리베이터 세션 연결

문 어댑터는 이동 계획의 문 요청을 실제 출입 설비와 연결한다

로봇이 닫힌 문 앞까지 간 뒤 별도 자동화가 열어주기를 기대하면 타임아웃과 소유권이 모호해집니다. 문 어댑터는 문 상태를 보고하고 개방 요청을 설비 제어기에 전달하며 요청이 끝난 뒤 정상 상태로 돌아가는 흐름을 담당합니다.

화재 신호, 접근 권한과 사람 우선 모드처럼 건물 시스템이 거부할 수 있는 조건을 명시해야 합니다. RMF 요청이 있었다는 사실과 실제 문이 안전하게 열렸다는 확인은 다른 상태이므로 센서 피드백과 제한 시간을 분리합니다.

엘리베이터는 단순한 층 버튼보다 세션 소유와 탑승 상태가 중요하다

플릿 간에 하나의 엘리베이터를 공유하려면 호출 층, 목적 층, 문 상태, 현재 모드와 세션 소유자를 관리해야 합니다. 로봇이 탑승하지 못했는데 문이 닫히거나 다른 요청이 세션을 빼앗는 실패를 다뤄야 합니다.

Open-RMF API 문서에는 lift watchdog과 schedule participant, interruption·issue 관련 API가 포함되어 있습니다. 설비 응답 타임아웃 뒤 자동 재시도 횟수와 수동 전환 주체를 운영 절차로 연결합니다.

좌표계와 지도 이름이 맞지 않으면 연결은 되지만 로봇은 다른 곳으로 간다

RMF 맵의 기준점과 제조사 맵 사이의 평행 이동, 회전과 스케일을 교정합니다. 층 이름과 waypoint 이름도 문자열이 같다는 이유로 동일하다고 가정하지 말고 대응표와 실제 주행 시험으로 확인합니다.

로봇 좌표계와 TF2 글의 원칙처럼 변환 방향과 단위를 명시해야 합니다. 지도 앵커를 세 점 이상 사용하고 양방향 변환 오차를 기록하면 회전 부호나 미터·픽셀 혼동을 빨리 찾을 수 있습니다.

작업과 인프라 연결 흐름을 구성요소별 상태로 추적한다

작업 ID 하나로 입찰, 플릿 낙찰, 로봇 명령, 문 요청과 엘리베이터 세션을 연결해 추적합니다. 각 시스템 로그 시각이 다르면 동일 사건의 순서를 복원하기 어려우므로 공통 시각과 원본 타임스탬프를 함께 저장합니다.

분산 로그의 시간 기준은 PTP와 하드웨어 타임스탬프 글에서 설명한 것처럼 정확도 요구를 정해 적용합니다. 모든 장치에 PTP가 불가능해도 게이트웨이 수신 시각과 설비 원본 시각을 분리하면 인과 관계를 추적하기 쉬워집니다.

작업 디스패처 플릿 어댑터 교통 스케줄 문과 엘리베이터 어댑터가 연결되는 Open-RMF 구조
작업은 디스패처에서 시작하지만 실제 로봇 명령은 플릿 어댑터가, 문과 엘리베이터 상태는 각 인프라 어댑터가 담당합니다. 출처: 피지컬 AI Lab.

오류 소유권은 플릿·RMF·건물 설비 중 한 곳에 명확히 둔다

로봇이 waypoint에 도달하지 못했는지, 문이 열리지 않았는지, 스케줄 협상이 끝나지 않았는지에 따라 첫 대응 주체가 다릅니다. 오류 코드는 현상뿐 아니라 감지 시스템, 영향받은 작업과 재시도 가능성을 담아야 합니다.

중단과 취소도 구분합니다. 일시 중단은 같은 작업을 이어갈 수 있지만 취소는 적재물 인계나 로봇 복귀 같은 보상 절차가 필요할 수 있으므로 API 응답 성공만으로 완료 처리하지 않습니다.

통합은 가상 플릿에서 시작해 한 대·한 문·한 층씩 넓힌다

먼저 제공 데모에서 디스패처와 스케줄의 정상 흐름을 재현하고, 제조사 API 모의 서버로 상태 지연과 실패를 주입합니다. 다음 단계에서 실제 로봇 한 대의 이동·취소·재접속을 검증한 뒤 문과 엘리베이터를 하나씩 추가합니다.

여러 플릿을 동시에 붙이기 전에 각 플릿의 좌표 오차, 경로 갱신 지연과 배터리 모델을 단독으로 측정합니다. 통합 범위를 한꺼번에 넓히면 어느 경계에서 상태가 틀어졌는지 찾기 어렵습니다.

단계검증 대상통과 조건
가상 데모작업·입찰·schedule정상·취소 흐름 재현
단일 플릿좌표·경로·재접속위치 오차와 상태 지연 한도
문·엘리베이터요청·피드백·타임아웃거부와 수동 복구 확인
다중 플릿충돌·협상·우선순위혼잡 시험과 감사 로그

VDA 5050과 Open-RMF는 같은 계층의 대체품으로 보면 안 된다

VDA 5050 가이드는 플릿 마스터 컨트롤과 이동 로봇 사이의 메시지 구조를 중심으로 봅니다. Open-RMF는 작업 디스패치, 여러 플릿의 교통 일정과 건물 인프라 통합을 포함하므로 두 기술의 책임 범위가 완전히 같지 않습니다.

VDA 5050을 말하는 로봇 플릿을 Open-RMF 플릿 어댑터로 연결할 수는 있지만 버전, 상태 매핑과 오류 의미를 구현해야 합니다. 표준 이름이 같다고 곧바로 상호운용된다고 가정하지 말고 어댑터 경계에서 계약 시험을 수행합니다.

운영 전에는 보안과 수동 복구를 포함한 경계 점검표를 닫는다

로봇·플릿·건물망 사이의 인증, 명령 권한, 감사 로그와 네트워크 분리를 설계합니다. OPC UA 로보틱스 가이드처럼 설비 인터페이스를 연결하더라도 안전 PLC의 권한과 상위 작업 요청의 권한을 섞어서는 안 됩니다.

마지막으로 문·엘리베이터 무응답, 로봇 오프라인, 중앙 재시작과 시계 오차를 주입합니다. 운영자가 어떤 시스템에서 작업을 중단하고 예약을 해제하며 물리 현장을 확인할지 절차가 있어야 자동화가 멈췄을 때도 안전하게 복구할 수 있습니다.

로봇 명령 좌표 시간 문 엘리베이터 오류 소유권을 확인하는 Open-RMF 통합 점검표
성공 경로보다 좌표 불일치, 설비 무응답, 작업 중단과 재시작의 책임을 먼저 합의해야 통합이 운영 단계로 넘어갑니다. 출처: 피지컬 AI Lab.

Open-RMF 구조에서 자주 묻는 질문

Open-RMF가 로봇의 SLAM과 경로 계획도 대신하나요?

보통 로봇 또는 제조사 플릿이 로컬 위치추정과 경로 실행을 담당합니다. Open-RMF는 플릿 어댑터가 제공한 상태와 경로를 바탕으로 작업과 공유 교통·인프라를 조정합니다.

제조사 API가 있으면 플릿 어댑터를 바로 만들 수 있나요?

위치와 배터리 조회만으로는 부족합니다. 경로 지시, 취소·일시중지, 완료 판단, 재접속과 지도 좌표 변환까지 확인해야 합니다.

문과 엘리베이터는 반드시 같은 프로토콜을 써야 하나요?

아닙니다. 각 설비 어댑터가 현장 프로토콜을 RMF의 요청·상태 모델에 연결할 수 있습니다. 다만 타임아웃과 거부, 세션 소유의 의미를 일관되게 구현해야 합니다.

Open-RMF와 VDA 5050 중 하나만 선택해야 하나요?

책임 범위가 다르므로 함께 사용할 수 있습니다. VDA 5050 기반 플릿을 Open-RMF 어댑터 뒤에 연결하되 상태와 명령 의미를 검증해야 합니다.

통합에서 가장 먼저 시험할 실패는 무엇인가요?

좌표 불일치, 로봇 상태 지연, 명령 취소 실패, 문·엘리베이터 무응답과 중앙 재시작을 먼저 권합니다. 정상 데모만으로는 운영 책임 경계를 확인할 수 없습니다.

Open-RMF API와 구성은 배포판·패키지 버전에 따라 달라질 수 있습니다. 사용 중인 릴리스의 공식 문서와 제조사 인터페이스 계약을 기준으로 통합·안전 시험을 수행하십시오.