DDS vs RMW: 로봇 통신 가이드

1. 먼저 결론: DDS와 RMW는 무엇이 다른가

DDS(Data Distribution Service)는 분산 System에서 Data를 발행·구독하고 발견하며 QoS 계약을 적용하기 위한 OMG 표준입니다. DDS 구현체는 Participant와 Endpoint Discovery, Serialization, 전송, 재전송, History와 Deadline 같은 정책을 실제로 처리합니다.

RMW(ROS Middleware Interface)는 ROS 2 Client Library와 실제 Middleware 사이의 추상화 API입니다. rclcpp와 rclpy는 특정 DDS 제품의 API를 직접 호출하지 않고 rcl과 rmw를 거칩니다. 그래서 같은 ROS 2 Code를 유지한 채 지원되는 RMW 구현을 선택할 수 있습니다.

핵심은 다음 한 문장입니다.

DDS는 통신 표준과 구현의 영역이고, RMW는 ROS 2가 Middleware를 사용하는 교체 가능한 경계입니다.

RMW 구현 중 상당수는 DDS를 사용하지만 RMW 자체가 DDS는 아닙니다. DDS가 아닌 통신 기술을 연결하는 RMW도 존재할 수 있습니다. 따라서 ROS 2 = DDS 또는 RMW = DDS라고 외우기보다 계층의 책임을 구분해야 합니다.

2. Publish 한 번이 Packet이 되기까지

Publisher Code의 한 줄 아래에서는 여러 계층이 연속으로 일합니다.

publisher.publish(message)

일반적인 흐름은 다음과 같습니다.

이 흐름을 알면 “Topic이 느리다”라는 막연한 증상을 다음처럼 나눌 수 있습니다.

• Application: Callback이 오래 걸리거나 Message 작성이 느리다.
• Executor: Callback이 Scheduling되지 못한다.
• RMW: Queue, Wait Set 또는 구현 설정이 기대와 다르다.
• Middleware: QoS Matching, Fragmentation이나 재전송이 발생한다.
• OS·Network: CPU, Socket Buffer, MTU, Wi-Fi 손실 또는 Firewall 문제가 있다.

같은 Host의 두 Process도 무조건 Network Interface를 거치는 것은 아닙니다. 구현과 설정에 따라 Loopback, Shared Memory Transport 또는 다른 최적화 경로를 사용할 수 있습니다. 같은 Process의 Component는 Client Library의 Intra-process 경로를 사용할 수 있습니다. 이 세 경우를 모두 “Zero Copy”라고 부르면 오해가 생깁니다.

3. DDS의 Data 중심 모델

DDS는 상대 Process에 함수를 호출하는 관점보다 어떤 Type의 Data가 어떤 Topic 이름과 QoS로 존재하는가에 초점을 둡니다.

• DomainParticipant: 한 DDS Domain에 참여하는 통신 주체입니다.
• DataWriter: Data를 쓰는 Endpoint이며 ROS Topic Publisher와 대응됩니다.
• DataReader: Data를 읽는 Endpoint이며 ROS Subscription과 대응됩니다.
• Topic·Type: 이름과 Data 구조를 정의합니다.
• QoS: History, Reliability, Durability, Deadline 등 통신 계약을 정의합니다.

ROS Node 하나와 DDS Participant 하나가 항상 1:1이라고 단정하면 안 됩니다. 매핑은 RMW 구현과 구성에 따라 달라질 수 있습니다. 진단할 때는 ROS Graph의 Node 수와 Network에서 관찰한 Participant 수가 다를 수 있음을 기억해야 합니다.

Service와 Action도 아래에서는 여러 Topic과 Endpoint를 이용해 구현됩니다. 사용자는 Request·Response와 Goal·Feedback·Result API를 보지만 Middleware는 Type이 있는 Data 흐름으로 처리합니다.

4. Discovery: 보이기 전에 먼저 서로를 찾는다

ROS 2 Node가 통신하려면 먼저 상대를 발견해야 합니다. DDS/RTPS 계열에서는 개념적으로 다음 두 범주를 구분합니다.

1. Participant Discovery: 같은 범위에서 통신 참가자의 존재와 Locator를 찾습니다.
2. Endpoint Discovery: Writer·Reader의 Topic, Type과 QoS 정보를 교환합니다.
3. Matching: 이름·Type·QoS가 호환되는 Endpoint끼리 연결합니다.
4. User Data: Matching이 끝난 뒤 실제 Sensor·Command Data가 흐릅니다.

Discovery 실패와 Data 실패를 구분하는 것이 중요합니다.

5. Domain ID와 Discovery 범위

ROS_DOMAIN_ID는 서로 발견하고 통신할 ROS 2 System의 논리적 범위를 나누는 기본 수단입니다. 값이 다르면 같은 Network에 있어도 일반적으로 서로 발견하지 않습니다.

# 현재 Shell 확인
printenv ROS_DOMAIN_ID

# Robot A
export ROS_DOMAIN_ID=10
ros2 run demo_nodes_cpp talker

# Robot A를 관찰하는 Terminal도 같은 값
export ROS_DOMAIN_ID=10
ros2 topic echo /chatter --once

Domain ID만으로 보안이 생기는 것은 아닙니다. 같은 값을 아는 다른 참가자는 같은 Domain에 들어올 수 있습니다. Robot Team 분리에는 유용하지만 인증·암호화·권한 통제가 필요하면 DDS Security 또는 조직의 보안 구조를 함께 설계해야 합니다.

최근 ROS 2 배포판에서는 Discovery 범위를 Localhost, Subnet 또는 지정 Peer 중심으로 제한하는 기능이 제공될 수 있습니다. 정확한 환경변수와 지원 범위는 사용하는 배포판의 공식 문서를 확인해야 합니다. 배포판이 다른 Robot을 함께 운용한다면 “설정 이름이 있다”가 아니라 실제 상호 발견 Test로 검증합니다.

# 두 Host의 핵심 Context를 나란히 기록
printenv | grep -E '^(ROS_|RMW_|CYCLONEDDS|FAST)' | sort
ros2 doctor --report

# Network가 Multicast를 전달하는지 별도 확인
# Computer A
ros2 multicast receive

# Computer B
ros2 multicast send

ros2 multicast가 실패하면 Topic Code를 고치기 전에 AP Isolation, VLAN, Firewall, VPN, Network Interface와 Multicast 정책을 확인합니다.

6. RMW 구현 확인과 안전한 변경

현재 Process가 사용할 RMW는 Process 시작 전에 결정됩니다. 이미 실행 중인 Node의 RMW를 환경변수만 바꿔 교체할 수는 없습니다.

# 설치된 RMW Package 확인
ros2 pkg list | grep '^rmw_'

# 현재 Shell의 명시적 선택 확인
printenv RMW_IMPLEMENTATION

# ROS 환경 Report에서 Middleware 확인
ros2 doctor --report

# 예: 설치된 경우 Fast DDS 계열 선택
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
ros2 run demo_nodes_cpp talker

# 예: 설치된 경우 Cyclone DDS 계열 선택
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
ros2 run demo_nodes_cpp listener

RMW를 바꿀 때는 다음 원칙을 지킵니다.

1. 목표 배포판에서 지원되고 설치된 Package 이름을 확인합니다.
2. 실험에 참여하는 Node와 CLI의 Environment를 기록합니다.
3. 기존 Process를 모두 종료합니다.
4. CLI Daemon이 이전 Context를 들고 있다고 의심되면 ros2 daemon stop 후 다시 조회합니다.
5. 이름·Type·QoS·Data 크기·Rate를 동일하게 유지해 비교합니다.
6. 결과가 좋아졌다고 바로 원인을 확정하지 말고 Vendor 설정과 Network Capture를 추가 확인합니다.

서로 다른 DDS 구현은 표준 상호운용을 목표로 하지만 ROS 2에서 혼합 구성이 모든 조합과 Extension까지 자동 보장된다고 가정해서는 안 됩니다. 운영 Robot은 검증된 동일 구성을 기준으로 삼고, 혼합이 필요하면 Type·QoS·Discovery·Security·대형 Data를 포함한 상호운용 시험을 별도로 수행합니다.

7. RMW를 공정하게 비교하는 실험

“A가 B보다 빠르다”는 말은 Hardware, Message 크기, QoS, Network, RMW Version과 설정이 빠지면 의미가 없습니다. 한 번에 한 조건만 바꿉니다.

# Terminal 1: 고정된 RMW와 Domain에서 Publisher 실행
export ROS_DOMAIN_ID=35
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
ros2 run demo_nodes_cpp talker

# Terminal 2: 같은 Context에서 관측
export ROS_DOMAIN_ID=35
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
ros2 topic info /chatter --verbose
ros2 topic hz /chatter --window 100
ros2 topic bw /chatter --window 100

비교 표에는 최소한 다음을 남깁니다.

CLI hz와 bw는 관측 Subscriber가 실제로 받은 값을 보여 주며 System 전체의 절대 진실은 아닙니다. 정밀 Benchmark는 performance_test 같은 전용 도구와 OS·Network 계측을 사용하고, 실제 Robot Workload로 다시 검증합니다.

8. QoS는 DDS/RMW 통신 계약이다

Topic 이름과 Type이 같아도 QoS가 호환되지 않으면 연결되지 않을 수 있습니다.

ros2 topic info /scan --verbose
ros2 topic echo /scan --qos-reliability best_effort --once

대표 판단 기준:

• Sensor Stream: 손실보다 최신성이 중요하면 BEST_EFFORT와 작은 Depth를 우선 검토합니다.
• Map·설정 Snapshot: 늦게 들어온 Subscriber도 마지막 값을 받아야 하면 TRANSIENT_LOCAL을 검토합니다.
• Command: 오래된 Command가 Queue에 쌓이지 않도록 작은 Depth와 Application Watchdog를 사용합니다.
• Event·Mission 상태: 유실 비용과 재전송 지연을 비교해 RELIABLE 여부를 결정합니다.

QoS는 안전장치가 아닙니다. RELIABLE은 “Robot이 안전하게 멈춘다”를 보장하지 않습니다. Command Timestamp 검증, Deadman Timeout, Velocity Limit와 Hardware E-stop은 별도로 있어야 합니다.

9. Wi-Fi와 대형 Message: Fragmentation의 함정

Camera Image나 PointCloud2는 작은 MTU의 Network Packet 여러 개로 나뉩니다. 조각이 많아질수록 일부 손실이 Message 전체의 지연이나 폐기로 이어질 가능성이 커집니다. RELIABLE이면 재전송으로 지연과 혼잡이 증가할 수 있고, BEST_EFFORT이면 손실된 Sample을 포기합니다.

예를 들어 각 조각의 독립적인 성공 확률을 p, 조각 수를 n이라 단순화하면 Message 전체 성공 확률은 pⁿ입니다. 실제 Network는 손실이 독립적이지 않고 Middleware Fragment 복구도 있으므로 이 식은 예측값이 아니라 조각 수가 위험을 증폭한다는 직관으로만 사용합니다.

권장 순서:

1. Robot 위에서 처리하고 결과 Feature만 전송합니다.
2. Image를 압축하고 해상도·Frame Rate를 줄입니다.
3. Sensor Data와 Control Network를 분리합니다.
4. BEST_EFFORT·Depth 1 등 최신성 중심 QoS를 시험합니다.
5. MTU·Socket Buffer·Vendor Fragment 설정은 계측 후 변경합니다.

ros2 topic type /camera/image_raw
ros2 topic hz /camera/image_raw --window 100
ros2 topic bw /camera/image_raw --window 100

# 압축 Transport가 구성된 System의 예
ros2 topic list | grep -E 'image_raw|compressed'

“Jumbo Frame을 켜면 해결된다”는 식의 단일 처방은 위험합니다. 경로의 Switch, NIC, Container와 상대 Host가 모두 같은 MTU를 지원해야 하며, Wi-Fi에서는 기대대로 동작하지 않을 수 있습니다.

10. Multicast, Unicast와 Discovery Server

Multicast는 별도 Peer 목록 없이 같은 Network의 참가자를 찾기 편하지만, 일부 Wi-Fi와 기업 Network에서는 차단되거나 낮은 Rate로 처리됩니다. Unicast Peer 지정은 대상이 명확하지만 Robot이 늘 때 설정 관리가 필요합니다.

Discovery Server는 지원하는 Middleware에서 Discovery 정보를 Server 중심으로 조직해 참가자 간 Discovery 부하를 줄이는 방식입니다. 일반적으로 실제 User Data까지 반드시 Server를 경유한다는 뜻은 아닙니다. 정확한 Data 경로와 장애 시 동작은 Vendor Mode와 설정을 확인해야 합니다.

# Fast DDS Discovery Server CLI는 설치된 Version의 Help를 먼저 확인
fastdds discovery --help

# 현재 Version이 지원하는 Option으로 Server 실행 후
# 각 Node와 CLI Terminal에 같은 Server Locator를 설정한다.
printenv ROS_DISCOVERY_SERVER
ros2 daemon stop
ros2 node list

Vendor 명령을 문서에서 그대로 복사하기 전에 현재 설치된 실행 파일의 --help와 해당 Version 문서를 확인합니다. Server가 단일 장애 지점이 되지 않도록 이중화, 재접속과 Monitoring을 설계하고 실제 Robot Network 단절 시험을 수행합니다.

11. Vendor 설정 파일을 다루는 원칙

Cyclone DDS, Fast DDS 등은 XML 또는 환경변수로 Interface, Peer, Transport, Buffer와 Discovery를 세밀하게 설정할 수 있습니다. 그러나 Vendor 설정은 ROS 2 공통 API가 아니므로 이름과 Schema가 Version에 따라 달라질 수 있습니다.

# Cyclone DDS 계열에서 설정 위치를 지정하는 대표 형태
export CYCLONEDDS_URI=file://$PWD/cyclonedds.xml

# Fast DDS 계열 Profile 위치는 사용 Version의 공식 문서에서
# 지원 환경변수와 XML Schema를 확인한다.
printenv | grep -E 'FAST|FASTDDS|FASTRTPS'

설정 파일 운영 Checklist:

• Repository에서 Version 관리하되 비밀 Key는 분리합니다.
• 파일 Hash와 적용 Host를 Deployment Log에 남깁니다.
• Interface 이름을 고정했으면 Ethernet·Wi-Fi 전환 시 실패 조건을 시험합니다.
• 설정이 실제로 읽혔는지 Middleware Log와 Packet Capture로 확인합니다.
• 모든 Node가 같은 파일을 써야 한다고 무조건 가정하지 말고 역할별 Profile을 명시합니다.
• 변경 전후 발견 시간, Hz, 손실, CPU와 Memory를 비교합니다.

12. Container와 다중 Host에서 자주 생기는 문제

Container에서 localhost는 Host의 localhost와 다릅니다. Bridge Network, NAT와 Multicast 전달 정책 때문에 Host에서는 되던 Discovery가 Container에서 실패할 수 있습니다.

# Container 안과 Host에서 각각 확인
ip address
ip route
printenv ROS_DOMAIN_ID
printenv RMW_IMPLEMENTATION
ros2 doctor --report

Host Network Mode는 진단을 단순하게 만들 수 있지만 격리와 Port 충돌 Trade-off가 있습니다. 무조건 권장하기보다 보안 정책과 배포 환경에 맞춰 선택합니다. Kubernetes나 다중 VLAN에서는 일반적인 Broadcast Domain 가정이 깨지므로 명시적 Peer, Discovery Service 또는 Router를 설계해야 합니다.

Time Synchronization도 중요합니다. DDS Discovery가 되더라도 Sensor Fusion과 Delay 측정은 Host Clock 차이 때문에 잘못될 수 있습니다. NTP·PTP 상태와 /clock 사용 여부를 통신 진단 Context에 포함합니다.

13. Security: Domain 분리와 암호화는 다르다

DDS Security 계열 기능은 일반적으로 다음 목표를 다룹니다.

• Authentication: 참가자가 신뢰할 수 있는 Identity인지 확인
• Access Control: 어떤 Domain·Topic을 Publish·Subscribe할 수 있는지 제한
• Cryptography: Discovery 또는 Data의 기밀성과 무결성 보호
• Logging: 보안 관련 사건 기록

ROS 2의 보안 도구와 환경변수는 배포판 문서를 기준으로 설정합니다.

# 설치된 배포판에서 지원되는 보안 CLI 확인
ros2 security --help

# 활성화 여부와 Keystore 경로는 배포 환경에서 명시적으로 관리
printenv | grep '^ROS_SECURITY'

Security를 켜면 인증서 배포, 이름 Enclave, Permission과 Clock 문제가 Discovery 실패처럼 보일 수 있습니다. 보안을 꺼서 운영하는 것을 해결책으로 삼지 말고, 격리된 Test Network에서 Policy와 Log를 검증합니다. Key·Certificate·Password를 강의 Log나 Repository에 넣지 않습니다.

14. 실제 Robot 통신 설계 예시

실내 이동 Robot 한 대

• /scan: BEST_EFFORT, 작은 Depth, 최신 Sample 중심
• /map: 늦게 들어온 Subscriber가 필요하면 TRANSIENT_LOCAL 검토
• /cmd_vel: 작은 Queue, Timestamp·Deadman Timeout·Safety Filter
• Camera 원본: Robot 내부 유선 또는 Shared Memory, 외부에는 압축·추론 결과

Robot 열 대와 관제 PC

• Robot별 Namespace와 Domain·Discovery Architecture를 함께 설계
• 모든 Raw Sensor를 중앙으로 보내지 않고 Robot에서 전처리
• 관제에 필요한 State·Diagnostic·Event만 제한된 Rate로 전달
• Discovery Server나 Router 도입 전 Failure Mode와 이중화 시험
• Mission ID와 Robot ID를 Log·Message Context에 포함

공장 Network

• VLAN, Firewall, Multicast 정책을 Network Team과 문서화
• 승인된 RMW·Version·설정 Profile을 배포 단위로 고정
• Security Identity와 Topic Permission을 최소 권한으로 구성
• Packet Loss, Link 단절과 Middleware 재시작 후 안전 상태 확인

15. 장애 진단 Runbook

다음 순서는 읽기 전용 확인부터 시작합니다.

# 1. Context
date -Is
printenv | grep -E '^(ROS_|RMW_|CYCLONEDDS|FAST)' | sort
ros2 doctor --report

# 2. Graph
ros2 node list
ros2 topic list -t
ros2 topic info /scan --verbose

# 3. Data
ros2 topic echo /scan --no-arr --once
ros2 topic hz /scan --window 100
ros2 topic bw /scan --window 100

# 4. Network
ip address
ip route
ros2 multicast receive

# 5. Daemon은 원인 전체를 고치지 않는다
ros2 daemon status
ros2 daemon stop

실제 Robot에서 설정을 바꾸기 전에는 Motion Command를 차단하고 E-stop, Watchdog와 독립 안전 계층을 확인합니다. 통신이 복구되는 순간 밀린 Command가 실행되지 않도록 Command Age와 Queue 정책을 검증합니다.

16. 설정 선택 의사결정표

RMW 선택은 인기 투표가 아닙니다. 기본 구현으로 요구사항을 만족하면 유지하고, 문제가 측정되었을 때 재현 가능한 Benchmark로 대안을 비교합니다.

17. 확인 퀴즈 15문항

연습 문제

1. 자신의 ROS 2 환경에서 설치된 RMW Package와 현재 선택값을 기록하세요.
2. DDS와 RMW를 각각 한 문장으로 설명하고 서로 바꾸어 말하면 안 되는 이유를 쓰세요.
3. 두 Host의 Discovery Context를 비교하는 점검표를 작성하세요.
4. /scan의 Publisher·Subscriber QoS를 조사하고 호환 여부를 판정하세요.
5. 같은 Topic을 두 RMW 조건에서 측정하는 공정한 A/B Test 계획을 작성하세요.
6. Camera 원본 30 Hz를 Wi-Fi로 보내는 대신 사용할 Data 감소 방안을 세 가지 제안하세요.
7. 같은 Process, 같은 Host의 다른 Process, 다른 Host 통신 경로를 비교하세요.
8. Robot 열 대에서 Discovery 부하를 줄일 Architecture와 장애 대응을 설계하세요.
9. Container에서 Host Node를 발견하지 못할 때의 확인 순서를 작성하세요.
10. ROS_DOMAIN_ID와 DDS Security가 해결하는 문제가 어떻게 다른지 설명하세요.
11. Discovery Server 장애가 발생했을 때 새 참가자와 기존 Data 경로가 어떻게 될지 시험 계획을 세우세요.
12. Command Topic이 재접속 후 오래된 값을 실행하지 않도록 안전 요구사항을 작성하세요.
13. Vendor XML 변경을 배포·검증·Rollback하는 절차를 작성하세요.
14. hz, bw, CPU, Memory와 Packet Loss를 함께 기록하는 Benchmark 표를 만드세요.
15. 실제 Robot 통신 장애 Incident를 가정해 읽기 전용 진단부터 설정 변경까지 Runbook을 작성하세요.

참고 자료

• ROS 2: Different ROS 2 middleware vendors
• ROS 2: Working with multiple RMW implementations
• ROS 2: The ROS_DOMAIN_ID
• ROS 2: Quality of Service settings
• ROS 2: Improved Dynamic Discovery
• ROS 2 Security tutorials
• OMG Data Distribution Service
• eProsima Fast DDS Documentation
• Eclipse Cyclone DDS Documentation