reprinted from Ancient-month: http://blog.csdn.net/hcx25909
Little rookie Colonel: Http://blog.csdn.net/xiaocainiaoshangxiao
first, the overall structureAccording to the maintainer and distribution of the ROS system code, there are two main parts: (1) Main: Core, mainly by Willow Garage Company and some developers to design, provide and maintain. It provides some basic tools for distributed computing, as well as programming the core parts of the entire Ros. (2) Universe: Worldwide code, developed and maintained by Ros community organizations in different countries. One is the code of the library, such as OPENCV, PCL, etc. the upper layer of the library is the code provided from a functional perspective, such as face recognition, they call the underlying library; The topmost code is the application-level code that allows the robot to complete a certain function. In general, there are three levels of ROS grading from another point of view: Compute graph level, file system level, community level.
second, calculate the chart levelThe calculation diagram is a kind of point-to-point network form of ROS processing data. When the program runs, all processes and the data processing they perform will be represented by a point-to-point network. This level includes several key concepts: node, message, Subject (topic), Service.
(1) nodeA node is a process of some straight-line computing tasks. The way Ros leverages scale is code modularity: A system is typically made up of a number of nodes. In this case, a node can also be called a "software module". We use "nodes" to make Ros-based systems more visualized at runtime: when many nodes are running at the same time, it is convenient to draw end-to-end communication as a graph, in which the process is the node in the graph, and the end-to-end connection is where the arc is connected.(2) NewsThe nodes are communicated by sending messages. Every message is a strict data structure. The original standard data types (integer, float, Boolean, and so on) are supported and also support the original array type. Messages can contain arbitrary nested structures and arrays (very similar to the C-language structure structs).
(3) Theme
Messages are passed in a publish/subscribe manner. A node can publish messages in a given topic. A node focuses on and subscribes to specific types of data for a topic. There may be multiple nodes publishing or subscribing to a message on the same topic. In general, publishers and subscribers do not understand each other's existence.(4) ServiceAlthough the topic-based publish/subscribe model is a flexible mode of communication, its broadcast path planning is not suitable for synchronous transmission modes that simplify node design. In Ros, we call it a service, defined by a string and a pair of strictly canonical messages: one for the request and one for the response. This is similar to a Web server, where a Web server is defined by URIs with a fully defined type of request and reply document. It is important to note that, unlike the topic, only one node can broadcast a service in any unique name: Only one service can be called a "classification symbol", for example, any given URI address can have only one Web server.
On the basis of the above concept, a controller is needed to enable all nodes to be executed methodically, which is a Ros controller (Ros Master). ROS Master provides a list of registrations and lookups of other calculated charts via RPC (remote Procedure call Protocol, a remoting procedure invocation). Without a controller, the node will not be able to find other nodes, exchange messages, or invoke services.
For example, the model for controlling node subscriptions and publishing messages is as follows:
The ROS controller stores registration information for the subject and services for the ROS node. Nodes communicate with the controller to report their registration information. When these nodes communicate with the controller, they can receive information about other registers and nodes and establish a connection with other registered nodes. The controller also feeds back these nodes when these registration information changes, allowing the node to dynamically create a connection to the new node.
The connection between the node and the node is straightforward, and the controller provides only the query information, just like a DNS server. Node subscription a topic will require a connection to the node that publishes the topic, and the connection will be established on the basis of the consent Connection Agreement. Another: Ros Controller control Services:
third, the file system levelThe Ros file system level refers to the form of Ros source code that is viewed on the hard disk.
There are countless nodes, messages, services, tools, and library files in Ros that require an effective structure to manage the code. At the file system level of ROS, there are several key concepts: Package, heap (stack),(1) package
The Ros software is organized in a package way. A package contains nodes, Ros dependent libraries, data sets, configuration files, third-party software, or any other logical composition. The goal of the package is to provide an easy-to-use structure to facilitate software reuse. In a sense, the Ros pack is short and lean.(2) Heap
A heap is a collection of packages that provides a complete set of functions, like the "Navigation stack". The stack is associated with the version number, and is the key to how the Ros software is distributed.
Ros is a distributed processing framework. This enables executables to be individually designed and loosely coupled at run time. These procedures can be encapsulated in packages (Packages) and heaps (Stacks) for easy sharing and distribution. The following figure is a concrete structure in the package and heap in the file: Manifests (manifest.xml): Provides information about the packages metadata, including its license information and the dependencies between the packs, as well as the language feature info like the Compile banner (compilation optimization parameters).
Stack manifests (stack.xml): Provides information about the stack metadata, including its permissions and the dependencies between the stacks.
Iv. Community-levelThe community-level concept of ROS is a manifestation of code publishing on Ros networks. The structure is shown in the following figure:
A federated system of code libraries. So that collaboration can also be distributed. This design from the file system level to the community level makes it possible to independently develop and implement work. Because of this distributed structure, the rapid development of ROS, the number of packets in the software warehouse increased exponentially.
The two most basic concepts in the Ros File system: Package and manifest, which are packages and manifest files.
The package is the most basic unit for organizing Ros code, and each package can include library files, executable files, scripts, and some other files.
The manifest file is a description of the package's related information. He provides the dependencies between packages, as well as the meta-information of a package, such as version, maintenance, and licensing information.
The file system provides several useful command-line tools that are designed to operate on Ros file systems.
Rospack is used to get information about a package, which only describes its find options, as follows: [HTML] view plain Copy # rospack find [package_name]
[HTML] view plain copy you can enter the following command in a newly opened terminal: [HTML] view plain copy rospack find Roscpp
You can find the location information for the Roscpp package, which may return a result similar to the following: [HTML] view plain copy/opt/ros/hydro/share/roscpp
The ROSCD command allows you to use the name of the package to switch directly to the appropriate file directory, which is, of course, used by the Ros file system as follows:
[HTML] view plain copy roscd [Locationname[/subdir]
For example, enter directly in the terminal: [HTML] view plain copy roscd Roscpp
You can switch directly to the directory of the Roscpp file, which can be verified using the following command: [HTML] view plain copy pwd
The returned result is similar to the following form: [HTML] view plain copy/opt/ros/hydro/share/roscpp
ROSCD will only open directories and subdirectories that exist with the environment variable Ros_package_path, you can use the following command to view the contents of the Ros_package_path:
[HTML] view Plain