The Evolution of ROS

What is ROS?

Just 10 years ago, most robotics developers would have complained about programming software that interacted with hardware. There was no common system for how robotic software should communicate, so it was almost always up to the developer to come up with a novel system for their robot. But because of differing hardware, other roboticists and developers could not reuse previously developed programs, and they had to make their own system. This process of reinventing the wheel dramatically hamped robotics research and development, oftentimes taking up significant portions of the 2–3 year time frames for most robotics projects.

The Robot Operating System (ROS) was a solution to this pain point. With the goal of providing a standard for robotics software development regardless of hardware, ROS allows developers to focus on key differentiating features of an application rather than re-building a foundation.

First created in 2007 by Willow Garage, a research center with a focus on robotics products, the ROS functions as a middleware that is responsible for handling the communication between programs in a distributed system. In essence, the Robot Operating System is a core set of communication frameworks that is then augmented by a variety of plug and play libraries for more specialized applications.

How does ROS work?

With robotics, it makes the most sense to develop software applications modularly to interact with specific pieces of hardware and then piece them together rather than coding up one giant code base with everything compiling and running in one block. This is especially true if you’re using different pieces of hardware from different vendors such as a RealSense camera from Intel, a Puck from Velodyne, and a robot arm from Agility. ROS allows you to easily separate your code base into packages of small programs called nodes, and then facilitates communication between them. It does so through 3 main tools: Topics, Services, and Actions.

• Topics essentially serve as data streams between nodes. One example would be a program that is monitoring the battery life of the robot and can send a data stream with the relevant data so that other nodes can obtain the information. This is typically also described as the general publish / subscribe architecture (or pub/sub).
• Services allow you to set up synchronous client/server communication between nodes, like changing a setting or sending a specific request. Frequent examples might include asking for XYZ data or enabling freedrive mode.
• Actions provide asynchronous client/server architecture, where the client can send requests that may take significant time to complete. The client is able to monitor the state of the server, as well as change or cancel the request at any time. A common example of an action might be pinging the robot to move to a new location.

These three tools form the foundation of the Robot Operating System, but it now encompasses far more than that. After Willow Garage closed-down in 2014, ROS has flourished into an open-sourced community of dedicated contributors around the world. Open Robotics serves as the global ROS committee that sets the general direction to follow for community development, and every year there is a worldwide event called ROSCON where development progress is shared. With such strong global support, ROS has seen an abundance of open sourced growth.

When developing software for a robot, there are dozens of functionalities that you have to build out, from motion planning to 3D visualization. For most of the common functionalities in robotics, you can find an open source ROS package. Some of the most notable open source ROS resources include:

• Ros_control: Ros_control is the go-to package for most robot’s main control loop, as the set of packages include controller interfaces, controller managers, transmissions, and hardware interfaces.
• URDF: URDF, or the Unified Robot Description Format, is an XML format that allows you to describe and represent a 3D model of your robot.
• MoveIt: MoveIt enables path and motion planning to allow you to generate high-degree of freedom trajectory through cluttered environments and avoid local minimums. For more information on motion planning, check out this article here.
• Navigation: This package supports mobile robots by serving as a 2D navigation stack that takes in information from odometry and other sensor streams and outputs safe velocity commands to a mobile base.
• Rviz: Rviz is the most used 3D visualization tool for ROS, a key functionality for most robotic software.
• Gazebo: Gazebo is a powerful simulation tool that streamline software testing, even with various physical constraints like gravity and wind. Gazebos suite of tools, libraries, and cloud services serves as a complete tool box for robotic simulation.
• Rosbridge: Rosbridge provides a JSON API that empowers communication between ROS and non-ROS environments. Many frontends are able to interface with rosbridge, including a WebSocket server for web browsers to interact with.

The Evolution of ROS

As arguably the most mature open source robotics project in the world, ROS has inevitably evolved over the years. In its early years with Willow Garage, it was developed alongside PR2, a humanoid robot that was able to navigate autonomously in its environment, and it aimed to be a scalable, standard robotic framework for all robotic software. The early levels of standardization and abstraction were guided by the PR2 characteristics: a single robot operating with no real-time requirements and strong network connectivity.

The first public distribution of ROS was released in 2009, known as ROS Mango Tango, or ROS 0.4. The 1.0 release coined Box Turtle was launched almost a year later in 2010, and it set a naming convention based on turtles. 5 more versions were released by Willow Garage before their dissolution, ending with ROS Groovy Galapagos in 2012. Under the oversight of the Open Source Robotics Foundation, ROS continued to develop and release new distributions starting with ROS Hydro Medusa in 2013.

However, by 2015, the deficiencies of ROS for commercial products were growing more and more apparent. Many critics pointed out ROS suffered from a single point of failure with the roscore. The roscore is a collection of nodes that are prerequisites for any ROS-based system; any flaw in the roscore meant failure for the software. Others pointed out the lack of security with ROS. Despite being one of the most adopted frameworks in the field of robotics, it still suffered from a variety of security issues that could interfere with the communication between ROS nodes. Finally, due to the nature of the origins of ROS with PR2, ROS never introduced real-time support, a functionality considered critical by many industrial applications.

While improvements to these issues could have been introduced and integrated into the existing ROS code, it was largely considered too risky to so dramatically alter the ROS system that was relied upon by so many people. With these concerns in mind, Open Robotics began an effort to create ROS 2.0, a parallel set of packages that could operate alongside ROS. The goal of the new framework was to address many of the shortcomings of ROS in industry. ROS 2 would be built for teams of multiple robots, small embedded systems, non-ideal networks, production environments, and real-time networks. Ardent Apalone, the first distribution release of ROS 2 was released in December of 2017, officially ushering in a new era of next-generation ROS development.

Beyond the high level differences mentioned above, there are many other changes from ROS and ROS 2. ROS uses mainly C++03 and targets Python 2, whereas ROS 2 mainly uses C++11 and is suitable for >= Python 3.5. Overall, there have been many efforts made to improve the flexibility of the ROS framework. ROS has a custom serialization format, can only choose between single-threaded execution or multi-threaded execution, and its roslaunch files are defined in XML with very limited capabilities. ROS 2 implementations are all based on the Data Distribution Service (DDS) standard, can support custom executors, and have launch files written in Python that enable more complex logic. Industry has been largely influential in suggesting changes to be made, and has guided many of the improvements so far.

Where is ROS now?

Since the transition from ROS to ROS 2, new ROS versions have stopped. ROS Noetic Ninjemys, the thirteenth and final ROS distribution release, was suitably released on World Turtle Day — May 23rd, 2020. The goal of this release is to provide support for developers and organizations that have not yet transitioned to ROS 2 and still need to work with ROS for a while. ROS Noetic’s End of Life is scheduled for 2025, so after that date, there will officially be no more of the original ROS.

Fortunately for us roboticists, ROS 2 has taken over the annual releases, with the most recent distribution, ROS 2 Humble Hawksbill, released on May 23rd, 2022. Since the previous year’s version ROS 2 Galactic Geochelone, Humble has introduced a variety of small features and quality of life improvements like support textures and embedded meshes for marker messages. An overview of the newest changes can be found here.

There’s still a lot of room for ROS 2 to grow. With no backwards compatibility with previous versions, many users are stuck with few wrappers except for the larger ones that have garnered support. Without the active wrappers, even integrating various state of the art algorithms like ORBSLAM3 or YOLOv5 can take more time and effort. ROS 2 also heavily relies on virtualization via docker containers. While this offers a slew of benefits like better dependency management and non-mixing of core library versions, for many roboticists, this might be unfamiliar territory. We’ve surveyed users across labs from UC Berkeley, Cornell, Virginia Tech, and Michigan: it takes on average 2 to 6 months to fully integrate a new robot with ROS 2 and to get robots to properly communicate. This combined with the sentiment that ROS is not yet “fit for production” has prevented ROS from fully emerging as the industry standard.

Despite this, the ROS community is more active than ever, with renewed community enthusiasm for ROS 2. With each new release of ROS 2, there are dozens of new innovations and offerings introduced. Take FogROS 2 as an example. Cloud robotics has long been an intriguing solution to many computing, storage, and resource management problems within robotics, but Fog robotics has recently emerged as another capability, allowing robots and IoT devices to leverage nearby Edge resources alongside Cloud data centers. Nevertheless, tapping into that power from modern cloud computing providers like AWS, GCP, and Azure is non-trivial to say the least. Introduced with the release of Humble Hawksbill, FogROS 2 serves as an open-source platform to streamline and facilitate both cloud and fog robotics compatible with the ROS 2 framework. Contributions to the ROS 2 open-sourced based of knowledge like FogROS 2 enable exciting progress across both research and industry.

Empowered by standard frameworks like ROS 2, robotic software is making leaps and bounds. It’s a great time to be a robot software programmer, so keep an eye out every World Turtle Day for the newest ROS 2 release and all of the development progress the community makes.