A robot is any system that can perceive the environment i.e, its surroundings (using sensors), take decisions based on the state of the environment(using computation and algorithms) and is able to execute the instructions generated(using actuators).
These sensors and actuators are not ideal and as a result introduce a great amount of uncertainty into the system. Hence, we can never know what the actual state of the system is, and as a result we can never know exactly where robot is or whether applying the same forces using actuators will result in the same motions. This introduces randomness into the system which makes working with real life robots extremely difficult. Add to it the seemingly unpredictable movement of other agents in the environment such as humans and animals and you have a very tough problem at your hands.
How do we solve these problems or let alone start to solve them? We need some system that can act as a bridge between our sensors and actuators. This something is a decision process or a set of steps that the system must follow to achieve the desired outcome. These steps are called algorithms and can be considered as the mind of the robot.
To build a complex robot, we need a wide range of sensors, For example, to build a self driving car we need LIDARs, Cameras, Inertial Measurement Units, Global Positioning System, etc. These systems can be made by different companies and may follow widely different approaches. Hence, there is a lack of uniformity. Also, some algorithms are very commonly used in robotic systems such as Kalman Filters, PID control, etc. If everyone was rewriting the same algorithms it might lead to a needless waste of time and effort. Let alone the quality of these programs(in terms of software engineering practices and computational efficiency) will not be very good.
From the authors of the paper describing ROS:
To meet these challenges, many robotics researchers, including ourselves, have previously created a wide variety of frameworks to manage complexity and facilitate rapid prototyping of software for experiments, resulting in the many robotic software systems currently used in academia and industry . Each of these frameworks was designed for a particular purpose, perhaps in response to perceived weaknesses of other available frameworks, or to place emphasis on aspects which were seen as most important in the design process.
Hence, there is a need for a system that can eliminate these unnecessary overheads, so that researchers around the world can contribute better and solve the hard problems posed by robotic systems. We need protocols to transfer data from one part of the system to another, We need uniform practices and tools to build our software against and we need pre-written libraries to avoid compatibility issues. Well ROS is such a system that provides us with rules and standard ways to organize our stuff so that we can collaborate on a massive scale and have some uniformity among things.
ROS is not an operating system but a meta operating system meaning, that it assumes there is an underlying operating system that will assist it in carrying out its tasks. But what is an operating system? There is no clear definition for operating systems. Usually, an operating system consists of all the things provided by the operating system provider.
Definition of ROS from the original paper:
ROS, an open-source robot operating system. ROS is not an operating system in the traditional sense of process management and scheduling; rather, it provides a structured communications layer above the host operating systems of a heterogeneous compute cluster.
An operating system is a software that provides interface between the applications and the hardware. It deals with the allocation of resources such as memory, processor time etc. by using scheduling algorithms and keeps record of the authority of different users, thus providing a security layer. The operating systems may include basic applications such as web browsers, editors, system monitoring applications etc. It almost always has a low level program called the kernel that helps in interfacing with the hardware and is essentially the most important part of any operating system. The operating systems may or may not provide Graphical User Interfaces.
We need to understand what libraries and frameworks are before understanding Meta OS. Libraries are essentially groups of functions that are widely used in software/programs and are popular enough to justify packaging them into separate files. Libraries are also used to make the software look cleaner and to build upon the tried and tested software, leading to fewer chances of errors. Not meaning that you cannot build your own libraries but here we are referring to the commonly used libraries. A framework is essentially a collection of libraries that may be used for particular applications.
An API is an Application Programming Interface. If you have some code and you want to use it without knowing everything about the code, you can use APIs. APIs provide a layer of abstraction and provide access to the underlying code. This is very helpful when working on projects since we can easily use peer reviewed, thoroughly tested code(libraries, frameworks etc.) without having to worry how it might work.
A Meta Operating system has a huge amount of functionality, so much that it cannot be classified as a framework or a cluster of libraries but not so much that it can be categorized as an operating system either. It provides functionalities of both Operating Systems as well as frameworks but not fully hence, it cannot be classified as either e.g, it does not provide the core functionalities that an operating system is supposed to provide but provides APIs.
ROS depends on the underlying Operating System. ROS demands a lot of functionality from the operating system. On top of that ROS must be freely available to a large population, otherwise a large population may not be able to access it. Much of the popularity of ROS is due to its open nature and easy availability to mass population. It also needs an operating system that is open source so the operating system and ROS can be modified as per the requirements of application.
Proprietary Operating Systems such as Windows 10 and Mac OS X may put certain limitations on how we can use them. This may lead to rigidity in the development process, which will not be ideal for an industry standard like ROS. Hence, most people prefer to run ROS on Linux particularly Debian and Ubuntu since ROS has a very good support with Debian based operating systems especially Ubuntu. That doesn’t mean that ROS can’t be run with Mac OS X or Windows 10 for that matter. But the support is limited and people may find themselves in tough situation with little help from the community.
There is a close proximity between ROS and OS, so much so that it becomes almost necessary to know more about the operating system in order to work with ROS. Using Linux as a newbie can be a challenge, One is bound to run in issues with Linux especially when working with ROS, and a good knowledge of Linux will be helpful to avert/fix these issues.
I personally had to reinstall my operating systems many times due to certain drivers mismatch(looking at you NVIDIA ) and the problem of dependency breaking has lead me down serious existential crises. To avoid such situations, I have compiled a list of the links that proved life savers at crucial times.
As noted above, NVIDIA drivers don’t go well with Linux. NVIDIA does not provide official drivers for Linux, So people hacked the NVIDIA cards and reverse engineered the drivers and built something called Nouveau . But NVIDIA knows about these and long story short, these don’t go well with NVIDIA graphics card. But NVIDIA does provide some drivers which you can use and they will most likely work(all the best!).
There are many other common errors that come with using ROS. But to understand these we would have to understand how packages are installed in Linux. This is a fascinating topic and deserves multiple blogs in its own right but we only cover it briefly in this blog.
To install any software or library in Linux we need something called repos(short for repositories). These are official servers provided by organizations to facilitate the distribution of software. The packages are stored on their servers and you can get them by using package managers or by manual process. By default there are only a certain number of repos that are searched by package managers for the requested package. But of course, we cannot have all the packages in one repo. Hence, we need multiple repos and since everyone does not need every repo it makes sense to include only a limited number of repos.
But what if we wanted to download packages from different repos? We will have to add them to the list of repos to be searched. This system is what protects Linux from viruses, since all the software come from trusted sources, there is very little chance that one of them is a virus. If however you add your own repos, then you will be responsible for the consequences. Hence, when you add repos to download packages from ROS, you need to provide GPG keys, in order to affirm that this repo is indeed secure. Here comes our first error the “ gpg key error ”, This blog can help you understand GPG keys better and solve this error.
Some packages might not be available for the current version of operating system, lets say Ubuntu 16.04 may have some outdated packages or maybe you need some packages that are only available on certain websites. This can be done with PPAs or Personal Package Archive. This may lead to a lot of errors and hence we need a ppa manager that can help us import keys if needed that is where Y-PPA Manager comes in.
One of the most common errors to run into is the dpkg error . dpkg or debian package is a package manager that is in the backend of ubuntu package managers such as apt. The thing is, it can only install one package at a time , Hence puts a lock on its usage. Hence, if you try to install more than one package it might throw dpkg error .
Even though Ubuntu comes with a lot of pre-installed software, some of which are very useful, it might be sometimes needed to install software that provide better alternatives. Here are some of the software i use. zsh - It is a very good-looking wrapper to make bash look better and provides some additional functionalities. Sublime is one of my favorite text editors, its interface and the shortcuts provided are extremely convenient. You may also want to install chrome .
In ROS everything is in the form of packages. This helps in packaging the code in such a way that it is easier to maintain. ROS provides a lot of packages that are ready to use. ROS packages can be installed by
sudo apt install ros-<distro>-<package-name>
e.g, On ROS kinetic, robot_localization package will be installed as:
sudo apt install ros-kinetic-robot-localization
Please refer to this page for more information about packages:
Software in ROS is organized in packages . A package might contain ROS nodes , a ROS-independent library, a dataset, configuration files, a third-party piece of software, or anything else that logically constitutes a useful module. The goal of these packages is to provide this useful functionality in an easy-to-consume manner so that software can be easily reused. In general, ROS packages follow a “Goldilocks” principle: enough functionality to be useful, but not too much that the package is heavyweight and difficult to use from other software.
Some of the important files/directories inside Packages are:
1. Nodes : A node is a process that performs computation.
2. CMakeLists.txt : It is the input to the CMake build system for building software packages.
3. Package.xml : It defines properties about the package such as the package name, version numbers, authors, maintainers, and dependencies on other catkin packages.
5. launch files: To run multiple nodes at once in ROS we use launch files.
Any code that will be written should be in the form of packages. And the packages should be inside workspace. Please refer to this page for more information.
A catkin workspace is a folder where you modify, build, and install catkin packages. It can contain up to four different spaces which each serve a different role in the software development process.
1. The source space contains the source code of catkin packages. This is where you can extract/checkout/clone source code for the packages you want to build. Each folder within the source space contains one or more catkin packages.
3. The development space (or devel space ) is where built targets are placed prior to being installed. The way targets are organized in the devel space is the same as their layout when they are installed. This provides a useful testing and development environment which does not require invoking the installation step.
4. Once targets are built, they can be installed into the install space by invoking the install target, usually with make install.
When we run our rosnodes, they perform computations and obtain results. But they may require results from other nodes in order to perform some other functions. Hence we need a mechanism that can help us transfer data from one node to other. One of the first thing we need to do is to setup a 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 peer-to-peer.
The transfer of data takes place via topics. If you want to send your data, you publish it to topics and whomever needs it, can subscribe to it using publishers. This is helpful in writing code and even more helpful when we are using ROS bags . ROS bags are helpful when we want to record some data, so we can play it later and replicate a behavior if we want to.
Topics are named buses over which nodes exchange messages . Topics have anonymous publish/subscribe semantics, which decouples the production of information from its consumption. In general, nodes are not aware of who they are communicating with. Instead, nodes that are interested in data subscribe to the relevant topic; nodes that generate data publish to the relevant topic. There can be multiple publishers and subscribers to a topic.
Services are another form of communication. They are used for remote procedural calls . i.e, one program can request a service from a program located in another computer. The data that is transferred is in the form of messages which are especially defined data types used in ROS. The last type of communication we are going to look at are actions , They are similar to services but the long term goals can be preempted i.e, can be requested to change.
The actionlib package provides tools to create servers that execute long-running goals that can be preempted. It also provides a client interface in order to send requests to the server.
Once we have all the code ready and running, we need to test our code so that we can make changes if necessary. Doing this on a real robot will be costly and may lead to wastage of time in setting up robot every time. Hence we use robotic simulations for that. The most popular simulator to work with ROS is Gazebo . It has a good community support, it is open source and it is easier to deploy robots on it.
The robot will be setup with different sensors and actuators, luckily we can find many of these in gazebo or otherwise build them on our own, which might take a long time but is still not very tough. While running these sensors, we may need to visualize their data. We use RViz for this.
RViz is a 3D Visualization tool for ROS. It is one of the most popular tools for visualization. It takes in a topic as input and visualizes that based on the message type being published. It lets us see the environment from the perspective of the robot.
ROS is extremely complex and hence somewhat overwhelming for newcomers. What makes ROS tough for people is the amount of prerequisite knowledge the person needs to have. Since most starting students don’t have that knowledge, they find it tough to get a good grasp on ROS.
This includes a good knowledge of Linux and a good idea of computer engineering principles including networking concepts and software engineering philosophies. ROS is mostly based on widely popular, tried and tested tools and technologies, for example rqt is derived from qt. Gazebo and stage were already quite popular before integrating with ROS and catkin is based on CMake.
To make things more complicated there are only a few good online resources. There are long books written but they hardly help newcomers. I found the book “ A Gentle Introduction To ROS ” to be extremely helpful since it was concise and helped me get started. The book- “ Programming Robots with Ros: A Practical Introduction To The Robot Operating System ” gives a good overview of how different things work in ROS. People also recommend “ ROS Robotics By Example ”. Much of the usage of different tools can be found on the wiki and if you are stuck feel free to head to the forums .
I hope this blog helped you know more about ROS and you now understand its usefulness. But ROS came out in 2007 and it was meant for particular use cases. Since then, a lot has changed, We have seen a resurgence in Artificial Intelligence research and increase in the number of use cases. Robotics is becoming more popular among the masses and even though ROS copes up with these challenges very well(even though it wasn’t made to), it requires a great number of hacks.
Hence, we require that changes be made to ROS so that it can cope with these new challenges. ROS2 is such an initiative, It is being developed so that ROS can be used on other operating systems like Windows, and can support a wider variety of hardware(e.g, embedded systems). It should also have better support for Reinforcement learning and multi robot systems.
Accompanying presentation and Youtube video are also available: