ROS1的通信架构的基础通信方式及相关概念

电子说

1.3w人已加入

描述

ROS的通信架构是ROS的灵魂所在,它包括数据处理,进程运行,消息传递等 。这篇文章主要介绍ROS1的通信架构的基础通信方式和相关概念,因为ROS1和ROS2的通信方式相差很大,文章后面会介绍ROS2 的通信框架和差异。

接下来介绍一下三组概念:master<-->node<-->launch、topic<-->msg、service<-->srv<-->parameter <-->action.

一、master<-->node<-->launch

node: ROS最小的进程单元就是节点node。一个软件包里面有多个可执行文件,可执行文件被运行就是进程(process),这个进程就是节点node。

rosnode list 列出当前运行的node信息

rosnode info node_name 显示出node的详细信息

rosnode kill node_name 结束某个node

rosnode ping 测试链接节点

rosnode machine 列出在特定机器或列表机器上运行的节点

rosnode cleanup 清除不可到达节点的注册信息

master: ROS网络架构的管理中心,管理着各个node。node先在master进行注册,node之间通信需要经过master编排才能点对点的通信。所以ROS程序启动, 第一步先执行roscore指令启动master,执行指令后同时启动的还有rosout(负责日志输出、记录当前系统状态)和parameter server(参数服务器,非node,负责存储参数配置) ,再由节点管理器按照cmakelists.txt、package.xml配置执行rosrun pkgname node_name 依次启动node

launch: 复杂节点启动管理文件。执行roslaunch pkg_name file_name.launch 指令后,首先系统先检测roscore是否启动,如果没有启动会默认自动拉起。然后按照launch配置启动规则,有序启动多个节点,减少终端输入。

二、topic<-->msg

ROS1的通信方式有四种:topic主题,service服务,parameter service 参数服务器 ,actionlib动作库。

topic: ROS通信最常用的一种,对实时性、周期性消息,使用topic传输是最佳选择。简单的说,启动topic 首先需要publisher和subscriber 节点到master进行注册,然后publisher 会发布topic,subscriber在master指挥下会订阅topic,从而建立sub-pub之间的通信。一个topic可以有多个publisher,一个publisher可以同时向多个subscriber发送消息,subscriber 接收消息会进行处理(回调函数 callback),publisher发送消息后就继续执行下一个动作,消息的状态和处理结构都不会影响publisher执行,subscriber只管消息接受和处理,publisher挂死不会对subscriber节点状态影响,所以topic通信实现了node之间的解耦,此通信方式属于异步通信。

rostopic list 列出当前所有topic

rostopic info topic_name 显示某个topic的属性信息

rostopic echo topic_name 显示某个topic的内容

rostopic pub topic_name 向某个topic发布内容

rostopic bw topic_name 查看某个topic的带宽

rostopic hz 查看某个topic的频率

rostopic find topic_type 查看某个类型的topic

rostopic type topic_name 查看某个topic类型的msg

message: 直观查看message就是一种数据格式。严格说按照规定的格式发送的数据就是message消息,所以消息既是内容也是标准格式。基本的msg包括bool、int8、int16、int32、int64(以及uint)、float、float64、string、time、 duration、header、可变长数组array[]、固定长度数组array[C]。

rosmsg list 列出系统消息

rosmsg show msg_name 显示某个msg的格式

---常见消息名称--

Vector 矢量; 向量

twist 转动,旋转

covariance 协方差;协变性;共离散;

Odometry 里程计

quaternion 四元组

  • 话题的通信机制

此处假设 Talker 首先启动,可分成图中所示的七步来分析建立通信的详细过程:

通信

  1. Talker 注册Talker 启动,通过 1234 端口使用 RPC 向 ROS Master 注册发布者的信息,包含所发布消息的话题名;ROS master 会将节点的注册信息加入注册列表中。

  2. Listener 注册Listener 启动,同样通过 RPC 向 ROS Master 注册订阅者的信息,包含需要订阅的话题名。

  3. ROS Master 进行信息匹配Master 根据 Listener 的订阅信息从注册列表中进行查找,如果没有找到匹配的发布者,则等待发布者的加入;如果找到匹配的发布者信息,则通过 RPC 向 Listener 发布 Talker 的 RPC 地址信息。

  4. Listener 发送连接请求Listener 接收到 Master 发回的 Talker 地址信息,尝试通过 RPC 向 Talker 发送连接请求,传输订阅的话题名、消息类型以及通信协议(TCP/UDP)。

  5. Talker 确认连接请求Talker 接收到 listener 发送的连接请求后,继续通过 RPC 向 Listener 确认链接信息,其中包含自身的 TCP 地址信息。

  6. Listener 尝试与 Talker 建立网络连接Listener 接收到确认信息后,使用 TCP 尝试与 Talker 建立网络连接。

  7. Talker 向 Listener 发布数据成功建立连接后,Talker 开始向 Listener 发送话题消息数据。

    从上面的分析中可以发现,前五个步骤使用的通信协议都是 RPC,最后发布数据的过程才使用到 TCP。ROS Master 在节点建立连接的过程中起到了重要作用,但是并不参与节点之间最终的数据传输。

三、service<-->srv<-->parameter <-->action

service: 请求--查询双向同步通信模型,service分层两部分,客户端(client)和服务端(server)。客户端(client)发送请求(request)要等服务端(server)处理,反馈回复(reply)才会发送下一个请求到服务端(server).

通信

名称 topic service
通信方式 异步通信 同步通信
实现原理 TCP/IP TCP/IP
通信模型 publisher/subscriber request/replay
映射关系 多对多 多对一
特点 subs收到数据会回调callback 远程过程调用(RPC)服务器端的服务
应用场景 连续、高频的数据发布 偶尔使用的功能、具体任务
举例 激光雷达、里程计发布数据 拍照、逆解计算、开关传感器

注意:远程过程调用(RPC)可以理解为一个进程里面调用另外一个进程的函数。

rosservice list 显示服务列表

rosservice info 打印服务信息

rosservice type 打印服务类型

rosservice uri 打印服务ROSRPC uri(统一资源标识,URI包含URL)

rosservice call 使用所提供的args调用服务

rosservice args 打印服务参数

rosservice find 查找服务

srv: service的数据类型,service通信的数据格式定义在*srv中,包含请求(request)和响应(reply)两部分。

rossrv show 显示服务描述

rossrv list 列出所有服务

rossrv md5 显示服务md5

rossrv package 列出包服务

rossrv packages 列出包含服务的包

  • 服务通信机制

服务是一种带有应答的通信机制,通信原理如下图所示,与话题的通信相比,其减少了 Listener 与 Talker 之间的 RPC 通信。

通信

  1. Talker 注册Talker 启动,通过 1234 端口使用 RPC 向 ROS Master 注册发布者的信息,包含所发布消息的话题名;ROS master 会将节点的注册信息加入注册列表中。
  2. Listener 注册Listener 启动,同样通过 RPC 向 ROS Master 注册订阅者的信息,包含需要订阅的服务名。
  3. ROS Master 进行信息匹配Master 根据 Listener 的订阅信息从注册列表中进行查找,如果没有找到匹配的服务提供者,则等待该服务提供者的加入;如果找到匹配的服务提供者信息,则通过 RPC 向 Listener 发布 Talker 的 TCP 地址信息。
  4. Listener 尝试与 Talker 建立网络连接Listener 接收到确认信息后,使用 TCP 尝试与 Talker 建立网络连接,并发送服务的请求数据。
  5. Talker 向 Listener 发布数据Talker 接收到服务请求和参数后,开始执行服务功能,执行完成后,向 Listener 发送应答数据。

parameter server: 参数服务器维护的一般是静态数据字典,它使用互联网传输,在节点管理器master中运行,实现整个通信。

rosparam set param_key param_value 设置参数****rosparam get param_key 显示参数 rosparam load file_name 从文件加载参数 (yaml格式) rosparam dump file_name 保存参数到文件 (yaml格式)rosparam delete 删除参数rosparam list 列出参数名称

  • 参数管理机制

    参数类似于 ROS 中的全局变量,由 ROS Master 进行管理,其通信机制较为简单,不涉及 TCP/UDP 的通信。

  • 通信

  1. Talker 设置变量Talker 使用 RPC 向 ROS Master 发送参数设置数据,包含参数名和参数值;ROS Master 会将参数名和参数值保存到参数列表中。
  2. Listener 查询参数值Listener 通过 RPC 向 ROS Master 发送参数查找请求,包含索要查找的参数名。
  3. ROS Master 向 Listener 发送参数值Master 根据 Listener 的查找请求从参数列表中进行查找,查找到参数后,使用RPC 将参数数值发送给 Listener。

这里需要注意的是,如果 Talker 向 Master 更新参数值,Listener 在不重新查询参数值的情况下是无法知晓参数值已经被更新的。所以在很多场景中,需要一种动态参数更新机制。

action: 动作类似service,属于请求--查询双向同步通信模型,但是通信过程连续反馈状态信息和随时终止请求。通信双方在action protocol 下通过消息进行数据交流,client和server为用户提供API来请求目标或者通过函数调用和回调来执行目标。

通信

action protocal: action协议包含三部分,目标(设定终点),反馈(实时状态信息),结果(时长、最终姿态)。

通信

ROS1和ROS2通信架构比对

这里主要给大家介绍ROS2和ROS1的通信架构区别,ROS1和ROS2的架构如下,可以分成3层:OS层、中间层和应用层

通信

  • OS层:ROS1主要构建在Linux上,但ROS2支持多个操作系统。
  • 中间层:ROS1通信基于TCPROS/UDPROS,而ROS2通信基于DDS(data distribution service)数据分发服务。它是专门为RTOS设计的数据分发/订阅标准,其技术关键是以数据为核心的发布/订阅 模型 DCPS(data-centric publish-subscribe),DCPS模型类似现在流行的容器命名空间技术,创建了一个全局数据空间,空间内的进程都可以直接访问。另外ROS2的intra-process 和ROS1的nodelet 数据传输方式类似,只是更名了而已,哈哈哈。
  • 应用层:ROS1强依赖于master单点,只要单点就会降低系统的可靠性,所以ROS1只适用于实验室研究,无法商用。ROS2取消了master节点管理器,节点间使用discover发现机制帮助彼此建立链接。

ROS 2 的通信模型

ROS 1的通信模型主要包含话题、服务等通信机制,ROS 2的通信模型会稍显复杂,加入了很多DDS的通信机制。如下图所示:

通信

基于DDS数据分发服务的ROS2模型包含以下几个关键概念。

参与者(Participant) :在 DDS 中,每一个发布者或者订阅者都成为参与者,对应于一个使用 DDS 的用户,可以使用某种定义好的数据类型来 读/写 全局数据空间。

发布者(Publisher) :数据发布的执行者,支持多种数据类型的发布,可以与多个数据写入器(DataWriter)相联,发布一种或多种主题(Topic)的消息。

订阅者(Subscriber) :数据订阅的执行者,支持多种数据类型的订阅,可以与多个数据读取器(DataReader)相联,订阅一种或多种主题(Topic)的消息。

数据写入器(DataWriter) :上层应用向发布者更新数据的对象,每个数据写入器对应一个特定的Topic,类似于ROS 1中的一个消息发布者。

数据读取器(DataReader) :上层应用从订阅者读取数据的对象,每个数据读取器对应一个特定的Topic,类似于ROS 1中的一个消息订阅者。

话题(Topic) :和 ROS 1 中的概念类似,话题需要定义一个名称和一种数据结构,但 ROS 2 中的每个话题都是一个实例,可以存储该话题中的历史消息数据。

质量服务原则(Quality of Service) :简称 QoS Policy,这是 ROS 2 中新增的、也是非常重要的一个概念,控制各方面与底层的通信机制,主要从时间限制、可靠性、持续性、历史记录这几个方面,满足用户针对不同场景的数据需求。

通信

  • 实时性增强:数据必须在 deadline 之前完成更新;
  • 持续性增强:DDS 可以为 ROS 2 提供数据历史服务,新加入的节点也可以获取发布者发布的所有历史数据;
  • 可靠性增强:配置可靠性原则,用户可以根据需求选择性能模式(BEST_EFFORT)或者稳定模式(RELIABLE)。
打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分