ROS 的三种基本通信机制
ROS的三种基本通信机制
简介
ROS 引入通信机制,是为了实现 ROS 节点(进程)之间的通信。利用ROS进程的分布式框架,可以使得每个进程独立的工作,甚至分布于不同的主机工作。机器人上的各种传感器,比如雷达、GPS 等,需要传递数据以实现对机器人的合理控制,进程通信的实现则是其中传输数据的关键。
ROS的基本通信方式将分为三种:
-
话题通信(发布订阅模式)
-
服务通信(请求响应模式)
-
参数服务器(参数共享模式)
接下来将会详细介绍三种通信方式的理论模型
话题通信
话题通信是 ROS 中使用频率最高的一种通信模式,话题通信是基于发布订阅模式的,也即:一个节点发布消息,另一个节点订阅该消息。话题通信的应用场景也极其广泛,比如下面一个常见场景:
机器人在执行导航功能,使用的传感器是激光雷达,机器人会采集激光雷达感知到的信息并计算,然后生成运动控制信息 驱动机器人底盘运动
话题通信的概念和作用
话题通信以发布订阅的方式实现不同节点之间数据交互的通信模式,用于不断更新的、少逻辑处理的数据传输场景。
话题通信的理论模型
话题通信模型中涉及到三个角色,分别是:
ROS Mater(管理者):负责保管 Taker 和 Listener 注册的信息,并匹配话题相同的 Talker 与 Listener,帮助 Talker 与 Listener 建立连接
Talker(发布者):发布消息
Listener(订阅者):接收 Talker 的消息
整个话题通信的流程如下图所示:
具体步骤如下:
-
Talker 注册。Talker 启动后,会通过 RPC 在 ROS Master 中注册自身信息,其中包含所发布消息的话题名称。ROS Master 会将节点的注册信息加入到注册表中
-
Listener 注册。Listener 启动后,也会通过 RPC 在 ROS Master 中注册自身信息,包含需要订阅消息的话题名。ROS Master 会将节点的注册信息加入到注册表中
-
ROS Master 实现信息匹配。ROS Master 会根据注册表中的信息匹配 Talker 和 Listener,并通过 RPC 向 Listener 发送 Talker 的 RPC 地址信息
-
Listener 向 Talker 发送请求。Listener 根据接收到的 RPC 地址,通过 RPC 向 Talker 发送连接请求,传输订阅的话题名称、消息类型以及通信协议(TCP/UDP)
-
Talker 确认请求。Talker 接收到 Listener 的请求后,也是通过 RPC 向 Listener 确认连接信息,并发送自身的 TCP 地址信息
-
Listene r与 Talker 件里连接。Listener 根据步骤4 返回的消息使用 TCP 与 Talker 建立网络连接
-
Talker 向 Listener 发送消息。连接建立后,Talker 开始向 Listener 发布消息
注意事项及说明
-
上述实现流程中,前五步使用的 RPC协议,最后两步使用的是 TCP 协议
-
只有当 Talker 和 Listener 的话题名称相同时才能进行话题通信
-
Talker 与 Listener 都可以有多个,启动无先后顺序要求
-
Talker 与 Listener 连接建立后,不再需要 ROS Master。也即,即便关闭 ROS Master,Talker 与 Listener 照常通信
-
在代码编写中,我们关注的一般是话题、消息传输的格式等等,而 Talker 和 Listener 所建立连接的过程是被封装好的
服务通信
服务通信是基于请求响应模式的,是一种应答机制。也即: 一个节点 A 向另一个节点 B 发送请求,B接收处理请求并产生响应结果返回给 A
比如如下场景:机器人巡逻过程中,控制系统分析传感器数据发现可疑物体或人,此时需要拍摄照片并留存
在上述场景中,就使用到了服务通信。服务通信更适用于对时时性有要求、具有一定逻辑处理的应用场景
服务通信理论模型
服务通信较之于话题通信更简单些,理论模型如下图所示,该模型中涉及到三个角色:
ROS master(管理者)
Server(服务端)
Clien(客户端)
ROS Master 负责保管 Server 和 Client 注册的信息,并匹配话题相同的 Server 与 Client ,帮助 Server 与 Client 建立连接,连接建立后,Client 发送请求信息,Server 返回响应信息
具体步骤如下:
-
Server注册。Server 启动后,会通过 RPC 在 ROS Master 中注册自身信息,其中包含提供的服务的名称。ROS Master 会将节点的注册信息加入到注册表中
-
Client 注册。Client 启动后,也会通过 RPC 在 ROS Master 中注册自身信息,包含需要请求的服务的名称。ROS Master 会将节点的注册信息加入到注册表中
-
ROS Master 实现信息匹配。ROS Master 会根据注册表中的信息匹配 Server 和 Client,并通过 RPC 向 Client 发送 Server 的 TCP 地址信息
-
Client 发送请求。Client 根据步骤 2 响应的信息,使用 TCP 与 Server 建立网络连接,并发送请求数据
-
Server 发送响应。Server 接收、解析请求的数据,并产生响应结果返回给 Client
注意事项
-
客户端请求被处理时,要保证服务端已经启动
-
服务端和客户端都可以存在多个
参数服务器
参数服务器在 ROS 中主要用于实现不同节点之间的数据共享。参数服务器相当于是独立于所有节点的一个公共容器,可以将数据存储在该容器中,被不同的节点调用,当然不同的节点也可以往其中存储数据,关于参数服务器的典型应用场景如下:
导航实现时,会进行路径规划,比如: 全局路径规划,设计一个从出发点到目标点的大致路径。本地路径规划,会根据当前路况生成时时的行进路径。全局路径规划和本地路径规划时,就会使用到参数服务器:路径规划时,需要参考小车的尺寸,我们可以将这些尺寸信息存储到参数服务器,全局路径规划节点与本地路径规划节点都可以从参数服务器中调用这些参数
参数服务器,一般适用于存在数据共享的一些应用场景,类似于全局变量
参数服务器理论模型
参数服务器实现是最为简单的,该模型如下图所示,该模型中涉及到三个角色:
ROS Master (管理者)
Talker (参数设置者)
Listener (参数调用者)
ROS Master 作为一个公共容器保存参数,Talker 可以向容器中设置参数,Listener 可以获取参数
具体步骤如下:
-
Talker 设置参数。Talker 通过 RPC 向参数服务器发送参数(包括参数名与参数值),ROS Master 将参数保存到参数列表中
-
Listener 获取参数。Listener 通过 RPC 向参数服务器发送参数查找请求,请求中包含要查找的参数名
-
ROS Master 向 Listener 发送参数值。ROS Master 根据步骤2请求提供的参数名查找参数值,并将查询结果通过 RPC 发送给 Listener
-
参数的数据类型:
· 32-bit integers
· booleans
· strings
· doubles
· iso8601 data
· lists
· base64-encoded binary data
· 字典
注意事项
-
参数服务器不是为高性能而设计的,因此最好用于存储静态的非二进制的简单数据
-
参数服务器不再是 talker 与 listener 之间传输数据