실시간 처리와 기록 데이터: VPN이 정말 필요한 경우는 언제인가?
어떤 로봇 작업이 네트워크를 넘어야 하는지 판단하세요. 시의적절한 결과, 관측 텔레메트리, 혹은 기록된 데이터셋입니다. 세 가지 조건과 bag 명령을 정리합니다.
한 방만 떨어져도 쓸모가 없어지는 로봇은 VPN 문제가 생기기 훨씬 전에 링크 문제나 작업량 문제를 겪는다. 암호화는 경로를 보호하지만 전파 도달 범위를 넓히지도 않고 원격 연산을 더 빨리 끝내지도 않는다. 판단해야 할 것은 어떤 작업이 실제로 네트워크를 넘어야 하는가이며, 그 답은 대개 사람들이 예상하는 것보다 많은 트래픽을 덜어낸다. 세 가지 조건이 이를 결정하며, 처리량은 그중 하나가 아니다.
세 가지 구성, 하나의 의존성 질문
표는 다이어그램에 어떤 소프트웨어가 보이는지가 아니라 링크에 무엇이 의존하는지로 구성을 나눈다.
| 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 |
이 표의 어느 행도 안전성 근거가 아니다. 제어와 안전 기능은 지연, 패킷 손실, 연결 끊김에 대해 여전히 검증된 답을 요구하며, 어떤 터널 표시기도 그것을 제공하지 않는다. 표는 의존성이 어디에 있는지 알려주며, 네트워크 설계가 실제로 바꿀 수 있는 부분이 바로 그것이다.
첫째 조건: 답이 시의적절해야 하는가?
원격 결과가 제어기에 입력되면 네트워크는 제어 루프 안에 있고, 그 지연과 지터, 단절이 제어 특성이 된다. 같은 결과가 화면이나 대시보드, 또는 지켜보는 사람에게만 간다면 동일한 지연은 겉모습일 뿐이다.
무선 링크에서 폐루프 작업은 가능하며, \"VPN이 느리다\"는 신고가 대부분 여기서 나오는 이유는 터널이 눈에 보이는 구성 요소인 반면 원인은 무선과 라우팅에 있기 때문이다. 터널 자체의 ping이 아니라 실제 메시지의 왕복 시간을 측정하고, 그 숫자가 루프의 예산에 맞는지 물어야 한다. 맞지 않으면 방 안의 누구도 제어하지 못하는 링크에 더 엄격한 서비스 수준을 협상하는 대신 단계를 온보드로 옮겨라. 측정한 숫자는 어떤 조건에서 측정했는지와 함께 기록하라, 다음 보고는 그 조건을 싣지 않고 도착하기 때문이다.
둘째 조건: 어떤 속도와 방향, 어느 정도의 중단을 선언할 수 있는가?
데이터, 속도, 방향, 그리고 애플리케이션이 견디는 최장 중단 시간을 적어 두라. 업스트림 카메라 스트림과 다운스트림 명령 채널은 서로 다른 방식으로 실패하며, 정지 검사가 견디는 중단이 이동 작업을 끝내기도 한다.
옵션을 비교할 때 물리적 연결과 터널을 분리해서 보라, 더 강한 무선과 더 작은 작업량은 서로 다른 수리이기 때문이다. 결국 완료되는 큰 전송은 시의적절한 결과가 꾸준히 도착한다는 것을 증명하지 못하며, 건강한 터널도 그 뒤의 무선을 증명하지 못한다.
그다음에는 수요를 옹호하는 대신 줄여라. 관측 스트림을 다운샘플링하고 요약이나 델타를 보내며, 저장은 싸고 전송은 비싼 곳에서 원시 센서 데이터는 온보드에 남겨 두라. 더 작은 페이로드는 더 빠른 링크의 명분을 약하게 만들고, 필요 자체를 없애는 경우가 많다.
셋째 조건: 누가 봐야 하며 무엇이 로컬에 남는가
관측은 보통 처리보다 훨씬 작은 요구 사항이다. 사람이 카메라를 지켜봐야 하고 나중에 로그가 남아야 한다면 그것은 텔레메트리와 저장이고, 모델이 돌아야 한다면 먼저 그것이 온보드에서 돌면서 결과만 전달될 수 있는지 물어야 한다. 무거운 단계를 온보드로 옮기면 동기 의존성이 사라지고 재시도할 수 있는 전송만 남는다.
같은 로봇에 두 개의 ROS 참가자가 있다는 사실만으로 터널이 정당화되지는 않는다. 노드 도달성, 애플리케이션 권한, 로컬 복구 계획은 각각 다른 문제이며, VPN은 첫 번째에만 답하며 그것도 라우팅을 요청받은 트래픽에 대해서만 답한다.
데이터셋 기록은 그 자체의 설계이며 그 자체의 명령을 가진다
버전에 맞춘 예로, ROS 2 Jazzy 기록 튜토리얼 은 선택한 토픽을 기록하고, 생성된 bag을 점검하고, 다시 재생하는 과정을 다룬다. 승인된 관측 토픽을 기록하고, 실행에 이름을 붙이고, 메시지 정의와 설정을 그 옆에 함께 두라.
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42도구가 쉽다고 해서 모든 토픽을 기록하지는 마라. 저장 공간이 차고, 카메라와 위치 데이터는 민감도를 지니며, 라벨 없는 토픽으로 이루어진 bag은 다음에 그것을 여는 사람에게 분석 문제가 된다. 배포된 배포판이 명령도 결정한다, ROS 1 bag용으로 작성된 도구는 ROS 2 bag으로 옮겨지지 않으므로, 문서를 로봇에 설치된 버전에 맞추어야 한다.
격리된 분석 또는 시뮬레이션 환경에서 재생하라. 기록된 명령 토픽을 살아 있는 로봇의 액추에이터로 재생하는 것은 사고이며, 예방은 별도의 ROS 도메인이나 루프에 하드웨어가 전혀 없는 구성이다.
의존성이 어디에 속하는지 정하고 기록하라: VPN은 반드시 일어나야 하는 교환을 보호하고, 온보드 처리는 동기일 필요가 없던 교환을 없애며, 기록된 데이터셋은 실시간 소비자를 나중의 소비자로 대체한다. 그다음 설계가 끝났다고 말하기 전에 로컬 작업이 계속 돌아가는 상태에서 연결이 끊긴 경우를 일부러 시험하라.