ROS : Why What and How.

If you are a robotics student, a researcher, a hobbyist or an engineer looking to develop applications ranging from a simple simulation to a full-blown fleet of autonomous robots, this post is for you. In this post, I’ll be providing an introduction to ROS (Robot Operating System), why you should use it, what it can do for your application and how you can proceed with your learning on this subject.

‍

Almost 5 years ago when I started studying robotics, I came across ROS. I looked around the web, trying to get an understanding of what it is, where I can use it and why should I learn it. In my attempt to understand the technology, I stumbled across some more terms - middleware, hardware abstraction, message-passing and many more. I couldn’t make much of these terms at the time but went ahead to install ROS anyway. As an inexperienced developer in Linux system, I struggled some more and eventually gave up. I just stuck to what I knew, MATLAB.

‍

If you are, like I once was, new to the development arena, I hope you make the best of this series of posts to help you start with developing robot applications. Before we begin, here is what 10 years of ROS looks like:

‍

First things first, why do I need ROS?

Let’s start with an example. For some reason, you have decided to build an autonomous mobile robot. You have realized you can get reliable yet economical motors from any of your favorite vendors. You have even managed to get an Arduino up and running to control your motors. Next, you have a 2D Lidar to localize and some obstacle sensors to prevent you from ramming into strangers. Finally, you just want to put all of them together on a Raspberry Pi. Here is what you would be doing without ROS:

1. Writing the serial communication with the Arduino to exchange feedback and motor commands.
2. Using the Lidar API to receive laser data.
3. Reading the ultrasonic sensor to gain obstacle information.
4. In order to ensure that failure of one I/O doesn’t crash your entire application, you would definitely want all these processes to run separately.
5. Since your processes are running separately, you have to write some sort of inter-process communication module (But I am not an OS engineer!!!)

‍

All this, just to be in a position to use that data! On top of this, you’ll have to figure out what datatype your localization algorithm uses as inputs, diagnostic tools and so much more. Furthermore, your processes could be so intermingled that changing one sensor source could cause widespread chaos across your code-base. Lastly, anyone willing to reproduce your amazing motion planning code will have to use the exact same sensors, motors and controllers to get the code running. Needless to say, it only gets worse as the number of components increases and you move to more complicated applications. Fortunately, this is where ROS comes in.

‍

OK then, what can ROS do for my robot?

Let’s continue the example we started with.

‍

See how several components are connected to each other, often depending on each other for operation? ROS provides that transport layer to facilitate this communication. It allows the exchange of data using standard data-types (called ROS messages). In the picture, they are shown within square braces, don’t worry if you don’t understand specifically what each of them means. Just grasp the basic idea that it is essentially like “int”, “string” or “float” from your C++ programming days. In practice, several hardware manufacturers provide ROS drivers for their components which allows users to readily build applications using them. It helps the vendors because it opens up the product for a range of applications by developers across the globe, it helps the roboticists as they don’t have to write custom communication for each sensor they purchase. Win-Win!

Now let’s look back at the terms that once had me scared:

1. Middle-ware: ROS by itself isn’t writing any of your algorithms or applications, it is just sitting on top of your OS (Ubuntu, Windows, etc) and facilitating communication from a range of drivers and processes. Here is the thing, thus far there may have been an implied assumption that all our applications are running on the same computer. Well, it need not be the case. The processes can be distributed across a network and nothing changes, it works exactly the same.
2. Hardware abstraction: The standard message types we created, that’s all the input any process needs. If you decide to change the Lidar or Motor controller, that’s totally fine, your application doesn’t depend on that specific choice of hardware. ROS has provided means to abstract such dependencies out of the loop.

‍

Neat. That’s the idea of ROS in a nutshell. Development in ROS provides several other advantages such as integrated libraries for applications, easy collaboration, a large support and development community, and several “out of the box” packages to setup your robot(s) in no time.

‍

How do I start developing using ROS?

The first thing to do would be to get your hands dirty and install ROS. www.ros.org is the home of ROS, you can check it out regularly for any updates, just go through it once to get a hang of it. Follow the instructions (https://www.ros.org/blog/getting-started/) to install ROS. If you are on Ubuntu 16.0X, you should use ROS Kinetic, for Ubuntu 18.0X use ROS Melodic. If you are familiar with Docker containers, you can also use them to kick-start your ROS journey.

After installation, you need to setup your environment and workspace. At the end of this process, you should have a directory called catkin_ws in your file system. Do not worry if you don’t know what a workspace is, I’ll be covering it in the next article along with other key concepts such as packages, nodes, topics, publishers, subscribers, services and more. Stay tuned!

‍

Thank you for reading this. Let me know in the comments if anything was too hard to grasp or needs more explanation. Feel free to drop any recommendations on topics you would want me to cover in the future.