ROS wiki系列|ROS入门基础概念讲解
上一期我们对ROS wiki中ROS部分进行了着重讲解，回顾戳这
这一期我们主要介绍ROS-getting started部分的一些基本概念
相关wiki页面：http://wiki.ros.org/ROS/Concepts
ROS中的概念分为三个级别：Filesystem level、Computation Graph level、Community level，也就是文件系统级别、计算图级别和社区级别，接下来我们也按这个顺序来做讲解~
1.ROS Filesystem Level
文件系统级别的概念主要包括你在磁盘上遇到的ROS资源，例如：
Packages
Packages——功能包是在ROS中组织软件的主要单元。一个功能包可能包含ROS运行时进程(节点)、依赖于ROS的库、数据集、配置文件或任何其他有效组织在一起的东西。
ROS中的功能包通常都遵循相同的结构，功能包内容通常包括：
include/package_name： c++包含头文件(确保在CMakeLists.txt中导出)
msg/：包含消息(msg)类型的文件夹
src/package_name/：源文件，特别是导出到其他包的Python源文件。
srv/：包含srv (Service)类型的文件夹
scripts/：可执行脚本
CMakeLists.txt：CMake构建文件(参见catkin/CMakeLists.txt)
package.xml：
CHANGELOG.rst：许多包会定义一个可以自动注入二进制包和包的wiki页面的更新日志
除了wiki中提到的这些文件，这里我再补充两个常见子目录：
cfg：存放功能包配置文件
launch：存放功能包启动文件
同时Packages是如何在ROS中组织文件的一个非常重要的概念，所以ROS中有相当多的工具可以帮助管理。包括:
rospack：查找和检索有关包装的信息
catkin_create_pkg：创建一个新包
catkin_make：构建包的工作空间
rosdep：安装一个包的系统依赖
rqt：在rqt中有一个叫做“Introspection/Package Graph”的插件，它将包依赖关系可视化为一个图形
Metapackages
Metapackages——元功能包是ROS中的专门包，它们不安装文件(除了它们的package.xml清单)，而且它们不包含任何测试、代码、文件或通常在包中找到的其他项目，一个元功能包只是简单地引用一个或多个松散地组合在一起的相关包。
eg.navigation功能包
Package Manifests
package manifest是一个名为package.xml的XML文件，它必须包含在任何符合catkin的包的根文件夹中。这个文件定义了关于包的属性，比如包名、版本号、作者、维护者以及对其他catkin包的依赖关系。
这里列举了package.xml的通常格式
包括基本标签< package >、一些必要标签如< name >< version >等、功能包所需的六种依赖、元功能包所需标签还有其他可以增加的标签，大家可以找一个功能包的package.xml文件来对照查看。
Message (msg) types
ROS使用简化的消息描述语言来描述ROS节点发布的数据值(即消息)。这种描述使得ROS工具可以很容易地自动为几种目标语言的消息类型生成源代码。消息描述存储在ROS包msg/子目录下的.msg文件中。
.msg文件由两部分组成:字段和常量。字段是在消息中发送的数据。常量定义了可以用来解释这些字段的有用值(例如，对于整数值，使用类似枚举的常量)。
在msg这个wiki页面中介绍了msg相关的命令行工具rosmsg、消息定义的一些规范例如定义的格式和允许的字段类型等，还有就是如何构建一个msg文件，需要在package.xml和CMakelists中进行什么操作，感兴趣的可以自行查看。
Service (srv) types
ROS使用简化的服务描述语言(srv)来描述ROS的服务类型。这直接建立在ROS msg格式上，以实现节点之间的请求/响应通信。服务描述以.srv文件的形式存储在包的srv/子目录下。在尝试编写.srv文件之前，应该熟悉msg格式。
这个的wiki页面跟msg的页面结构一样，同样是介绍了相关的命令行工具rossrv、服务定义规范以及如何构建.srv文件，此处不做展开。
2.ROS Computation Graph Level
计算图是一起处理数据的ROS进程的点对点网络。ROS的基本计算图概念是节点、主服务器、参数服务器、消息、服务、主题和包，它们都以不同的方式向图提供数据。这部分的概念都是ROS中比较核心的基础概念。
Nodes
节点是执行计算的进程。节点组合成一个图，并使用主题流、RPC服务和参数服务器相互通信。这些节点应该以细分的规模进行操作;机器人控制系统通常由许多节点组成。例如，一个节点控制激光测距仪，一个节点控制机器人的轮电机，一个节点执行定位，一个节点执行路径规划，一个节点提供系统的图形视图，等等。ROS节点是使用ROS客户端库(如roscpp或rospy)编写的。
Master
ROS Master为ROS系统中的其他节点提供命名和注册服务。它跟踪主题和服务的发布者和订阅者。Master的作用是使单个ROS节点相互定位。一旦这些节点确定了彼此的位置，它们就会进行对等通信。
Master还提供参数服务器。
Master通常使用roscore命令运行，该命令加载ROS主机和其他基本组件。
这里举了一个例子说明了master的作用，简单概括一下：camera节点告诉master——我要通过images这个话题发点东西，然后成功发布话题，但是此时话题只是被发布了还没有被订阅，image viewer节点跳出来表示——哥，我想看看有没有images这个话题可以订阅，master一看，哎好家伙，给你俩牵个线吧，然后两个节点之间就可以通过images话题来通信了，这里我们可以把master当做一个媒人~
Parameter Server
参数服务器是一个共享的、可以通过网络api访问的多变量字典。节点使用此服务器在运行时存储和检索参数。由于它不是为高性能而设计的，所以它最好用于静态的、非二进制的数据，比如配置参数。它应该是全局可见的，以便工具可以轻松地检查系统的配置状态，并在必要时进行修改。
参数服务器使用XMLRPC实现，并在ROS Master中运行，这意味着它的API可以通过普通的XMLRPC库访问。
在这个wiki页面中主要是介绍了参数的一些命名约定、参数支持定义的一些类型、私有参数的概念以及相关命令行工具rosparam
Messages
节点之间通过传递消息进行通信。消息只是由输入字段组成的数据结构。支持标准基元类型(整型、浮点型、布尔型等)，以及基元类型数组。消息可以包含任意嵌套的结构和数组(很像C结构体)。
Topics
消息通过发布/订阅的方式进行传递。节点通过将消息发布到给定的主题来发送消息。主题是一个名称，用于标识消息的内容。对某种类型的数据感兴趣的节点将订阅适当的主题。单个主题可能有多个并发发布者和订阅者，单个节点可以发布和/或订阅多个主题。一般来说，发布者和订阅者并不知道对方的存在。其思想是将信息的生产与消费分离开来。从逻辑上讲，可以将主题看作强类型消息总线。每个总线都有一个名称，任何人都可以连接到总线来发送或接收消息，只要它们是正确的类型。
Services
发布/订阅模型是一种非常灵活的通信范式，但它的多对多单向传输不适用于分布式系统中经常需要的请求/应答交互。请求/应答是通过服务完成的，服务由一对消息结构定义:一个用于请求，一个用于应答。提供节点以一个名称提供服务，客户机通过发送请求消息并等待应答来使用该服务。ROS客户端库通常向程序员呈现这种交互，就好像它是一个远程过程调用。
这里说一下话题和服务的区别：话题的通信方式为异步，而服务为同步；系统中可能同时有多个节点在进行发布或订阅同一话题的消息，但只允许一个节点提供指定命名的服务。
Bags
包是一种保存和回放ROS消息数据的格式。包是存储数据的重要机制，比如传感器数据，这些数据可能很难收集，但对于开发和测试算法是必要的。我们可以使用rosbag命令行工具来进行消息的记录和回放。
3.ROS Community Level
ROS社区级别的概念是ROS资源，使不同的社区能够交换软件和知识。这些资源包括:
Distributions：ROS发行版是可以安装的有版本的堆栈的集合。发行版扮演着与Linux发行版相似的角色:它们使安装一组软件变得更容易，而且它们还在一组软件之间维护一致的版本。
Repositories：ROS依赖于共享网络上的开源代码，不同的机构可以在这里开发和发布自己的机器人软件组件。
ROS Wiki：ROS社区Wiki是记录ROS信息的主要论坛。任何人都可以注册一个帐户并贡献自己的文档、提供更正或更新、编写教程等等。
Bug Ticket System：可以提交一些tickets反馈关于ROS的相关问题或请求
Mailing Lists：ROS用户邮件列表是关于ROS新更新的主要沟通渠道，也是一个询问ROS软件问题的论坛。
ROS Answers：一个回答您ROS相关问题的问答站点。
Blog：ros.org博客提供定期更新，包括照片和视频。（此页面已停止维护，ROS相关新闻可以移步ROS wiki中的News）
Over.