The Soul of Robots or ROS in 10 Minutes

Introduction

Developing a robot is quite challenging. This task is also complicated significantly by the ever-growing functionality of modern robots. An engineer alone can develop only simple robotic devices. Whereas creating a full-fledged cybernetic device requires the work of many narrow specialists. For a long time, the development of robots began with architecture (see our previous article), which was created depending on the task, and then specific hardware was built and dedicated software was developed. Be aware of How We Do Software at Indeema. All this required the efforts of numerous highly skilled specialists. Of course, robots were incredibly expensive. 

In the 21st century, frameworks have emerged that partially solve the problem. Probably the most popular now is ROS (Robot Operating System). And there are reasons for this.

1. What’s ROS exactly and how does it work?

Despite the name, ROS is not an operating system in the usual sense. This is rather a set of frameworks installed on top of the usual operating system. In most cases, the Ubuntu Linux distribution is used as a foundation. On this operating system, all versions of ROS are tested. One can also use Debian, and since ROS 2 Foxy Fitzroy, full support of Windows and macOS is granted (previous builds of ROS for these operating systems were experimental). The basis of ROS is interactive information infrastructure. All processes communicate with each other through messages. The smallest component of ROS is called a node. Each node communicates directly with other nodes through a system of topics and services. Thus, the ROS system is a computational graph consisting of a set of nodes that interact with each other.

To exchange messages between nodes, a master node called roscore must work. It can run on one of the robots or on the control computer. This node acts as a message server. The first message between the nodes will always pass through the master node, but the next communications can be direct to save resources.

The Node is the smallest executable ROS program, but it cannot run on itself without settings. The basic structural unit of ROS is a package, it combines nodes associated with a single task or written in a single programming language and with the same settings. Each package is completely independent and can be installed separately. The package can use its own programming language. The main development languages for ROS are C++ and Python, but there is no fundamental restriction on other languages, although all tools for development and compilation integrated into ROS are for these two. 

ROS implements three basic principles of communication between nodes:

Topics, Services and Actions use messages to interact with each other. A message in ROS is a data structure used to exchange information between nodes. Messages can include both basic types (integer, floating-point number, logical, etc.) and arrays. In addition, messages can encapsulate other existing message types and special headers.

The main way to exchange messages is Topic. The Publisher node first registers its topic on the Master node and then begins publishing messages on this topic. Subscriber nodes that want to receive information on this topic with the help of the Master get the address of this topic and then receive messages from this topic. One node can contain several Publishers that pass data on different topics. The process that receives a message from a particular Topic is called a Subscriber.

Subscriber registers in the Master-node, indicating the message from which topics Subscriber wants to receive. Then, the Publisher begins sending messages to Subscriber. Communication with the Topic for Subscribers is asynchronous (Publisher publishes messages regardless of the status of Subscribers). This type of interaction is convenient to use when working with sensors that continuously transmit measured values. 

The communication model in Service mode creates a two-way synchronous connection between the Service Client that creates the request and the Service Server that responds to the request. This method is convenient to use for periodic data transmission, or when there is a need for synchronous communication (request-response mode). Server responds only when there is a Service Request and a client that can receive a Service Response. Unlike the Topics model, the Service model works with "disposable" connections.

Therefore, when the request and response cycle is complete, the connection between the two nodes will terminate.

The communication model in Action mode is used when the execution of the requested command takes a long time and requires feedback from the process.

This is very similar to the Service: Service Request model here is called Action Goal, and Action Result plays the role of Service Response. But here, an additional Action Feedback is used to transfer to the client-node the intermediate results of the process performance.

The use of different communication types and the absolute independence of the packages allow developers to build up the necessary logic of the robots from the ready-made codes, depending on the task and the configuration.

ROS belongs to the so-called middleware because it is an intermediate link between the hardware of robots (sensors, manipulators, engines, cameras) and the software components (object recognition, information processing). Modern ROS builds include a set of ready-made solutions in the form of packages: for visualization of the inner world of the robot (RViz – Robot Visualization), packages for solving basic SLAM tasks (mapping and localization) – slam toolbox, gmapping and a set of libraries for planning the movement of the robotic arm (MoveIt Motion Planning Framework). ROS also includes a set of intermediate libraries to integrate the Gazebo modeling and the visualization system. Gazebo is another open-source project that allows providing physically accurate simulations of robots in a static and dynamic environment. In fact, instead of Gazebo, one can use various other simulators, such as a powerful, commercially available Simulink from MathWorks. However, Gazebo is the accepted standard for ROS because it supports the same principles of openness and accessibility to everyone.

2. Why is ROS important for robotics?

Every year, robots and cybernetic systems become more complex, the requirements for them become more stringent. The development of new robots is extremely expensive. Of course, developers who invest in a particularly specialized type of robot can make considerable strides. Examples are camera quadcopters or consumer vacuum cleaner robots. However, with universal robots, or robots for a new industry, everything is more difficult. And here ROS comes in handy. The main principles of ROS are the maximum use of ready-made tools, a division into separate specialized modules and complete openness of the code with the possibility of use in commercial projects.

These approaches not only help developers but also unite manufacturers. It is advantageous for the manufacturer of sensors to make a package for ROS and a visual model for RViz and give it free access because it will increase the demand for such a product. The same applies to manufacturers of cameras, engines or grasping systems. It is also advantageous for robot manufacturers to use modules for which there are already basic packages and models available, because it significantly speeds up the development process, and hence the final cost. In fact, ROS stimulates both sides to develop and interact.

Another important aspect of ROS is the scientific and research side. Scientists do not need to know and develop all the modules of the robot to test their own algorithms and ideas. A researcher develops only a module that meets his needs and in the accustomed programming language.

No wonder that the standard ROS development language on a par with C++ is Python, a language created by scientists for scientists. And although Python has gone far beyond science, it still performs its main task.

The possibility of mass production of identical robots is also important for the industry. The ROS architecture allows not only to create identical or similar robots with inter-replaceable parts quickly but is also perfectly suitable for fast scaling. ROS also supports the possibility of centralized remote control of robots (or robotic manipulators) through a single Master node. It is convenient for mass production or the conveyor when it is important that all robots work as a whole.

3. Strengths and limitations of ROS

3.1 Open code

ROS is a fully open-source system as well as all its components (tools and libraries) because they are distributed under the BSD license. This means that ROS can be used for training, research and business on a commercial basis. This approach involves numerous developers and specialists from different fields in the project. In addition, the ability to use ROS in commercial products encourages big businesses to invest in the project.

3.2 Modularity

Due to the modular structure of ROS, each individual process (node, package) can be developed by a separate developer, in a specific language and according to its architecture or scheme. This allows a narrow specialist to deal exclusively with his or her task exploiting tools that are most familiar to him or her. For example, a motion dynamics specialist may work with a robotic arm motion-planning module and an algorithms specialist with a SLAM or path search module.

However, the modularity of the system increases resource consumption and can limit data flows. Each module needs its own resources, settings, code interpreters etc. Communication through messages requires building these messages in a standardized format in one node and decrypting in another. This leads to the fact that often the data stream may contain less than half of the useful information.

3.3 Easy scaling

The modular structure of ROS and communication via standard protocols allow developers to increase the number of interacting robots and robots controlled by one center easily and quickly. For a developer, it makes almost no difference whether he or she works with two or with a hundred of the same type of robots. The active use of the Docker virtual environment, which is promoted among ROS developers in recent years, also helps. All debugging, simulations and development is made in a Docker container and can be easily applied without changes to an unlimited number of robots.

Also, the use of Docker containers allows making the development on a remote server or in a cloud with virtually unlimited resources. It is relevant because simulations of complex robots and systems require considerable computational resources.

3.4 Big community

Numerous scientists and developers from around the world have joined for the creation and development of ROS. Forums, channels on social networks and Q&A allow you to get answers to almost any question. Involved people are always ready to help new developers who are just beginning to understand ROS and robotics. There are a huge number of books, courses and video lessons, both paid and free. All this makes it easy to become one of the developers who use ROS to model and design robots.

On the other hand, the combination of source-openness and availability of changes to many users generates numerous forks, sources, and unfinished and poorly documented projects. This creates chaos and stochastic noise, which often interferes with finding codes needed to solve the problem, even if they exist. Also, there is a need to constantly check the functionality of libraries and collections, as there may be undocumented changes in the libraries and tools. And changing the version of ROS almost always leads to the need for deep processing and adaptation of solutions. 

3.5 High entry threshold for beginners

In order to start using ROS tools, one must either already have certain tools, or spend a certain amount of time on their development. One needs to understand the operation of operating systems and be able to build a system from raw code (to install ROS). One must be able to work with CAD to build a robot world; one needs to be capable of interpreting the data coming from the sensors. Not to say that one also needs to get acquainted with numerous libraries and ROS utilities (which do not always work exactly as documented). Probably, there is more of a problem with robotics as such, which unites several already complex disciplines (mathematical modeling, algorithms, electronics and electrical engineering, programming). But some of the commercial tools for developing and building robots and robotic devices are still more friendly to beginners.

Conclusion 

Projects, similar to ROS, define the future of robotics. The nature of ROS encourages completely different people and organizations to collaborate. It uses the approaches aimed to reduce the cost of industrial robots and, consequently, the final products they produce. On the other hand, ROS transfers robotics from the prerogative of large corporations and research centers to the public. Now, small groups of researchers or even individual scientists have the opportunity to join in the creation of robots, or even the development of something completely new without having to do all the heavy lifting from the beginning. ROS allows students with basic practical knowledge to be involved in the development process. This approach will increase the number of specialists in the field of robotics and thus accelerate its development. And the future is in robotics, no matter what anyone says.

Related: The Role of Robot Evolution: Paving the Way for Today's IoT Advancements