ROS 2 Design

This site is repository of articles which are designed to inform and guide the ROS 2 design efforts. The goal of the ROS 2 project is to leverage what is great about ROS 1 and improve what isn’t.

If you would like to contribute to this site, checkout the contribute page to learn how. If you would like to contribute to the ROS 2 project, see this page for more details.

The best mailing list for discussing these topics is, the Special Interest Group on Next-Generation ROS mailing list. You can view the archives here.

To read more about ROS 2’s detail and architecture, please see the Science Robotics paper introducing ROS 2. If you use ROS 2 in your work, please cite the following:

S. Macenski, T. Foote, B. Gerkey, C. Lalancette, W. Woodall, “Robot Operating System 2: Design, architecture, and uses in the wild,” Science Robotics vol. 7, May 2022.

    author = {Steven Macenski  and Tully Foote  and Brian Gerkey  and Chris Lalancette  and William Woodall },
    title = {Robot Operating System 2: Design, architecture, and uses in the wild},
    journal = {Science Robotics},
    volume = {7},
    number = {66},
    pages = {eabm6074},
    year = {2022},
    doi = {10.1126/scirobotics.abm6074},
    URL = {}


Here is a list of the articles (white papers) which have been written so far. These articles should serve as an entry point for anyone wanting to join the conversation about a variety of the topics that relate to ROS 2.


Why ROS 2?

This article captures the reasons for making breaking changes to the ROS API, hence the 2.0.

Stories driving the development

This article captures some stories which drive the direction of features in ROS.

The build system “ament_cmake” and the meta build tool “ament_tools”

This article describes the build system “ament_cmake” and the meta build tool “ament_tools”.

A universal build tool

This article describes the rationale for a universal build tool.

Changes between ROS 1 and ROS 2

This article provides an overview about the changes being made in ROS 2 compared to ROS 1.



This article makes the case for using DDS as the middleware for ROS, outlining the pros and cons of this approach, as well as considering the impact to the user experience and code API that using DDS would have. The results of the “ros_dds” prototype are also summarized and used in the exploration of the issue.

ROS 2 middleware interface

This article describes the rationale for using an abstract middleware interface between ROS and a specific middleware implementation. It will outline the targeted use cases as well as their requirements and constraints. Based on that the developed middleware interface is explained.

Node to Participant mapping

This article analyzes the performance implications of enforcing a one-to-one mapping between ROS Nodes and DDS Participants, and proposes alternative implementation approaches.

ROS QoS - Deadline, Liveliness, and Lifespan

This article makes the case for adding Deadline, Liveliness, and Lifespan QoS settings to ROS. It outlines the requirements and explores the ways it could be integrated with the existing code base.


Interface definition

This article specifies the file format describing the data structures exchanged by ROS 2 components to interact with each other.

Mapping between ROS interface types and DDS IDL types

This article specifies the mapping between the ROS interface types and the DDS types.

Generated C++ interfaces

This article describes the generated C++ code for ROS 2 interfaces.

Generated Python interfaces

This article describes the generated Python code for ROS 2 interfaces.

IDL - Interface Definition and Language Mapping

This describes defining interfaces using a subset of the Interface Definition Language (IDL).

Interface definition using .msg / .srv / .action files

This article specifies the file format coming from ROS 1 describing the data structures exchanged by ROS components to interact with each other.


ROS 2 DDS-Security integration

Robotics is full of experimentation: evaluating different hardware and software, pushing ahead with what works, and culling what doesn’t. ROS was designed to be flexible to enable this experimentation; to allow existing components to easily be combined with new ones or swapped with others. In ROS 1, this flexibility was valued above all else, at the cost of security. By virtue of being designed on top of DDS, ROS 2 is able to retain that flexibility while obtaining the ability to be secured by properly utilizing the DDS-Security specification. This article describes how ROS 2 integrates with DDS-Security.

ROS 2 Access Control Policies

This article specifies the policy format used for access control when securing ROS subsystem.

ROS 2 Security Enclaves

This article specifies the integration of security enclaves.

ROS 2 Robotic Systems Threat Model

This document describes security concerns robotic systems built using ROS 2 may face. The first section describes potential threats to ROS 2 systems. The second section describes potential attacks and mitigations on a reference platform (TurtleBot 3). The third covers potential attacks, mitigations and some preliminary results in an industrial reference platform (MARA modular robot).


ROS on ZeroMQ and Friends

This article makes the case for using ZeroMQ and other libraries to implement a new, modern middleware for ROS. This article also covers the results of the ZeroMQ based prototype made by OSRF.

RPC API design in ROS

This article is an exploration of possible design patterns for the next generation of ROS Remote Procedure Call interfaces. We focus here on specifying the user API and leave the implementation unspecified. It is expected that there are one or more RPC implementations which can be used, such as Apache Thrift, ROS RPC, or MsgPack.

Parameter API design in ROS

This article is proposed design for the interfaces for interacting with parameters in ROS 2. We focus here on specifying the system design and leave the implementation unspecified.

Unicode Support

This article describes how ROS 2 will support sending multi-byte character data using the Unicode standard. It also describes how such data will be sent over the ROS 1 bridge.

Introduction to Real-time Systems

This article is a brief survey of real-time computing requirements and methods to achieve real-time performance.

Proposal for Implementation of Real-time Systems in ROS 2

Proposal for a test-driven approach to the real-time performance requirement in ROS 2.

Clock and Time

This article describes the ROS primitives to support programming which can run both in real time as well as simulated time which may be faster or slower.

Topic and Service name mapping to DDS

This article describes the proposed mapping between ROS topic and service names to DDS topic and service names.

Remapping Names

Topics, parameters, and services are identified by Names. Names are hard coded in ROS nodes, but they can be changed at runtime through remapping. Without remapping every instance of a node would require changes in code. This article describes the requirements, rationale, and mechanisms for remapping names in ROS 2.

ROS 2 Launch System

The launch system in ROS is responsible for helping the user describe the configuration of their system and then execute it as described. The configuration of the system includes what programs to run, where to run them, what arguments to pass them, and ROS specific conventions which make it easy to reuse components throughout the system by giving them each different configurations. Also, because the launch system is the process (or the set of processes) which executes the user’s processes, it is responsible for monitoring the state of the processes it launched, as well as reporting and/or reacting to changes in the state of those processes.

ROS 2 Launch XML Format

The XML format for declarative launch descriptions in the ROS 2 launch system.

ROS 2 Launch Static Descriptions - Implementation Considerations

The launch system in ROS 2 aims to support extension of static descriptions, so as to easily allow both exposing new features of the underlying implementation, which may or may not be extensible itself, and introducing new markup languages. This document discusses several approaches for implementations to follow.

ROS Command Line Arguments

This article describes ROS 2 nodes command line arguments and their syntax.

Migration guide from ROS 1

This article has been moved to


Actions are one of the three core types of interaction between ROS nodes. This article specifies the requirements for actions, how they’ve changed from ROS 1, and how they’re communicated.

Cross-compiling ROS 2 packages

This article is a design proposal for developing a ROS 2 tool that sets up and manages sysroot environments for cross-compilation with the objective of being simple and extensible. Extending support for new cross compilation configurations using colcon mixins is also proposed.

Topological Discovery and Communication Negotiation

This article lays out the logical components and possibilities within a discovery and transport negotiation system. This article was written to try and understand the different possibilities for how the middleware could be implemented.

Intra-process Communications in ROS 2

Description of the current intra-process communication mechanism in ROS 2 and of its drawbacks. Design proposal for an improved implementation. Experimental results.

Managed nodes

This article describes the concept of a node with a managed life cycle. It aims to document some of the options for supporting manage d-life cycle nodes in ROS 2. It has been written with consideration for the existing design of the ROS 2 C++ client library, and in particular the current design of executors.

Per-Package Documentation

This article describes the requirements and design of ROS 2’s per-package documentation system.

ROS 2 Quality of Service policies

This article describes the approach to provide QoS (Quality of Service) policies for ROS 2.

External configurability of QoS policies.

This article describes a mechanism to allow reconfiguration of QoS settings at startup time.

ROS 2 Message Research

This article captures the research done in regards to the serialization component, including an overview of the current implementation in ROS 1 and the alternatives for ROS 2.

Unique Network Flows

Enable unique network flow identifiers for publishers and subscriptions in communicating nodes

Zero Copy via Loaned Messages

Additional Resources