ROS学习02.ROS架构

2.1 ROS架构设计

可将其分成3个层次：OS层、中间层、应用层

• OS层
  ROS不是一个传统意义上的操作系统，不能直接运行在计算机硬件之上，而是需要依托于Linux系统。在OS层，可以直接使用ROS官方支持度最好的Ubuntu操作系统,也可以使用其它Linux操作系统。
• 中间层
  由于Linux并没有针对机器人开发提供特殊的中间件，所以ROS在中间层做了大量工作。
  最重要的是基于TCPROS/UDPROS的通信系统。ROS在基础的TCP/UDP网络之上，进行了再次封装，构成了TCPROS/UDPROS。通信系统使用发布/订阅、客户端/服务器等模型，实现多种通信机制的数据传输。
  Nodelet：进程内的通信方法。可以为多进程通信提供一种更优化的数据传输方式，适合对数据传输实时性方面有较高要求的应用。
  提供大量机器人开发相关的库：如数据类型定义、坐标变换、运动控制等，可以提供给应用层使用
• 应用层
  在应用层，ROS需要运行一个管理者——Master，负责管理整个系统的正常运行。ROS社区内共享的机器人应用功能包，这些功能包内的模块以节点为单位运行，以ROS标准的输入输出为接口，开发者不需要了解模块的内部实现机制，只需了解接口就能实现复用，极大提供开发效率。

从系统实现的角度看，ROS也可以分为三个层次：

• 开源社区：ROS资源是如何分布式管理的
• 文件系统：程序文件是如何组织和构建的
• 计算图：描述程序是如果运行的

2.2 计算图

从计算图的角度看，ROS系统软件的功能模块以节点为单位独立运行，可以分布于多个相同或不同的主机中，在系统运行时通过端对端的拓扑结构进行连接。

2.2.1 节点

节点：一些执行运算任务的进程。
软件模块：一个有多个节点组成的系统。
节点之间的连线：端对端的连接关系。
节点关系图：用节点和连线的方式绘制系统基于ROS的运行图。

2.2.2 消息

基于发布/订阅模型的消息（Message）通信：节点之间最重要的通信机制。
每一个消息：

• 一种严格的数据结构
• 支持标准数据类型（整型、浮点型、布尔型等）、
• 支持嵌套和数组
• 可以根据需求由开发者自定义

2.2.3 话题

消息的传递方式：发布/订阅（Publish/Subscribe）
话题：

• 一个节点针对某个话题发布消息
• 也能为关注某个话题而订阅特定数据
  发布者和订阅者并不了解彼此的存在，系统中可能同时由多个节点发布或订阅同一个话题的的消息。

2.2.4 服务

单向的通信模式：基于话题的发布/订阅模型
双向的同步传输：服务Service，基于客户端/服务器模型（Client/Server），包含两个部分的通信数据类型：请求、应答。
注意：在ROS中，只允许由一个节点提供指定命名的服务，而话题允许有多个节点发布。

2.2.5 节点管理器

ROS节点管理器（ROS Master）：一个控制器，统筹所有节点有条不紊地执行。
功能：ROS Master通过远程过程调用(RPC)，提供登记列表和对其他计算图表的查找功能，帮助ROS节点之间相互查找、建立连接，同时还为系统提供参数服务器，管理全局参数。
重要性：是管理者，没有ROS Master，节点将无法找到彼此，也无法交换消息或调用服务，整个系统将会瘫痪。

2.3 文件系统

文件系统：ROS将所有文件按照一定的规则进行组成，不同功能的文件被放置在不同文件夹下。
结构如下：

• 文件系统
  • 元功能包：组织多个用于同一目的的功能包。
    • 元功能包清单：类型功能包清单，并且元功能包清单可能包含运行时需要依赖的功能包或声明一些引用的标签。
    • 功能包：ROS软件中的基本单元，包含ROS节点、库、配置文件等。
      • 功能包清单 ：每个功能包都有一个名为package.xml的功能包清单，用于记录功能包的基本信息。
      • 消息类型：消息（发布\订阅）既可以使用ROS提供的消息类型，也可以使用.msg文件在功能包的msg文件夹下自定义所需要的消息类型。
      • 服务类型：服务（请求/应答）既可以使用ROS提供的服务类型，也可以使用.srv文件在功能包的srv文件夹中进行自定义。
      • 代码：用于放置功能包节点源代码的文件夹。
      • 其他

2.3.1 功能包

一个功能包的典型文件结构：

• config：放置配置文件，由用户创建，文件名可以不同
• include：放置头文件
• scripts：放置可以直接运行的Python脚本
• src：放置需要编译的C++代码
• launch：放置所有启动文件
• msg：放置自定义的消息类型
• srv：放置自定义的服务类型
• action：放置自定义的动作指令
• CMakeLists.txt：编译器编译功能包的规则
• package.xml：功能包清单

功能包清单：

• 描述了给功能包的名称、版本号、信息描述、作者信息和许可证
• ：定义了功能包中代码编译所依赖的其他功能包
• ：定义了功能包中可执行程序运行时所依赖的其他功能包
• 在开发ROS功能包的过程中，这些信息可以根据功能包的具体内容进行修改

ROS的常用命令：

catkin_create_pkg 　　创建功能包
rospack　　　　　　　获取功能包的信息　
catkin_make　　　　　编译工作空间中的功能包
rosdep　　　　　　　　自动安装功能包依赖的其他包
roscd　　　　　　　　　功能包目录跳转
roscp　　　　　　　　　拷贝功能包中的文件
rosed　　　　　　　　　编辑功能包中的文件
rosrun　　　　　　　　运行功能包中的可执行文件
roslaunch　　　　　　　运行启动文件

2.3.2 元功能包

一种特殊的功能包，只包含一个package.xml元功能包清单文件。
主要作用：将多个功能包整合成为一个逻辑上独立的功能包，类似功能包集合的概念。
元功能包清单文件和功能包清单文件类似，但需要包含一个引用标签：

<export>
	<metapackage/>
export>

注意：

1. 元功能包清单不需要标签声明编译过程依赖的其他功能包
2. 元功能包清单需要标签声明功能包运行时依赖的其他功能包

以导航功能包为例，查看该元功能包中package.xml文件的内容：

roscd navigation
gedit package.xml

2.4 开源社区

链接：http://wiki.ros.org/cn

• 发行版：ROS发行版包括一系列带有版本号、可以直接安装的功能包，使得ROS的软件管理和安装更加容易，并且可以通过软件集合来维持统一的版本号。
• 软件源：ROS依赖于共享网络上的开源代码，不同的组织机构可以开发或者共享自己的机器人软件。
• ROS wiki：记录ROS信息文档的主要论坛。
• 邮件列表：ROS邮件列表是交流ROS更新的主要渠道，同时也可以交流ROS开发的各种疑问。
• ROS Answers：是一个咨询ROS更新的主要渠道，同时也可以交流ROS开发的各种疑问。
• 博客：发布ROS社区中的新闻、图片、视频

ROS社区的资源组织形式：

• 软件仓库
  • 元功能包
    • 功能包
      • 节点
      • 消息
      • 服务

2.5 ROS的通信机制

ROS的底层和核心：分布式通信机制
ROS是一个分布式框架，为用户提供多节点（进程）之间的通信服务，所有软件功能和工具都建立在这种分布式通信机制之上。
最核心的三种通信机制：话题通信、服务通信、参数管理

2.5.1 话题通信机制

话题：在ROS中使用最频繁，通信模型也较为复杂。
ROS中有两个节点：发布者Talker、订阅者Listener。
两个节点分别发布、订阅同一个话题，启动顺序没有强制要求。

基于发布/订阅模型的话题通信机制：（假设Talker首先启动）

1. Talker注册
2. Listener注册
3. ROS Master进行信息匹配
4. Listener发送连接请求
5. Talker确认连接请求
6. Listener尝试与Talker建立网络连接
7. Talker向Listener发布数据

步骤1-5：使用RPC作为通信协议
步骤6-7：使用TCP
ROS Master 在节点建立连接的过程中起了重要作用，但不参与节点之间的最终数据传输。
注意：在节点建立连接后，可以关闭ROS Master，节点间的数据传输不会受到影响，但是其他节点也无法加入这两个节点之间的网络。

2.5.2 服务通信机制

服务是一种带有应答的通信机制。
与话题通信相比，其减少了Listener与Talker之间的RPC通信。

基于服务器/客户端的服务通信机制：

1. Talker注册
2. Listener注册
3. ROS Master进行信息匹配
4. Listener和Talker建立网络连接
5. Talker向Listener发布服务应答数据

步骤1-3：使用RPC
步骤4-5：使用TCP
注意：服务的通信过程相比与话题的通信过程，少了4-5步骤的Listener发送连接请求、Talker确认连接请求的过程。

2.5.3 参数管理机制

参数类似于ROS中的全局变量，有ROS Master进行管理，起通信机制较为简单，不涉及TCP/UDP的通信。
基于RPC的参数管理机制：

1. Talker设置变量
2. Listener查询参数值
3. ROS Master向Listener发送参数值

步骤1-3：使用RPC（远程过程调用）
注意：如果Talker向Master更新参数值，Listener在不重新查询参数值的情况下，无法知晓参数值已经被更新。
改进：在很多应用场景场景中，需要一种动态参数更新机制，会在随后的博文中进行介绍。

2.6 话题与服务的区别

话题和服务是ROS中最基础，也是使用最多的通信方法：
表2-1 话题与服务的区别

	话题	服务
同步性	异步	同步
通信模型	发布/订阅	客户端/服务器
底层协议	ROSTCP/ROSUDP	ROSTCP/ROSUDP
反馈机制	无	有
缓冲区	有	无
实时性	弱	强
节点关系	多对多	一对多（一个Server）
适用场景	数据传输	逻辑处理

总结：

• 话题：基于发布/订阅的异步通信模式。将信息的产生和使用双方解耦，常用于不断更新的、含有较少逻辑处理的数据通信。
• 服务：基于客户端/服务器的同步通信模式。常用于数据量较小，但有强逻辑处理的数据交换。

2.7 本章小结

1. 什么是节点？见2.2.1节
2. 话题和服务通信的异同点？见2.6节
3. ROS Master在系统中的作用是什么？见2.2.5节
4. 话题通信中有哪七个步骤？见2.5.1节
5. 相比话题通信，服务通信少了哪几个步骤？见2.5.2节
6. ROS参数管理时有没有用的TCP/UDP通信？见2.5.3节

参考文献

[1] 胡春旭编著.ROS机器人开发实现[M].机械工业出版社.2018:11-21