Xử lý trực tiếp hay dữ liệu đã ghi: VPN thực sự cần cho việc gì?
Hãy quyết định công việc robot nào phải đi qua mạng: kết quả kịp thời, telemetry quan sát hay một bộ dữ liệu đã ghi. Ba điều kiện, rồi đến các lệnh bag.
Một robot hết hữu ích khi cách xa một căn phòng sẽ có vấn đề về liên kết hoặc khối lượng công việc từ rất lâu trước khi có vấn đề về VPN. Mã hóa bảo vệ một đường đi, nhưng nó không mở rộng vùng phủ sóng vô tuyến và không làm một phép tính từ xa kết thúc sớm hơn. Quyết định trước mắt bạn là công việc nào thực sự phải đi qua mạng, và câu trả lời đó thường loại bỏ nhiều lưu lượng hơn người ta tưởng. Ba điều kiện quyết định điều đó, và thông lượng không phải là một trong số đó.
Ba cách bố trí, một câu hỏi về sự phụ thuộc
Bảng phân biệt các cách bố trí theo việc gì phụ thuộc vào liên kết, không theo phần mềm nào xuất hiện trong sơ đồ.
| Arrangement | What depends on the link | What stays onboard |
|---|---|---|
| Live remote processing | The exchange and any timely result the workstation returns | Only what the remote step does not block |
| Onboard processing, remote observation | The declared telemetry or display stream | The processing loop itself |
| Local recording, later analysis | Transfer of one selected dataset | The entire run, including raw sensors |
Không hàng nào trong bảng đó là một lập luận an toàn. Các chức năng điều khiển và an toàn vẫn cần một câu trả lời đủ tiêu chuẩn cho độ trễ, mất gói và kết nối bị ngắt, và không chỉ báo đường hầm nào cung cấp điều đó. Bảng cho biết sự phụ thuộc nằm ở đâu, và đó chính là phần mà một thiết kế mạng thực sự có thể thay đổi.
Điều kiện một: câu trả lời có phải kịp thời không?
Nếu một kết quả từ xa nuôi một bộ điều khiển, mạng nằm bên trong vòng điều khiển, và độ trễ, jitter và sự cố của nó trở thành thuộc tính điều khiển. Nếu cùng kết quả đó chỉ nuôi một màn hình, một bảng điều khiển hay một người đang xem, thì độ trễ y hệt chỉ là hình thức.
Công việc vòng kín qua một liên kết không dây là khả thi, và đó cũng là nơi phần lớn các báo cáo "VPN chậm" bắt nguồn, vì đường hầm là thành phần nhìn thấy được trong khi vô tuyến và định tuyến mới là nguyên nhân. Hãy đo thời gian khứ hồi của thông điệp thực tế chứ không phải ping của chính đường hầm, rồi hỏi xem con số đó có vừa ngân sách của vòng hay không. Nếu không vừa, hãy chuyển bước đó lên trên thiết bị thay vì đàm phán một mức dịch vụ chặt chẽ hơn cho một liên kết mà không ai trong phòng kiểm soát. Ghi lại con số đã đo cùng với các điều kiện đo, vì báo cáo tiếp theo sẽ đến mà không có chúng.
Điều kiện hai: bạn có thể khai báo tốc độ, hướng và gián đoạn nào?
Hãy ghi ra dữ liệu, tốc độ, hướng và khoảng gián đoạn dài nhất mà ứng dụng chịu được. Luồng camera hướng lên và kênh lệnh hướng xuống thất bại theo cách khác nhau, và một khoảng gián đoạn mà việc kiểm tra tĩnh chịu được sẽ kết thúc một nhiệm vụ đang di chuyển.
Hãy tách riêng kết nối vật lý và đường hầm khi so sánh các lựa chọn, vì một vô tuyến mạnh hơn và một khối lượng công việc nhỏ hơn là hai cách sửa khác nhau. Một lần truyền lớn cuối cùng hoàn tất không chứng minh gì về một kết quả nhạy cảm thời gian đến đều đặn, và một đường hầm khỏe mạnh không chứng minh gì về vô tuyến phía sau nó.
Sau đó hãy giảm nhu cầu thay vì bảo vệ nó. Giảm mẫu luồng quan sát, gửi bản tóm tắt hoặc delta, và để dữ liệu cảm biến thô ở trên thiết bị nơi lưu trữ rẻ còn truyền tải thì không. Một payload nhỏ hơn làm yếu lập luận cho một liên kết nhanh hơn và thường loại bỏ luôn nhu cầu về nó.
Điều kiện ba: ai phải thấy nó, và điều gì ở lại cục bộ
Quan sát thường là một yêu cầu nhỏ hơn nhiều so với xử lý. Nếu một người phải xem camera và sau đó phải có nhật ký, đó là telemetry cộng lưu trữ; nếu một mô hình phải chạy, trước tiên hãy hỏi liệu nó có thể chạy trên thiết bị và chỉ chuyển tiếp kết quả của nó hay không. Việc chuyển bước nặng lên thiết bị loại bỏ phụ thuộc đồng bộ và để lại một lần truyền có thể thử lại.
Việc có hai thành viên ROS trên cùng một robot không tự nó biện minh cho một đường hầm. Khả năng tiếp cận nút, ủy quyền ứng dụng và kế hoạch phục hồi cục bộ là những vấn đề riêng, và VPN chỉ trả lời điều đầu tiên, và chỉ cho lưu lượng được yêu cầu định tuyến.
Ghi một bộ dữ liệu là một thiết kế riêng, với các lệnh riêng
Với một ví dụ gắn với phiên bản, hướng dẫn ghi của ROS 2 Jazzy bao gồm việc ghi các chủ đề đã chọn, kiểm tra bag tạo ra và phát lại nó. Ghi các chủ đề quan sát đã được phê duyệt, đặt tên cho lần chạy, và giữ các định nghĩa thông điệp cùng cấu hình bên cạnh.
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42Đừng ghi mọi chủ đề chỉ vì công cụ làm việc đó dễ dàng. Lưu trữ đầy lên, dữ liệu camera và vị trí mang tính nhạy cảm, và một bag gồm các chủ đề không nhãn là vấn đề phân tích cho người mở nó tiếp theo. Bản phân phối được cài đặt cũng quyết định các lệnh: công cụ viết cho bag ROS 1 không chuyển sang bag ROS 2, vì vậy hãy khớp tài liệu với phiên bản cài trên robot.
Phát lại trong một môi trường phân tích hoặc mô phỏng tách biệt. Phát lại các chủ đề lệnh đã ghi vào cơ cấu chấp hành của một robot đang sống là một tai nạn, và cách phòng ngừa là một miền ROS riêng hoặc không có phần cứng nào trong vòng.
Hãy quyết định sự phụ thuộc thuộc về đâu và ghi lại: VPN bảo vệ một trao đổi buộc phải diễn ra, xử lý trên thiết bị loại bỏ một trao đổi không bao giờ cần đồng bộ, và một bộ dữ liệu đã ghi thay thế người tiêu dùng trực tiếp bằng một người tiêu dùng sau đó. Rồi hãy cố ý thử trường hợp mất kết nối, trong khi công việc cục bộ vẫn chạy, trước khi ai đó tuyên bố thiết kế đã xong.