ROS2 Strategy review 09/2015

This page is intended to list issues with the ROS2 Strategy. It has been announced at ros.users mailing list: http://lists.ros.org/lurker/thread/20151002.132624.a2e2ea35.en.html

At the point of writing (09/2015), the following state of affairs can be used to understand the strategy of ROS2:

1. ROS2 uses DDS-implementations as the default communication layer, this decision has been announced #ros2announce, #ros2query, #ros2whydds

2. ROS2 selects one of several DDS implementations at link time (C++, ...) or runtime (Python, ...) #ros2rmw

3. The only DDS implementations with a standard Open-Source license are OpenSplice and eProsima

4. OpenSplice however has seen only 3 release commits in the last 12 months, and less than 50 in the last 4 years (#OpenhubOpenSplice)

5. OSRF still negotiates with RTT Connext over providing a suitable open-source license, a non-standard free-for-research license is available #ros2announce

6. ROS2 core packages and tool support sources are completely separated from ROS1 sources

7. The ROS2 client API is not backwards compatible with ROS1 Discussion

8. The ROS2 build tool (ament) is not backwards compatible with catkin Discussion Migration guide with idea to add backwards compatibility

9. All message definition packages are being duplicated as ROS2 packages Discussion1 Discussion2

10. Some message definitions differ between ROS1 and ROS2 in name and structure (see below)

11. Many core ROS tools will need to be rewritten for ROS2 (rosrun, rosmsg, rosnode, rostopic, rosparam, rviz, rqt, roslaunch, ...) Discussion

12. ROS2 defines different language baselines than ROS1 (Python3, C++11) Detail

13. OSRF goal for ROS2 is to fix flaws in ROS1 such as Windows support, connectivity over lossy networks, multi-robot, which are essential for industry users
14. OSRF promises that ROS1 will continue to be released for a long time

15. No REP, not even in draft form, has been created for any ROS2 feature. Documentation is available at #ros2design

16. ROS2 can be installed side-by-side with ROS1
17. ROS1 topics and ROS2 topics can be bridged via relay nodes (1 for each topic)
18. ROS1 and ROS2 services/actions cannot yet cross the border between ROS1 and ROS2

Planned / proposed message structure changes:

• Removal of seq from Header

• Message Format changes

  • Header header changes to std_interfaces/Header header
  • time changes to builtin_interfaces/Time
  • duration changes to builtin_interfaces/Duration

• Proposal of diverse changes (CameraInfo, PointCloud)

Review Claims and Rebuttals

Quality and effort

Software forks reduce community synergies

Claim: When some teams use ROS2, and other teams use ROS1, the innovation rate in the robotics community decreases as the teams cannot share packages and features easily among each other. [TK]

Rebuttal: This will eventually be okay when everyone uses ROS2. Several libraries can be implemented in middleware-agnostic ways, too.

Software forks discourages contributions

Claim: When ROS1 is to be end-of-lifed in the future and ROS2 is not quite ready yet, maintainers have little incentive to contribute to either. [TK]

Rebuttal: Hopefully the community will be excited about ROS2 and contribute, and feel loyalto ROS1 and continue to contribute.

Too many changes to be reviewable

Claim: By creating ROS2 from scratch rather than making small incremental changes to ROS1, it is impractical for the community to review all changes. [TK]

Rebuttal: Some reviews are done by individual community members who follow certain github repos. Example: Node lifecycle Example parameters

OSRF lacks resources to both support ROS1 and create ROS2 adequately

Claim: OSRF is strained with just supporting the ROS1 ecosystem. Given ROS2 shares no code with ROS1, OSRF will have to spread its sparse resources over two middleware ecosystems, causing a general loss of quality and innovation rate. [TK]

Rebuttal: OSRF is willing to meet that challenge.

Migration

Too many APIs have breaking changes

Claim: To migrate a ROS1 package, it will need changes to the buildsystem, the client API, the message structures, dynamic reconfigure, pluginlib/nodelets, roslaunch files, rosbag, etc. [TK]

Rebuttal: Every breaking change was necessary, hopefully the community will appreciate that the benefits outweight the efforts, in particular in the long run.

Package forks causes avalanche effect on migration effort

Claim: Given all the changes required to migrate packages to ROS2, it is likely that migration will also change more structures. This will cause even more effort for dependent packages who try to migrate, as their dependencies will have structural changes as well. [TK]

Rebuttal: Hopefully package maintainers will try hard to make migration of all dependees easy.

Interoperability and parallel maintenance

Parallel maintenance looks hard

Claim: OSRF and all package maintainers will have to spend much more time on maintenance than before. Aside from migrating, maintainers will have to multi-test (test using ros1, ros2+opensplice, ros2+connext, ros1-ros2 interop), multi-document, multi-release, multi-support. It is unclear how much additional effort this would require. [TK]

Rebuttal: For companies using ROS by using non-public packages without relying on open-source packages, this is not an issue, as all packages could be moved to ROS2 in one step when ROS2 becomes mature.

ROS2 improvements are hard to backport to ROS1 (e.g. ament)

Claim: Many mprovements in ROS2 could also benefit ROS1, which is expected to remain the sole feature-complete ROS for a long time. However, by making ROS2 tools completely separate software forks (without sharing version control history), it is very difficult to provide the benefits of ROS2 in ROS1. As an example the ament buildsystem is not backwards-compatible with catkin. This is disadvantage to all ROS1 users. If ROS2 is never successful, the efforts will be wasted. [TK]

Rebuttal: Backporting most new features to ROS1 could break things, this is considered too high a risk, and also too much effort. There are ideas about adding backwards compatibility to ament, and also to merge other tools and libraries back later, in case ROS2 adoption is not "high enough". By making ROS2 more attractive to industry users, OSRF might be able to receive more funding to spend efforts on backporting featres.

Interoperation causes many namespace clashes

Claim: Given ROS1 and ROS2 will live alongside each other and possibly interoperate, there will be many name clashes between ROS1 and ROS2 packages. This is different from multiple ROS1 distributions living alongside each other, where interoperability is rarely required. [TK]

Rebuttal: Hopefully good solutions will be found.

Bridges are brittle

Claim: There is a prototype for creating a node relaying messages between ROS1 and ROS2 on a single topic. To solve interoperation like this such a node would have to be created for each topic, with additional mapping logic for each instance of message type structure being different in ROS1 and ROS2. This is not very usable. Relaying service calls between ros1 and ros2 is not solved.[TK]

Rebuttal: Hopefully the bridges will be sufficient for the communities needs.

Validity of goals

[Refuted] ROS2 should not be based on DDS

Refuted, see section Refutals

[Refuted] DDS lacks free support and licensing

Refuted. See in section below.

ROS2 promotes vendor heterogenity

Claim: Since there is no single optimal DDS vendor, ROS2 will cause packages to be published bound to specific vendors, causing a heterogenity of DDS implementations at runtime on any robot, and a reduced reusability of packages. [TK]

Rebuttal: Hopefully this will not impact users negatively. OSRF expects a single DDS implementation to eventually become a de facto default. Discussion

Multi-DDS support causes much effort as ripple-effects

Claim: The technical possibility to switch between DDS implementations at link time or runtime cause more problems than benefits. Documentation and tutorials will need to cover multiple implementations, testing will have to be done using multiple implementations, support will have to cope with issues concerning specific DDS implementations. [TK]

Rebuttal: OSRF expects a single DDS implementation to eventually become a de facto default.

Learning curve increases

Claim: The complexity of DDS cannot be completely hidden under a thin ROS2 API, users will still have to deal with DDS for debugging purposes, and so the learning curve will become very steep. [TK]

Rebuttal:

Name "ROS2" lacks justification

Claim: ROS2 is fundamentally different from ROS1 and not backwards compatible. Thus it dilutes the brand "ROS". Also it makes for a poor prefix for the tooling, and makes it difficult to use search engines for problems that are specific to ros1 or ros2. [TK]

Rebuttal: OSRF has also considered using a different name, but did not find a suitable name (yet?).

Community Involvement

ROS2 a large disruption to the ecosystem, despite community wish

Claim: The community has expressed a wish for less disruptions to the ROS ecosystem after the introduction of catkin. The large-scale migration from ROS1 to ROS2 which will be inevitable for most ROS1 users is a much larger disruption. [TK]

Rebuttal: Alternative paths have been considered, but OSRF has found no alternative viable. direct response Article

REP process not followed

Claim: The REP process for managing changes in the ROS ecosystem provides many benefits over mere documentation:

• The community is informed about every change early on, having the chance to react early
• Initiators of change need to motivate every change
• Initiators of change need to achieve community approval
• The community is informed early on to give feedback early
• Decisions and discussions are documented for posteriority
• The power to decide is shared between benevolent dictators and the benevolent community
• The status of each proposal (draft, proposed, accepted, rejected) is transparent

Despite many major decisions being required for ROS2, OSRF repeatedly decided to delay creation of any REP to some uncertain later date. Instead, the design website serves to document some technical aspects and decisions #ros2design. [TK]

Rebuttal: The design website #ros2design and the process of discussing and reviewing articles on github is preferred by OSRF.

Feature set decided without community

Claim: The features that go into ROS2 (and those which do not) are being decided without community vote, and often without even informing the community early. (Changes being made in public github repositories does not count as having informed the community.) It remains unclear who made any feature decision and why, allowing the impression to emerge that any OSRF member can add his own preferred feature to ROS2, while the community at large has no power to do so or to prevent features in ROS2. Examples are the new node runtime that replaces pluginlib / nodelet (presented at ROSCon 2014 #Roscon2014Slides), and the managed node / lifecycle (Draft). [TK]

Rebuttal: "Our [OSRFs] decision was based on feedback from users and potential users. We specifically reached out to ROS users as well as people and companies we know have chosen not to use ROS so we could identify the use cases not supported by the current version of ROS." citation

Change set should be more moderate

Claim: The stated goal of OSRF with ROS2 is to fix flaws in ROS1. OSRF could have chosen to conservatively only change critical problems. Instead, OSRF also adds several other perceived improvements to ROS2, making the migration to ROS2 harder.

Examples: Message structure change, switch to new system baselines (Python3, C++11), support of multiple DDS/RMW implementations (instead of just one), changes to roslaunch / pluginlib / nodelets. [TK]

Rebuttal: The further improvements are difficult to make in ROS1, yet easy to change in ROS2 while nobody uses ROS2. Hopefully the community will appreciate that the benefits are worth the additional effort. Discussion

Software forks minimizes effort at OSRF, maximizes effort in the community

Claim: The community efforts for adopting ROS2 consists of the following:

• Effort to maintain ROS1 packages for some time (code, tests, documentation, infrastructure)
• Effort to migrate packages
• Effort to maintain ROS2 packages (code, tests, documentation, infrastructure)
• Effort to support interoperability (code, tests, documentation, infrastructure)

Keeping ROS1 and ROS2 more closely aligned would reduce these costs in the community (at the higher costs at OSRF of having to remain backwards compatible). [TK]

Rebuttal: OSRF has considered multiple options with different tradeoffs. OSRF decided it was better to keep ROS1 stable by creating ROS2 as a completely independent system without any cross dependencies (other than bridges depending on both ROS1 and ROS2). This reduces the risk of breaking ROS1, and makes it easier to add new features to ROS2. citation

ROS ecosystem becomes less trustworthy

Claim: By breaking many APIs and changing many core concepts without community concepts, ROS2 causes the ROS brand to be less trustworthy. I.e. If ROS2 is so easily so drastically changed without community votes, with high migration and maintenance efforts to be expected, it might as well disappear just as quickly in favour of some totally different ROS3. This in itself can discourage potential users from adopting ROS. [TK]

Rebuttal:

General Comments and Discussion

TODO:

• add link to article about why ROS2 has separate sources from ros1 (no disturbance?)

Refuted claims

[Refuted] DDS lacks free support and licensing

Claim: Given that OpenSplice is the only DDS implementation that is free for commercial use, and OpenSplice seems to be moving slow, ROS2 should not be based on DDS. (#OpenhubOpenSplice, note that the number of commits shows release commits, not individual changes). [TK]

Rebuttal: eProsima is an open-source alternative to OpenSplice. Also OSRF works on an minimal RMW implementation FreeRPTS (though pre-alpha and targeted mostly at embedded devices).

[Refuted] ROS2 should not be based on DDS

Claim: As the current efforts show, DDS is a suitable solution for industry users who do not wish to participate in open-source. A thin wrapper around DDS does not improve DDS significantly for industry users. [TK]

Rebuttal: Hopefully ROS2 will still provide sufficient benefits over existing DDS implementations. Academia will hopefully also benefit from switching to ROS2. #ros2announce Rebuttal

Reviewers

1. TK: Thibault Kruse

References

1. ros2design: http://design.ros2.org/

2. ros2announce: https://groups.google.com/forum/#!topic/ros-sig-ng-ros/fQLysM_AEFY

3. ros2query: http://ros-users.122217.n3.nabble.com/ROS-amp-DDS-td4020618.html

4. ros2alpha: https://groups.google.com/forum/#!topic/ros-sig-ng-ros/B4BAQY5c3xs

5. OpenhubOpenSplice: https://www.openhub.net/p/opensplice-dds

6. Roscon2014Slides: http://www.osrfoundation.org/wordpress2/wp-content/uploads/2015/04/ROSCON-2014-Why-you-want-to-use-ROS-2.pdf

7. http://youtu.be/XvYF4pW02p4

8. ros2whydds: http://design.ros2.org/articles/ros_on_dds.html

9. ros2rmw:http://design.ros2.org/articles/ros_middleware_interface.html

SIG discussions

1. https://groups.google.com/forum/#!topic/ros-sig-ng-ros/RaA617pJZtU

2. https://groups.google.com/forum/#!topic/ros-sig-ng-ros/wwKMRBov-7c

3. https://groups.google.com/forum/#!topic/ros-sig-ng-ros/gyToaPoiQi4

4. https://groups.google.com/forum/#!topic/ros-sig-ng-ros/suTQfcddeh8