Welcome to your ROS learning journey!
If you are interested in robotics, you must have heard of ROS (Robot Operating System). ROS is now very popular among roboticists. Researchers, hobbyists, and even robotics companies are using it, promoting it. and supporting it. But what is ROS? How did ROS reach its current state as a robotics standard? Why is ROS becoming a must-have skill for robotics practitioners? In this article, we will reveal the answers to these questions.
Keep on reading to understand ROS, or jump ahead to the section that interests you most.
A history of ROS
What is ROS?
Start learning ROS
A history of ROS
Before we understand what ROS is, let me introduce you to ROS with a short history of how it started, the main reasons behind it, and its current status.
- The Stanford Period
- Similar frameworks at the time
- Switching gears
- Willow Garage takes the lead
- Under the Open Source Robotics Foundation umbrella
- ROS 2.0
- Recent movements in the ROS ecosystem
The Stanford Period
ROS started as a personal project of Keenan Wyrobek and Eric Berger while at Stanford, as an attempt to remove the reinventing-the-wheel situation from which robotics was suffering. These two guys were worried about the most common problem of robotics at the time:
- too much time dedicated to re-implementing the software infrastructure required to build complex robotics algorithms (basically, drivers to the sensors and actuators, and communications between different programs inside the same robot)
- too little time dedicated to actually building intelligent robotics programs that were based on that infrastructure.
Even inside the same organization, the re-invention of the drivers and communication systems was re-implemented for each new project. This situation was beautifully expressed by Keenan and Eric in one of their slides used to pitch investors.
In order to attack that problem, Eric and Keenan created a program at Stanford called the Stanford Personal Robotics Program in 2006, with the aim to build a framework that allowed processes to communicate with each other, plus some tools to help create code on top of that. All that framework was supposed to be used to create code for a robot they would also build, the Personal Robot, as a test bed and example to others. They would build 10 of those robots and provide them to universities so that they could develop software based on their framework.
NOTE: People more versed in ROS will recognize the precursors of ROS-comm libraries and the Rviz, rqt_tools and the like of current modern ROS distributions. Also, the Personal Robot was the precursor to the famous PR2 robot.
Similar frameworks at the time
The idea of such a system for robotics was not new. Actually, there were some other related projects already available for the robotics community: Player/Stage, one of the most famous in the line of open source, and URBI in the line of proprietary systems. Even Open-R, the system developed by Sony, which powered the early Aibo robots of 1999, was a system created to prevent that problem (a shame that Sony cancelled that project, as they could have become the leaders by now. Ironically, this year, Sony launched a new version of the Aibo robot… which runs ROS inside!). Finally, another similar system developed in Europe was YARP.
Actually, one of the leaders of the Player/Stage research project was Brian Gerkey, who later went to Willow Garage to develop ROS, and is now the CEO of Open Robotics, the company behind the development of ROS at present. On its side, URBI was a professional system led by Jean-Christoph Baillie, which worked very well, but could not compete with ROS, which was free.
That is an important point to discuss: URBI was (at least) as good as ROS. I used it for many research tasks while doing my Ph.D.: for example, this code about making the Aibo robot walk using neural networks (in 2005!), and making Aibo dance, and do some other tricks. But URBI failed when competing with ROS. URBI had as many tools for debugging, and as much documentation as ROS. So, why did URBI fail against ROS?
The fastest readers will jump to the point that URBI was not free. Actually, it was quite expensive. Was the price what killed URBI? I don’t think so. In my opinion, what killed URBI was the lack of community. It takes some time to build a community, but once you have it, it acts like changing gears. URBI could not build a community because it relied on an (expensive) paid fee. That made it so that only people that could buy it were accessing the framework. That limits the amount of community you can create. It is true that ROS was free. But that is not the reason (many products that are free fail). The reason is that they built a community. Being free was just a strategy to build that community.
While at Stanford, Keenan and Eric received $50k of funding and used it to build a PR robot and a demo of what their actual project was. However, they realized that in order to build a really universal system and to provide those robots to the research groups, they would need additional funding. So they started to pitch investors.
At some point around 2008, Keenan and Eric met with Scott Hassan, investor and the founder of Willow Garage, a research center with a focus on robotics products. Scott found their idea so interesting that he decided to fund it and start a Personal Robotics Program inside Willow Garage with them. The Robot Operating System was born, and the PR2 robot with it. Actually, the ROS project became so important that all the other projects of Willow Garage were discarded and Willow Garage concentrated only on the development and spread of ROS.
Willow Garage takes the lead
ROS was developed at Willow Garage over the course of 6 years, until Willow shut down, back in 2014. During that time, many advancements in the project were made. It was this push during the Willow time that skyrocketed its popularity. It was also during that time that I acknowledged its existence (I started with ROS C-turtle in 2010) and decided to switch from Player/Stage (the framework I was using at that time) to ROS, even if I was in love with Player/Stage (I don’t miss you because ROS is so much better in all aspects… sorry, Player/Stage, it’s not me, it’s you).
In 2009, the first distribution of ROS was released: ROS Mango Tango, also called ROS 0.4. As you can see, the name of the first release had nothing to do with the current naming convention (for unknown reasons to this author). The release 1.0 of that distribution was launched almost a year later in 2010. From that point, the ROS team decided to name the distributions after turtle types. Hence, the following distributions and release dates were done:
- Box Turtle, in 2010
- ROS C-Turtle, in 2010
- Diamond Back, in 2011
- ROS Electric Emys, in 2011
- ROS Fuerte Turtle, in 2012
- ROS Groovy Galapagos, in 2012
Around that time, other events also happened:
- In 2009, they built a second version of the Personal Robot, the PR2
- In xxx, they launched ROS Answers, the channel to answer technical questions about ROS.
- The first edition of the ROSCON was in 2012. The ROSCON became the official yearly conference for ROS developers.
- In 2010, they built 11 PR2 robots and provided them to 11 universities for robotics software development using ROS (the original idea of Eric and Keenan). At that point, the PR2 robot was for sale, so anybody in the world could buy one (if enough money was available ;-)).
- Simulation started to become very important. More precisely, 3D simulation. That is why the team decided to incorporate Gazebo, the 3D robotics simulator from the Player/Stage project, into ROS. Gazebo became the default 3D simulator for ROS.
As ROS was evolving, all the metrics of ROS were skyrocketing. The number of repositories, the number of packages provided, and of course, the number of universities using it and of companies putting it into their products.
Another important event that increased the size of the ROS community was when, in 2011, Willow Garage announced the release of the Turtlebot robot, the most famous robot for ROS developers. Even if PR2 was the intended robot for testing and developing with ROS, its complexity and high price made it non-viable for most researchers. Instead, the Turtlebot was a simple and cheap robot that allowed anybody to experiment with the basics of robotics and ROS. It quickly became a big hit, and is used even today, in its Turtlebot2 and Turtlebot 3 versions.
In 2013, Willow Garage ‘announced’ that the company would dissolve that year.
I remember when we received the news that Willow Garage was closing. I was working at Pal Robotics at the time. We at Pal Robotics were all very worried. What would happen with ROS? After all, we had changed a lot of our code to be working with ROS. We removed previous libraries like Karto for navigation (Karto is software for robot navigation, which at present is free, but at that time, we had to pay for a license to use it as the main SLAM and path planning algorithms of our robots).
The idea was that the newly created Open Source Robotics Foundation would take the lead in ROS development. And many of the employees were absorbed by Suitable Technologies (one of the spin-offs created from Willow Garage, which ironically does not use ROS for their products ;-)). The customer support for all the PR2 robots was absorbed by another important company, Clearpath Robotics.
Under the Open Source Robotics Foundation umbrella
Under the new legal structure of the OSRF, ROS continued to develop and release new distributions.
- ROS Hydro Medusa, in 2013
- ROS Indigo Igloo, in 2014
- ROS Jade Turtle, in 2015
- ROS Kinetic Kame, in 2016
- ROS Lunar Loggerhead, in 2017
- ROS Melodic Morenia, in 2018
The reports created after each year are publicly available here under the tag ROS Metrics.
Having reached this point, it is important to state that the last distribution of ROS will be released in 2020. It is called ROS Noetic, which will be based on Python 3, instead of Python 2 as all the previous ones were. From that date, no more ROS 1 distributions will be released, and the full development will be taken for ROS 2.
(Update: ROS Noetic Ninjemys has been released on May 23rd, 2020. )
What is ROS 2? Let’s dig in…
Around 2015, the deficiencies of ROS for commercial products were manifesting very clearly. Single point of failure (the roscore), lack of security, and no real-time support were some of the main deficiencies that companies argued for not supporting ROS in their products. However, it was clear that, if ROS had to become the standard for robotics, it had to reach the industrial sector with a stronger voice than that of the few pioneer companies already shipping ROS in their products.
In order to overcome that point, the OSRF took the effort to create ROS 2.0.
ROS 2.0 had already reached its fourth distribution in June 2019 with the release of Dashing Diademata.
Recent movements in the ROS ecosystem
- In 2017, the Open Source Robotics Foundation changed its name to Open Robotics, in order to become more of a company than a foundation, even if the foundation branch still exists (some explanation about it can be found in this post and in this interview with Tully Foote).
- Recently, Open Robotics has opened a new facility in Singapore and established a collaboration with the government there for development.
- Local ROS conferences have been launched:
- ROSCON France
- ROSCON Japan
- In the last few months, big players like Amazon, Google, and Microsoft have started to show interest in the system, and show support for ROS.
That is definitely a sign that ROS is in good health (I would say in better than ever) and that it has a bright future in front of it. Sure, many problems will arise (like, for example, the current problem of creating a last ROS 1 distribution based on Python 3), but I’m 100% sure that we, and by we I mean the whole ROS community, will solve them and build on them.
What is ROS?
- Why are there not enough developers for robotics?
- Roboticists programming robots
- What is the robot ROS API?
- What is ROS anyway?
- ROS for service robots
- ROS for industrial robots
- ROS for agricultural robots
A story of software & hardware: why are there not enough developers for robotics?
In general, software developers do not like to deal with hardware. It is very likely that you are a software developer and never thought about entering into the robotics field. You probably think that by programming for robots, you would have to know about electronics, and maybe even mechanics. You probably think that hardware and software are too coupled in robots, that you cannot touch one without touching the other. And sometimes, it is true…
About 10 years ago, we had to develop a navigation system for a robot. However, our navigation program was not working at all. We thought that it was something wrong with the program, but after extensive review and testing in simulations, we found that it actually was a problem with the electronics of the laser scanner that we used to localize the robot. In order to find that error, we had to go to the basics and find where the problem within the physical laser was. For that, we needed to mess with the electronics. We had to take the laser out of the robot, put it on the table, and start experimenting. Different voltages, different interruptions to the power, all in order to try to reproduce the effect in a controlled environment. That is a lot of interaction with the hardware.
That interaction with the hardware is something that many software developers don’t like. After all, they decided to become software developers, not hardware developers!!
Roboticists programming robots
Due to this, the programming of robots has been done by roboticists, who are the people that build the robots. Maybe some of the roboticists were not directly involved in the creation of the robot, but they definitely have no problem getting into the hardware and trying to fix hardware problems in order to make their programs work.
But let’s face it, most roboticists are not as good at programming as software developers are. That is why robotics could benefit so much from having lots of expert programmers coming to the field.
The good news is that getting developers into the field is easier than ever. Thanks to the Robot Operating System, ROS, you can completely abstract the hardware from the software, so you can program a robot just by knowing the robot’s ROS API and having a simulation for testing. By using the ROS API, you can forget about the hardware and just concentrate on the software that makes the robot do what you want.
What is the robot ROS API?
The ROS API is the list of ROS topics, services, action servers, and messages that a given robot is providing to give access to its hardware, that is, sensors and actuators. If you are not familiar with ROS, you may not understand what those terms mean. But simply put in the developers’ language, topics/services/messages are like the software functions you can call on a robot to get data from the sensors or make the robot take action. It also includes the parameters you can pass on to those functions.
Most modern robot builders are providing off-the-shelf ROS APIs, for example, the ROS-Components shop that provides all its hardware running with a ROS API.
If the robot you want to work with does not run ROS, you can still make the robot work with ROS by ROSifying it. To ROSify means to adapt your robot to work with ROS. ROSifying a robot usually requires knowledge to access the hardware. You need to learn how to communicate with the electronics that provide the sensor data or access the motors of the robot. In this series of ROS tutorials, we are not dealing with that subject because it gets out of scope for developers. But if you are interested in this topic, you can learn more about it in this Robot Creation Course.
What is ROS anyway?
ROS stands for Robot Operating System. Even if the name says so, ROS is not a real operating system since it goes on top of Linux Ubuntu (also on top of Mac, and recently, on top of Windows). ROS is a framework on top of the O.S. that allows it to abstract the hardware from the software. This means, you can think in terms of software for
all the hardware of the robot. And that is good news for you because this implies that you can actually create programs for robots without having to deal with the hardware. Yea!
ROS works on Linux Ubuntu or Linux Debian. Experimental support already exists for OSX, Gentoo, and a version for Windows is under way, but we really don’t recommend for you to use them yet unless you are an expert. Check this page for more information about how to use ROS on those systems.
ROS for service robots
ROS is becoming the standard in robotics programming, at least in the service robots sector. Initially, ROS started at universities, but quickly spread into the business world. Every day, more and more companies and startups are basing their businesses on ROS. Before ROS, every robot had to be programmed using the manufacturer’s own API. This means that if you changed robots, you had to start the entire software again, apart from having to learn the new API. Furthermore, you had to know a lot about how to interact with the electronics of the robot in order to understand how your program was doing. The situation was similar to that of computers in the 80s, when every computer had its own operating system and you had to create the same program for every type of computer. ROS is for robots like Windows is for PCs, or Android for phones. By having a ROSified robot, that is, a robot that runs on ROS, you can create programs that can be shared among different robots. You can build a navigation program, that is a program to make a robot move around without colliding, for a four-wheeled robot built by company A and then use the same exact code to move a two-wheeled robot built by company B… or even use it on a drone from company C, with minor modifications.
ROS for industrial robots
ROS is being used in many of the service robots that are created at present. On the other side, industrial robotics companies are still not completely convinced about using it, mainly because they will lose the power of having a proprietary system. However, four years ago, an international group called ROS-Industrial (https://rosindustrial.org/) was created, whose aim is to make industrial manufacturers of robots understand that ROS is for them, since they will be able to use all the software off-the-shelf that other people have created for other ROS robots.
ROS for agricultural robots
In the same vein as ROS-Industrial, ROS-Agriculture (http://rosagriculture.org/) is another international group that aims to introduce ROS for agriculture robots. I highly recommend that you follow this group if you are interested because they are a very motivated team that can do crazy things with several tons of machine, by using ROS. Check out, for instance, this video (https://youtu.be/obu_Ru2gDHk) about an autonomous tractor running ROS, built by Kyler Laird of the ROS Agriculture group.
The question then is this: why has ROS emerged on top of all the other possible contestants? None of them is worse than ROS in terms of features. Actually, you can find some features in all the other middlewares that outperform ROS. If that is so, why or how has ROS achieved the status of becoming the standard?
A simple answer from my point of view: excellent learning tutorials and debugging tools.
Here is a video where Leila Takayama, early developer of ROS, explains when she realized that the key for ROS to be used worldwide would be to provide tools that simplify the reuse of ROS code. None of the other projects have such a set of clear and structured tutorials. Even less, those other middlewares provide debugging tools in their packages. Lacking those two essential points is preventing new people from using their middlewares (even if I understand why the developers of OROCOS and YARP for not providing it… who wants to write tutorials or build debugging tools… nobody! 😉 )
Additionally, it is not only about Tutorials and Debugging-Tools. ROS creators also managed to create a good system of managing packages. The result of that is that developers worldwide could use others’ packages (relatively) easily. This created an explosion in available ROS packages, providing almost anything off-the-shelf for your brand-new ROSified robot.
Now, the rate at which contributions to the ROS ecosystem are made is so fast that it makes ROS almost unstoppable in terms of growth. According to ABI Research, about 55% of the world’s robots will include a ROS package by 2024. This is an indication of the fact that in ten years, ROS has become a defacto robotics standard, in academia and increasingly in industry. More and more universities are teaching robotics with ROS. The ROS Curriculum For Campus project that we launched in 2018 has been used by hundreds of universities. It is easy to see why ROS has become a must-have skill in the CV of robotics practitioners.
How to start learning ROS
Now, if you are convinced about becoming a ROS developer 😉 then using this beginner’s guide, we can follow these five steps to successfully learn ROS:
- How to learn ROS
- How to install ROS & ROS 2
- Start coding on ROS
- How to test your ROS programs
Explore the chapters…
Setting up ROS
Learn step-by-step how to install ROS Melodic in a fresh Ubuntu 18.04.
Setting up ROS
Learn step-by-step to install ROS 2 Crystal in a fresh Ubuntu 18.04.
Create your ROS programs
In order to create ROS programs, you will need a C++ or Python code editor. In this chapter, we are going to show you a list of integrated environments for programming ROS with those languages.