물류센터나 병원에 로봇이 한두 대일 때는 제조사가 준 관리 화면으로 충분합니다. 제조사가 다른 로봇이 같은 통로와 엘리베이터를 나눠 쓰기 시작하면, 누가 어떤 작업을 맡고 누가 먼저 지나갈지 정하는 “관제 계층"이 필요해집니다. 이 글은 그 계층을 만드는 대표적인 두 방식인 VDA 5050과 Open-RMF를 공식 문서로 정리하고, 로봇 수에 따른 관제 부하를 계산합니다.
멀티 로봇 관제가 하는 세 가지 일
| 일 | 무엇을 정하나 | 놓치면 생기는 문제 |
|---|---|---|
| 작업 배정 | 어떤 작업을 어느 로봇에게 줄지 | 가까운 로봇을 두고 먼 로봇이 이동, 충전 시점 겹침 |
| 교통 관리 | 같은 통로·교차로를 누가 먼저 지날지 | 마주 오는 로봇끼리 교착, 우회 경로 폭증 |
| 공용 설비 연동 | 문, 엘리베이터, 충전기 사용 순서 | 엘리베이터 앞 대기열, 충전기 선점 충돌 |
로봇 한 회사 제품만 쓰면 이 세 가지를 그 회사 플릿 관리 소프트웨어가 모두 맡습니다. 문제는 제조사가 섞일 때입니다. MiR의 설명도 여러 브랜드가 섞인 플릿은 복잡한 교통 상황을 만들 수 있고, 공통 관제원이 이를 단순하게 만든다고 적습니다.
현장에서 모델을 계속 개선하는 데이터 순환은 로봇 플릿 MLOps에서 다뤘습니다. 이 글은 그보다 아래, 지금 움직이는 로봇들을 실시간으로 조율하는 계층을 다룹니다.
VDA 5050: 로봇과 관제 사이의 공통 언어
VDA 5050은 독일자동차산업협회(VDA)가 정한 이동 로봇과 플릿 관제 사이의 통신 규격입니다. GitHub 저장소 기준 최신 공개 버전은 3.0.0입니다. 전송은 MQTT를 쓰고 최소 버전은 MQTT 3.1.1이며, 메시지는 JSON입니다.
| 토픽 | 방향 | 내용 |
|---|---|---|
order | 관제 → 로봇 | 지나갈 노드와 엣지 목록 |
instantActions | 관제 → 로봇 | 일시 정지 같은 즉시 실행 액션 |
state | 로봇 → 관제 | 위치, 작업 진행, 배터리, 오류 |
visualization | 로봇 → 시각화 시스템 | 위치와 계획 경로를 높은 주기로 전송(선택) |
connection | 브로커·로봇 → 관제 | 연결 상태 |
factsheet | 로봇 → 관제 | 로봇의 능력과 사양 |
주문(order)은 노드 목록과 엣지 목록 두 개로 전달되고, 엣지 수는 노드 수보다 하나 적어야 합니다. 이미 주행을 허락한 구간을 base, 아직 허락하지 않은 앞쪽 구간을 horizon이라고 부릅니다. 관제는 horizon을 미리 보여 주되 base만 조금씩 늘려 주는 방식으로 교차로 진입 순서를 조절할 수 있습니다. 구조를 줄여 쓰면 다음과 같습니다.
{
"orderId": "pick-0412",
"orderUpdateId": 0,
"nodes": [
{"nodeId": "dock-A", "sequenceId": 0, "released": true},
{"nodeId": "aisle-3", "sequenceId": 2, "released": true},
{"nodeId": "shelf-17", "sequenceId": 4, "released": false}
],
"edges": [
{"edgeId": "dock-A_aisle-3", "sequenceId": 1, "released": true},
{"edgeId": "aisle-3_shelf-17", "sequenceId": 3, "released": false}
]
}
위 예시는 구조를 보여 주기 위해 필드를 줄인 것입니다. 실제 필수 필드와 스키마는 저장소의 json_schemas 폴더를 따릅니다. 로봇의 state 메시지는 사양상 의미 있는 이벤트가 생길 때 또는 최소 30초마다 보내야 합니다.
Open-RMF: 여러 플릿 위에 얹는 조율 계층
Open-RMF는 여러 플릿을 함께 관리하기 위한 오픈소스 플랫폼입니다. ROS 2 위에 만들어졌고 Humble, Jazzy, Kilted, Rolling 배포판을 지원하며, 라이선스는 Apache-2.0입니다. 상용 로봇, 건물 설비, 작업 셀이 이미 여러 종 연동됐고, 새 플릿은 fleet_adapter_template에서 어댑터를 만들어 붙입니다.
VDA 5050이 “로봇 한 대와 관제가 주고받는 말"을 정한다면, Open-RMF는 그 위에서 서로 다른 플릿의 경로와 공용 설비 사용을 조율하는 쪽에 가깝습니다. ROS 2 멀티 로봇 가이드는 플릿 어댑터의 통합 수준을 다음처럼 나눕니다.
- Full Control: RMF가 로봇이 따라갈 경로를 직접 지정하고, 필요하면 중간에 바꾼다. 위치도 실시간으로 갱신된다.
- Traffic Light Control: RMF는 로봇을 일시 정지하거나 다시 출발시킬 수만 있고, 경로는 제조사 시스템이 정한다.
통합 수준이 낮을수록 교통 관리의 정밀도도 떨어집니다. 정지·재개만 가능한 로봇이 많으면 RMF는 충돌을 피하려고 더 자주, 더 일찍 멈춰 세워야 합니다.
| 비교 | VDA 5050 | Open-RMF |
|---|---|---|
| 성격 | 통신 규격(인터페이스 정의) | 소프트웨어 플랫폼(구현) |
| 범위 | 로봇 한 대와 플릿 관제 사이 | 여러 플릿과 건물 설비 사이 |
| 기반 | MQTT, JSON | ROS 2 |
| 공용 설비 | 규격 범위 밖 | 문·엘리베이터 연동을 다룸 |
| 도입 방식 | 로봇과 관제 양쪽이 규격 지원 | 플릿별 어댑터 작성 또는 제공받음 |
둘은 경쟁 관계라기보다 층이 다릅니다. VDA 5050을 지원하는 로봇과 관제 시스템을 쓰면서, 건물 설비 연동이나 다른 계열 로봇과의 조율은 별도 계층에서 맡기는 구성이 가능합니다.
로봇 수에 따른 관제 메시지 부하 계산
관제 서버와 MQTT 브로커가 감당할 부하는 로봇 수, 메시지 주기, 메시지 크기로 어림합니다. 규격의 최소 주기만으로 계산하면 실제보다 훨씬 작게 나오므로, 실제 운용 주기를 가정해 함께 계산합니다.
robots = 50
# 1) 규격 최소치: state를 최소 30초마다 (VDA 5050 v3.0.0)
min_msgs_per_s = robots / 30
print(round(min_msgs_per_s, 2)) # 1.67 msg/s
# 2) 운용 가정: state 1Hz(2KB), visualization 10Hz(0.5KB) — 가정값
state_hz, state_kb = 1, 2.0
vis_hz, vis_kb = 10, 0.5
msgs_per_s = robots * (state_hz + vis_hz)
mbit_per_s = robots * (state_hz * state_kb + vis_hz * vis_kb) * 1024 * 8 / 1e6
print(msgs_per_s, round(mbit_per_s, 2)) # 550 msg/s, 2.87 Mbit/s
같은 50대라도 규격 최소치(초당 약 1.7건)와 운용 가정(초당 550건)은 300배 넘게 차이 납니다. 메시지 크기와 주기는 로봇 제조사와 관제 소프트웨어 설정에 따라 다르므로, 위 가정값 대신 시험 운용에서 브로커가 받은 실제 메시지 수와 크기를 넣어 다시 계산해야 합니다.
도입 전에 로봇 제조사와 관제 업체에 확인할 다섯 가지
- 지원하는 VDA 5050 버전과 액션 목록: 버전이 다르면 필드와 동작이 다르다.
- 통합 수준: 경로까지 지정할 수 있는지(Full Control), 정지·재개만 되는지(Traffic Light).
- 공용 설비 연동: 문, 엘리베이터, 충전기를 관제가 제어할 수 있는지.
- 메시지 주기와 크기:
state와visualization을 몇 Hz로 보내는지, 한 건이 몇 KB인지. - 관제가 끊겼을 때의 동작: 로봇이 즉시 멈추는지, 현재 작업을 마치는지.
이렇게 정리한 대수와 운용 조건은 물류·제조 로봇 TCO·ROI 계산 모델의 입력값으로 이어집니다. 휴머노이드가 실제 현장에 들어가는 순서는 휴머노이드 현장 배치 사례에서 볼 수 있습니다.