The Robot Operating System, commonly referred to as ROS, has become an indispensable tool in the development of robotic systems, particularly in research. Since its introduction in 2007, ROS has rapidly gained popularity among robotics developers, with countless researchers worldwide utilizing it. As an open-source platform, it continues to grow its user base, thanks to the extensive sharing of information and resources within its community. While it is occasionally referred to as the Robotics Operating System, the correct name is Robot Operating System.
The popularity of ROS stems from its numerous advantages. It simplifies communication between essential programs in robotic systems and is highly modular, making it easy to use pre-existing programs and libraries that have been shared by the community. Because of these features, ROS is attracting attention not only from researchers but also from industries, and its potential applications are expected to expand further. However, ROS has not seen as widespread adoption in industrial robotics as it has in research. This is due to its inherent limitations, as it was primarily designed with research-focused development in mind.
In this post, we’ll explore the fundamentals of ROS, look at real-world applications, and explain how it can contribute to robotics research in detail.
By the way, if you are interested in getting to know how to implement communications between different processes outside ROS, I have a helpful post introducing examples using ZeroMQ.
Table of Contents
Robot Operating System: How it started
The Robot Operating System (ROS) project began in 2007 at the Stanford Artificial Intelligence Laboratory in the United States. It was created to help robotics developers simplify the process of developing and researching complex robotic systems. The project saw significant growth in 2013 when Willow Garage, once the center of robotics software and hardware development, contributed heavily to the development and dissemination of ROS, pushing it further forward.
The reason for the emergence of ROS was largely due to the complexity and inefficiency in robotics research and development. Roboticists often had to manually implement hardware control, sensor integration, and algorithm development from scratch. Each project would use different hardware and software, making reuse and collaboration across research teams difficult. As a result, the demand for a standardized platform grew, one that could lower the barriers to entry for robotic development.
ROS ultimately became the standard platform for robotics research and development, significantly reducing the complexity of building robotic systems and promoting collaboration among researchers. After Willow Garage’s initial leadership, development and maintenance are now overseen by Open Robotics, and although its use in industry is still somewhat limited, ROS has made notable strides beyond academic research.
Robot Operating System: Before and After ROS
Robotic systems are inherently complex, as they require multiple components to function together seamlessly. This means that for systems like autonomous vehicles or bipedal robots, efficient communication between programs is essential to ensure real-time responsiveness. Before ROS, the development process was far more complicated.
Development Before ROS
Building a system for experimentation often required researchers to learn how to program and operate each hardware component individually. While hardware manufacturers might offer some resources, the inherent complexity of integrating multiple systems into a single robotic platform meant researchers had to spend significant time on implementation. Outsourcing these tasks was sometimes possible with additional funding, but in most academic labs, the burden of system integration often fell on graduate students.
The lack of standardized platforms across different hardware manufacturers meant that even when code was shared between research groups, the differences in implementation made it difficult to reuse. This was a major hindrance in a field where comparing and building upon other researchers’ work is critical. The inefficiency and lack of standardization in robotics system development was a significant obstacle, which ROS was designed to address.
Development After ROS
With the release of ROS and the growth of its community, much of the development process has been simplified. One of ROS’s greatest strengths is its ability to facilitate seamless communication between different programs. Networking knowledge, which was once a requirement for implementing communication protocols, is no longer necessary to the same extent. ROS provides easy-to-use communication mechanisms, such as broadcasting and remote procedure calls (RPC), both of which are critical in robotic systems, depending on the task at hand.
Another major advantage is the standardization of data formats, which has significantly improved development efficiency. Before ROS, even slight differences in data structure between similar sensors made it difficult to swap or replace programs. It promotes the use of standardized data formats, making it much easier to integrate and reuse programs within the its ecosystem. This also eliminates the need for researchers to repeatedly learn and interpret data structures when using code from other teams.
Thanks to these conveniences, the use of ROS within the robotics research community has grown substantially. As more users adopt the platform, the number of shared resources has increased, leading to a positive feedback loop where the advantages of using ROS continue to grow.
Why ROS is Effective
ROS comes with several advantages, but two stand out the most: the ease of inter-process communication (IPC) and the standardization of data.
Convenience in Inter-Process Communication (IPC)
ROS abstracts each program into a concept known as a node and makes communication between nodes simple. There are three main communication methods in ROS, and I will discuss two of them below.
1. Broadcasting Method (Topic-Based Communication)
The broadcasting method supports one-to-many asynchronous data transmission. In ROS, broadcasting is implemented through topics.
Features
- One-to-Many Communication: A node can publish a message, and multiple nodes can subscribe to receive that message. For instance, a robot’s sensor data (such as camera or LiDAR) can be published by one node, and various other nodes can subscribe to use the sensor data.
- Asynchronous Communication: When a message is published, subscribing nodes receive it asynchronously in real-time. The publisher node doesn’t need to know how many subscribers there are or when they will receive the data. Subscribing nodes process data asynchronously as it arrives.
- Periodic or Event-Driven: Messages can be published periodically as data updates (e.g., sensor data) or when specific events occur, making this communication structure ideal for continuously changing information or event-based triggers.
- Scalability: Broadcasting is highly scalable, as multiple nodes can communicate freely and share data, making it especially useful for systems where several nodes need to work with the same data.
Examples
- When a robot’s camera sensor publishes an image as a topic, subscribing nodes can use it for tasks like image processing, object recognition, or path planning.
- In multi-robot systems, each robot can publish its location, and other robots can subscribe to this information to collaborate effectively.
Advantages
- Asynchronous, many-to-many communication is advantageous for expanding systems and handling complex communication structures.
- It is well-suited for transmitting sensor data, status information, or other data that requires real-time communication.
Disadvantages
- There is no response or acknowledgment process for published data. Once data is published, the publisher has no way of knowing how the subscribers will handle it.
- It’s not suitable for request-response communication patterns.
2. Service Method (Request-Response Communication)
The service method provides one-to-one synchronous communication, based on a request-response pattern. In ROS, a service handles synchronous requests and responses between a client and a server.
Features
- One-to-One Communication: The client sends a request to the server, and the server processes the request and returns a response. The client waits until the server responds.
- Synchronous Communication: After sending the request, the client waits for the server’s response. Since this is synchronous, the client cannot perform other tasks until the response is received.
- One-Time Operations: Services are generally used for one-time operations or calculations. Unlike broadcasting, services are used when a client needs to send a request only when necessary. For example, a robot might send a command to move to a specific location, and the server would return a response once the task is completed.
Examples
- When a robot needs to plan a path to a target location, the client sends the target coordinates to the server, which calculates the path and sends the result back.
- It’s also suitable for one-time actions, like querying sensor status or controlling a motor once.
Advantages
- Guaranteed Response: Since the client waits for a response, it can verify that the request was successfully processed.
- Simple One-to-One Communication: It’s ideal for handling simple tasks where only a single request and response are required.
Disadvantages
- Lack of Scalability: The service method only supports one-to-one communication, making it less suitable for systems where multiple nodes need to exchange data simultaneously.
- Not Suitable for Asynchronous Tasks: Because the client waits for a response, this method is not ideal for real-time systems where asynchronous communication is necessary.
Advantages in Standardization
One of the key strengths of ROS is that it provides a standardized development environment for robotics research and development. This is especially beneficial when creating new programs by leveraging existing resources.
Modular Standard Interfaces
ROS offers standardized interfaces for various components of a robotic system, such as sensors, actuators, controllers, and algorithms. For example, sensor data is transmitted and received in a predefined message format, which allows different sensors or hardware to be handled using the same message structure. This standardization makes it convenient for researchers to replace hardware or port their systems to different platforms.
Reusable Package Ecosystem
ROS offers a vast ecosystem of packages—standardized collections of robot-related algorithms and drivers. Researchers can leverage these pre-developed packages to build on existing work, which significantly reduces the time needed for new projects or studies. Furthermore, because these packages are managed within the ROS ecosystem in a standardized way, they are highly interoperable, making it easier to integrate them into different systems.
Support for Various Hardware Platforms
ROS provides standardized drivers that maintain compatibility with a wide range of robot hardware platforms. This allows researchers to easily switch between or add different hardware without being locked into a specific system. The ability to support various hardware platforms gives researchers the flexibility to adjust their experimental environments and test different hardware setups.
Strengthened Collaboration with the Community
By using standardized software and protocols, ROS helps researchers and developers around the world share their work more easily. This enables the exchange of research results and fosters collaboration within the global robotics community. Standardized code and modules can be quickly applied to various projects, accelerating the pace of innovation in robotics research.
Limitations when using ROS
Despite its many advantages, ROS is not widely used in industrial systems involving robotics. This is largely due to its design as an open-source framework focused on research and development, which brings certain limitations.
Inefficiency Traded for Convenience
While ROS makes inter-process communication (IPC) easy to implement, it is not always the most technically efficient communication method. The framework prioritizes flexibility and general-purpose use, which can result in unnecessary latency and timing issues. This added complexity makes the communication system heavier than it needs to be, leading to inefficiencies in some use cases.
Incomplete Maturity of Open-Source Resources
Not all open-source resources suffer from this issue, but many open-source libraries and frameworks are released without fully developed reliability, especially in terms of stability. Unlike commercial projects that are backed by significant funding and large engineering teams, open-source projects often lack the resources needed to ensure perfection. While ROS itself has improved significantly over time, benefiting from contributions from many users, other open-source packages available for ROS can vary greatly in quality. When integrating multiple open-source packages, ensuring system stability becomes even more challenging. In industrial settings, where even minor errors can lead to significant losses, this can be a critical issue.
Security Concerns
In industrial applications, most software modules are proprietary and considered confidential, while ROS encourages resource sharing among users. This open-sharing approach makes it less suitable for protecting intellectual property.
Moreover, ROS was developed with research use in mind, so it lacks robust security measures to prevent hacking or other security threats. This makes it less favorable for industries where security is a top priority.
Personal Opinions
While ROS is an excellent tool that has made significant contributions to robotics research—and I frequently use it in my own work—I try not to become overly reliant on it. One reason for this is the concern that my development skills could become overly dependent on it, to the point where I would feel almost incapacitated without it. Relying too heavily on a tool without fully understanding the underlying systems can lead to situations where even simple problems are handled with unnecessarily complex solutions, just because the tool is being used beyond its intended purpose.
I believe it’s important to first understand what kind of framework ROS is and carefully consider whether it’s the right tool for the problem at hand before deciding to use it. This kind of decision-making process will make developers more thoughtful and capable in their approach.
On the other hand, I also think that taking the time to dive deeper into how certain features of ROS are implemented can offer a valuable opportunity to grow as a developer. For instance, understanding the Boost library, which it uses for networking, could empower you to develop similar functionality without relying on it, optimizing it for your specific use case.
Conclusion
In this post, we explored both the strengths and limitations of ROS from various perspectives. It is a highly effective tool that allows researchers to quickly and easily implement many necessary aspects of robotic systems that might otherwise detract from focusing on the core research. This makes it an invaluable resource for robotics research. However, outside of research purposes, it has certain limitations in terms of scalability, and it may not always be the ideal solution for all robotics development projects. It’s important to recognize that it is not the one-size-fits-all answer for every robotics application.