当前位置：首页 > article >正文

ROS2软件架构全面解析-学习如何设计通信中间件框架

article 2025/1/4 10:30:16

前言

ROS（Robot Operating System） 2 是一个用于开发机器人应用的软件平台，也称为机器人软件开发工具包 (SDK)。
ROS2是ROS1的迭代升级版本，最主要的升级点是引入DDS（Data Distribution Service）为基础的底层通信系统。
为解决ROS1存在主要几个缺陷：

为解决一个主节点通信故障(ROSMaster)，需要对所有现有的Client库进行单独的补丁处理，并且每个补丁都是定制的解决方案。因为ROS1中Client和Master是高度耦合，一旦Master节点需要修复bug，那所有的Client节点功能都需要修改。
对于ROS系统安全问题通过SROS 项目增强，但它难以维护，并且需要进一步开发以满足不断变化的安全趋势。

ROS2软件架构

我先用一句话来总结ROS2：为机器人设计以DDS为底座的通信中间件
让我们来看一下总体通信架构图
ROS2 Client Library API Stack
最上层是User Application，就是机器人系统自己写代码开发的功能，基于一种特定场景解决功能问题。
第二层是API接口层，对Application提供功能接口，比如：create_publisher、create_subscription、ActionClient、ActionServer，因为ROS2支持Python、C++、Java所以API接口层在图片上有三种类别，推荐使用Python接口代码最美观。
第三层（rcl）是API实现层，对API层提供通用功能的底层逻辑实现。
第四层（rmw）是通信API定义层，这是对适配各种DDS组件功能的API规范化，可以使用各种vendor 厂商的DDS。类似于Android AIDL，规定好API让Vendor厂商按照rmw标准适配API，实现更好的模块解耦。
最下面一层就是DDS通信层，可以选择各种DDS实现代码框架：Cyclone DDS、Fast DDS。

为什么ROS2选择DDS

DDS（Data Distribution Service）规范描述了一种用于分布式应用程序通信和集成的数据中心发布-订阅（DCPS）模型。该规范定义了应用程序接口（API）和通信语义（行为和服务质量），从而实现信息从信息生产者到匹配消费者的高效传递。
上面是DDS的定义，但是这并不能解释标题问题，继续来看官方文档。

DDS 提供一个发布-订阅传输，它与 ROS 的发布-订阅传输非常相似。
DDS提供的默认发现系统，需要使用DDS的发布-订阅传输，是一个分布式发现系统。这允许任何两个 DDS 程序进行通信，而无需像 ROS Master这样的工具。
-DDS让ROS 2 旨在获得一流的安全性、嵌入式和实时支持、多机器人通信以及在非理想网络环境中的操作能力。
回答解决部分疑惑，但是我认为还有以下原因：
机器人操作系统很重要的一点就是实时性和低延迟，无人飞行机器人对环境的反应是否低延时，能够实时的调整飞行姿态，对障碍做出避让行为。在这种场景下通信过程中重要就是数据流程，设计这种系统的通信中间件最看重数据采样、发送、接收、处理，一切以数据为核心进行整个系统的状态流转。
ROS2就是为机器人各种场景设计的通信中间件，通信的实时性和低延迟就是最核心的要求，所以就要以数据为核心流转，而DDS这样的以数据为中心的分布式通信规范刚好满足其需求。

我之前一直很疑惑ROS2为什么不选择以为someip核心的通信中间件，并且也都是有Client、server模式那和someip有什么区别，而且也有文章表现车载中间件中的DDS和someip之争（参考文献二）。
本人认为还是应用场景的区别，现在的整车操作系统各个ECU的功能都会以服务的形式把能力提供出来，让其他模块来使用，以服务为通信核心，注重服务订阅、发布、通知，所以从整车通信架构范围来说肯定是someip通信协议使用范围广。但是在聚焦某一部分实时、低延迟性、大数据量业务，就可以考虑使用DDS。对于主机厂肯定会考虑到两种协议的兼容性问题，所以现在主流做法的是写一套像ROS2一样的SOA（Service Oriented Architecture）服务，其中整合someip和DDS区分场景来自动化选用。
这篇博客关注ROS2软件架构的目的就是想要借鉴、分析ROS2这套通信中间件是怎么设计的，来启发、讨论如何设计一套好的通信中间件。

未完待续！持续更新！欢迎大家关注！！！