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 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 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 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.
This article has been moved to https://index.ros.org/doc/ros2/Contributing/Migration-Guide/.
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.
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 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.
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 approach to provide QoS (Quality of Service) policies for ROS 2.
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.
These articles are not finished or maybe not even started yet: