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
Contributors should keep additions short and non-personal. While wiki editors should be bold, on this page they should generally follow the idea of respectfully agreeing to disagree where consent seems impossible. Discussions should be kept short and soon replaced by clarifying text. Where a lengthy discussion is likely, consider starting a thread here instead: https://groups.google.com/forum/#!forum/ros-sig-ng-ros
Claims and rebuttals may be signed by all supporters in short form: '[P1, P2, P3]'
At the point of writing (09/2015), the following state of affairs can be used to understand the strategy of ROS2:
ROS2 selects one of several DDS implementations at link time (C++, ...) or runtime (Python, ...) #ros2rmw
The only DDS implementations with a standard Open-Source license are OpenSplice and eProsima
OSRF still negotiates with RTT Connext over providing a suitable open-source license, a non-standard free-for-research license is available #ros2announce
- ROS2 core packages and tool support sources are completely separated from ROS1 sources
The ROS2 client API is not backwards compatible with ROS1 Discussion
- Some message definitions differ between ROS1 and ROS2 in name and structure (see below)
Many core ROS tools will need to be rewritten for ROS2 (rosrun, rosmsg, rosnode, rostopic, rosparam, rviz, rqt, roslaunch, ...) Discussion
ROS2 defines different language baselines than ROS1 (Python3, C++11) Detail
- 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
- OSRF promises that ROS1 will continue to be released for a long time
No REP, not even in draft form, has been created for any ROS2 feature. Documentation is available at #ros2design
- ROS2 can be installed side-by-side with ROS1
- ROS1 topics and ROS2 topics can be bridged via relay nodes (1 for each topic)
- ROS1 and ROS2 services/actions cannot yet cross the border between ROS1 and ROS2
Planned / proposed message structure changes:
- Header header changes to std_interfaces/Header header
- time changes to builtin_interfaces/Time
- duration changes to builtin_interfaces/Duration
- ROS2 Strategy review 09/2015
Review Claims and Rebuttals
- Quality and effort
- Interoperability and parallel maintenance
- Validity of goals
- Community Involvement
- General Comments and Discussion
- Refuted claims
Review Claims and Rebuttals
In this section Claims have a title and a short description, and a rebuttal
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]
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.
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]
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?).
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]
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]
General Comments and Discussion
This section allows to drop in comments, complaints, TODOs, questions and such in a non-structured way.
- add link to article about why ROS2 has separate sources from ros1 (no disturbance?)
When the claimants agree that their claim is rebuked, the claim can be moved to this section for posterity.
[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]
- TK: Thibault Kruse