ROS architecture (two)-calculation graph
table of Contents
From the perspective of computational graphs, the functional modules of the ROS system software run independently in units of nodes, can be distributed in multiple same or different hosts, and are connected through an end-to-end topology when the system is running. Computational graph is a point-to-point network form of ROS processing data. When the program is running, all processes and their data processing will be expressed through a point-to-point network. This level mainly includes several important concepts: node (node), message (message), topic (topic), service (service).
1. Node
Nodes are processes that go straight to computing tasks. The way ROS can grow in scale is code modularization: a system is typically composed of many nodes. Here, nodes can also be referred to as "software modules". We use "nodes" to make the ROS-based system more visual when it is running: when many nodes are running at the same time, it is easy to draw the end-to-end communication into a graph, in this graph, the process is the node in the graph , And the end-to-end connection relationship is the arc connection. In robot applications, multiple functions need to be coordinated. For example, the control of a robotic arm needs to first obtain information processed by a vision sensor. In the application, each node should maintain a brief introduction, each node corresponds to a function, do not pursue big and comprehensive.
2. News
The nodes communicate by sending messages. Every message is a strict data structure. The original standard data types (integer, floating point, boolean, etc.) are all supported, and primitive array types are also supported. Messages can contain arbitrary nested structures and arrays (much like C language structure structs). ROS Master provides registration and search for the name of the node. If there is no Master process, the node will not be able to find the object to be communicated and the service to be called. In distributed system applications, the Master process should be run on one of the computers, and the remaining nodes communicate through this Master.
3. Topic
Topic is the way all ROS nodes transmit data. Nodes send messages through Topic (the node publishes a topic), and nodes also receive messages through topic (the node subscribes to a topic). The relationship between them is similar to the communication between students through small notes, each student (Node) can write or read messages (Message) on the small notes (Topic). There is no other connection between nodes. As long as the message type is correct, data can be sent and read through topic. Messages are delivered in a publish/subscribe manner. A node can publish messages in a given topic. A node pays attention to and subscribes to a specific type of data for a certain topic. There may be multiple nodes publishing or subscribing to the same topic at the same time. In general, publishers and subscribers do not understand each other's existence.
4. Service
In some robot applications, the simple publish/subscribe mechanism of communication is not appropriate. For this purpose, Services is for applications that require a request/response mechanism, allowing one node to call another node to perform a specific function and task. Although the topic-based publish/subscribe model is a very flexible communication mode, its broadcast path planning is not suitable for the synchronous transmission mode that can simplify node design. In ROS, we call it a service, which is defined by a string and a pair of strictly standardized messages: one for request and one for response. This is similar to a web server. The web server is defined by URIs, with complete defined types of request and response documents. It should be noted that, unlike topics, only one node can broadcast a service with any unique name: only one service can be called a "category symbol", for example, any given URI address can only have one web server.
5. Node Manager
ROS Master provides registration lists and search for other calculation charts through RPC (Remote Procedure Call Protocol). Without the controller, the node will not be able to find other nodes, exchange messages or call services.
