1、机器人操作系统 ROS 1.何谓 ROS ROS 是一个机器人软件操作平台，前身由斯坦福大学 (Stanford Artificail Intelligence Laboratory)所研发。它提供一些标准操作系统服务，目前主要支持 Ubuntu 操作系统。 ROS可分为两层，低层是操作系统层，高层是实现不同功能的软件包。 2.ROS 的版本 ROS1.0 版本 叫做 Box Turtle,2010 年 3 月 2 日发布； ROS 1.1-1.2 C Turtle， 2010 年 8月 2 日发布； ROS 1.3-1.4 Diamondback,2011 年 3 月 2 日发布。 3.RO
2、S 文件系统的概念和操作 (1)ROS 文件系统的概念 Packages: 它位于 ROS 软件的最底层，可以包含任意的东西 : libraries,tools,executables,etc. Manifest: 是 package 的描述。其最重要的角色是定义 packages 之间的依赖关系（ manifest.xml）。 Stacks: 它是 package 的集合，是一个更高层的 library。 Stack Manifest: stack 的描述（ stack.xml）。 setup.sh 文件设置 ROS 工作区的环境变量。 source /setup.sh：将设置永久化。 此时
3、键入 echo $ROS_PACKAGE_PATH 指令，会看到类似于 home/user/ros_workspace:/opt/ros/electric/stacks 的路径。 （ 2） ROS 文件系统的操作 a.rospack find package name 返回指定 package 的路径（ rospack 提供与 package 相关的信息）。 b.rosstack find stack name 返回指定 stack 的路径； c.roscd 更改文件夹； d.rosls 允许根据名字而不是 package 路径直接列出 package、 stack 等的内容。 e.TAB 键
4、可以在前边有提示的情况下，代替后面的字符。 4.在工作区中创建一个新的 package 的方法 $ cd /ros_workspace /挺像 dos的 $ roscreate-pkg beginner_tutorials std_msgs rospy roscpp 5.建立一个 ROS package rosdep = ros+dep(endencies) : a tool to install package dependencies rosmake = ros+make : makes (compiles) a ROS package ROS（机器人操作系统， Robot Operati
5、ng System），是专为机器人软件开发所设计出来的一套电脑操作系统架构。它是一个开源的元级操作系统（后操作系统），提供类似于操作系统的服务，包括硬件抽象描述、底层驱动程序管理、共用功能的执行、程序间消息传递、程序发行包管理，它也提供一些工具和库用于获取、建立、编写和执行多机融合的程序。 ROS的运行架构是一种使用 ROS通信模块实现模块间 P2P的松耦合的网络连接的处理架构，它执行若干种类型的通讯，包括基于服务的同步 RPC（远程过程调用）通讯、基于 Topic 的异步数据流通讯，还有参数服务器上的数据存储。 发展目标 ROS 的首要设计目标是在机器人研发领域提高代码复用率。 ROS 是一
6、种分布式处理框架（又名 Nodes）。这使可执行文件能被单独设计，并且在运行时松散耦合。这些过程可以封装到数据包（ Packages）和堆栈（ Stacks）中，以便于共享和分发。 ROS 还支持代码库的联合系统。使得协作亦能被分发。这种从文件系统级别到社区一级的设计让独立地决定发展和实施工作成为可能。上述所有功能都能由 ROS 的基础工具实现。 为了实现“共享与协作”这一首要目标，人们制订了 ROS 架构中的其他支援性目标： “轻便”： ROS 是设计得尽可能方 便简易。您不必替换主框架与系统，因为 ROS 编写的代码可以用于其他机器人软件框架中。毫无疑问的， ROS 更易于集成与其他机器人
7、软件框架。事实上 ROS 已完成与 OpenRAVE、 Orocos 和 Player 的整合。 ROS-agnostic 库：【 agnostic：不可知论】建议的开发模型是使用 clear 的函数接口书写ROS-agnostic 库。 语言独立性： ROS 框架很容易在任何编程语言中执行。我们已经能在 Python 和 C+中顺利运行，同时添加有 Lisp、 Octave 和 Java 语言库。 测试简单： ROS 有 一个内建的单元 /组合集测试框架，称为“ rostest”。这使得集成调试和分解调试很容易。 扩展性： ROS 适合于大型实时系统与大型的系统开发项目。 ROS 的概念 R
8、OS 有三个层次的概念：分别为 Filesystem level， Computation graph level， 以及Communication level。 以下内容具体的总结了这些层次及概念。除了这三个层次的概念， ROS 也定义了两种名称 - Package 资源名称和 Graph 资源名称。同样会在以下内容中提及。 ROS 的 Filesystem Level 文件系统层概念就是你在碟片里面遇到的资源，例如： Packages： ROS 的基本组织，可以包含任意格式文件。一个 Package 可以包含 ROS 执行时处理的文件（ nodes），一个 ROS 的依赖库，一个数据集合，
9、配置文件或一些有用的文件在一起。 Manifests： Manifests (manifest.xml) 提供关于 Package 元数据，包括它的许可信息和 Package之间依赖关系，以及语言特性信息像编译旗帜（编译优化参数）。 Stacks: Stacks 是 Packages 的集合，它提供一个完整的功能，像“ navigation stack” Stack 与版本号关联，同时也是如何发行 ROS 软件方式的关键。 Manifest Stack Manifests: Stack manifests (stack.xml) 提供关于 Stack 元数据，包括它的许可信息和 Stack 之
10、间依赖关系。 Message (msg) types: 信息描述 , 位置在路径： my_package/msg/MyMessageType.msg, 定义数据类型在 ROS 的 messages ROS里面。 Service (srv) types: 服务描述 ,位置在路径： my_package/srv/MyServiceType.srv, 定义这个请求和相应的数据结构 在 ROS services 里面。 ROS 的 Computation Graph Level Computation Graph Level（计算图）就是用 ROS 的 P2P（ peer-to-peer 网络传输协议
11、）网络集中处理所有的数据。基本的 Computation Graph 的概念包括 Node， Master， Parameter Sever， messages, services, topics， 和 bags， 以上所有的这些都以不同的方式给 Graph 传输数据。 Nodes: Nodes（节点）是一系列运行中的程序。 ROS 被设计成在一定颗粒度下的模块化系统。一个机器人控制系统通常包含许多 Nodes。比如一个 Node 控制激光雷达，一个 Node 控制车轮马达，一个 Node 处理定位，一个 Node 执行路径规划，另外一个提供图形化界面等等。一个 ROS 节点是由 Librar
12、ies ROS client library 写成的 , 例如 roscpp 和 rospy. Master: ROS Master 提供了登记列表和对其他计算图的查找。没有 Master，节点将无法找到其他节点，交换消息或调用服务。 Server Parameter Server: 参数服务器使数据按照钥匙的方式存储。目前，参数服务器是主持的组成部分。 Messages:节点之间通过 messages 来传递消息。一个 message 是一个简单的数据结构，包含一些归类定义的区。支持标准的原始数据类型（整数、浮点数、布尔数，等）和原始数组类型。 message 可以包 含任意的嵌套结构和数组
13、（很类似于 C语言的结构 structs） Topics: Messages 以一种发布 /订阅的方式传递。一个 node 可以在一个给定的 topic 中发布消息。 Topic 是一个 name 被用于描述消息内容。一个 node 针对某个 topic 关注与订阅特定类型的数据。可能同时有多个 node 发布或者订阅同一个 topic 的消息；也可能有一个 topic 同时发布或订阅多个 topic。总体上，发布者和订阅者不了解彼此的存在。主要的概念在于将信息的发布者和需求者解耦、分离。逻辑上， topic 可以看作是一个严格规范 化的消息 bus。每个 bus 有一个名字，每个 node
14、都可以连接到 bus 发送和接受符合标准类型的消息。 Services:发布 /订阅模型是很灵活的通讯模式，但是多对多，单向传输对于分布式系统中经常需要的“请求 /回应”式的交互来说并不合适。因此，“请求 /回应” 是通过 services 来实现的。这种通讯的定义是一种成对的消息：一个用于请求，一个用于回应。假设一个节点提供了一个服务提供下一个 name 和客户使用服务发送请求消息并等待答复。 ROS 的客户库通常以一种远程调用的方式提供这样的交互。 Bags: Bags 是一种格式，用于存储和播放 ROS 消息。对于储存数据来说 Bags 是一种很重要的机制。例如传感器数据很难收集但却是开
15、发与测试中必须的。 在 ROS 的计算图中， ROS的 Master 以一个 name service 的方式工作。它给 ROS 的节点存储了 topics 和 service 的注册信息。 Nodes 与 Master 通信从而报告它们的注册信息。当这些节点与 master 通信的时候，它们可以接收关于其他以注册节点的信息并且建立与其它以注册节点之间的联系。当这些注册信息改变时 Master 也会回馈这些节点，同时允许节点动态创建 与新节点之间的连接。 节点之间的连接是直接的； Master 仅仅提供了查询信息，就像一个 DNS 服务器。节点订阅一个 topic 将会要求建立一个与发布该 t
16、opics 的节点的连接，并且将会在同意连接协议的基础上建立该连接。 ROS里面使用最广的连接协议是 TCPROS，这个协议使用标准的 TCP/IP 接口。 这样的架构允许脱钩工作（ decoupled operation），通过这种方式大型或是更为复杂的系统得以建立，其中 names方式是一种行之有效的手段。 names 方式在 ROS 系统中扮演极为重要的角色： topics, services, and parameters 都有各自的 names。每一个 ROS 客户端库都支持重命名，这等同于，每一个编译成功的程序能够以另一种形似【名字】运行。 例如，为了控制一个北阳激光测距仪（ Ho
17、kuyo laser range-finder），我们可以启动这个hokuyo_node 驱动，这个驱动可以给与激光仪进行对话并且在 “扫描 “topic 下可以发布sensor_msgs/LaserScan 的信息。为了处理数据，我们也许会写一个使用 laser_filters 的 node来订阅 “扫描 “topic 的信息。订阅之后，我们的过滤器将会自动开始接收激光仪的信息。 注意两边是如何脱钩工作的。 所有的 hokuyo_node 的节点都会完成发布 “扫描 “，不需要知道是否有节点被订阅了。所有的过滤器都会完成 “扫描 “的订阅，不论知道还是不知道是否有节点在发布 “扫描 “。 在不引发任何错误的情况下，这两个 nodes 可以任何的顺序启动，终止，或者重启。 以后我们也许会给我们的机器人加入另外一个激光器，这会导致我们重新设置我们的系统。我们所需要做的就是重新映射已经使用过的 names。当我们开始我们的第一个 hokuyo_node时，我们可以说它用 base_scan 代替了映射扫描，并且和我们的过滤器节点做相同的事。现在，这些节点将会用 base_scan的 topic来通信从而代替 ,并且将不再监听 “扫描 “topic的信息。然后我们就可以为我们的新激光测距仪启动另外一个 hokuyo_node。
