멀티머신 통신 시 필수 고려사항
네트워크 구성 확인
ROS2 멀티머신 환경을 구성할 때 가장 먼저 고려해야 할 요소는 네트워크의 물리적, 논리적 구성이다. 기본적으로는 서로 다른 물리적 장비(PC, 임베디드 보드 등)가 같은 서브넷(Subnet) 안에 있어야 하며, 통신할 IP 대역이 일관성 있게 설정되어야 한다.
IP 주소 및 서브넷 마스크: 멀티머신 환경에서 각 장비가 서로 다른 IP 주소를 사용하도록 하고, 서브넷 마스크가 서로 호환되는지 반드시 확인한다.
브로드캐스트/멀티캐스트 트래픽: ROS2는 DDS의 Discovery 메커니즘을 활용해 노드를 자동 검색한다. 이때 브로드캐스트나 멀티캐스트 패킷 사용이 불가능한 네트워크 구성(예: 방화벽, VLAN, VPN 설정 등)에서는 노드를 찾지 못하거나 Discovery가 지연될 수 있다.
게이트웨이 및 라우팅: 서로 다른 라우터나 게이트웨이를 거치는 경우, UDP 멀티캐스트 트래픽이 차단될 가능성이 높다. 따라서 이런 환경에서는 Discovery Server, Peer-to-Peer Manual Discovery, 혹은 RTPS Relaying 등의 대안을 모색한다.
ROS_DOMAIN_ID 설정
ROS2 멀티머신 통신에서 충돌을 막고 논리적으로 독립된 네트워크를 구성하기 위해 자주 사용하는 방법이 ROS_DOMAIN_ID 설정이다.
기본 원리:
ROS_DOMAIN_ID값이 같은 노드들끼리는 DDS Discovery를 통해 서로를 인식할 수 있고, 값이 다르면 서로를 인식하지 못한다.활용 사례: 하나의 물리적 네트워크에서 다수의 ROS2 시스템을 독립적으로 운영해야 할 때,
ROS_DOMAIN_ID를 다르게 부여한다.환경 변수 설정: 셸에서 다음과 같이 설정할 수 있다.
export ROS_DOMAIN_ID=10DDS QoS 정책
ROS2 통신은 DDS(데이터 분산 서비스) 프로토콜을 기반으로 한다. DDS QoS(Quality of Service)를 적절히 설정해야 원활한 멀티머신 통신이 이루어진다.
Reliability(신뢰성): Reliability QoS는 ‘Reliable’ 혹은 ‘Best Effort’로 구성할 수 있다. 중요한 제어 신호라면 ‘Reliable’을 사용하지만, 대역폭이 높은 카메라 이미지 스트림 같은 경우는 ‘Best Effort’가 오히려 지연을 낮출 수 있다.
Durability(내구성): Durability QoS는 메시지를 한쪽에서 늦게 구독을 시작해도 이전 데이터를 받을 수 있도록 해주지만, 네트워크 트래픽이 증가할 수 있다. 환경에 따라 적정 수준을 설정해야 한다.
Deadline: Deadline QoS는 특정 주기 내에 반드시 메시지를 전송해야 하는 경우 사용하는 정책이다. 로봇 시스템에서는 제어 주기 안에 데이터를 수신하지 못하면 안전 문제가 생길 수 있으므로, Deadline 설정이 중요한 경우가 많다.
Discovery 지연 및 트래픽 평가
DDS Discovery가 제대로 이루어지지 않거나 오래 걸린다면, 노드 간 통신 자체가 끊기거나 초기화가 불완전해질 수 있다. 네트워크 지연(latency)에 대한 기본적 분석을 할 때 노드 $i$와 노드 $j$ 사이의 네트워크 지연을 $d_{ij}$라 할 때, 이를 추산하는 단순 모델은 다음처럼 표현할 수 있다.
여기서 $\Delta_{ij}$는 물리 거리 혹은 링크 상태에 따른 기본 지연 요소, $\alpha$와 $\beta$는 네트워크 환경(라우팅, QoS 설정 등)에 따라 달라지는 상수다. 이 지연이 커지면 Discovery가 제때 이루어지지 않을 수도 있으므로, DDS 설정(HeartBeat, Lease Duration 등)을 적절히 조정해야 한다.
시간 동기화(Time Synchronization)
ROS2 멀티머신 환경에서 시간 동기화는 필수다. 노드 간의 메시지 타임스탬프가 일치하지 않으면, 센서 데이터나 제어 명령이 뒤죽박죽 정렬되어 의미 있는 로봇 제어를 어렵게 만든다.
NTP 사용: 가장 일반적인 방법은 NTP(Network Time Protocol) 서버를 두고 모든 머신이 동기화하도록 설정하는 것이다.
Chrony 등 대안 사용: 로컬 네트워크 환경에서 짧은 지연과 높은 정확도가 필요하다면 Chrony, PTP(Precision Time Protocol) 등을 고려할 수 있다.
ROS2 내장 Clock 사용 시 주의: ROS2 노드가 시스템 시간을 그대로 쓰는 경우가 많으므로, 시스템 시간이 불규칙하다면 토픽 메시지의 타임스탬프가 잘못 표기될 수 있다.
보안 및 방화벽 설정
멀티머신 환경에서 네트워크 보안을 유지하려면 방화벽이나 VPN을 사용하는 경우가 많다. 하지만 ROS2의 Discovery 메커니즘이 이러한 설정에 막히는 경우 통신이 끊길 수 있다.
UDP 포트 열기: 기본적으로 ROS2 DDS 통신은 UDP를 사용하므로, 필요한 포트를 방화벽에서 허용해야 한다. 각 DDS 구현마다(예: Fast DDS, Cyclone DDS, RTI Connext) 포트 범위가 다를 수 있으니 문서를 확인한다.
VPN 구간: VPN 구간에서는 멀티캐스트 트래픽이 차단되기도 한다. 이때 Discovery Server 또는 수동 Discovery 설정을 사용하는 편이 안전하다.
Security Plugin: RTI Connext나 Fast DDS 보안 플러그인을 사용하면 DDS 통신을 암호화하거나 인증할 수 있다. 시스템 요구사항에 맞게 구성한다.
Discovery Server, Peer-to-Peer 설정
멀티머신 네트워크가 복잡해지거나, 브로드캐스트/멀티캐스트가 차단된 환경이라면 Discovery Server 같은 외부 서비스를 통해 노드 정보를 공유할 수 있다.
Discovery Server: 중앙 집중형 서버를 통해 노드 정보를 교환하므로, 동적 IP나 제한된 네트워크에서도 Discovery가 가능하다.
Peer-to-Peer Manual Discovery: 노드들이 서로의 IP를 직접 알고 있는 경우,
ROS_MASTER_URI를 세팅하던 ROS1 방식과 유사하게 각 노드의 주소를 수동으로 등록해 바로 연결할 수 있다.RTPS Relay: RTPS(Packet) 레벨에서 중계(리레이)해주는 소프트웨어 솔루션도 존재한다. 네트워크 트래픽을 중앙에서 제어하거나, 방화벽을 우회하고자 할 때 사용하는 방법이다.
자원 사용량 고려
멀티머신 환경에서 카메라, LiDAR 등 대용량 데이터를 송수신하면 CPU나 메모리, 네트워크 대역폭을 많이 소모한다.
CPU 부하 측정: 주기적으로 ‘top’, ‘htop’, 혹은 ROS2 내장 통계 도구 등을 통해 각 노드 CPU 사용량을 확인한다.
메모리 사용량 관리: 실시간으로 이미지, 포인트 클라우드 같은 대규모 데이터를 송수신하면 메시지 버퍼가 커질 수 있으므로, QoS 설정에서 히스토리(History)나 큐 사이즈를 조절한다.
네트워크 대역폭: 여러 로봇이 동시에 대규모 데이터를 퍼블리시할 때는 스위치나 라우터의 대역폭이 포화되지 않는지 확인해야 한다. 필요하다면 VLAN 분리나 네트워크 증설을 검토한다.
RMW 구현체 선택
ROS2 멀티머신 환경에서는 동일한 RMW(Robot Middleware) 구현체를 사용하는 것이 유리하다. RMW가 다르면 DDS Discovery와 QoS 적용이 완전히 호환되지 않을 수 있다.
예시: Fast DDS, Cyclone DDS, RTI Connext 등.
성능 차이: 메시지 전송 지연, 브로드캐스트 범위, 보안 플러그인 지원 여부 등이 구현체마다 다르므로, 멀티머신 통신 특성에 적합한 구현체를 선택하는 것이 중요하다.
호환성 문제: 서로 다른 RMW를 사용하는 노드 간에도 통신이 가능한 경우가 있지만, QoS 정책이나 보안 설정에 따라 제약이 생길 수 있다.
ROS2 Launch 파일 구성
멀티머신 환경에서 여러 노드를 동시에 실행하려면 Launch 파일을 신중히 구성해야 한다.
멀티 노드 실행: 로컬 머신에서 여러 노드를 실행하는 것 외에도, 원격 머신의 노드를 SSH 명령어로 제어할 수 있다. Launch 파일에서 별도의 로직을 넣어 분산 실행을 지원하도록 스크립팅할 수 있다.
환경 변수 전달: Launch 파일 내에서
ROS_DOMAIN_ID나 DDS 관련 설정을 적용하려면, ‘environments’ 섹션에 환경 변수 설정을 추가하거나, 별도 스크립트를 호출하여 실행한다.
모니터링 및 디버깅
네트워크 지연이나 DDS Discovery 실패 같은 문제가 자주 발생할 수 있으므로, 모니터링과 디버깅 툴을 익숙하게 다루어야 한다.
ROS2 CLI:
등을 활용해 해당 노드 혹은 토픽이 정상적으로 보이는지 확인한다.
DDS 레벨 로깅: DDS 구현체마다 제공하는 로깅 옵션을 활성화하면 Discovery, QoS 협상 과정에서 발생하는 메시지를 확인할 수 있다.
Wireshark 분석: 마지막으로는 Wireshark 등의 패킷 스니퍼 도구를 통해 멀티캐스트 패킷이 실제 네트워크를 타고 다니는지, 특정 포트가 막히는지 직접 확인할 수 있다.
Docker/가상환경에서의 멀티머신 통신
Docker 컨테이너나 가상머신으로 ROS2 노드를 실행할 때 네트워크 설정이 달라질 수 있다.
Bridge 네트워크: Docker 컨테이너 기본 설정이 NAT 기반이므로, 멀티캐스트 패킷이 제대로 전달되지 않는 경우가 있다. ‘host’ 네트워크 모드를 사용하거나, 별도 브리지 네트워크를 구성해 다리를 만들어야 한다.
가상머신(VM): VM 환경에서는 호스트와 VM 간 브리지 설정이 필요하다. 가상 네트워크 어댑터가 멀티캐스트를 지원하는지, 방화벽 설정이 있는지 확인한다.
실시간성(Real-Time) 고려
물리 로봇 시스템에서 분산 제어를 하는 경우에는 실시간 처리 요구사항이 중요하다.
RT 커널 사용: 리눅스 RT(Real-Time) 커널을 사용하면 스케줄링 지연을 낮출 수 있다.
RTDDS, Micro-ROS: 초저지연을 위한 실시간 DDS 구현체 혹은 Micro-ROS로 임베디드 장치와 통신할 때, 실시간성 보장을 위한 추가 설정이 필요하다.
QoS 설정 재점검: Reliability, Deadline, Liveliness QoS가 엄격하게 요구될 경우, 네트워크 지연이 매우 작은 환경(예: 단일 스위치)으로 제한하거나, 별도의 시간 동기화 및 로우 레벨 최적화가 필요하다.
Last updated