Contents
ROS的概念分為三個層次：文件系统层、计算图层、社区层，這些層次以及概念將會在接下來的章節介紹。
除了这三个层次的概念，ROS同样定义两个names类型，Package Resource Names and Graph Resource Names -- 下面会讨论
注意：从ROS Groovy开始，这些wiki页面介绍的概念针对新的构建系统catkin，针对旧版本的ROS使用rosbuild构建系统，查阅： rosbuild/ROS/Concepts
ROS文件系统层次
文件系统层概念主要指在硬盘里能看到的ROS目录和文件, 例如：
Packages: Packages是在ROS中整理及組織軟體的主要單元。一個Packages包含節點（ROS runtime processes）、ROS程式庫（ROS-dependent library）、數據集（datasets）、配置文件（configuration files）⋯⋯等等。Packages是您在ROS中能建立及分享的最小單元。
Metapackages: Metapackages 是一组具体的服务相关的功能包。大部分的metpackages 只作为转换rosbuild Stacks的向后兼容的备选。
Package Manifests: Manifests (package.xml) 描述一个package的元信息，包括了package的名字，版本，功能简述，证书信息，依赖关系，以及一些其他的被export的package所有的信息。关于package.xml 的文件说明，参考REP-0127.
Repositories: 代码仓库是使用VCS版本控制系统的软件包集合，软件包利用版本控制维持同一版本，它能使用catkin自动发布工具bloom进行发布。这些代码仓库常通过映射来进行转换 rosbuild Stacks.仓库可以是只有一个软件包。
Message (msg) types: 存储在my_package/msg/MyMessageType.msg的Message文件，主要定义了ROS系统的messages传输的数据结构。
Service (srv) types: 存储在 my_package/srv/MyServiceType.srv的服务services文件，定义了ROS的服务通信时的请求（request ）和响应（response ）相关的数据结构。
ROS计算图层次
计算图是ROS在点对点网络里整合并处理数据的过程。基本计算图概念是 节点, 主机, 参数服务器, 消息, 服务, 话题, and 数据包，它们通过不同的方式提供数据给图层。
这些概念是在ros_comm库里实现的
Nodes: 节点主要执行计算处理 。ROS被设计为细粒度的模块化的系统;一个机器人控制系统通常有很多节点组成 。例如，一个节点控制激光测距仪，一个节点控制轮电机，一个节点执行定位，一个节点执行路径规划，一个节点提供系统图形界面，等等。一个ROS节点通过ROS客户端库 client library编写，例如 roscpp o或rospy
Master: The ROS Master provides name registration and lookup to the rest of the Computation Graph. Without the Master, nodes would not be able to find each other, exchange messages, or invoke services.
Parameter Server: The Parameter Server allows data to be stored by key in a central location. It is currently part of the Master.
Messages: Nodes communicate with each other by passing messages. A message is simply a data structure, comprising typed fields. Standard primitive types (integer, floating point, boolean, etc.) are supported, as are arrays of primitive types. Messages can include arbitrarily nested structures and arrays (much like C structs).
Topics: Messages are routed via a transport system with publish / subscribe semantics. A node sends out a message by publishing it to a given topic. The topic is a name that is used to identify the content of the message. A node that is interested in a certain kind of data will subscribe to the appropriate topic. There may be multiple concurrent publishers and subscribers for a single topic, and a single node may publish and/or subscribe to multiple topics. In general, publishers and subscribers are not aware of each others' existence. The idea is to decouple the production of information from its consumption. Logically, one can think of a topic as a strongly typed message bus. Each bus has a name, and anyone can connect to the bus to send or receive messages as long as they are the right type.
Services: The publish / subscribe model is a very flexible communication paradigm, but its many-to-many, one-way transport is not appropriate for request / reply interactions, which are often required in a distributed system. Request / reply is done via services, which are defined by a pair of message structures: one for the request and one for the reply. A providing node offers a service under a name and a client uses the service by sending the request message and awaiting the reply. ROS client libraries generally present this interaction to the programmer as if it were a remote procedure call.
Bags: Bags are a format for saving and playing back ROS message data. Bags are an important mechanism for storing data, such as sensor data, that can be difficult to collect but is necessary for developing and testing algorithms.
The ROS Master acts as a nameservice in the ROS Computation Graph. It stores topics and services registration information for ROS nodes. Nodes communicate with the Master to report their registration information. As these nodes communicate with the Master, they can receive information about other registered nodes and make connections as appropriate. The Master will also make callbacks to these nodes when this registration information changes, which allows nodes to dynamically create connections as new nodes are run.
Nodes connect to other nodes directly; the Master only provides lookup information, much like a DNS server. Nodes that subscribe to a topic will request connections from nodes that publish that topic, and will establish that connection over an agreed upon connection protocol. The most common protocol used in a ROS is called TCPROS, which uses standard TCP/IP sockets.
This architecture allows for decoupled operation, where the names are the primary means by which larger and more complex systems can be built. Names have a very important role in ROS: nodes, topics, services, and parameters all have names. Every ROS client library supports command-line remapping of names, which means a compiled program can be reconfigured at runtime to operate in a different Computation Graph topology.
For example, to control a Hokuyo laser range-finder, we can start the hokuyo_node driver, which talks to the laser and publishes sensor_msgs/LaserScan messages on the scan topic. To process that data, we might write a node using laser_filters that subscribes to messages on the scan topic. After subscription, our filter would automatically start receiving messages from the laser.
Note how the two sides are decoupled. All the hokuyo_node node does is publish scans, without knowledge of whether anyone is subscribed. All the filter does is subscribe to scans, without knowledge of whether anyone is publishing them. The two nodes can be started, killed, and restarted, in any order, without inducing any error conditions.
Later we might add another laser to our robot, so we need to reconfigure our system. All we need to do is remap the names that are used. When we start our first hokuyo_node, we could tell it instead to remap scan to base_scan, and do the same with our filter node. Now, both of these nodes will communicate using the base_scan topic instead and not hear messages on the scan topic. Then we can just start another hokuyo_node for the new laser range finder.
ROS Community Level
The ROS Community Level concepts are ROS resources that enable separate communities to exchange software and knowledge. These resources include:
Distributions: ROS Distributions are collections of versioned stacks that you can install. Distributions play a similar role to Linux distributions: they make it easier to install a collection of software, and they also maintain consistent versions across a set of software.
Repositories: ROS relies on a federated network of code repositories, where different institutions can develop and release their own robot software components.
The ROS Wiki: The ROS community Wiki is the main forum for documenting information about ROS. Anyone can sign up for an account and contribute their own documentation, provide corrections or updates, write tutorials, and more.
Bug Ticket System: Please see Tickets for information about file tickets.
Mailing Lists: The ros-users mailing list is the primary communication channel about new updates to ROS, as well as a forum to ask questions about ROS software.
ROS Answers: A Q&A site for answering your ROS-related questions.
Blog: The Willow Garage Blog provides regular updates, including photos and videos.
Contents
Names
Graph Resource Names
Graph Resource Names provide a hierarchical naming structure that is used for all resources in a ROS Computation Graph, such as Nodes, Parameters, Topics, and Services. These names are very powerful in ROS and central to how larger and more complicated systems are composed in ROS, so it is critical to understand how these names work and how you can manipulate them.
Before we describe names further, here are some example names:
/ (the global namespace)
/foo
/stanford/robot/name
/wg/node1
Graph Resource Names are an important mechanism in ROS for providing encapsulation. Each resource is defined within a namespace, which it may share with many other resources. In general, resources can create resources within their namespace and they can access resources within or above their own namespace. Connections can be made between resources in distinct namespaces, but this is generally done by integration code above both namespaces. This encapsulation isolates different portions of the system from accidentally grabbing the wrong named resource or globally hijacking names.
Names are resolved relatively, so resources do not need to be aware of which namespace they are in. This simplifies programming as nodes that work together can be written as if they are all in the top-level namespace. When these Nodes are integrated into a larger system, they can be pushed down into a namespace that defines their collection of code. For example, one could take a Stanford demo and a Willow Garage demo and merge them into a new demo with stanford and wg subgraphs. If both demos had a Node named 'camera', they would not conflict. Tools (e.g. graph visualization) as well as parameters (e.g. demo_name) that need to be visible to the entire graph can be created by top-level Nodes.
Valid Names
A valid name has the following characteristics:
First character is an alpha character ([a-z|A-Z]), tilde (~) or forward slash (/)
Subsequent characters can be alphanumeric ([0-9|a-z|A-Z]), underscores (_), or forward slashes (/)
Exception: base names (described below) cannot have forward slashes (/) or tildes (~) in them.
Here are some regexps to validate a name:
(?=.*[A-z0-9_]$)^[/~A-z][A-z0-9_/]*$
^[A-z][A-z0-9_]*$ (for a base name)
Resolving
There are four types of Graph Resource Names in ROS: base, relative, global, and private, which have the following syntax:
base
relative/name
/global/name
~private/name
By default, resolution is done relative to the node's namespace. For example, the node /wg/node1 has the namespace /wg, so the name node2 will resolve to /wg/node2.
Names with no namespace qualifiers whatsoever are base names. Base names are actually a subclass of relative names and have the same resolution rules. Base names are most frequently used to initialize the node name.
Names that start with a "/" are global -- they are considered fully resolved. Global names should be avoided as much as possible as they limit code portability.
Names that start with a "~" are private. They convert the node's name into a namespace. For example, node1 in namespace /wg/ has the private namespace /wg/node1. Private names are useful for passing parameters to a specific node via the parameter server.
Here are some name resolution examples:
Node |
Relative (default) |
Global |
Private |
/node1 |
bar -> /bar |
/bar -> /bar |
~bar -> /node1/bar |
/wg/node2 |
bar -> /wg/bar |
/bar -> /bar |
~bar -> /wg/node2/bar |
/wg/node3 |
foo/bar -> /wg/foo/bar |
/foo/bar -> /foo/bar |
~foo/bar -> /wg/node3/foo/bar |
Remapping
Any name within a ROS Node can be remapped when the Node is launched at the command-line. For more information on this feature, see Remapping Arguments.
Package Resource Names
Package Resource Names are used in ROS with Filesystem-Level concepts to simplify the process of referring to files and data types on disk. Package Resource Names are very simple: they are just the name of the Package that the resource is in plus the name of the resource. For example, the name "std_msgs/String" refers to the "String" message type in the "std_msgs" Package.
Some of the ROS-related files that may be referred to using Package Resource Names include:
Package Resource Names are very similar to file paths, except they are much shorter. This is due to the ability of ROS to locate Packages on disk and make additional assumptions about their contents. For example, Message descriptions are always stored in the msg subdirectory and have the .msg extension, so std_msgs/String is shorthand for path/to/std_msgs/msg/String.msg. Similarly, the Node type foo/bar is equivalent to searching for a file named bar in Package foo with executable permissions.
Valid Names
Package Resource Names have strict naming rules as they are often used in auto-generated code. For this reason, a ROS package cannot have special characters other than an underscore, and they must start with an alphabetical character. A valid name has the following characteristics:
- First character is an alpha character ([a-z|A-Z])
Subsequent characters can be alphanumeric ([0-9|a-z|A-Z]), underscores (_) or a forward slash (/)
- There is at most one forward slash ('/').
Code API
roscpp::names API reference (ROS Noetic)