标题：From ROS to Unity: leveraging robot and virtual environment middleware for immersive teleoperation
0. 摘要
通常提出虚拟现实系统作为用于开发用于自治和半自治系统的远程操作接口的适当技术。 过去，此类系统通常被开发为“一次性”实验系统，部分原因是缺乏用于机器人软件开发和虚拟环境基础结构的通用软件系统。 最近，已经出现了用于机器人控制（例如，ROS）以及虚拟环境显示和交互（例如，Unity）的通用框架。 在这里，我们考虑开发集成了这两种环境的系统的任务。 基于Web套接字的基于yaml的通信协议用于将两个软件环境粘合在一起。 这允许使用标准软件工具包独立地控制每个系统，同时在这两个基础结构之间提供灵活的接口。
1. 介绍
长期以来，人们一直在开发基于虚拟环境的接口技术以控制和监视自主和半自主设备。基本概念可以追溯到远程智能的早期工作（请参见[1]）：通过为操作员提供感知环境，使其与远程设备位于同一地点，体验与他们所经历的体验一致则操作员的性能将得到改善。虚拟现实似乎是提供这些基本感知线索的合适技术。考虑到这种界面可能提供的潜力，已经开发了许多不同的实验和操作系统。例如，已经开发了用于太空操作（例如，[2]），越野车（例如，[3]和无人飞行器（例如，[4]）的系统，仅举几例。系统取得了成功，一方面限制了该概念的更广泛应用，另一方面是缺乏用于机器人控制和虚拟现实系统的通用且易于访问的软件基础结构。幸运的是，最近几年见证了针对机器人控制和虚拟现实基础设施的许多标准软件系统的开发和采用。 在这里，我们探索如何在针对自主机器人的基于虚拟现实的远程操作界面的开发中利用这些进步。
A. 自主机器人中间件
已经进行了许多尝试来开发标准的机器人中间件。 开发此类用于机器人控制的软件基础架构的早期工作包括Ayllu [5]，Player [6]和COLBERT / Saphira [7]。 尽管这些努力提高了我们对自主机器人中间件需求的理解，但由于多种原因，这些系统并未在学术界和工业界得到广泛采用。 不同的系统有不同的吸引力，但是系统通常针对特定的硬件平台/传感器平台，或者计算硬件/操作系统或语言支持有限。 在过去的十年中，ROS（机器人操作系统）[8]已经成为用于自治系统开发的标准软件中间件。在ROS中，整个机器人控制被建模为通过消息传递进行通信的异步过程（称为节点）的集合。 尽管ROS已被移植到许多不同的硬件平台上，并且存在针对多种不同语言的绑定，但是支持主要针对Ubuntu，其软件库针对C ++和Python。 对性能较低的设备（例如Android平台）的支持水平非常有限，但是此类设备上有限的内存占用量使开发和部署变得更加复杂。
ROS成为机器人软件的标准软件中间件的原因有很多。 首先，尽管该软件确实依赖可靠的TCP / IP通信，但它几乎没有对硬件或网络进行任何假设。 其次，独立通信代理的软件模型实现了极大的模块化，包括跨多个硬件站点（包括远程站点）的软件集成。 第三，支持大量的机器人和传感器。 最后，存在大量用于常见机器人任务的软件工具和库。
图1展示了一个基于ROS的机器人系统。 图1（a）显示了基于Mobile Robots开发的P3-AT平台的机器人。 机器人依靠打滑转向，并由安装在机器人内部的PC104计算机控制。 机器人根据少量的ROS节点公开传感器/运动系统。 安装在机器人顶部的一台标准笔记本电脑运行Ubuntu，并装有两台激光扫描仪，一个安装在水平面上，另一个安装在垂直面上，并与机器人内的ROS环境通信。 外部运营商可以通过wifi看到整个ROS基础架构。
图1（b）显示了在约克大学在室内操作的机器人所获得的环境图。 该地图依靠水平面激光和里程计信息来解决SLAM（同时定位和映射）问题，然后使用SLAM的解决方案将水平和垂直激光数据集成到环境的单点云表示中。
ROS提供了许多可视化工具-包括用于生成图1（b）的工具。 尽管这些工具功能强大，但它们并非旨在支持复杂的虚拟现实基础架构（例如HMD，头部跟踪器等）。
B. 虚拟现实中间件
正如机器人中间件在过去十年中已经成熟一样，支持虚拟现实安装的软件系统的开发也发生了类似的变化。 专用硬件以及缺乏复杂的跟踪器，渲染系统，物理引擎等的标准化，阻碍了开发基于VR的基础架构的早期工作。 早期的VR系统（例如VE [9]和FLow VR [10]）通常与特定的硬件系统和渲染库（例如SGI硬件，OpenGL）绑定在一起。 对跟踪器和其他输入设备的支持是有限的，并且需要大量的精力来支持不同的VR显示技术和渲染结构。
图2说明了开发有效的VR标准软件中间件所涉及的挑战。图2（a）显示了基于HMD的VR系统，该系统利用运动基座来提供与立体声视频流耦合的物理运动提示。尽管ROS的rviz之类的工具当然可以提供机器人环境的可视化模拟，但是rviz缺少必要的基础结构，无法轻松地集成头部跟踪器，运动基座等。图2（b）说明了另一种潜在的交互技术，即沉浸式视觉显示器。在IVY [9]中，显示器的每个外表面都是使用立体声视频流向后投影的。跟踪头部位置以便更新视觉显示以模拟不同的观察位置/方向。尽管IVY使用了各种不同的软件基础结构来提供一致的视觉显示，但是必须观察到每个外部视频信号必须在受控视点下生成并且这些信号必须被帧锁定，这一点至关重要。同样，诸如rviz之类的工具在设计时并没有考虑这些类型的约束。
现在存在许多不同的软件中间件/库，它们支持生成复杂的视觉场景，这些场景与到多个屏幕/投影仪，跟踪器，物理引擎，音频生成，用户界面设备和物理运动基座等的接口耦合。 其中许多系统将诸如Ogre [11]和Unity [12]之类的“游戏引擎”与外部库和其他工具集成在一起。 通常，此类游戏引擎提供某种脚本工具或其他机制，以使开发人员能够扩展游戏引擎本身可用的基本基础结构。 存在许多外部系统，例如MiddleVR [13]，其提供对专用VR硬件的支持，并且还提供了到用于内容管理的游戏引擎的适当链接。
尽管存在许多不同的游戏引擎/外部库系统，但Unity为沉浸式远程操作系统的开发提供了许多优势。 首先，它支持广泛的不同平台。 其次，它提供了许多不同的脚本选项。 最后，它提供了受支持的库，用于通过MiddleVR等系统访问外部VR硬件。
在Unity中，基本软件模块是GameObject。 GameObject提供对象的视觉外观的封装并与物理引擎挂钩，以及交互，动画等的逻辑。 与许多游戏引擎一样，Unity以帧驱动的方式运行，在这种情况下，视觉刷新视觉显示的需求至关重要，并驱动了基本的软件基础架构。 尽管此模型适用于游戏引擎系统和虚拟现实硬件，但该模型与机器人控制系统（如ROS）中的软件基础结构并不太吻合。
C. 总结
尽管存在针对机器人和虚拟现实系统的中间件，这些中间件可以很好地完成各自的任务，但是这两个软件环境不容易集成。 ROS是机器人软件的事实上的标准（至少在研究领域中）是基于消息传递范例的。 典型的游戏软件基础结构（以Unity为代表）与渲染循环紧密相关，并使用游戏对象作为基本原语。 整合这两个环境需要处理以下现实。
ROS消息必须映射到可以在可视化系统中作为基本呈现循环一部分处理的事件。
映射到虚拟现实系统的用户意图必须映射到机器人软件环境中的相应ROS消息中。
处理渲染环境的活泼性要求至关重要。 通常，维护渲染循环的过程必须足够快地完成（通常少于1/30秒），以保持虚拟现实界面的生动性。
2. 将ROS与Unity联系起来
在这里，我们描述了将基于Unity的虚拟现实远程操作界面与基于ROS的地面接触机器人（特别是图1中所示的机器人）集成在一起的过程。 如上所述，该机器人利用ROS作为其操作中间件，并使用运行Linux的计算机集合在板上进行所有计算和传感。 迄今为止，测试主要集中在平坦的地面上进行，但如果完全实施，则预计机器人将在崎uneven不平的地面上运行，并且车辆的侧倾角和俯仰角将通过由驾驶员引起的实际侧倾角和俯仰角传达给操作员。 运动平台如图2（a）所示。 初步测试使用了不太复杂的虚拟现实硬件-从图2（b）所示的沉浸式投影环境，到跟踪的HMD到基于笔记本电脑的简单显示器。
利用可以部署到这些和其他硬件基础结构的软件基础结构至关重要。 尽管许多不同的可视化/虚拟现实工具箱都可以满足此要求，但是在这里我们选择使用Unity。 Unity提供了在各种不同平台上部署/开发软件的灵活性，现有的库可提供对我们可用的各种虚拟现实交互服的控制/交互。
在操作上，此遥控机器人分两个阶段运行：映射阶段和遥控阶段。在制图阶段，将获取机器人环境的地图。完成此过程的过程不在本手稿的讨论范围之内，但它可以是手动的-使用手动获取的地图-或可以是自动的-使用某些标准SLAM算法。图1（b）中所示的图是使用较新的技术获得的，但是该过程对于此处介绍的工作并不关键。该地图可以采用许多不同的形式，但是在这里，我们假设在某些全局坐标系中使用3D点云表示。在远程操作阶段，机器人由用户通过用Unity编写的基于虚拟现实的远程操作界面来驱动。 ROS和Unity世界都可以访问预先计算的地图，该地图会通过车辆的实时遥测，车辆在行驶过程中获得的局部点云以及车载倾斜/俯仰传感器来增强，从而进行自动驾驶。运动基座相对于重力的方向。 （参见图3。）
A.与ROS消息传递系统接口
在ROS中，使用基于TCP / IP套接字的内部协议传递消息。这是一种复杂的协议，旨在在ROS内的异步节点之间提供可靠的传输。尽管可以直接与该协议接口，但是许多ROS基础结构对远程操作接口几乎没有兴趣。替代处理ROS世界的复杂性，替代方法是通过rosbridge框架公开ROS基础结构的有趣部分[14]。 Rosbridge提供了一种机制，在该机制中，ROS环境中生成的消息将暴露给外部代理，并且外部代理可以在其中将消息注入ROS环境。该过程利用WebSocket [15]协议作为通信层，这意味着只要外部代理具有对ROS环境的网络访问权限，它就可以物理上位于任何地方。存在许多使用Unity脚本环境支持WebSocket协议的库。
ROS和Unity之间的通信过程涉及通过网络套接字传输yaml编码的消息。 yaml消息是关键字-值对的集合。 该协议非常简单，尽管并非毫无顾虑，正如我们不久将看到的那样。 消息很容易制作。 例如，要请求ROS将所有时钟消息从ROS环境传输到Unity环境，Unity环境将简单地通过websocket协议进行传输
ROS环境的响应将通过websocket连接异步显示。 太过向ROS环境注入（发布）特定消息，Unity环境首先宣告它将在特定主题上发布特定类型的消息。
然后在需要时使用
其中msg是编码传感器msgs / Joy消息的yaml字符串。 在服务消息协议方面必须解决的一个问题是，Unity中的渲染过程假定与场景中渲染相关联的任何脚本都将快速完成。 考虑到从ROS环境发送/接收数据的潜在延迟，这实质上需要异步处理来处理远程ROS环境。 在当前的实现中，这是通过处理rosbridge消息流的单独Unity线程来完成的。
在当前的实现中，静态环境图不是通过rosbridge接口传输的，而是预先存储为二进制文件并由Unity中的脚本加载的。 与使用rosbridge接口相比，这提供了实质性的性能改进。 YAML是一种七位干净的协议，尽管它具有许多优点，但它的确意味着大型数据结构（地图可能在点云中包含十万多个点）可能需要花费大量时间才能传输。 使用存储在Unity和ROS文件系统上的文件可解决此特定问题。 由于正在传输的实际数据量相对较小，因此在远程操作期间使用内存相对较低的YAML消息就不再是问题。
在远程操作期间，Unity环境将预加载的地图（点云）显示为粒子系统。操作员使用操纵杆或其他输入设备命令机器人。输入消息将转换为相应的ROS传感器msgs / Joy消息，并注入到机器人上的ROS控制环境中，从而使其移动。当机器人移动时，在机器人上运行的姿势估计过程会相对于ROS和Unity环境通用的全局地图，保持对机器人姿势的估计。在ROS环境中，由机器人收集的传感器数据将转换为全局参照系中的点云，并且此信息由Unity环境进行订阅。这使得信息由rosbridge自动传递到Unity环境，在该环境中，信息将转换为第二点云并与全局地图信息一起显示。姿势估计过程中的错误可以看作是映射环境和返回的传感器数据之间的差异。如果用户愿意，他们可以为ROS环境中的本地化过程提供提示。这样的提示被捕获为Unity中的用户交互事件，并通过rosbridge传输到ROS环境，在那里它们成为姿势估计过程的局部校正。如果自主定位系统无法保持对机器人当前姿势的准确估计，则这些定位提示可能被证明是必要的。
3. 总结和未来的工作
为自治系统构建基于虚拟现实的远程操作界面需要将两种截然不同的软件技术融合在一起。 启用ROS的机器人利用基于消息传递的软件体系结构，而虚拟现实系统通常与渲染循环相关联。 本文介绍了将这两种不同的技术联系起来的系统和通用方法。 rosbridge和websocket并不是在ROS中开发VR节点，而是提供了一种机制，VR基础结构可以在该机制中侦听ROS消息并将ROS消息注入ROS环境。
使用websocket作为基础通信协议可以使ROS和VR环境在完全独立的硬件上运行。 它仅需要通过可靠的网络连接将两个系统耦合在一起。
这里报道的实验是在室内并使用相对简单的显示系统进行的。 正在进行的工作是调查将机器人部署到户外并使用运动平台向相对于重力的方向提示操作者从运动平台控制机器人的车辆侧倾/俯仰方向。