自动驾驶通信中间件

对不同自动驾驶系统所用的通信中间件比较感兴趣。但直接相关的资料比较少。最近看了两篇比较早的论文，大致先总结下里面的内容，之后再逐渐往上补充内容。

为什么需要通信中间件

现代基本的软件设计原则是模块化。模块化可以提高可维护性、代码重用性并隔离故障。例如，一个大型机器人系统可以分解成特定的任务，如数据采集、状态估计、任务规划等。为了完成它们的任务，模块必须与其他模块交换信息。在现代操作系统中，将单个模块映射到软件进程非常方便，这些进程可以位于相同的计算设备上，也可以位于物理上独立的计算设备上。这就把信息交换的任务转化成了深入研究的进程间通信问题 。

模块化为开发提供了便利，但也引入了对通信中间件的需求。将模块映射到单独的进程的一个最显著的特性是每个模块接收一个单独的内存地址空间。这一界限的引入带来了许多好处;模块可以在相同或不同的主机设备上运行，可以独立启动和停止，可以用不同的编程语言和不同的操作系统编写，一个模块的灾难性故障不一定会影响另一个模块。与此同时，模块之间的隔离使得共享信息也不再是一项简单的任务。模块设计人员必须仔细考虑在模块之间共享哪些信息，如何将这些信息封送编码到消息中，如何将封送的消息从一个模块传递到另一个模块，以及如何在接收到消息后解码。

通信中间件的引入整体上可以帮助开发人员提高工作效率。尽管消息传递系统引入了复杂性，但它也提供了分析和内省的机会，这对开发人员来说可能是无价的。特别是，可以通过专门设计用于帮助系统开发的模块捕获和分析消息。这些模块可以将消息记录到磁盘，提供关于带宽、消息速率等方面的统计信息。如果消息是根据正式的类型系统编组（Marshalling）的，那么流量检查模块可以自动解码消息，就像程序调试器可以自动解码正在运行的应用程序的堆栈变量一样。

通信中间件该满足什么特性

基于通信中间件的工作流程，一个中间件应该包括以下几个模块:数据类型规范语言、消息传递系统、日志/回放工具和实时分析工具.

依据以上主要模块，好的通信中间件应该拥有以上特性：

• 数据类型规范语言应独立于平台和具体的编程语言，以消除用户实现编组（Marshalling）代码的需要，同时保证运行时类型的安全性
• 消息传递系统需要在不同的进程之间传输消息，并提供低延迟的消息传递功能，且消除对中央通信的依赖
• 需要使混合模拟、记录和实时数据源的工作更容易。
• 需要提供大量的日志记录、回放和流量检查工具，以简化常见的开发和调试任务

关于通信中间件有什么相关工作

目前有各种消息传递系统，每个系统都有进行一下权衡。是否使用可靠或不可靠的数据传输以及是否提供自动数据编组系统。

Player

Player project(Player 2.0: Toward a practical robot programming framework)是一个比较著名的系统，它提供了一个机器人控制的客户端/服务器模型。服务器在单个进程中运行,并有一组用户可配置的驱动(Driver)，每个驱动在其自己的线程中。Player发行版包含许多驱动，每个驱动都有一个指定的任务，比如读取摄像机数据或执行轮速命令。用户编写客户端程序来通过服务器与驱动交互，通常是通过在客户端地址空间中的驱动代理(proxy)对象上进行操作。代理对象处理与服务器的通信和数据编组.

Player为习惯于传统应用程序开发的软件开发人员提供了一个熟悉的编程模型，并尝试简化机器人开发的许多方面。这些努力包括各种各样的驱动，促成了它的广泛成功。然而，这种架构也有其缺点：创建新驱动是一个复杂的过程，一个驱动的失败可能会影响到其他驱动，甚至可能导致整个机器人的失败；单片进程的特性使调试单个组件变得复杂。Player最初是为客户端-驱动通信而设计的;驱动-驱动和客户端-客户端通信的机制已经被添加到player中，但是在组合的自由度上依然存在一定局限性。

Player默认使用TCP通信。虽然TCP本身是可靠和有序的，但Player添加了一组add-replace规则，如果订阅方无法跟上发布方，这些规则会导致消息被删除。如果没有这样的规定，TCP缓冲区最终将被填满，并导致发布服务器的运行变慢

在内部，Player使用（XDR）[http://www.rfc-editor.org/rfc/rfc1832.txt]进行数据编组。Player的内置类型利用并鼓励用户使用XDR。

MOOS

MOOS(MOOS - mission orientated operating suite)在水下机器人社区中特别流行。它提供了一个发布订阅模型，其中所有通信都通过一个中央服务器路由，客户端以固定的速率(通常为10hz)获取消息。MOOS消息是ASCII字符串，其优点是使消息易于被人类读取，缺点是比二进制编码的消息消耗更多的带宽。

CARMEN

CARMEN robotics包(Perspectives on standardization in mobile robot programming: The carnegie mellon navigation (carmen) toolkit)主要使用IPC消息传递系统(Inter-Process Communication)。IPC使用TCP和一个中心来协调模块之间的通信。默认情况下，中央服务器路由所有通信，但也可以将其配置为用于促进客户端到客户端直接通信的撮合服务。在这两种模式中，IPC都实现了发布/订阅模型。与pull系统不同，push系统尽可能快地向订阅者发送消息。IPC提供了一种工具，它可以部分地自动化消息的编组和反编组，但它要求用户手动将类型的ASCII描述与C结构声明保持同步吗，用户必须确保其结构的包装和对齐方式符合ASCII描述，对于不同单词大小的机器，这容易导致出错

JAUS

JAUS实现了一个路由消息模型，在这个模型中，单个消息被定位到特定的目的地[The Joint Architecture for Unmanned Systems: Reference Architecture Specification]。JAUS的主要优势不是消息处理系统本身，而是JAUS规范包含了200多个标准化数据类型。原则上，实现这些标准格式的模块可以自由地组合在一起，以构建大型系统。

JAUS是围绕一个路由消息传递系统设计的，其中每个消息都有一个特定的目的地。

尽管组件可以在没有相应查询的情况下单方面传输消息(包括广播)，但其也支持基于“query查询“”和“inform通知“”消息的类似rpc的机制。作为这个消息传递框架的一部分，JAUS允许一个通信节点树。JAUS规范本身没有指定传输，但是通常使用UDP。因此，JAUS不保证消息传递。与Player和MOOS相比，消息丢失的机制是不同的，但是效果是非常相似的。

JAUS没有提供自动生成编组代码的功能:每种数据类型都必须手工编码。此外，消息的类型(命令代码)编码在一个16位小整数中，这些值的赋值由JAUS规范指定。由于这个集合只有一个子空间可用于用户定义类型，开发人员必须确保以无冲突的方式分配这些值。

虽然JAUS以前支持Java，但是OpenJAUS v3.3中取消了这种支持。JAUS规范的其他限制包括4096字节的消息限制，以及每个节点必须由系统构建器手动分配一个全局惟一标识符。

ROS

机器人操作系统(ROS)旨在为机器人开发提供一个完整的环境。例如，它提供了一个自动处理依赖项的包管理系统。它的消息传递子系统提供了发布/订阅模型和面向服务的模型。采用match-maker流程来促进客户与客户之间的联系。消息传递接口足够通用，可以使用不同的传输，包括共享内存、TCP、UDP和Spread最初的版本使用TCP作为唯一的消息传输。

ROS还提供了一种基于类似于c的类型规范语言的数据组服务。这允许在little-endian系统上进行快速而简单的数据编组，但是不支持big-endian系统

RDS

Microsoft s Robotics Development Studio (RDS)(Microsoft robotics studio: A technical introduction,)与大多数其他系统的不同之处在于，它没有提供发布/订阅模型，而是采用了服务模型。这个模型可以看作是一种有状态的远程过程调用习惯用法，它基于简单对象访问协议(Simple Object Access Protocol, SOAP)。有几个传输层可用，从简单的内存副本(用于相同内存空间中的服务)到通过Internet连接的服务的XML/RPC。

对现有中间件的整体总结

在现有系统中有几个重复出现的主题。发布/订阅模型是最常用的，TCP是最常用的传输。大多数这些系统使用一个集中的中心，不管它是用于消息路由还是仅仅用于匹配。几乎所有这些系统都提供了一个可靠且有序的传输系统，尽管有些系统将UDP传输作为非标准选项提供。

服务模型提供了一种熟悉的编程模型，但这有其缺点。例如，将以前记录的数据注入基于服务的系统通常比较困难。这种能力在开发感知和其他数据处理算法时特别有用，因为可以使用相同的代码操作日志数据和实时数据。在发布/订阅系统中，这可以通过简单地将以前的消息重新发送到客户机来实现。由于在面向服务的系统中通信是有状态的，因此事件注入需要服务本身的协作。

这些系统在它们所提供的数据编组支持方面差异很大。二进制格式的消息具有简洁的显著优点，大多数系统都使用这种格式。一些系统使用基于xdr的编组系统，尽管一些实现只提供部分自动代码生成。例如，语言支持通常是有限的，在某些系统中，用户必须手动保持格式化字符串与结构的布局同步

再看通信中间件需要什么特性

• 基本上需要一个push-based发布/订阅模型。
• 使用UDP多播作为低延迟但不可靠的传输，从而避免了对集中式sub的需要。
• 提供基于正式类型声明语言生成编组代码的工具;此代码可以为大量平台和操作系统生成，并提供运行时类型安全性。
• 提供一个相对独立的消息传递系统，以便于集成而不是提供操作环境，包括预定义的数据类型、准备使用的模块、事件循环、消息传递系统、可视化和仿真工具、包管理等等的集合。
• 支持灵活的程序调试和运行数据分析的功能。虽然所有的系统都提供了某种机制来将消息从一个模块传递到另一个模块，但是很少有系统提供一种方法来方便地调试和检查实际传输的消息。这样做的通常是以牺牲效率和性能为代价的。

 

来源：《南浔遇雨 博客》