ROS 2 qua VPN: khám phá không phải đường dữ liệu

Hai node ROS 2 ở hai đầu đối diện của một VPN có thể liệt kê các chủ đề của nhau mà vẫn không gửi được một thông điệp nào. Khám phá và dữ liệu người dùng là những trao đổi riêng biệt với những đường đi riêng biệt, và máy chủ khám phá không chuyển tiếp payload. Kiểm tra cái này và giả định cái kia là cách các nhóm cuối cùng thay thế middleware trong khi đường hầm đơn giản là chưa bao giờ mang dữ liệu. Quy trình dưới đây tách hai kết quả trước khi bất cứ điều gì được thay thế.

Máy chủ khám phá thực sự mang gì

Trong Fast DDS, một Discovery Server phân phối thông tin về các endpoint: ai xuất bản, ai đăng ký và mỗi bên mong đợi QoS nào. Khi các peer biết nhau, dữ liệu người dùng di chuyển trực tiếp giữa chúng thay vì qua máy chủ đó. Việc đến được máy chủ chỉ chứng minh rằng bên môi giới của các lời giới thiệu có phản hồi, không hơn gì nữa. Một VPN được định tuyến vẫn cần một đường hoạt động theo cả hai chiều giữa các địa chỉ mà các peer quảng bá.

Sự khác biệt đó cũng giải thích các lỗi một phần, khi các peer hiện có tiếp tục trao đổi dữ liệu trong khi khám phá mới ngừng hoạt động. Hãy coi chúng là hai cuộc điều tra.

Đọc RMW mà các node thực sự dùng

ROS 2 có thể tải các middleware khác nhau, và một biến được xuất trong shell của bạn không đến được các tiến trình được khởi động ở nơi khác. Hãy hỏi hệ thống đang chạy thay vì lịch sử terminal của bạn.

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

Một biến không được đặt thường có nghĩa là giá trị mặc định đã cài đặt, giá trị này có thể khác nhau giữa các máy trong cùng một thí nghiệm. Báo cáo cũng nêu tên bản phân phối và middleware đang được sử dụng, vì vậy hãy so sánh chúng ở cả hai phía của đường hầm trước khi giả định chúng khớp nhau. Daemon dòng lệnh của ROS lưu trạng thái trong bộ nhớ đệm, vì vậy hãy khởi động lại nó sau khi thay đổi môi trường thay vì để một daemon cũ trả lời cho cấu hình cũ. Ghi lại bản phân phối và RMW của cả hai máy chủ trong ghi chú thử nghiệm khi phiên đang mở.

Kiểm tra khám phá và dữ liệu như hai kết quả

Chọn một chủ đề vô hại và đo lời giới thiệu tách biệt khỏi việc phân phối. Lệnh info liệt kê các endpoint và QoS, trong khi echo chứng minh liệu một thông điệp có thực sự đi qua liên kết hay không.

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

Các endpoint xuất hiện trong đầu ra của info là một kết quả của khám phá. Một thông điệp đến được người đăng ký là kết quả của vận chuyển, và chỉ kết quả thứ hai mới thử nghiệm đường mà ứng dụng cần. Khi khám phá hoạt động và echo hết thời gian, hãy kiểm tra các địa chỉ được quảng bá và tuyến quay lại thay vì dịch vụ khám phá. Chạy cả hai lệnh từ mỗi máy chủ, vì một tuyến VPN không đối xứng thường chỉ lộ ra từ một phía.

Thay một phụ thuộc mỗi lần

Khi đường dữ liệu thất bại, hãy tránh thay đổi middleware, chế độ khám phá và kích thước thông điệp trong cùng một phiên, vì sau đó không kết quả nào có thể được quy cho nguyên nhân. RMW Zenoh là một lựa chọn thay thế hợp lý, nhưng bộ định tuyến của nó trở thành một phụ thuộc khác phải tiếp cận được qua đường hầm.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Dưới RMW đó, bộ định tuyến mang khám phá theo cách bố trí mặc định của Jazzy, và khám phá multicast bị tắt ở đó, vì vậy phụ thuộc này thuộc về ghi chú của bạn chứ không phải một giả định vay mượn từ middleware khác. Giữ khối lượng công việc cố định trong khi bạn thay đổi một cài đặt, sau đó lặp lại bài kiểm tra echo và ghi lại hướng, tốc độ thông điệp và điều kiện liên kết. Chạy so sánh hai lần để tách một cải thiện thực sự khỏi một lần kết nối lại may mắn. Nếu một thay đổi cải thiện khám phá trong khi phân phối giữ nguyên, bạn đã di chuyển dịch vụ giới thiệu, không phải đường dữ liệu.