Proving my point that ROS1 and ROS2 are targeting different audiences (ie. communities).
Proving my point that ROS1 and ROS2 are targeting different audiences (ie. communities).
But (and there is always a “but”), why can’t we make both these communities happy?
No one of us wants to make the entry barrier for ROS2 worse than it was for ROS1. Or at least, I believe this should be the goal. I expect ROS2 to be (become?) as “beginner friendly” as ROS1 is.
The only extra thing to learn is probably lifecycle management, something that a 10 minutes tutorial will teach you.
Just take a look at this for example: https://roscon.ros.org/2017/presentations/ROSCon%202017%20ROS2%20Fine%20Tuning.pdf
Tell me how beginner friendly that is. In ROS1 you have TCP handling everything for you, but in ROS2 you need to do it all by yourself, tuning the parameters to achieve good results.
Want to send messages bigger than 64K? Not so easy, need special settings for that depending on your network and the expected bandwidth of your topic.
My hope is that it would be possible, but my intuition is that one can’t overstate how difficult it will be. Still, I would say it’s extremely unlikely that one will satisfy (and leverage) all the relevant stakeholders if one doesn’t first define who they are along with their abilities, needs, and constraints.
For instance, I don’t even think that the aforementioned communities (“academia” and “industry”) are the only two classes of stakeholder that we care about or even that each of those classes has a unified set of requirements.
I agree with @Hugo that ROS2 must get the “default values” right so that only people with very special needs should care about learning this, not the 90% of us that is happy with the one-fits-all configuration.
I trust that people developing ROS2 share the same vision, i.e. simplicity first, fine tuning for those who care.
Probably ROS2 is “not there yet” in terms of simplicity, but I hope it will.
Similarly, I agree with @jbohren that unless you know the needs of your stakeholders, you can’t have a clear roadmap.
So we all agree and everyone is happy…
Buuuuuuut, I believe that OSRF has been sufficiently transparent about its vision.
And bear in mind that I am not one of “those” ROS evangelists that worship ROS 
My last words in this thread (I don’t believe that I have anything else constructive to add) is that, in my personal opinion, a world where ROS2 replaces ROS1 and they do not coexist, will be a better world. I doubt I will see this anytime soon, though.
I want to believe that one day ROS2 will be as beginner friendly as ROS1, but it will take time and resources (including economic resources).
Cheers
Davide
1 Like
Just to answer the original question from @mkhansen: I personally feel that another ROS1 LTS release in 2020 is needed.
My main reasons are that I fear a loss of trust in the ROS-brand in general and the destruction of value for existing endeavors that have committed themselves to ROS1 long-term, in particular. I share the fear of other posters that the effective quality of ROS1 support will decline much earlier than the EOL of any last ROS1 LTS.
People keep repeating “let’s make melodic the last LTS release, this gives people 5 years to migrate”. I have some trouble parsing this statement. Could you please clarify?
Should melodic be…
- the last LTS release (but we will continue doing non-LTS releases for the next 5 years), or
- the last release ever, or
- melodic (LTS), noetic (non-LTS), then nothing?
I don’t honestly think that people actually mean option (1), I just listed it for completeness’ sake (maybe I’m wrong and that’s actually what people mean). And in my opinion, option (2) and (3) do not give people 5 years to migrate, because without upcoming releases, active development will be much much harder. For perspective: in 2023, Melodic will be as old as Hydro is today. If Hydro had been the last ROS release (on Ubuntu Precise 12.04!) , would it be fair to say that ROS development would have been possible until today?
I honestly don’t see the issue with maintaining two versions of ROS. ROS1 = hobby + academic. ROS2 = industry. Linux went this way with its distros as well. Open Source/Hobby and industry ready and hardened server systems. Each community will uphold their own.
This solution completely solves this thread.
@TheDash - the issue is how many resources OSRF has to continue to put out releases for both. You’re correct that if the community picks up the ROS1 work, then the problem is solved. OSRF could focus their resources on ROS2, and the community that still wants to use ROS1 could continue to do LTS releases themselves. That’s a solution.
However, I haven’t heard any of the community members to date step up and say “We’ll take ownership from here, we’ll do the Python2->Python3 port in 2020 and own delivering ROS releases from that point forward”. If someone would step up and say that, then you’re right, everyone would be happy.
Of course then there’s also the issue of the package maintainers. For example, @pyo is the maintainer for Turtlebot3, and he may not have the resources to continue to deliver package updates for both indefinitely. So the community would have to pick up other key packages also.
From my observations there’s really two systems that exist within ROS1. There’s the ‘core’ middleware and then the communities applications/programs that exist around it. OSRF still maintains most of the core middleware and is a major responsibility for them.
I guess the conflict of interest situation is like this, from my understanding: Those who have the money to pay to support ROS1, want to use ROS2 to advance their interests and make their products better. Therefore, those using ROS1 won’t have any one to pay to maintain the core product of ROS1 and thus ROS1 is ‘unmaintained’.
Originally, who was funding ROS1? Why’d that stop? It’s clear there is a large majority of members who rely on the ‘core’ ROS1 parts which will in the near future be abandoned.
I guess of course everyone will just have to suck it up and follow industry’s trends if they aren’t willing to cough up the bill for ROS1, however.
Please see the following post about the plan of Open Robotics regarding future ROS 1 releases: Planning future ROS 1 distribution(s)
3 Likes
I agree. There are domain specific categories automotive, avionics, industrial, medical, military, etc. each having domain specific standards (from which requirements are derived from). However in every domain there are differences in requirements (risk based requirement estimation, product category based requirement estimation) as well. For e.g. medical devices there are country specific device classes with varying requirements which may potentially deviate from country to country. One important point is to consider non-technical requirements like development process related requirements as well (e.g. traceability of requirements to production source code, traceability of production source code to test code, code review etc.). As far as I know many domain specific standards are based on IEC61508 (at least in Germany) and related risk based requirement and best practice determination. That means domains may have an unified set of requirements. As requirements may have huge impact (if you are not in research but want to actually certify and sell a product) and can be hard/impossible to be implemented/“added” later it would be ideal to have at least one representative of each domain which shall be addressed in the ROS2 TSC I guess.
@gerkey Based on the rate of development so far and taking into account the large increase in development power that has become available over the last year or so, what do you see the state of ROS2 being in 4.5 years, when Melodic’s support ends?
Are you asking me to do long-term software development estimation? 
Everyone please save this post so that over the next few years you can periodically give me back exact quotes demonstrating what I’ve gotten wrong:
Given the current status and level of community contributions I expect that ROS 2 will be well-featured and very usable for a wide variety of applications long before Melodic goes EOL in 4.5 years. At some point between now and then we’ll get to a situation in which any new robotics project that could be tackled with ROS 1 could just as well (and hopefully better) be done using ROS 2. By that time it will also be feasible to transition any existing ROS 1 system to ROS 2. And before then we’ll see new systems written from scratch using ROS 2 that are deployed in products.
Of course, irrespective of the state of ROS 2 I expect that many many people will still be using ROS 1 in 4.5 years and even after, primarily because of a combination of familiarity and reliance on existing ROS 1 code.
5 Likes
Given that we still get emails on the Player mailing list every few months, I think this is a sure bet. 
1 Like
I wanted to follow up on some of the previous comments with our experiences and plans for the transition.
HXR is a startup currently working on installlation / deployment automation tools for ROS2 based on some of our previous work building USB/ISO installers for ROS1.
ROS1 is OK (for some use cases)
Aside from academic projects and contributing to the occasional art project, members of the team have worked on two commercial projects with ROS1 with experiences worth highlighting.
We avoided the safety issues on one project by selling TurtleBots primarily to academics & researchers and for the other project, the end product was the data produced by the system not the system itself. We have generally avoided real-time issues by avoiding safety issues.
Instead of lifecycle management, we were able to improve reliability for a ROS1 based system by implementing watchdogs that could trigger a node reset if the diagnostics threw an error and a hardware reset if a node failed to produce data within n seconds of starting. In our experience much of the core ROS1 code has been very robust and I think there have been many valuable lessons learned getting it to where it is now, hopefully they won’t be forgotten.
We “implemented” QoS on ROS1 by using 2 quad-port gigabit Ethernet cards that had backplanes that could support all ports at full speed. This prevented an array of hardware synchronized GigE Vision cameras from crashing the network every 30th of a second. I imagine actual QoS is required for an office full of people trying to teleop into the same robot at the same time.
Historically, we tried to do what we could for security on the TurtleBot2 by having roscore running as user ‘ros’, making this user part of group ‘video’, writing udev rules to provide access, etc. This approach has had some usability and functionality issues particularly with nodelets. The best option has been to avoid connecting ROS1 to the Internet at all. ROS2 looks to solve many of the security issues from ROS1 at the obvious cost of complexity. We hope to help with usability here.
Nodelets mostly work, except when they don’t. Be lucky, don’t try to chain too many filters with nodelets.
IIRC, services on ROS1 under some conditions could block the entire node. Don’t use services or be lucky.
ROS2 or bust
ROS2 Bouncy lacks support for two of the most important features; rosbags and diagnostics. The bagging infrastructure cuts development time spent chasing stupid software bugs. Diagnostics help cut development time chasing stupid hardware bugs. ROS2 development will be slower than it needs to be until these features land, hopefully in Crystal. We expect to see a significant increase in external contributions to ROS2 once this happens.
For many new robotics startups, ROS1 is not an option. It lacks critical features for most use cases and it is going to be hard to sell ROS1 to the management/board when ROS2 is in “beta”. Also, startups that just got funding will have about 18 months to deliver something with ROS2, because VCs will demand results. Having the bridge is nice, but it still requires some investment in ROS1 that I believe many without existing ROS1 codebases / experience would rather put into ROS2.
PhDs want to graduate in a few years and get jobs knowing the latest technology not something that was just obsoleted, and there are easy ROS2 papers out there waiting to be written. My gut says hobbyists will switch to ROS2 once some documentation/tutorials are written just to keep up with the latest technology.
I have heard people say that ROS1 has a learning cliff, however ROS2 currently has a learning asymptote, some of the code doesn’t even exist yet. If we can get past that I believe people will port legacy systems from ROS1 and we will avoid a fork.
While ROS2 is not currently production ready, I think much of the complexity with QoS and Lifecycle will get worked out, documented and simplified in the same way catkin improved quickly after it’s initial release. Is anyone still using rosbuild at this point? I’m much more concerned about where ROS2 will be in a year rather than where it is now. ROS2 documentation will improve.
I think our biggest concern with ROS2 at this point is that some of the more common dependencies (pcl, diagnostics, etc) will get a direct port instead of the refactoring/redesign they really need. Then we will hypothetically end up with something like diagnostics2 in ROS2.1 and some of the initial development efforts will be wasted. However, it probably isn’t the worst thing if it gets more people using ROS2.
Transition Plan
Despite the current state of ROS2, we have no plans to actively support ROS1 moving forward. Our team is currently working on our devops infrastructure for ROS2 and helping out where we can with development. We also plan to offer ROS2 porting/driver development as a consulting service soon.
4 Likes
Apparently the first PR2 marathon was nearly done in by everyone at Willow Garage SSH’ing into the robot and launching their own rviz instances at the same time.
@LucidOne, It has been more than a year since you posted your analogy and I’m curious what your thoughts are now about ROS2.
2 Likes