实时处理还是录制数据：VPN 究竟需要什么？

一台隔一个房间就失去用处的机器人，问题出在链路或工作量上，而不是 VPN，而且往往早得多。加密保护一条通路，它不扩大无线电覆盖，也不会让远程计算更早完成。摆在你们面前的决定是：哪项工作确实必须跨网络，而这个答案通常砍掉的流量比人们预想的多。三个条件就能定下来，吞吐量不在其中。

三种安排，一个依赖性问题

这张表按「什么依赖链路」来区分安排，而不是按图里出现哪套软件。

表中没有一行能当作安全论证。控制与安全功能仍然需要对延迟、丢包和断线给出有依据的答复，而任何隧道指示灯都不提供这个答复。这张表说明依赖落在哪里，而网络设计真正能改动的正是这一部分。

条件一：结果必须及时吗？

如果远程结果要喂给控制器，网络就位于控制回路之内，它的延迟、抖动和中断都会变成控制特性。如果同一结果只喂给屏幕、仪表盘或观看的人，那么同样的延迟只是表面文章。

无线链路上的闭环工作是可行的，而大多数「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 保护一次必须发生的交换，机上处理消除一次本来不需要同步的交换，录制数据集则用一个更晚的消费者替换实时消费者。然后，在任何人宣布设计完成之前，趁本地作业还在运行时，故意测一遍断线的情形。