转载原文地址：Bridging Simulation and Robotics: A ROS 2 Interface for VR-Forces and VR-Vantage – MAK Technologies
文章简介： 在本篇客座文章中，Synergy Integration Ltd.（MAK 尊敬的分销商）的 Omer Salomon 探讨了一款面向 VR-Forces 和 VR-Vantage 的 ROS 2 接口的开发过程。该接口使自主性研发团队能够利用逼真的 MAK ONE 合成环境来进行测试与训练。
在仿真领域，我们常常会遇到两类极少产生交集的项目。一类是大型演习：包含数百个实体、真实地形、行为逻辑，以及持续运行数小时的情景。另一类是单机/自机仿真器（Ownship Simulator）：针对单一车辆/载具进行深度建模，通过其传感器和动力学系统驱动真实的硬件在环系统。机器人团队往往生活在第二个世界中，且在这个世界里他们普遍使用 ROS 2。因此，当有客户询问 VR-Forces 和 VR-Vantage 是否能够驱动其机器人的自主栈（Autonomy Stack）时，最有趣的地方并不在于这些产品能否做到，而在于此前从没人为他们将这两个世界连接起来。
本文将介绍我们为此构建的一套插件（客户称之为 “面向 MAK ONE 的 ROS2 插件”），以及我们在开发过程中积累的经验教训。
项目的起点
客户是一家正在开发无人地面车（UGV）的自主性研发团队。他们面临的测试难题可能许多人都不陌生：野外实地测试不仅成本高昂、依赖天气条件，且难以重复；更棘手的是，最关键、最需要测试的边缘场景往往恰恰是无法安全模拟的。 他们希望仿真系统能提供两样东西：
- 用于导航的相机图像： 不是直接提供位置的真值（Truth Feed），而是渲染出的图帧（包含可见光与热红外波段），以便其感知代码能像处理真实相机信号一样对其进行处理。
- 包含真实地点和其他交通流的情景（Scenarios）： 其他车辆在他们实际运行区域的地形上穿梭，以便可以在指定地点建立运行测试，并通过修改变量进行重复测试。
VR-Forces 已经能很好地实现第二个需求；VR-Vantage 则擅长渲染第一个需求。唯一缺失的是连接到 ROS 2 的桥梁，以及在机器人视角下，将这两款产品无缝整合为“一台搭载了传感器的单一载具”的严谨架构。
(注：原图中展示了同一热红外图帧的对比——右侧由 VR-Vantage 结合 SensorFX 渲染，左侧为 ROS 2 订阅者接收到的图像)
各组件如何协同工作
面向 MAK ONE 的 ROS2 插件实际上由两个插件组成（每个产品各一个），各自在宿主进程内部运行一个 ROS 2 节点。VR-Forces 和 VR-Vantage 之间保持原有的通信方式（通过 DIS 协议）；而机器人端只能看到以该实体名称命名的命名空间下的 ROS 2 Topics（话题）。
(注：原图架构说明：VR-Forces 和 VR-Vantage 通过 DIS 交换实体状态；自主栈侧仅能看到 ROS 2 Topics)
在 VR-Forces 端： 挂载在实体上的组件会发布载具自身传感器原本会报告的数据：包括 IMU、指南针、GPS（形式为 NavSatFix 加 UTM 位置）、里程计，以及一个带有可配置随机游走漂移（Random-walk Drift）的独立车轮里程计话题——这样导航栈就无法通过盲目信任数据来“作弊”。在另一个方向上，它接收驾驶指令（针对差速/滑移转向载具的标准 Twist 指令，或针对转向载具的 AckermannDrive 指令），并将这些指令输入到 VR-Forces 自身的车辆动力学系统中。实体的行驶方式完全遵循仿真物理规律，而不是通过脚本强行传送。
在 VR-Vantage 端： 插件查找被成像的实体，并根据配置文件中定义的每个相机创建一个观察者（Observer）和渲染通道（Rendering Channel），随后发布每一帧数据：
- 彩色图像，或当相机切换为 MWIR/LWIR（中波/长波红外）SensorFX 设备时的热红外图像；
- 深度图像（始终提供）；
- 带有通道真实内参的
CameraInfo； - 从载具主体到每个相机光学坐标系的静态变换（Static Transforms）。
每个相机在运行时也可以通过 ROS 进行实时控制：包括俯仰/偏航（Pan/Tilt）、视场角（FOV）以及传感器波段。因此，测试人员可以在运行中途将相机从可见光切换为 LWIR，而无需触碰 VR-Vantage 的图形界面。
开发过程中的难点
我们原本以为热红外图像会是讨论的核心——毕竟每个客户都想要令人信服的热红外效果，而 SensorFX 也确实做到了。但在每次会议中，客户反复强调的却只有一个词：延迟（Latency）。
导航栈需要通过相机闭环控制循环。如果它所依据的图帧是过时的，车辆就会基于“物体过去所在的位置”来进行转向，那么针对真实相机调优的控制栈就会失效。渲染出高质量的图像是容易实现的承诺；但确保每一帧都能足够快地交付，才是我们必须克服的硬仗。
最初的版本采用了最直观的做法：在渲染线程上依次读取、压缩并发布每个相机的数据。虽然可行，但每增加一个相机，速度就会变慢一些。
最终解决该难题的突破口在于将“工作”与“渲染”解耦：
- 统一提取像素： 将从显卡获取像素的操作整合为所有相机共享的单一步骤，而不是每个相机单独处理。
- 后台异步处理： 压缩和发布工作转移到了后台，渲染器无需再等待这些步骤。
- 丢弃过期图帧： 相机仅保留最新的图帧并丢弃旧帧，这样即使订阅者处理跟不上，接收到的依然是最新图像而非堆积的历史帧。
- 按需按订阅采集： 对于没有节点监听的话题，完全不进行任何采集。
现在，帧率由显卡和场景复杂度决定，而非由插件瓶颈决定。优化这一流水线所花费的时间比开发任何功能都要多。
另一个教训则更为隐性但同样关键。
在仿真系统和机器人之间存在着多个坐标系，每一个都必须完全准确：
- VR-Forces 以地心坐标系（Geocentric Coordinates）报告位置；
- 机器人需要的则是局部东北天坐标系（Local East-North-Up World）；
- 载具主体被三种方式共同描述：DIS、VR-Vantage 的模型坐标系以及 ROS 坐标系；
- 每个相机以一定的偏移量安装在车体上，而图像本身拥有自己的光学坐标系（Z轴沿镜头方向延伸），这才是感知代码实际读取的坐标系。
整整七层坐标转换，每一层旋转都极易发生微小的偏差。 当其中某一层出错时，自主栈不会直接崩溃，而是会“产生轻微的驾驶偏差”——这比直接崩溃更糟糕。因此，一次性确保每一个坐标系都完全正确，并将其详细记录在接口控制文档（ICD）中，其重要性不亚于任何核心功能。
未来展望
我们的目标是彻底消除这两个世界之间的隔阂：机器人团队只需插上硬件，连接到 MAK ONE，就能以尽可能少的配置将机器人的世界替换为仿真世界。
这意味着我们需要提升插件的自动化程度，使实体、相机和话题能够直接从场景设定中自动提取，而无需手动配置。此外，我们正在为 MAVLink 构建类似的方案，以便飞行控制器能够像现在的 ROS 栈驱动 VR-Forces 地面车辆一样，直接驾驶 VR-Forces 中的飞行器。
