Discussion on ROS to ROS2 transition plan

I think you have misunderstood me, I didn’t mean to criticize you. My apologies if I haven’t made myself clear! :smiley:

Given the fact that no one here has any examples of porting ROS1 code to ROS2, except for a scheduled interest by @Vilas_Chitrakara, I’m going to believe that this entire discussion is speculation because no one knows the real resources required to port a system from ROS1 to ROS2 or if that effort is greater than maintaining a ROS1 release.

I’ve predicted this before and I’ll reiterate - the ROS2 release is going to split the community so that there are two distros of ROS eventually maintained. Industry backed/invested ROS2 (for the next 5~ years) and current Open Source ROS1. Users from current open source ROS1 won’t move to ROS2 until industry paves way. So, we’ve got another ~5 years of ROS1 in my opinion.

The only people who benefit from seeing the amount of ROS2 users go up in this thread is Open Robotics/OSRF as it stands presently. I don’t think anyone else is making a profit off of a ROS2 based system as of now. So until ROS2 features become mainstream this trend will continue. Of course, Open Robotics would never admit that they are not making profit off of ROS2. So with that reasoning I’m going to assume they are already making profit off of it (because they will always claim to be). BUT. I bet their revenues (not including funding/investments for ROS2) are mostly in ROS1 projects as of now. Actually I guarantee it and would bet money on it.

So, that begs the question… who’s got skin in the game for ROS2?

The community as a whole will benefit by more people being in ROS2, but as it stands as of this date all of the vested interest is in Open Robotics/OSRF. IMHO that means Open Robotics should provide some resource allocation towards porting some robots/example systems so that others can follow in their footsteps. However now that Open Robotics is a for-profit business, it’s a little bit contradictory that they should help their competitors out, don’t ya think? :slight_smile: Another point validating the prediction that the ROS community is going to split for the next 5 years.

Is this good? Maybe. We do need a bridge/defined porting process to prevent this though. Surprised no one is being paid to think about this engineering problem out in the open source world. More proof that the only people actively moving to ROS2 are industry backed and are probably holding their solutions/cards to their chest. More proof that industry will only eventually open source their ROS2 solutions/implementations when it is no longer beneficial to competitors. (e.g in 3-5 years time).

That being said. If anyone out there is interested in publicly supporting an open source path forward for a ROS1->ROS2 transition, feel free to contact me :smiley: … one last thing… OSRF … how was a transition plan not designed for or planned for or accounted for?? BIG fail.

Besides the technical and logistical issues here, I don’t understand how there are so many commentators that appear to have inside knowledge of how OR runs their business, where they get their funding or what their evil plans are for ROS 1 and/or ROS 2.

Am I happy with how things are going: no, perhaps not with everything.

Do I start posting accusatory comments on a thread that started with the question “how can we make sure the a transition to ROS 2 can be done in an efficient and as painless manner as possible?”: no, I don’t.

Do I get out the bucket of vitriol, take a large gulp and fire up Discourse? Neither.

Could things have been perhaps more clearly communicated by the various stake-holders and people involved: yes, surely. And that would have avoided quite a bit of frustration.

Unfortunately the situation is as it is right now, so can we please be constructive and make the best of it?

And @TheDash: “no one here has any examples” -> you conclude this after 1 day?


Edit: just to clarify: I’m not defending anyone here. I’m simply amazed by the level of the comments that pass by here in this thread and felt a need to respond to that.

7 Likes

I would just like to politely point out that this post was made to get that exact conversation started - and it has started. You can’t just come up with a plan like that out of nowhere.

1 Like

For those who are taking the position that a “one or the other” approach is the only way to go: We’ve had some aspects of ROS2 running in production-critical systems for nearly 3 months now, and we continue to be a maintainer of ros_comm (and numerous other ROS1 packages besides). We push bugfixes and improvements back to the community for both.

One thing I wanted to mention was that @gerkey stated the above 8-9 person-months for an average ROS1 LTS release. I’d like to get an estimate of what it will be to do the Python2 → Python3 conversion in addition to the ‘normal’ library upgrades and such of an average new LTS release. My guess is that it’s significantly more, thus my original proposal.

Also, I think the idea of the community taking up the work to do it is a completely valid one. If people don’t want to move to ROS1, then nothing should stop them from self-organizing and taking on the work of doing the Python2->3 port themselves and creating a new LTS in 2020.

So maybe the transition plan could be a combination of things:

  1. A migration script to do 80% of the ROS1 → ROS2 conversion for those who want to migrate
  2. An improved ROS1 bridge for running hybrid systems?
  3. ROS2 support in 2020 on both 18.04 and 20.04
  4. Support of Melodic until 2023
  5. Better documentation of ROS2 (see @mikeferguson thread)

Anything I missed there that is discussed in this thread?

On some platforms (e.g. Gentoo) ROS 1 users are already using Python 3 today. So “some part” of the code base is already Python 3 compatible. The amount of work necessary is hard to estimate. From my experience changing existing Python code to support both (version 2 and version 3) is commonly fairly simple. There are only very few cases where it is more difficult. As soon as a distro would be setup offering Jenkins bases CI / PR jobs using Python 3 those should be fixable iteratively. This is also a task where contributions from the community could go a long way to spread the workload.

@dirk-thomas - thanks for the reply. Could you estimate that add if it were to be done by OSRF? Is it a 10% add, 25%, 50%? I have been operating with the understanding that it is in that 25-50% add range, but I don’t know the code base that well. I think understanding the effort is important to this discussion.

One aspect that is lacking from this analysis IMHO is that the value of ROS2 is also dependent on its community (one of reasons for success of ROS1 IMHO). Bigger community often doesn’t just mean more community packages, but also more contributions to the core, more developers (potential hires) that are familiar with the ecosystem and want to work with these tools, attracting in turn more businesses. So if you want to benefit from ROS2, it is probably in your economical interest to have a strong ROS2 community, and one way to help this is ensuring that there is no hard split in the overall ROS community. This means that at least IMHO it is in your economical interest to ensure a transition that is as smooth as possible, which can only happen with $ spent on ROS1.

Of course I can appreciate that it is often easier to argue funding “missing ROS2 feature X” at a company than to argue “funding ease of transition ROS1 > ROS2” if you don’t happen to be a company with a ROS1 code base, but that doesn’t mean there is no economical reason to still do it. If you fund ROS1 that way, you are not just funding “commercially inviable technology”, you are (hopefully) funding the future ROS2 community.

With the same argument I think it is it absolutely legitimate for OSRF to “redirect” ROS2 funds to support ROS1 (from the discussion I take it that most people agree).

1 Like

So you agree with the development mindset that a system should be developed without any regard of how a majority of its users are going to use it or get their hands on it? Yeah, that’s a nope from me.

Imagine if Apple released a new iOS and didn’t provide information on how to upgrade to it or switch to it. Or didn’t even think about it at all until after it was released. I think that’s the way of how Windows 8 was released from Microsoft and we all know how that went.

" I think understanding the effort is important to this discussion."

From this thread no one has completely transitioned a robot to full ROS2 support. So perhaps it’s just not possible at this point.

@TheDash

  1. Robotis has ported over turtlebot stack: [TB3] Introducing ROS2 Tutorials (entire robot supported)
  2. Apex.AI is porting Autoware algorithms: AutowareAuto / AutowareAuto · GitLab
  3. @fkromer has a list of more than 50 packages and drivers ported to ros2: GitHub - fkromer/awesome-ros2: The Robot Operating System Version 2.0 is awesome!
  4. Bosch/William ported rviz GitHub - ros2/rviz: ROS 3D Robot Visualizer
  5. Toyota has an entire robot: https://roscon.ros.org/2018/presentations/ROSCon2018_supercharging_the_jaguar4x4.pdf
  6. OSRF ported gometry2

And then as already mentioned above much more is in progress:

  1. ROS 2 Collaboration Bulletin Board - #41 by swatifulzele
  2. https://docs.google.com/spreadsheets/d/14GY9shcwa2QKnw5u5T7F_2-4XuuwLkS3W20-tVp8EOY/edit#gid=0

So I do not know - do you just don’t want to see see all the work that has been done or what kind of examples are you looking for?

5 Likes

I am very excited about what ROS2 already is today. No one is perfect, and no project is run perfectly. Yet we roboticists have complained about the limitations of ROS1 for years. Now we finally have an improved alternative that addresses many of those limitations. Why all the fuss?

Open source funding and development is hard and you won’t get rich off it. Yet Open Robotics, many partners, and the community have brought to the world (free of charge) a new platform with very limited resources. While no one is saying it will happen tomorrow, I’m looking forward to ramping down ROS1 development and future releases. Instead we need to focus our limited community resources on a better robotics middleware that wasn’t built in a graduate student lab in 2007.

+1 @mikeferguson to organizing the ROS2 docs!

3 Likes

The Open Source Robotics Corporation may be a company that is legally allowed to make a profit. That does not mean that they exist to make money nor that they necessarily have “competitors”. The reasons for forming a company were more about allowing the sorts of donations that a non-profit foundation is not allowed by law to receive.

https://www.osrfoundation.org/were-collaborating-with-toyota-research-institute/
https://www.osrfoundation.org/welcome-to-open-robotics/

1 Like

Right, and this isn’t a software architecture analysis, this is a business model analysis. I think what a lot of ROS and ros2 users and developers are struggling with is that they don’t understand what their business relationship is with Open Robotics.

I’ve asked a few people about this, and never seen even something as simple as business model canvas for ROS and ros2. I think if @gerkey or someone at Open Robotics could put something like that or equivalent together, it would make a lot of these discussions easier. Does anyone know if that work has already been done or published somewhere?

People’s comments and criticisms could (and really need to be) be grounded in which market segment relationships they’re talking about. But before we can do that, we need to all agree on what those are.

At the end of the day, it’s up to Open Robotics to analyze the size, value, and impact of the different market segments to determine where they should be directing resources. The latter is clearly something that Open Robotics has already done, since it’s driving their resource allocation decisions, but maybe it’s worth taking another look.

1 Like

Over at Amazon we’ve started working on some tools to help with migration from ROS1 to ROS2. See ROS1 to ROS2 Migration Tools for more details.

6 Likes

For anyone who is curious about how we operate our business, you can start by reading how we publicly advertise it. And for anyone who wonders where the money comes from to pay our team, we’ve cleverly concealed that information here.

Open Robotics builds and applies open source software (and sometimes hardware) for a wide variety of robotics domains, paid for by contracts and grants from industry and government. We also receive donations, but with a couple of notable exceptions, they don’t represent a significant share of our revenue. We don’t sit on an endowment or other pile of cash and we haven’t taken outside investment.

We choose clients and we design projects to maximize the portion of our work that will be done in the open and furthermore to maximize the level of reusable improvements that can be made to ROS (1 & 2) and Gazebo along the way. We sometimes work on projects that involve some amount of closed work, though as I’ve said previously, our DOD-funded work is 100% open. We often work on projects that involve some amount of application-specific work that isn’t easily reusable. When we worked on the DARPA Robotics Challenge, we developed a bunch of code and documentation that you mostly likely haven’t touched and never will. But if you’re using Gazebo today you are benefiting from the countless improvements that our team made during that multi-year effort. Our goal with each project is to find the right balance so that we can meet the needs of the client, who after all is paying for the work, but at the same time continue to improve the underlying platform in a manner that’s broadly beneficial.

As @davetcoleman said, funding open source development is hard. If your job includes interaction with clients or customers, I encourage you to ask them if they’d be willing to pay you to do work that you will then deliver to them via a public repo under an open source license where everyone else can also use it. It’s especially fun to have that conversation with their corporate attorneys and contracts people.

I’m sometimes asked how we manage priorities and decide what to work on. We take information from the following sources (in no particular order):

  • Our own opinions. Some of us have been at this a long time, know a lot about how the current systems work, and as a result have a decent intuition about what’s important.
  • Feedback from everyone in the community. Discussions like this one (at least the parts of this thread that can be called a discussion) provide us with invaluable information about what’s important to people outside our team.
  • Activity in the marketplace. If companies are selling lots of material-moving robots to warehouses, we pay attention. If there’s huge investment in autonomous vehicles, we’re not going to ignore it.
  • The needs of our clients. None of what we’re doing works without having revenue to pay our team.

It’s through the fusion of that information that we make strategic decisions like embarking on the development of ROS 2 or re-architecting Gazebo into the ignition libraries.

Everyone’s welcome to disagree with the decisions that we make and when you do, we want to hear about it. I’m perfectly comfortable with the fact that we can’t make everyone happy. And, having done open source development since the 90s, I’m also comfortable with the fact that that unhappiness is aired publicly.

I do ask, echoing @gavanderhoorn’s comment, that everyone find a way to be both constructive and civil. I realize that civility is rapidly going out of fashion and that, at least in the political world, trying to stick to it has at least in part led to some very troubling results in recent years. But, at the risk of sounding aggrieved and perhaps giving trolls what they crave, I can tell you that claims of moral turpitude, accusations of criminal wrongdoing, and unreasonable demands are, well, demoralizing. Some of my colleagues specifically don’t read these threads because doing so just makes it too hard to keep spending time writing code and giving it away for everyone to use.

7 Likes

I think the relationship between Open Robotics and federal funding sources has always been pretty clear, as are any relationships that Open Robotics has private enterprise through contract services. But these aren’t the only participants in the community. Different segments have different types of needs, requirements, costs, and constraints. Not only that, but different segments use, contribute, and maintain different types code. I think seeing a breakdown and a graph of these relationships of that would be really valuable.

I think it might really ease some of these questions about where community members should direct their efforts in order to best drive the community forward without sacrificing their own engineering or research objectives. @gerkey, do you know if there’s a sketch of that that anyone could share?

Read a post earlier in the context. The question is about who has transitioned a whole system running in ROS1 to ROS2. Something like a PR2 or other mobile manipulator. An example of migrating a system that has been set up to execute tasks in a real world setting (or to run a demo to customers / future sponsors, support a research area spawning valuable academic publications) where the robot would solve some impressive challenge in ROS1, and then a team made the robot do the same thing with ROS2.

It seems a rather unrealistic thing to happen. Economically speaking, if a robot system is set up to do a task well, and this setup works nicely (and pays the bills), then switching the middleware is a high-cost high-risk operation with zero return of investments.

So the question should not just be has any team migrated a full system from ROS1 to ROS2, but does any team even have a plan to do so? How many teams would use ROS2 rather than ROS1 to start a new system? It more a question for a ROS survey.

2 Likes

@tkruse I would disagree, and add that ROS 1 is not suitable for most production software and safety-critical environments. This fact is not a secret among the community.

Here’s an incomplete list of the primary limitations I believe exist in ROS 1 WRT a production software product:

  1. Custom middleware that does not provide QoS settings, and lacks native shared memory communication
  2. Lack of real-time development principles, such as avoiding dynamic memory allocation at steady time, and avoiding indefinitely blocking calls
  3. Nodes are unmanaged; there isn’t a state machine / managed lifecycle
  4. Security exists, but mostly for Python which has it’s own challenges WRT production software
  5. Test coverage is good for an open source project, but the coverage is insufficient for safety-critical systems
  6. Documentation has room *for improvement, though I’ll agree the active community partly mitigates this

ROS 2 has a massive opportunity to become a critical component in production software, while also maintaining its high value in education, R&D, and hobby projects that we’ve seen with ROS 1.


So the question should not just be has any team migrated a full system from ROS1 to ROS2, but does any team even have a plan to do so?

Yes; companies that are creating software that run on production robots, or in safety-critical systems.

There are multiple automotive companies that have implemented autonomous vehicle algorithms as ROS 1 R&D projects, and it’s my opinion that they now have a need to port those implementations to a framework that is capable of operating in (or can be modified to operate in) safety-critical systems.

Edit: add a quote at the beginning; finish my thought on documentation

1 Like