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.
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.
This article captures the reasons for making breaking changes to the ROS API, hence the 2.0.
This article captures some stories which drive the direction of features in ROS.
This article describes the build system “ament_cmake” and the meta build tool “ament_tools”.
This article describes the rationale for a universal build tool.
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.
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.
This article analyzes the performance implications of enforcing a one-to-one mapping between ROS Nodes and DDS Participants, and proposes alternative implementation approaches.
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.
This article specifies the file format describing the data structures exchanged by ROS 2 components to interact with each other.
This article specifies the mapping between the ROS interface types and the DDS types.
This article describes the generated C++ code for ROS 2 interfaces.
This article describes the generated Python code for ROS 2 interfaces.
This describes defining interfaces using a subset of the Interface Definition Language (IDL).
This article specifies the file format coming from ROS 1 describing the data structures exchanged by ROS components to interact with each other.
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.
This article specifies the policy format used for access control when securing ROS subsystem.
This article specifies the integration of security enclaves.
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).
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.
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.
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.
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.
This article is a brief survey of real-time computing requirements and methods to achieve real-time performance.
Proposal for a test-driven approach to the real-time performance requirement in ROS 2.
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.
This article describes the proposed mapping between ROS topic and service names to DDS topic and service 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.
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.
The XML format for declarative launch descriptions in the ROS 2 launch system.
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.
This article describes ROS 2 nodes command line arguments and their syntax.
This article has been moved to https://index.ros.org/doc/ros2/Contributing/Migration-Guide/.
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.
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.
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.
Description of the current intra-process communication mechanism in ROS 2 and of its drawbacks. Design proposal for an improved implementation. Experimental results.
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.
This article describes the requirements and design of ROS 2’s per-package documentation system.
This article describes the approach to provide QoS (Quality of Service) policies for ROS 2.
This article describes a mechanism to allow reconfiguration of QoS settings at startup time.
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.
Enable unique network flow identifiers for publishers and subscriptions in communicating nodes
These articles are not finished or maybe not even started yet: