Skip to the content.

Default DDS provider template


Every year, the ROS 2 TSC is mandated to choose a default RMW provider for the next ROS 2 release. In 2021, that selection will affect Humble Hawksbill, the release scheduled for May 2022. The default RMW provider must be a Tier 1 provider as specified in REP-2000, and must be open-source. For Humble Hawksbill, the two RMW providers that meet this criteria are rmw_cyclonedds_cpp and rmw_fastrtps_cpp.

In order to make an informed decision, the TSC needs to be provided with a report that has details about each of the available choices. The report is comprised of data directly from the RMW providers, plus common language that Open Robotics provides. This template is the series of questions that each of the RMW providers should answer for that report. Every question listed below was submitted either by TSC members, or from members of the community based on real world usage.

Remember that the TSC and end-users mostly care about how the DDS implementation works as part of the ROS 2 system, not standalone. Each response should be measured in context of the entire ROS 2 stack, or should be measured for both the DDS implementation and the ROS 2 stack where there is a significant difference.

It is up to the DDS provider to answer the questions in the way that they feel is best. That includes choosing the hardware platform, the operating system, the tuning parameters, individual metrics, etc. Keep in mind that most of the TSC members are users of ROS 2 in robotics applications, so the choices that are made should reflect that. Choosing only high-end, cloud-connected machines, or only microcontrollers, probably does not match the day-to-day experience of ROS 2 users. Each choice that is made should be documented, and the rationale for each choice should be explained in the responses to the question.

Each response should be as detailed, accurate, and reproducible as possible. That means that a detailed description of how any data was collected and analyzed should be included with each answer. Graphs are very useful and encouraged for each answer where it makes sense. Where relevant, graphs should show the data from the same test run using rmw_cyclonedds_cpp and rmw_fastrtps_cpp.

Data should be taken using the specific ros2.repos file. When building these packages, they must be built in the default configuration as they will be delivered in ROS 2 Humble.

When the RMW providers are ready to deliver the report (see the Relevant Dates below), they should open a pull request to the TSC repository, targeting The format of the reports should be Markdown, as that is what will be rendered by GitHub into the final report.

Relevant Dates


The length of the response to all of the questions combined should be no more than 4000 words, with as many graphs as needed to support that. If additional space is needed, feel free to provide a link to an external resource with more information.




We’ve had a lot of reports from users of problems using ROS 2 over WiFi. What do you think the causes of the problems are, and what are you doing to try to address these problems?




In this section, you can add any additional information that you think is relevant to your RMW implementation. For instance, if your implementation has unique features, you can explain them here. These should be things technical in nature, not just marketing. Please keep your responses limited to 2000 words with a reasonable number of graphs; we’ll truncate anything longer than that during editing of the report. If you cannot fit all of your data into the limit, feel free to provide a link to an external resource which we’ll include in the report.