Ros Knowledge (2)-Understanding the structure of ROS systems

The architecture of the ROS system is mainly designed and divided into three parts, none of which represent a hierarchical concept:

• File system level (FileSystem levels)
• Calculate graph level (computaion graph Levell)
• Open Source community (Community level)

The first level is the file system level. You will use this set of concepts to understand the internal composition of Ros, the folder structure, and the core files needed to work.

The second level is the graph level, which represents the communication between the process and the system. You will see the various concepts and functions of ROS, including establishing systems, handling various processes, communicating with multiple computers, and more.

The third level is the open source community level. This level is very important because the strong support of the open source community makes Ros fast growing.

1. Understanding the Ros File system level

Just contact with Ros, which involves a lot of unfamiliar concepts, but when you understand these concepts, will be pro, feel more cordial. The file system structure of ROS is as follows:

Feature Pack: A Feature Pack is a basic form of software organization in Ros. A feature pack has minimal structure and minimal content for creating ROS programs. It can contain Ros running processes (nodes), configuration files, and so on.

Feature Pack manifest (Manifest): The Feature Pack manifest provides information about feature packs, licensing information, dependencies, compilation flags, and so on. The feature Pack manifest is a manifests.xml file that enables the management of feature packs.

Feature Pack Set (Stack): If you organize several feature packs with some functionality, you will get a set of feature packages. In the ROS system, there are a large number of different functional package sets such as the navigation feature set.

Feature Pack set manifest (Stack manifest): The Feature Pack manifest (stack.xml) provides a checklist of Feature pack sets, including license information for open source code, dependencies on other feature sets, and so on.

Message type (message/msg type): Message is the information that a process sends to other processes. There are many standard messages already defined in the ROS system, and you can also customize messages that are stored under the MSG folder of the corresponding Feature pack. The description of the message type is stored in mypackage/msg/mymessagetype.msg, which is the MSG folder corresponding to the Feature pack.

Service type (SERVICE/SRV type): A file describing the type of service, a request for service in a Ros system, and a corresponding data structure, which are stored in the mypackage/srv/ Myservicetype.srv, that is, the corresponding function can be wrapped under the SRV folder.

The following is an example diagram of a Feature Pack's file structure:

2, understanding the calculation chart level

Ros creates a network that is linked to all processes. Any node in the system can access this network and interact with other nodes through the network to obtain additional information about the node and publish its own data on the network.

The most basic concepts at this level include nodes, node managers, parameter servers, messages, services, topics, and message-logging packages. These concepts all provide data in a different way to the calculated chart level.

Node: The node is the primary calculation execution process. A feature pack can have multiple node functions, meaning that there can be multiple main portals. If you want to have a process that can interact with other nodes, you need to create a node and link the node to the ROS network. Typically, the system contains multiple nodes capable of implementing different functions, and in order to reduce the risk of the system, it is best to have a single function for each node rather than creating a large sections point for Paul Vientiane in the system. The point is that you can write programs using Ros client libraries such as roscpp (C + +) or Rospy (Python).

Node Manager (Master): Node Manager is used for node name registration and lookup, and so on. If there is no node management in your entire ROS system, there will be no communication between nodes, services, and messages. It is important to note that since Ros itself is a distributed network system, you can run the Node Manager on a single computer and run the nodes managed by that manager on other computers.

Parameter server (Parameter server): The parameter server enables data to be stored in the core of a system through keywords. By using parameters, you can configure nodes at run time or change the work tasks of the nodes.

Message: Nodes communicate with each other through messages. A message contains data information that a node sends to another node. Ros contains a variety of standard types of messages, such as integers, bytes, etc., and you can also develop custom types of messages based on standard messages.

Theme (Topic): The subject is a data bus that is managed by the ROS network for message-to-LU and message management. Each message is published to the appropriate topic. When a node sends data, we say that the node is publishing a message to the topic. A node can receive messages from other nodes by subscribing to a topic. A node can subscribe to a topic, and it does not require that the node publish the topic at the same time. This guarantees the interaction between the publisher of the message and the Subscriber, without knowing the other person's presence at all. The name of the theme must be unique, otherwise there will be an error in message routing between topics with the same name.

Service: When you publish a topic, the data being sent can interact in many-to-many ways. But when you need to get a request or answer from a node, you can't do it with a theme, in which case the service is needed and the service allows us to interact directly with a node. Additionally, the service must have a unique name. When a node provides a service, all nodes can communicate with it by using code written by the Ros client library.

Message Recorder (BAG): A message logger is a file format for saving and replaying ROS message data. A message-logging package is an important mechanism for storing data. He was able to capture and document various sensor data that were difficult to collect. We can obtain the experimental data through the message recording packet, and carry out the necessary development and algorithm testing. When experimenting with complex robots, it is often necessary to use message-logging packages.

3. Open Source Community level

Ros Knowledge (2)-Understanding the structure of ROS systems