ROS架构
1、ROS架构设计
ROS架构可以分为三个层次:OS、中间层和应用层。
2、计算图
节点
一些执行运算任务的进程
消息
节点之间最重要的通讯机制是基于发布/订阅(publish/subscribe)模型的消息(message)通信。针对一个给定的话题,可以存在多个节点订阅该话题的消息,也可以存在多个节点发布该话题的消息。
(图1 发布/订阅模型)
上述节点间信息传递方式并不适用于双向同步信息传输,此时需要采用基于服务模型的节点通讯机制,具体为:首先 client node 向 server node request ,然后 server node 根据request 向 client node 发送response .
(图2 服务模型)
节点管理器(ROS Master)
作用:帮助节点之间的相互查找,建立连接,同时为系统提供参数服务器和其他计算图表的查找功能。
实现方式:通过远程过程调用(RPC)提供登记列表和对其他计算图表的查找功能。
3、文件系统
文件系统涉及到的概念:
1、元功能包(Meta Package):同一目的的功能包的集合。
2、功能包(Package):ROS软件中的基本单元,包含ROS节点、库以及配置文件等。
3、功能包清单(Package Manifest):每个功能包都会包含一个 package.xml 的功能包清单,用于记录功能包的基本信息,包含作者信息、许可信息、依赖选项、编译标志等。
4、元功能包清单:类似于功能包清单,具体差异等接下来深入学习是再说。
5、消息类型:指在进行基于订阅/发布模型的节点间通信时,节点之间传输的信息的类型。可以使用ROS定义的消息类型,也可以在功能包的msg文件下通过 .msg 文件进行自定义消息类型。
6、服务类型:指在进行基于请求/应答模型的节点通信时,节点之间传输信息的类型。可以使用ROS提供的类型,也可以在功能包的srv文件下通过.srv文件进行自定义消息类型。
7、代码:放置功能包节点的源代码的文件夹。
图3 文件结构
功能包
功能包中包含的主要的文件如下:
1、config:放置功能包中的配置文件,由用户创建,文件名可以不同。
2、include:放置功能包中需要用到的头文件。
3、scripts:放置可以直接运行的python脚本。
4、src :放置需要编译的c++代码。
5、launch:放置功能包中的所有启动文件。
6、msg:放置功能包自定义的消息类型。
7、srv:放置功能包自定义的服务类型。
8、action:放置功能包自定义的动作指令。
9、CMakeLists.txt:编译器编译功能包的规则。
10、package.xml:功能包清单。
元功能包
元功能包可以理解为是一种特殊的功能包,其中只包含一个 package.xml 元功能包清单文件。元功能包的主要作用是将多个功能包整合成为一个逻辑上独立的功能包。
元功能包清单文件与功能包清单文件的区别是:
1、元功能包清单文件不需要
2、元功能包清单文件需要添加引用标签;
1 2 3 | <export> <metapackage/> </export> |
4、ROS的通信机制
ROS采用一种分布式的通信机。接下来将详细介绍ROS的三种核心通信机制:
话题通信机制
话题通讯机制中包含两个节点,一个 publisher 一个 subscriber,两个节点的启动顺序没有要求。假设 publisher 节点先启动,则可以将话题通讯机制写成如下七步:
1、publisher 注册
publisher 节点启动,通过1234端口使用 RPC 向ROS Master 注册 publisher 信息,包含发布消息的话题名;ROS Master 将publisher 节点的注册信息加入到注册列表中。
2、subscriber 注册
subscriber 启动,通过RPC 向ROS Master注册subscriber 信息,包含需要订阅的话题名。
3、ROS Master 进行信息匹配
Master 根据subscriber 的订阅信息从注册列表中进行查找:如果没有找到则等待;如果找到匹配的发布者信息,则通过RPC向subscriber 发送 publisher的RPC地址信息。
4、subscriber 发送连接请求
subscriber 接收到ROS Master 发回的地址信息,尝试通过RCP向publisher发送连接请求,传输subscribe的话题名、消息类型以及通信协议(TCP/UDP)。
5、publisher 确认连接请求
publisher接收到subscriber发送的连接请求,继续通过RPC向subscriber确认连接信息,其中包含自身的TCP地址信息。
6、subscriber 尝试与publisher建立网络连接
subscriber接收到确认信息后,使用TCP尝试与publisher建立网络连接。
7、subscriber向publisher发布数据
成功建立连接后,publisher将向subscriber发送话题消息数据。
服务通信机制
服务通信机制是一种带有应答的通信机制,与话题通信机制相比,减少了节点之间的RPC通信。
1、service 注册
service 启动,通过端口1234使用RPC向ROS Msater 注册service 的消息,包含提供的服务名,ROS Master将节点的注册信息注册到注册列表中。
2、client 启动,通过RPC向ROS Master 注册client 的信息,包含需要查找的服务名。
3、ROS Master 根据client 的信息从注册列表中进行查找。如果没有匹配的服务提供者,则等待service 的加入;如果有 服务提供者的信息,则通过RPC向client 发送service的TCP地址信息。
4、client 与 service 建立网络连接
client 接收到确认信息后,使用TCP尝试与service 建立网络连接,并且发送服务的请求数据。
5、service 向 client 发布服务应答数据
service 接受到服务请求和参数后,开始执行服务任务,执行完成后向client发送应答数据。
服务通信机制相对于话题通讯机制主要缺少了节点间的RPC通信环节。
话题与服务的区别
话题 | 服务 | |
---|---|---|
同步 性 | 异步 | 同步 |
通信模型 | 发布/订阅 | 客户端/服务端 |
底层协议 | ROSTCP/ROSUDP | ROSTCP/ROSUDP |
反馈机制 | 无 | 有 |
缓冲区 | 有 | 无 |
实时性 | 弱 | 强 |
节点关系 | 多对多 | 一对多(只能有一个server) |
使用场景 | 数据传输 | 逻辑处理 |
参数管理机制
参数类似于ROS中的全局变量,由ROS Master进行管理。
1、talker(publisher与service)设置变量
talker 使用RPC向ROS Master 发送参数设置数据,包含参数名和参数值;ROS Master 会将参数名和参数值保存到参数列表中。
2、listener (subscriber 与client)查询参数值
listener 通过RPC向ROS Master 发送参数查询请求,包含所要查找的参数名。
3、ROS Master 向listener发送参数配置
Master 根据listener的查找请求从参数列表中进行查找,查找到参数后通过RPC将数值发送给listener。
参考资料:
《ROS机器人开发实践 》