最近工作中要用到ros,所以将所学到的东西,所看到的东西记录下来,方便以后的总结和回顾。

目录

大体印象

ros给我的感觉,更像是一种通信框架,类似于mqtt的一种发布和订阅的消息传输方式,用c++或者python编写的,但又有所区别

ROS分级的

主要分为三个级别

  • 计算图级:描述该程序是怎么实现的
  • 文件系统级:文件是如何组织和构建的
  • 社区级:程序的分布式管理 *** 其实这样分级的主要目的,还是为了软件工程的一个很重要的思想(*高内聚,低耦合*),ros这样的分级,使得这个框架适用于高迸发的场景,感觉有点像类似于分布式的处理,研究不是很深,所以也只是感觉。 下面分别总结以下这三个分级 ***

计算图级

计算图其实就是ros在处理数据时的一种点对点的网络形式。程序运行时,所有进程以及他们所进行的数据处理,将会通过一种点对点的网络形式表现出来。这一级主要包括几个重要概念:

节点(node)

节点就是一些*执行运算任务的进程*。 ROS利用规模可增长的方式是代码模块化: 一个系统就是典型的由很多节点组成的。在这里,节点也可以被称之为“软件模块”。 使用节点使得基于ROS的系统在运行的时候更加形象化:当许多节点同时运行时, 可以很方便的将端对端的通讯绘制成一个图表,在这个图表中,进程就是图中的节点, 而端对端的连接关系就是其中弧线连接。 消息(message)

节点之间是通过传送消息进行通讯的。每一个*消息*都是一个严格的数据结构。原来标准的数据类型(整型,浮点型,布尔型等等)都是支持的,同时也支持原始数组类型。消息可以包含任意的嵌套结构和数组(很类似于C语言的结构structs)。

主题(topic)

消息以一种*发布/订阅*的方式传递,这里有点像我之前接触到的*mqtt*的方式。一个节点可以在一个给定的主题中发布消息。一个节点针对某个主题关注与订阅特定类型的数据。可能同时有多个节点发布或者订阅同一个主题的消息。总体上,发布者和订阅者不了解彼此的存在,这里充分体现了ros通信机制的特点。

服务(service)

虽然基于话题的*发布/订阅模型*是很灵活的通讯模式,但是它广播式的路径规划对于可以简化节点设计的同步传输模式并不适合。在ROS中,我们称之为一个服务,用一个字符串和一对严格规范的消息定义:一个用于请求,一个用于回应。这类似于web服务器,web服务器是由URIs定义的,同时带有完整定义类型的请求和回复文档。需要注意的是,不像话题,只有一个节点可以以任意独有的名字广播一个服务:只有一个服务可以称之为“分类象征”,比如说,任意一个给出的URI地址只能有一个web服务器。

在上面概念的基础上,需要有一个控制器可以使所有节点有条不紊的执行,这就是一个ROS的控制器(ROS Master)。ROS Master 通过RPC(Remote Procedure Call Protocol,远程过程调用)提供了登记列表和对其他计算图表的查找。没有控制器,节点将无法找到其他节点,交换消息或调用服务。

ROS的控制器给ROS的节点存储了主题和服务的注册信 息。节点与控制器通信从而报告它们的注册信息。当这些节点与控制器通信的时候,它们可以接收关于其他以注册及节点的信息并且建立与其它以注册节点之间的联系。当这些注册信息改变时控制器也会回馈这些节点,同时允许节点动态创建与新节点之间的连接。

节点与节点之间的连接是直接的,控制器仅仅提供了查询信息,就像一个DNS服务器。节点订阅一个主题将会要求建立一个与出版该主题的节点的连接,并且将会在同意连接协议的基础上建立该连接。

文件系统级

ROS文件系统级指的是在硬盘上面查看的ROS源代码的组织形式。

ROS中有无数的节点、消息、服务、工具和库文件,需要有效的结构去管理这些代码。在ROS的文件系统级,有以下几个重要概念:包(package)、堆(stack)、

  • ROS的软件以包的方式组织起来。包包含节点、ROS依赖库、数据套、配置文件、第三方软件、或者任何其他逻辑构成。包的目标是提供一种易于使用的结构以便于软件的重复使用。

  • 堆是包的集合,它提供一个完整的功能,像“navigation stack”。Stack与版本号关联,同时也是如何发行ROS软件方式的关键。ROS是一种分布式处理框架。这使可执行文件能被单独设计,并且在运行时松散耦合。这些过程可以封装到包(Packages)和堆(Stacks)中,以便于共享和分发。

图一

社区级

ROS的社区级概念是ROS网络上进行代码发布的一种表现形式。结构如下图所示:

图二

总结

目前市面上有很多ros的版本,大部分都是先在pc上安装虚拟机,然后运行ubantu环境,然后在安装ros,与机器相连很不方便,接下来的工作,有时间可以探索一下树莓派的ros安装