서로를 찾는 것과 자료를 처리하는 것
ROS 2의 통신 계층은 사용자 코드와 같은 층이 아니다. 클라이언트 라이브러리 아래에서 RMW(ROS Middleware) 인터페이스가 미들웨어 구현과 연결된다. 여기서는 DDS 기반 RMW를 가정한다. DDS는 분산 데이터 교환과 발견 등의 기능을 제공하는 표준 계열이다. ROS 2라는 이름만으로 모든 구현의 내부 동작이나 네트워크 설정이 같다고 가정하지 않는다.
발견(discovery)은 다른 참여자와 통신 대상을 알아가는 과정이다. 일반적인 DDS 기반 구성에서는 같은 ROS 도메인에 속한 참여자들이 발견 정보를 교환한다. ROS_DOMAIN_ID가 다른 두 집단은 기본 직접 통신에서 분리된다. 별도 브리지나 중계가 구성된 예외는 이 기본 모델과 구분한다. 같은 도메인이라고 네트워크 도달성·보안 설정·타입·QoS까지 모두 충족하는 것은 아니다. 도메인 번호는 물리적인 다른 LAN을 만드는 장치도, 접근 제어를 완성하는 보안 경계도 아니다.
네임스페이스(namespace)는 이름의 범위를 나눈다. 노드의 네임스페이스가 /robot_a이고 상대 Topic 이름이 joint_states라면 완전한 이름은 /robot_a/joint_states다. /joint_states처럼 처음부터 /로 시작하는 절대 이름은 이 네임스페이스를 붙이지 않는다. remap은 지정한 이름을 다른 이름으로 바꾸는 규칙이며 최종 해석 이름으로 연결 여부를 비교해야 한다. 서로 다른 노드 이름 자체가 같은 Topic 통신을 막는 것은 아니다. 반대로 비슷한 노드 이름이나 폴더에 있어도 최종 Topic이 다르면 같은 흐름을 읽지 못한다. 메시지 안의 frame_id 같은 문자열에는 노드 네임스페이스가 자동 적용되지 않으므로 좌표계 분리와도 구별한다.
같은 QoS가 아니라 호환되는 QoS를 찾는다
QoS(Quality of Service)는 전달과 보관 등의 정책 묶음이다. 발행자는 제공(offered) 정책을, 구독자는 요구(requested) 정책을 갖는다. 통신 중에 두 값이 알아서 동일해지는 ‘협상’으로 생각하지 않는다. 호환은 각 발행자와 구독자 쌍에서 판정한다. 다른 구독자의 설정이 이 쌍의 요구를 대신 낮춰 주지도 않는다.
reliability의 best effort는 손실이 있을 수 있는 전달 방식이고 reliable은 재전송 등을 사용하는 신뢰 전달 방식이다. best effort 발행에 reliable을 요구하는 구독은 호환되지 않는다. reliable 발행에 best effort를 요구하는 구독은 이 정책에 대해서는 호환된다. durability의 volatile은 늦게 참여한 구독자를 위해 이전 자료를 보관하려 하지 않고, transient local은 살아 있는 발행자가 보관한 자료를 늦은 구독자에게 제공하는 데 쓰인다. volatile 발행과 transient local 요청은 호환되지 않는다. 둘 다 transient local인 경우에도 보관 깊이와 자원·수명 조건에 따라 제공 가능한 과거 자료가 제한된다. 디스크에 영구 저장하는 데이터베이스와 같은 뜻은 아니다.
다음 표에서는 다른 정책과 이름·타입·발견 조건이 모두 맞는다고 가정한다. 실제 판정에서는 호환에 영향을 주는 모든 정책을 확인한다.
| 발행 제공 | 구독 요구 | 이 표의 판정 |
|---|---|---|
| best effort / volatile | reliable / volatile | reliability 불일치 |
| reliable / volatile | best effort / volatile | 호환 |
| reliable / volatile | reliable / transient local | durability 불일치 |
| reliable / transient local | reliable / transient local | 호환, 보관 조건은 별도 |
history의 keep last와 depth N은 보관할 최근 표본 수를 정하는 정책이다. keep all도 자원 제한을 없애는 마법은 아니다. depth를 늘리면 오래된 자료가 남을 수 있지만 처리 속도가 느린 문제 자체가 사라지지는 않는다. reliable도 사용자 콜백의 기한 내 실행, 디스크 기록 성공, 물리적인 작업 성공을 자동으로 보장하지 않는다. 통신 정책과 응용 수준의 완료 조건을 구분한다.
깊이와 시간은 서로 다른 질문이다
가상 보관 모델에서 메시지가 0, 20, 40, 60 ms에 하나씩 도착하고 그동안 소비가 전혀 없다고 하자. keep last 깊이 3으로 마지막 세 개만 남긴다면 20, 40, 60 ms 자료가 남는다. 판단 시각이 같은 시계의 70 ms라면 가장 오래된 자료의 나이는 50 ms, 최신 자료의 나이는 10 ms다. 이는 수신 직후 자료를 넣는 단일 가상 보관함의 계산이며 모든 DDS 구현의 정확한 큐 배치나 콜백 순서를 재현한 것은 아니다.
깊이를 1로 줄이면 이 모델에는 60 ms 자료만 남지만, 증분 명령이나 모든 사건을 세어야 하는 기록에 중간 자료를 버려도 되는지는 별도 요구다. 절대 상태의 최신 관측과 순서 의존 명령을 같은 방식으로 다루지 않는다. deadline은 기대 발행/수신 간격과 관련된 정책 및 위반 사건을 제공하지만 늦은 시스템을 자동으로 빨라지게 하지는 않는다. lifespan은 만료 자료의 전달을 제한하는 정책이며 센서 획득 시각부터 응용이 계산한 나이와 자동으로 동일하지 않다. 자세한 시간 계약은 M05.06에서 이어간다.
미수신 진단은 한 가지 버튼을 누르는 일이 아니다. 양쪽 실행 환경과 도메인·네트워크에서 서로를 발견하는지, 최종 이름과 타입이 같은지, 양쪽 QoS가 호환되는지, 실제 발행과 콜백 처리가 진행되는지를 차례로 연결한다. 기존 1장의 센서 상태 예제를 읽을 때에도 echo 도구 자체가 하나의 구독자라는 점을 고려한다. 관측 도구의 QoS가 맞지 않으면 도구에 안 보이는 것과 생산자의 미발행을 혼동할 수 있다.