Learning ROS for Robotics Programming（Second Edition）
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

Understanding the ROS Computation Graph level

ROS creates a network where all the processes are connected. Any node in the system can access this network, interact with other nodes, see the information that they are sending, and transmit data to the network:

Understanding the ROS Computation Graph level

The basic concepts in this level are nodes, the master, Parameter Server, messages, services, topics, and bags, all of which provide data to the graph in different ways and are explained in the following list:

  • Nodes: Nodes are processes where computation is done. If you want to have a process that can interact with other nodes, you need to create a node with this process to connect it to the ROS network. Usually, a system will have many nodes to control different functions. You will see that it is better to have many nodes that provide only a single functionality, rather than have a large node that makes everything in the system. Nodes are written with a ROS client library, for example, roscpp or rospy.
  • The master: The master provides the registration of names and the lookup service to the rest of the nodes. It also sets up connections between the nodes. If you don't have it in your system, you can't communicate with nodes, services, messages, and others. In a distributed system, you will have the master in one computer, and you can execute nodes in this or other computers.
  • Parameter Server: Parameter Server gives us the possibility of using keys to store data in a central location. With this parameter, it is possible to configure nodes while it's running or to change the working of the nodes.
  • Messages: Nodes communicate with each other through messages. A message contains data that sends information to other nodes. ROS has many types of messages, and you can also develop your own type of message using standard messages.
  • Topics: Each message must have a name to be routed by the ROS network. When a node is sending data, we say that the node is publishing a topic. Nodes can receive topics from other nodes simply by subscribing to the topic. A node can subscribe to a topic, and it isn't necessary that the node that is publishing this topic should exist. This permits us to decouple the production from the consumption. It's important that the name of the topic be unique to avoid problems and confusion between topics with the same name.
  • Services: When you publish topics, you are sending data in a many-to-many fashion, but when you need a request or an answer from a node, you can't do it with topics. Services give us the possibility of interacting with nodes. Also, services must have a unique name. When a node has a service, all the nodes can communicate with it, thanks to ROS client libraries.
  • Bags: Bags are a format to save and play back the ROS message data. Bags are an important mechanism to store data, such as sensor data, that can be difficult to collect but is necessary to develop and test algorithms. You will use bags a lot while working with complex robots.

In the following figure, you can see the graphic representation of this level. It represents a real robot working in real conditions. In the graph, you can see the nodes, the topics, which node is subscribed to a topic, and so on. This graph does not represent messages, bags, Parameter Server, and services. It is necessary for other tools to see a graphic representation of them. The tool used to create the graph is rqt_graph; you will learn more about it in Chapter 3, Visualization and Debug Tools.

These concepts are implemented in the ros_comm repository.

Understanding the ROS Computation Graph level

Nodes and nodelets

Nodes are executables that can communicate with other processes using topics, services, or the Parameter Server. Using nodes in ROS provides us with fault tolerance and separates the code and functionalities, making the system simpler.

ROS has another type of node called nodelets. These special nodes are designed to run multiple nodes in a single process, with each nodelet being a thread (light process). This way, we avoid using the ROS network among them but permit communication with other nodes. With that, nodes can communicate more efficiently, without overloading the network. Nodelets are especially useful for camera systems and 3D sensors, where the volume of data transferred is very high.

A node must have a unique name in the system. This name is used to permit the node to communicate with another node using its name without ambiguity. A node can be written using different libraries, such as roscpp and rospy; roscpp is for C++ and rospy is for Python. Throughout this book, we will use roscpp.

ROS has tools to handle nodes and give us information about it, such as rosnode. The rosnode tool is a command-line tool used to display information about nodes, such as listing the currently running nodes. The supported commands are as follows:

  • rosnode info NODE: This prints information about a node
  • rosnode kill NODE: This kills a running node or sends a given signal
  • rosnode list: This lists the active nodes
  • rosnode machine hostname: This lists the nodes running on a particular machine or lists machines
  • rosnode ping NODE: This tests the connectivity to the node.
  • rosnode cleanup: This purges the registration information from unreachable nodes

In the upcoming sections, you will learn how to use these commands with examples.

A powerful feature of ROS nodes is the possibility of changing parameters while you start the node. This feature gives us the power to change the node name, topic names, and parameter names. We use this to reconfigure the node without recompiling the code so that we can use the node in different scenes.

An example of changing a topic name is as follows:

$ rosrun book_tutorials tutorialX topic1:=/level1/topic1

This command will change the topic name topic1 to /level1/topic1. I am sure that you don't understand this at this moment, but you will find the utility of it in the upcoming chapters.

To change parameters in the node, you can do something similar to changing the topic name. For this, you only need to add an underscore (_) to the parameter name; for example:

$ rosrun book_tutorials tutorialX _param:=9.0

The preceding command will set param to the float number 9.0.

Bear in mind that you cannot use names that are reserved by the system. They are as follows:

  • __name: This is a special, reserved keyword for the name of the node
  • __log: This is a reserved keyword that designates the location where the node's log file should be written
  • __ip and __hostname: These are substitutes for ROS_IP and ROS_HOSTNAME
  • __master: This is a substitute for ROS_MASTER_URI
  • __ns: This is a substitute for ROS_NAMESPACE

Topics

Topics are buses used by nodes to transmit data. Topics can be transmitted without a direct connection between nodes, which means that the production and consumption of data are decoupled. A topic can have various subscribers and can also have various publishers, but you can take care about publishing the same topic with different nodes because it can create conflicts.

Each topic is strongly typed by the ROS message type used to publish it, and nodes can only receive messages from a matching type. A node can subscribe to a topic only if it has the same message type.

The topics in ROS can be transmitted using TCP/IP and UDP. The TCP/IP-based transport is known as TCPROS and uses the persistent TCP/IP connection. This is the default transport used in ROS.

The UDP-based transport is known as UDPROS and is a low-latency, lossy transport. So, it is best suited to tasks such as teleoperation.

ROS has a tool to work with topics called rostopic. It is a command-line tool that gives us information about the topic or publishes data directly on the network. This tool has the following parameters:

  • rostopic bw /topic: This displays the bandwidth used by the topic.
  • rostopic echo /topic: This prints messages to the screen.
  • rostopic find message_type: This finds topics by their type.
  • rostopic hz /topic: This displays the publishing rate of the topic.
  • rostopic info /topic: This prints information about the active topic, topics published, ones it is subscribed to, and services.
  • rostopic list: This prints information about active topics.
  • rostopic pub /topic type args: This publishes data to the topic. It allows us to create and publish data in whatever topic we want, directly from the command line.
  • rostopic type /topic: This prints the topic type, that is, the type of message it publishes.

We will learn to use it in the upcoming sections.

Services

When you need to communicate with nodes and receive a reply, you cannot do it with topics; you need to do it with services.

Services are developed by the user, and standard services don't exist for nodes. The files with the source code of the messages are stored in the srv folder.

Similar to topics, services have an associated service type that is the package resource name of the .srv file. As with other ROS filesystem-based types, the service type is the package name and the name of the .srv file. For example, the chapter2_tutorials/srv/chapter2_srv1.srv file has the chapter2_tutorials/chapter2_srv1 service type.

ROS has two command-line tools to work with services: rossrv and rosservice. With rossrv, we can see information about the services' data structure, and it has exactly the same usage as rosmsg.

With rosservice, we can list and query services. The supported commands are as follows:

  • rosservice call /service args: This calls the service with the arguments provided
  • rosservice find msg-type: This finds services by service type
  • rosservice info /service: This prints information about the service
  • rosservice list: This lists the active services
  • rosservice type /service: This prints the service type
  • rosservice uri /service: This prints the ROSRPC URI service

Messages

A node sends information to another node using messages that are published by topics. The message has a simple structure that uses standard types or types developed by the user.

Message types use the following standard ROS naming convention; the name of the package, then /, and then the name of the .msg file. For example, std_msgs/ msg/String.msg has the std_msgs/String message type.

ROS has the rosmsg command-line tool to get information about messages. The accepted parameters are as follows:

  • rosmsg show: This displays the fields of a message
  • rosmsg list: This lists all messages
  • rosmsg package: This lists all of the messages in a package
  • rosmsg packages: This lists all of the packages that have the message
  • rosmsg users: This searches for code files that use the message type
  • rosmsg md5: This displays the MD5 sum of a message

Bags

A bag is a file created by ROS with the .bag format to save all of the information of the messages, topics, services, and others. You can use this data later to visualize what has happened; you can play, stop, rewind, and perform other operations with it.

The bag file can be reproduced in ROS just as a real session can, sending the topics at the same time with the same data. Normally, we use this functionality to debug our algorithms.

To use bag files, we have the following tools in ROS:

  • rosbag: This is used to record, play, and perform other operations
  • rqt_bag: This is used to visualize data in a graphic environment
  • Rostopic: This helps us see the topics sent to the nodes

The ROS master

The ROS master provides naming and registration services to the rest of the nodes in the ROS system. It tracks publishers and subscribers to topics as well as services. The role of the master is to enable individual ROS nodes to locate one another. Once these nodes have located each other, they communicate with each other in a peer-to-peer fashion. You can see in a graphic example the steps performed in ROS to advertise a topic, subscribe to a topic, and publish a message, in the following diagram:

The ROS master

The master also provides Parameter Server. The master is most commonly run using the roscore command, which loads the ROS master, along with other essential components.

Parameter Server

Parameter Server is a shared, multivariable dictionary that is accessible via a network. Nodes use this server to store and retrieve parameters at runtime.

Parameter Server is implemented using XMLRPC and runs inside the ROS master, which means that its API is accessible via normal XMLRPC libraries. XMLRPC is a Remote Procedure Call (RPC) protocol that uses XML to encode its calls and HTTP as a transport mechanism.

Parameter Server uses XMLRPC data types for parameter values, which include the following:

  • 32-bit integers
  • Booleans
  • Strings
  • Doubles
  • ISO8601 dates
  • Lists
  • Base64-encoded binary data

ROS has the rosparam tool to work with Parameter Server. The supported parameters are as follows:

  • rosparam list: This lists all the parameters in the server
  • rosparam get parameter: This gets the value of a parameter
  • rosparam set parameter value: This sets the value of a parameter
  • rosparam delete parameter: This deletes a parameter
  • rosparam dump file: This saves Parameter Server to a file
  • rosparam load file: This loads a file (with parameters) on Parameter Server
上一章目录下一章