VPN을 통한 ROS 2: 검색은 데이터 경로가 아닙니다

VPN의 양끝에 있는 두 ROS 2 노드는 서로의 토픽을 나열할 수 있지만 메시지를 하나도 전달하지 못할 수 있습니다. 검색과 사용자 데이터는 별도의 경로를 가진 별도의 교환이며, 검색 서버는 페이로드를 중계하지 않습니다. 하나를 확인하고 다른 하나를 가정하는 것이 터널이 데이터를 전혀 전달하지 않았는데도 미들웨어를 교체하게 되는 이유입니다. 아래 절차는 무엇이든 교체하기 전에 두 결과를 분리합니다.

검색 서버가 실제로 나르는 것

Fast DDS에서 Discovery Server는 엔드포인트에 대한 정보를 배포합니다: 누가 게시하고, 누가 구독하며, 각자가 어떤 QoS를 기대하는지입니다. 피어가 서로를 알게 되면 사용자 데이터는 그 서버를 거치지 않고 직접 이동합니다. 서버에 도달한다는 것은 소개 브로커가 응답한다는 것만 증명합니다. 라우팅된 VPN은 여전히 피어가 광고하는 주소 사이에 양방향으로 작동하는 경로가 필요합니다.

이 구분은 기존 피어는 데이터 교환을 계속하지만 새 검색이 작동을 멈추는 부분 실패도 설명합니다. 이를 두 개의 별도 조사로 다루세요.

노드가 실제로 사용하는 RMW 읽기

ROS 2는 다양한 미들웨어를 로드할 수 있으며, 셸에서 내보낸 변수는 다른 곳에서 시작된 프로세스에 도달하지 않습니다. 터미널 기록 대신 실행 중인 시스템에 물어보세요.

printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20

변수가 설정되지 않았다는 것은 보통 설치된 기본값을 의미하며, 같은 실험의 머신마다 다를 수 있습니다. 보고서는 사용 중인 배포판과 미들웨어도 알려주므로, 일치한다고 가정하기 전에 터널 양쪽에서 비교하세요. ROS 명령줄 데몬은 상태를 캐시하므로 환경을 변경한 후 다시 시작하고, 오래된 데몬이 이전 구성에 응답하게 두지 마세요. 세션이 열려 있는 동안 두 호스트의 배포판과 RMW를 테스트 노트에 기록하세요.

검색과 데이터를 두 결과로 시험하기

무해한 토픽을 선택하고 소개를 전달과 별도로 측정하세요. info 명령은 엔드포인트와 QoS를 나열하고, echo는 메시지 하나가 실제로 링크를 건너는지 증명합니다.

ros2 topic info /chatter --verbose
ros2 topic echo /chatter --once

info 출력에 엔드포인트가 나타나는 것은 검색 결과입니다. 메시지가 구독자에게 도착하는 것은 전송 결과이며, 두 번째만이 애플리케이션에 필요한 경로를 시험합니다. 검색이 작동하고 echo가 시간 초과되면 검색 서비스 대신 광고된 주소와 반환 경로를 조사하세요. 각 호스트에서 두 명령을 모두 실행하세요, 비대칭 VPN 경로는 종종 한쪽에서만 드러나기 때문입니다.

한 번에 하나의 종속성만 바꾸기

데이터 경로가 실패하면 나중에 어떤 결과도 귀속시킬 수 없으므로 같은 세션에서 미들웨어, 검색 모드, 메시지 크기를 변경하지 마세요. Zenoh RMW는 합법적인 대안이지만, 그 라우터는 터널을 통해 도달할 수 있어야 하는 또 다른 종속성이 됩니다.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

그 RMW에서는 라우터가 Jazzy 기본 구성에서 검색을 운반하며, 거기서 멀티캐스트 검색은 비활성화되어 있으므로, 이 종속성은 다른 미들웨어에서 빌려온 가정이 아니라 메모에 속합니다. 하나의 설정을 변경하는 동안 워크로드를 고정하고, 그다음 echo 테스트를 반복하고 방향, 메시지 속도, 링크 조건을 기록하세요. 실제 개선과 운 좋은 재연결을 구분하려면 비교를 두 번 실행하세요. 변경이 검색을 개선해도 전달이 그대로라면, 이동한 것은 소개 서비스이지 데이터 경로가 아닙니다.