ROS 2 Introduction

What is ROS in a nutshell

Content Outline

    Before we start, let’s address the elephant in the room, or more precisely, the number in the title: “ROS 2” If this is your first time hearing about ROS, or if you want to understand what it’s about, you’re probably asking yourself: if the title is “ROS 2” that may imply there is a “ROS 1”. And yes, you are correct but, to be precise, there was a ROS 1. It reached end-of-life (EOL) in May 31 2025, see Noetic Ninjemys: The Last Official ROS 1 Release↗. But without getting into too much detail, think of ROS 2 as the successor to ROS 1. Sadly, the application programming interfaces (APIs) or, in simpler terms, the libraries that let you program and interact with a ROS system are not compatible between ROS 1 and ROS 2. Fortunately, all the concepts are compatible. So, learning ROS 2 is essentially learning ROS 1 (conceptually); you just need to learn the APIs.

    But if you are wondering:

    Important:

    Do I need to learn to ROS 1 to be able to learn ROS 2 (or vice versa), the answer is NO.

    If you’re a curious mind, at the end of this note we will discuss the architectural differences between ROS 1 and ROS 2. That will give you the big picture of those differences and what they imply.

    Harley: Insert some information about from now on the term “ROS” refers to the Ecosystem without distribution and ROS 1 and ROS 2.

    Why Do We Need ROS?

    If you think this is a trivial task to the point of “just share the code”, I honestly wouldn’t blame you for thinking that, but the reality is that is not a trivial task.

    I like to start with a mental exercise using a “toy example”.

    The LiDAR sensor can be as cheap as the RPLidar A1↗ ~100 USD or expensive as the Velodyne Puck↗ ~4,600 USD (there are more expensive LiDAR sensors), but apart from the price difference they have different communication interfaces. The RPLidar A1 uses an adapter from UART-to-USB and the Velodyne uses a Ethernet connection.

    To motivate the example let’s think about a 2D LiDAR and the following pipeline:

    A toy example.

    The first pieces of software that would later become ROS were being developed at Stanford University by two master’s students Eric Berger and Keenan Wyrobek in the Personal Robotics Program↗. The first steps in creating this unified system began with building the robot called PR1↗ as a prototyping hardware to start working on the software from, borrowing best practices from other macros and open source software such as switchyard from Morgan Quigley another PhD student who had been working on STAIR↗ (Stanford Artificial Intelligence Robot) at the Stanford Artificial Intelligence Lab. Eric Berger and Keenan Wyrobek in search of funding to continue the development of PR1 met Scott Hassan founder of Willow Garage a technology incubator. Hassan shared Berger and Keenan’s vision of creating a unified system for robotics and invited them to work at Willow Garage, making the first ROS code commit↗ on November 7, 2007.

    Willow Garage began developing the robot PR2 using ROS as runtime software, as successor of PR1. Soon after ROS was released (0.4 Mango Tango) followed by a paper showing the tool “Robot Visualization” (RVIZ) and the first article about ROS (ROS: an open-source Robot Operating System↗).

    In 2010 Willow Garage started the creation of Open Source Robotics Foundation (OSRF) and then in 2013 OSRF became the main maintainer of ROS as Willow Garage would be absorbed by its founders. Then Clearpath Robotics↗ takes over the support responsibilities for PR2 in early 2014, as described in PR2 Support transferred to Clearpath Robotics↗. Since then OSRF has taken over the primary development of ROS, releasing a new version every year.

    A key later restructuring step happened in December 2022, see Intrinsic Acquires OSRC and OSRC-SG↗, when Open Robotics (Brian Gerkey) announced that Intrinsic↗ was acquiring assets from the for-profit subsidiaries “Open Source Robotics Corporation” (OSRC) and OSRC-SG (Singapore), not OSRF itself. In that same post, Gerkey explains the organizational background: OSRF was created in 2012 as the nonprofit steward; OSRC was created in 2016 as a for-profit subsidiary for commercial engagements; and OSRC-SG was created two years later to expand Asia-Pacific involvement, with Gerkey noting that its creation led directly to the release of Open-RMF.

    That 2022 transaction is explicitly connected to the next governance step in Open Robotics’ March 18, 2024 Announcing the Open Source Robotics Alliance↗. Open Robotics states that the sale of OSRC was the first step in a broader restructuring vision, and that the launch of the Open Source Robotics Alliance (OSRA)↗ was the next major step. Open Robotics describes OSRA as a new initiative from OSRF to improve long-term sustainability and health of its open-source robotics projects, using a mixed membership / meritocratic model and assigning OSRA responsibility for governance of ROS, Gazebo, Open-RMF, and supporting infrastructure, under OSRF board oversight via a TGC/PMC structure. How it works - OSRA↗. On the same date (March 18, 2024), Intrinsic published its own statement supporting OSRA: Supporting the Open Source Robotics Alliance (OSRA)↗, saying it would join as one of the inaugural members and (for the first time) participate in governance via the Technical Governance Committee (TGC) and Project Management Committees (PMCs) under the chartered structure.

    Here an official blog about Why ROS↗.

    What is ROS

    Although this is the official definition of ROS, in my experience interacting with people who know nothing about ROS, or who are new to robotics, the definition contains terms like “middleware (suite)”, “operating system” and “framework” that often lead to the wrong mental model of what ROS is. Even the name “Robot Operating System” leads people to think it is something like Windows, macOS, or GNU/Linux. The reality is that ROS is not an operating system in the traditional sense of what most people think an operating system is. So, you may be wondering: why is it called a “Robot Operating System” if it is not an OS (as we normally know)? Well, the answer is embedded in the definition:

    […] it has hardware abstraction functions, low-level device control, inter-process communication, package management, network communication and a wide range of macros […]

    This is the key to calling ROS an operating system: it provides functionalities that are inherently associated with what, from a technical point of view, an operating system is expected to do. For that reason, some definitions describe ROS as a meta-operating system (see What is ROS? - ROS wiki↗). However, telling newcomers that ROS is a meta-operating system is often even more confusing than simply calling it an operating system.

    If you decide to lean into the wording of “middleware” or “middleware suite”, a common question from newcomers and students who want to learn ROS is: what exactly is middleware? The problem is that there is no single, universal definition of middleware that everyone agrees on. Different communities and industries use the term in slightly different ways, which can make it harder for beginners to build a clear mental model of what ROS actually is.

    The word “framework” is also problematic, especially for people from other backgrounds, such as web development. In those contexts, a framework usually implies a specific way of structuring code, a defined development style, and a set of conventions you are expected to follow. ROS does provide tools, libraries, and conventions, but thinking of it as just another framework can still lead to an incomplete or misleading understanding of what it does in practice.

    As of today, ROS is all of those things and more, so it is hard to encompass it in a single term that defines it completely while still conveying its core idea. However, from my experience interacting with learners, I have found that the following simplified definition helps people build a clearer mental model of what ROS is:

    This simplified definition lays the foundation for a broader understanding of what ROS is, and it is by no means a replacement for the more complete official definition. On the contrary, it is designed to complement it, but with less technical verbosity.

    ROS Ecosystem Conceptually

    ROS Ecosystem Conceptually.

    Base (Host) Operating System

    Middleware + Plumbing + Clients APIs

    The middleware layer of ROS serves as the backbone for client APIs (in multiple languages), allowing users to write code that interacts with a ROS system through a common communication infrastructure.

    Execution Models

    • Iterative execution
    • Event-oriented execution

    Communication Paradigms

    • Publish/Subscribe (asynchronous)
    • Services (synchronous)
    • Actions (asynchronous)

    Conventions

    ROS also provides conventions that improve interoperability and collaboration, such as:

    • Reference frames
    • Message definitions for interoperability
    • Code and package organization conventions

    Tools

    ROS includes a rich set of tools for development and debugging, including:

    • Logging and plotting
    • Communication graph visualization
    • Diagnostics
    • Visualization
    • Simulation

    Capabilities

    On top of its core infrastructure, the ROS ecosystem enables higher-level robotics capabilities such as:

    • Control
    • Perception
    • Navigation
    • Manipulation
    • Planning System
    • And more

    Community

    ROS is also a large and active community that includes:

    • Schools and Universities
    • Company. See this amazing collection of companies using ros, ROS Robotics Companies↗ by Víctor Mayoral Vilches.
    • Research Institute
    • Hobbies

    ROS Versions

    If you are new to ROS you are probably a little frustrated trying to understand why there are two ROS versions, when to use one over the other or even which one to learn. As I mentioned at the beginning, don’t really worry so much about it and to keep things simple, think of ROS 1 as the old one and ROS 2 as the new one.

    The truth is, there are many technical details about the differences that are not necessary to cover at this point, but if you are curious here it is: Changes between ROS 1 and ROS 2↗.

    Is correctly spelled with a space: ROS 2 or ROS 1, check the Trademark Rules And Guidelines 2022↗ section “ROS in text”.

    ROS Distributions

    From this definition, let us, for now, refer to a “ROS package” simply as a “software package” since we have not yet discussed what a ROS package is. We will return to that concept later in a separate note dedicated to ROS Packages.

    Each ROS distribution defines a coherent, tested target platform matrix, including the operating system version, architecture, middleware support, and key dependency versions. In other words, a ROS distribution is not just a version label, but a specific combination of ROS packages and system dependencies that has been validated to work together. In practice, this gives users more predictable binaries, clearer “continuous integration” (CI) coverage, and more reliable packaging support, such as the common package manage in Ubuntu apt hosting packages and official archives.

    Seen from this perspective, the ROS distribution model makes practical sense: it pins a tested software stack to a specific Ubuntu generation, rather than attempting to support every platform combination equally. That constraint is what enables the ecosystem to provide stable binaries, reproducible builds, and dependable installation paths for users.

    The concept of ROS Distributions.

    Full list of ROS distributions:

    ROS Variants

    Each ROS distribution is distributed in predefined installation variants, each designed for a different level of functionality. These variants range from minimal core components to more complete development setups.

    The list of ros2-variants↗:

    • desktop
    • desktop_full
    • perception
    • ros_base
    • ros_core
    • simulation

    Example how to install a ros2-variants. But in reallity you need to do more things as describe in the official documentation, e.g. Ubuntu (deb packages)↗

    sudo apt install ros-humble-desktop

    the format is:

    sudo apt install ros-<distro>-<variant>

    In practice, these variants provide convenient starting points depending on whether you need a lightweight runtime, a general development environment, or additional tools for perception and simulation. Thus, the concept of a variant is best understood in relation to a ROS distribution, as illustrated in the following diagram.

    ROS Programming Languages

    Important:

    Nope, ROS is NOT a programming language.

    ROS is a ecosystem, not a language itself. You do not “code in ROS” the way you code in Python or C++, instead you write programs using ROS client-libraries and tools for visualization, simulation or debugging.

    One of ROS’s strengths is that it can intermix programming languages within the same robotic system. This means you can write programs in different languages and still have them communicate through ROS’s middleware layer. In practice, ROS provides official support for the main languages used in robotics development, including:

    • C
    • C++
    • Python

    This flexibility allows developers to choose the most suitable language for each part of the system, for example, using C++ for performance-critical components and Python for rapid prototyping or higher-level orchestration.

    Architecture ROS 2

    Architecture ROS 1 vs. ROS 2.

    Source code for ROS 2 base-stack:

    Do We Really Need ROS?

    ROS Resources

    ROSources ? (bad joke):