ROS（机器人操作系统）核心概念

资源分类

ROS（机器人操作系统）核心概念

2019-11-26 |

114 |

原标题：ROS（机器人操作系统）核心概念

来源：AI研习社链接：https://www.yanxishe.com/TextTranslation/1816

在上一篇文章中，我们介绍了ROS的概述，并希望完成安装过程。在本文中，我们将介绍ROS的一些核心概念，熟悉术语。简要介绍ROS教程或其他资料中可能看到的概念。如果你遵循安装和后续配置要求，文件系统中的某个位置应有命名为catkin_ws的目录（取决于你所设置的配置）。那么这个目录是什么，为什么如此重要？

Catkin工作空间

等一下，什么是catkin？catkin是一个应用构建系统。能够将其视为CMake或GU Make的“高级”版本。由于你的ROS应用程序可能包括从.cpp到.py文件的各种软件，以及大量依存关系，因此ROS开发人员认为，catkin是最好的解决方案。你可以在此阅读更多关于这方面应用的信息。Catkin工作空间是ROS应用程序的主目录，是进行代码开发、构建以及安装的位置。面向实际需求，你可以在桌面任意设置多个工作区。且这些工作区不一定命名为catkin_ws，可以使用任何有效的目录名称。

那么，你想怎么决定何时创建一个新的工作空间？这取决于有无硬性规定所有项目都只能使用一个工作空间，或者相反，必须一个程序包使用一个工作空间（如下所述），但两者都不合理。将工作区是为应用程序，则所有代码和相关文件都应放在此处。比如，如果你正在处理两个项目：一个应用于移动机器人，另一个应用于机械臂，则需要相关“程序包”存入单独工作空间，以便于代码构建、共享以及管理。

没关系，你可能想知道你到底在哪里编写代码？在Catkin工作空间中某个位置。

ROS程序包

这是实际放代码的位置。可将其视为能够构建、安装以及运行的最小独立用户开发实体。这样想：当工作在一个用于驱动自主移动机器人（或者是自动驾驶车辆）的项目中，需要几个较小应用程序同时完成最终目标。比如，其中一项任务是通过摄像机接口提供视觉数据，另一项任务是理解这些数据用于识别车道线、障碍物和标志牌。再一项任务是进行路径规划，等等。每一项任务都需要开发人员提供不同专业知识，并在整个应用中的角色完全不同。

一个ROS程序包是保存这些任务的源代码、脚本、CMakeLists、启动文件、消息文件、服务文件及其他文件的地方。同样，对于一个ROS程序包而言，虽然没有硬性规定仅关注应用程序的一个特定方面，但要维护时要谨慎使用这种方法。如果想进一步了解ROS软件包的设计和组件，请参阅本文以获得更深入了解。

目前为止，使用“过程”一词来指代所执行的任何应用程序代码。其实在ROS系统中，这样的可执行文件称为ROS节点，是使用ROS框架与其他此类可执行文件进行通信的程序。提供了使用发布者、订阅者、服务或动作服务器-客户端进行通信的方式。

发布者和订阅者

考虑到移动机器人开发中的典型情况，希望定位模块能够在世界坐标系中连续提供机器人的姿态。该姿态必须通过控制算法实现给定路径跟踪，然后该控制器节点将向电机驱动器进程发送速度命令。注意，机器人姿态和速度命令必须要一直提供。ROS中提供了发布者和订阅者机制来实现该功能。在我们讨论的示例中，定位节点将“发布”机器人姿态，控制器节点“订阅”该信息，然后“发布”运动命令。这里有一个问题：“如果这些节点都在发送和接收数据，那节点如何知道要使用哪些数据以及使用这些数据的目的是什么”。

这就需要提出ROS主题。ROS节点基本上是广播（发布）特定主题的数据（消息），并且一个或多个节点可以接收（订阅）该信息。这些主题中的的消息都有唯一标识。问题是，定义机器人姿态所需的数据类型与描述摄像机流所需的数据类型明显不同。因此ROS为大多数常用信息提供了一些内置的消息类型，允许用户根据应用程序的需要定义自己的消息类型。

如下图所示，发布者用于发送数据，一个或多个节点可以订阅该信息。

ROS：发布者和订阅者

ROS服务

发布者-订阅者机制通常适合于更连续的通信，常需要进行远程过程调用（RPC）。但 ROS服务只是进程间等价的函数调用，涉及到客户端的请求和服务器的响应，通常适用于更离散的事件，比如LED打开/关闭、设置或获取参数或任何其他合适的功能评估。与发布者-订阅者机制相同，服务也具有唯一的服务名称，并且在服务类型中定义了请求和响应对。此外，与消息类似，ROS附带了一些预构建的服务，允许用户根据每个需求进行开发。

ROS：服务主机和请求

如上图所示，每个服务主机都能够回答几个请求，但这些请求不是并发的。即一次只能处理一个请求，其余查询排队（用户可以指定队列长度）。

ROS 动作库

假设一个场景，该情况要求启动特定动作并提供反馈，然后在成功、失败或抢占后停止。例如，物流作业中的机器人顶部有一个传送带，我们希望在货物停靠到精确位置时启动传送带移动，并在装载作业完成时终止移动。执行此操作的一个简便方法是，启动从任务管理器到传送带控制的服务调用，等待并希望在进程完成时得到响应，在执行此操作时停止整个代码。但是如果执行机构出现问题，且完全没有运动时怎么办？很明显，代码仿佛被遗落在无人区，卡在服务中无法退出。而ROS 动作库就是建立在ROS消息中，为这种情况提供已有功能。动作客户端通过目标请求发起调用，能够抢占目标，动作服务器在其处于运动状态时提供连续反馈，在终止时根据用户定义的标准判断成功/失败。有一定的自由度后，可以将其理解为服务调用的混合，通过使用类似订阅者的功能启动某个动作，以获取反馈并最终接受服务器的响应。与消息和服务类似，动作文件可用于定义所交换数据的操作类型和要标识的主题名称。通常情况下，ROS有一些内置的动作类型，同时还提供了用户创建自定义动作文件的功能。

基于动作库通信的示意图如下所示。虽然一个动作服务器能够回答多个客户端请求，但是每个目标请求都会抢占之前的进程。说明了动作服务器中每次只能有一个客户端进行有效通信。