From shallow to deep understanding of ROS (2)

ROS File system

users can directly see the official website: Http://wiki.ros.org/ROS/Tutorials/NavigatingTheFilesystem

The two most basic concepts in the Ros File system: Package and manifest, which are packages and manifest files.

(1) The package is the most basic unit for organizing Ros code, and each package can include library files, executable files, scripts, and other files.

(2) 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.

Catkin compile the build system's function package--the compiled executable file is not stored in the Feature Pack directory, but is stored in a separate standardized directory hierarchy. For a feature pack installed with Apt-get, the root directory is/opt/ros/indigo. The executable file is stored in the Lib subdirectory under this root directory. Similarly, the auto-generated header files are stored in the include sub-directory. When needed, Ros is automatically set by Setup.bash by searching the directory listed in the CMAKE_PREFIX_PATH environment variable.

Note: You might see the concept of a Feature pack set (stack) in some documents. A Feature pack set is a collection of tightly related feature packs. Starting with the groovy version of Ros, the concept of the feature Pack set is phased out, and the meta-Feature Pack (Metapackages), which has a functional package list like any other feature pack, has no other feature pack in its directory, The feature Pack set, in turn, stores the feature packs it contains in its directory.

 Node Manager (the Master)one of the basic goals of ROS is to enable many node nodes (executables, almost independent small programs) of a robot to run simultaneously. To do this, these nodes must be able to communicate with each other. The key part of implementing communication in Ros is the ROS node manager. To start the Node Manager, use the following command: Roscore. The node manager should continue to operate throughout the entire time it takes to use ROS. A reasonable workflow is to start Roscore in one terminal and then open other terminals to run other programs. When finished, you can stop the node Manager by typing ctrl-c at the Roscore terminal. If the roscore is terminated, the other nodes that are currently running will not be able to establish a new connection, even if restarting Roscore later is useless. Roslaunch is a startup file that is designed to start multiple nodes at once. Each boot file should be associated with a specific feature pack. The usual naming scheme is to use. Launch as the suffix for the startup file. This is an adaptive tool that, if no node Manager runs when a multi-node is started, it automatically starts the Node manager, and if one node manager is already running, it will be used. Rosrun only one node can be started at a time, and roslaunch may start multiple nodes at the same time. The generic launch file is placed in the root directory of the feature Pack. In the future will be devoted to talk about Roslaunch.  node (Nodes)Once you start Roscore, you can run the ROS program. A running instance of the ROS program is called node, for example Rosrun Turtlesim turtlesim_node This node is an instantiation of the executable turtlesim_node, responsible for creating Turtlesim windows and simulating the movement of turtles. You can see that the Rosrun command has two parameters, where the first parameter is the name of the feature Pack, and the second parameter is the name of the executable file in the package. It is also important to note that registering as a ROS node through the node manager occurs inside the program, not through the Rosrun command. After starting Roscore, run rosnode list to see the node/rosout appears. Rosout The node is a special node that is Roscore Auto-start. Its use is somewhat similar to the standard output ( std::cout) used in the console program. /rosout is also a topic, and all nodes are published to the topic/rosout, which is subscribed by/rosout nodes of the same name. The purpose of this topic is to generate text log messages for each node. In some places/rosout refers to both the node and the topic. But Ros is not confused by this repetitive name, because Ros can infer from the context whether we are talking about/rosout nodes or/rosout topics.
For example, it might be better to illustrate this example in the topic and in the news.  readers also note that the name of the executable file in the Rosrun command is not necessarily the same as the node name. The node name is named in code such as Ros::init (argc, argv, "Odom"), and the executable name is named in CMakeLists.txt. However, you can use the Rosrun command to explicitly set the name of the node, with the following syntax: Rosrun package-name Executable-name _ _name:=node-name This method overrides the default name of the node with the name given by the Node-name parameter. Because ROS requires a different name for each node, this approach is important, especially in porting programs.  Topics and News
The most important mechanism used to communicate between ROS nodes is message delivery. In Ros, messages are organized in the topic. The idea of messaging is that when a node wants to share information, it publishes (publish) messages to one or more of the corresponding topics; When a node wants to receive information, it subscribes (subscribe) to one or more of the topics it needs. The ROS Node Manager is responsible for ensuring that both the publishing node and the subscription node can find each other, and that the message is passed directly from the publishing node to the subscription node, not through the node manager.

View the calculation diagram of the node composition: first introduced a tool Rqt_graph, to see the connection between the nodes, I am afraid to represent it as a graph is the most convenient to see. The simplest way to view the publish - subscribe relationship between nodes in a ROS system is to enter the terminal as ordered:rqt_graph. R stands for ros,qt refers to the Qt graphical interface (GUI) toolkit used to implement this visualizer.

In this diagram, the ellipse represents a node, and a forward edge represents a publish-subscribe relationship between its two nodes. The calculation diagram tells you that the/teleop_turtle node is released to the topic/turtle1/cmd_vel, and the/turtlesim node subscribes to these messages ("Cmd_vel" is the abbreviation for "command Velocity"). However, the debug node is omitted, including the Rosout node, because, by default, Rqt_graph hides the nodes it considers to be used only during debugging. You can disable this feature by canceling the "Hide Debug" option, which is complete:

Note that rqt_graph itself is a node. All nodes are published to the topic/rosout, which is subscribed by the/rosout node of the same name. As mentioned before, this topic is used to generate text log messages for each node, where the name/rosout refers to both the node and the topic. But Ros will not be confused by this repetitive name because Ros can infer from the context whether we are talking about/rosout nodes or/rosout topics. Unlike Ros Services,ROS nodes are often designed to publish their useful information without worrying about whether there are other nodes to subscribe to
These messages. This helps to reduce the degree of coupling between each node.

From shallow to deep understanding of ROS (2)