ROS
ROS is a robot software platform similar to an operating system for developing robot applications. ROS provides hardware abstraction, sub-device control, and sensing, recognition, drawing, motion planning and other functions that are widely used in robot engineering. In addition, ROS also provides message parsing between processes, function package management, libraries, and rich development and debugging tools.
Master node
The master node (master) 2 is responsible for node-to-node connection and message communication, similar to a name server (Name Server). roscore is its running command. When you run the master node, you can register the name of each node and obtain information as needed. Without the master node, access and message exchange (such as topics and services) cannot be established between nodes. The master node uses XML remote procedure call (XMLRPC, XML-Remote Procedure Call) 3 to communicate with the node. XMLRPC is an HTTP-based protocol. The master node does not maintain a connection with the nodes connected to the master node. In other words, a node can only visit the master node and obtain information when it needs to register its own information or send request information to other nodes. Normally, the connection status of each other is not checked. Because of these characteristics, ROS can be used in very large and complex environments. XMLRPC is also very light and supports multiple programming languages, making it very suitable for ROS supporting various hardware and languages.
When ROS is started, the master node will obtain the URI address and port listed in the ROS_MASTER_URI variable set by the user. Unless otherwise set, by default, the URI address uses the current local IP and the port uses 11311.
node
Node 4 refers to the smallest processor unit running in ROS. Think of it as an executable program. In ROS, it is recommended to create a node for a purpose, and it is recommended to pay attention to reusability when designing. For example, in the case of a mobile robot, in order to drive the robot, each program is subdivided. In other words, multiple subdivision nodes such as sensor drive, sensor data conversion, obstacle judgment, motor drive, encoder input and navigation are used. While the node is running, register the name of the node with the master node, and also register the names of the publisher, subscriber, service server, and service client, and register the message form , URI address and port. Based on this information, each node can exchange messages with other nodes using topics and services. Nodes use XMLRPC to communicate with the master station, and use TCP/IP communication series XMLRPC or TCPROS5 for communication between nodes. The connection request and response between nodes uses XMLRPC, and the message communication uses TCPROS, because it is a direct communication between nodes and has nothing to do with the master node. The URI address and port use the environment variable named ROS_HOSTNAME stored on the computer running the current node as the URI address, and set the port to any inherent value.
Feature pack
The package 6 is the basic unit of ROS. ROS applications are developed in units of functional packages. The function package includes at least one node or a configuration file of a node for running other function packages. It also contains all the files required by the feature pack, such as ROS dependency libraries, data sets, and configuration files for running various processes. The current number of official function packages registered as of July 2017: ROS Indigo up to about 2500 (http:// repositories.ros.org/status_page/ ros_indigo_default.html), ROS Kinetic up to about 1600 ( http://repositories.ros.org/status_page/ros_kinetic_default.html). In addition, although there will be some repetitions in the function packages developed and shared by users, there are also about 4600 (http://rosindex.github.io/stats/).
news
The nodes send and receive data through messages 8. Messages are variables of types such as integer, floating point, and boolean. Users can also use simple data structures such as a message including a message or a message array structure that enumerates the messages. Communication methods using messages include TCPROS, UDPROS, etc. According to the situation, one-way message sending/receiving topic (topic) and two-way message request (request)/response (service) are used.
topic
A topic is a "story". After the publisher node registers with the master node about the story, it publishes an advertisement about the story in the form of a message. The subscriber node wishing to receive the story obtains the information of the publisher node registered with this topic in the master node. Based on this information, the subscriber node directly connects to the publisher node, and uses topics to send and receive messages.
Publish and Publisher
Publish refers to sending data in the form of a message corresponding to the content of the topic. In order to perform publishing, the publisher node registers its own topic and other information on the master node, and sends messages to subscriber nodes that wish to subscribe. The publisher declares in the node that he is the individual who executes the publication. A single node can become multiple publishers.
Subscribers and subscribers
Subscription refers to receiving data in the form of messages corresponding to the topic content. In order to perform the subscription, the subscriber node registers its own topic and other information on the master node, and receives from the master node the information of the publisher nodes that publish the topics that the node wants to subscribe to. Based on this information, the subscriber node directly contacts the publisher node to receive the message. The subscriber declares the individual who performs the subscription in the node. A single node can become multiple subscribers.
The topic in the publish and subscribe concept is asynchronous, which is a good way to send and receive data as needed. In addition, since it sends and receives continuous messages through a single connection, it is often used for sensor data that must send messages continuously. However, in some cases, a synchronous message exchange scheme that uses requests and responses together is required. Therefore, ROS provides a message synchronization method called service. Services are divided into service servers that respond to requests and service clients that receive responses after the request. Unlike topics, services are a one-time message communication. When the service request and response are completed, the connection between the two nodes is disconnected.
service
Service message communication is a synchronous two-way message communication between a service client and a service server. Among them, the service client requests the service corresponding to the specific purpose task, and the service server is responsible for the service response.
action
Action is a message communication method used when a two-way request like a service is required. The difference is that a long response is required after the request is processed, and the value needs to be fed back in the middle. Action files are also very similar to services, with goals and results corresponding to requests and responses. In addition, a feedback corresponding to halfway has been added. It consists of an action client that sets a goal and an action server. The action server executes actions based on the goal and sends feedback and results. Asynchronous two-way message communication between the action client and the action server.
parameter
The parameter in ROS refers to the parameter used in the node. Think of it as a *.ini configuration file in a Windows program. These parameters are set by default and can be read or written from the outside as needed. Especially, it can change the setting value in real time by using the external write function, so it is very useful. For example, you can specify settings such as the USB port of the PC connected to the external device, the camera calibration value, the motor speed, or the maximum and minimum values of the command.