ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Discussion on ROS to ROS2 transition plan

Jumping ship and burning bridges has never been a great recipe when you are dragging a lot of weight (community) with you.

@bmagyar why do you talk about burning bridges? Who ever mentioned this? It is a bit sad to see this being brought up out of the blue. This post and similar events are exactly to not do that and get the feedback from the community and prepare it for the transition.


If you already have an inflight or working ROS1 application it can, and probably should stay on ROS1 until that application has exhausted its useful lifecycle. Any new or next generation of that application should be targeted to be built on ROS2 and getting the libraries there to support it.

Using ROS 1 and ROS 2 side by side using works perfectly as we have detailed in our ROSCon talk:

So a) you do not need to do transition over the night and b) you could even keep running your system as ROS 1 and ROS 2 hybrid.

1 Like

@tkruse noone is stating that Melodic will be the last release. We are polling the community and will decide based on the feedback.

I’d like to take a brief moment to note that this thread and all of the valid concerns discussed herein seems to have stemmed from a relatively innocuous discussion had in the ROS2 TSC, and that neither those meeting minutes nor @gerkey’s reply are advocating for any near-term deprecation at all.

In general, I think that these are good conversations to have for planning purposes, but I’d like to request that people don’t project the positions taken in this thread by those who are not Open Robotics management as positions which Open Robotics is in fact standing behind or advocating.

I’d also like to remind members of the ROS2 TSC of their roles as well - the ROS2 TSC does not guide the entirety of Open Robotics efforts any more than it guides the efforts of the entire ROS community, so statements like ‘[The ROS2 TSC] are polling the community and will decide [on the ROS1 release plan] based on the feedback’ is a bit of an overreach.


If you have been cleanly separating your ROS 1 code per 5Cs and want to end up with the same workarounds in your application code as Moritz mentions above, I think that scripting can actually take you really far.

If you want to make your product really right, then your hunch is correct. At the very end ROS 1 has some fundamental and software engineering issues that logistics and home robotics companies have been able to work around but developers in automotive, medical and aero space were not, because the requirements in the latter 3 domains are too stringent. ROS 2 however is suitable for the use in these domains.

I will try to explain in couple of points why I think so:

  1. ROS 1 lacks quality of service (QoS) settings which ROS 2 now has. This is such a fundamental feature for especially multirobot setups on corporate WiFis that we had to do tons of work on top of ROS 1 sub/pub to mimic them. When porting to ROS 2, developers will actually have to sit down and think about how they want their communication between nodes, robots to look like. After they will think about it, the implementation will be super straight forward but still not search-replace like.
  2. ROS 1 lacks managed nodes, lifecycle manager and heartbeat functionality. Again, we spent tons of work in the past to mimic this behaviour but at the best ended up with the hack. And you can not build a production system without these features. ROS 2 has rclcpp_lifecyle (managed node API), launch system that understands and can command managed nodes and will also have heartbeat. Here again, the design of a ROS 2 system will have to change a bit, e.g. you will have to think what to do in the init, configure and run state and when to go to and what to do in the failure state. However after you will figure this out you will be able to develop systems that are repeatable in behaviour and much more robust.
  3. Security. I see that developers do not take this serious at all. But we will see robots be hacked in the future and there will be bad press for those robots where you can just simply do the following in your root shell “rostopic pub /control TwistCmd 5m/s”. ROS 2 offers security but again you have to consider which parts of your ROS system you wanna run as trusted and how much of overhead the security brings.
  4. Large data support. I hear from many parties that TCPROS is not fast enough for them. And so many went ahead and implemented their own SHM transport in ROS 1 or used a different framework because ROS 1 does not provide SHM.
    At least 2 DDS providers (DDS is a middleware of choice in ROS 2) offer their own SHM transport.
  5. Real-time and determinism. Below 3 talks go into details why making your system be real-time with ROS 1 is a hack. ROS 2 offers constructs such as separation of Nodes and Executors, Waitsets (in works),, … which will allow for a synchronous flow of data but which also means that as well in this case you need to sit down and re-think your architecture.
    1. Ingo last year
    2. Brian
    3. Chris this year

In general I absolutely see the concern of a large code base being built on top of ROS 1 and I think that we should start carefully and openly planning which ROS packages are the most needed and get them ported to ROS 2 and give the community enough time to make a switch. For starters I think that these 2 lists offer a pretty good overview and I would suggest adding to them:


If this is not an acceptable solution, then the very next thing that comes to my mind is that we go and try to find money for additional OSRF people that will let them do continuous ROS 1 releases without impacting any ROS 2 work. Just my personal opinion but I think that it would also make sense that this money comes from parties that largely depend on ROS 1.



I think you may still need at least one more ROS1 release on an LTS Ubuntu distro – here’s why:

  • ROS2 isn’t fully featured yet – as an example: actions will hopefully be part of the upcoming release, but I can imagine it taking 1-2 release cycles at a minimum to get those fully ironed out.
  • Until those features are there, some large portion of the developer and code base will not end up on ROS2 (I can imagine that the trajectory will be very similar to ROS1 – a few folk outside the core team end up using the C-release, but the majority of the community shows up for D- or E-releases). Even if they start to use ROS2, they’ll probably be bridging things in from ROS1.
  • If we suggest that the E release will be the first very highly useable release, then I think E ends up supporting Ubuntu 18.04 (since it is tail end of 2019?)
  • However, ROS2 releases after that will probably end up supporting Ubuntu 20.04 and not 18.04 – meaning that you no longer have ROS1 packages to bridge over to your ROS2 installation. Right?

To me, that says that after April 2020 (only about 18 months away), it gets a lot harder to run the current ROS2 release with any ROS1 packages bridged in. Is that logic right? By releasing ROS1 on Ubuntu 20.04, you can an extra 2 years of bridge availability.



Asking Open Robotics to make the “morally best decision” is a passive aggressive way of claiming that they’re choosing to do the morally wrong thing.

Let me expand. As a non-profit open-source foundation creating software without commercial license, Open Robotics has 2 distinct groups of stakeholders: The sponsors and the users. The obligations towards the sponsors are legal and economical. What obligatios are there towards the users? I call those obligations towards the users “moral”, making choices impacting the users “morally wrong” or “morally right”. I am open to other wording, such as “contradicting the self-defined mission of the foundation”, or “counterproductive in establishing and maintaining trust”, but I suggest using “morally right/wrong” for the sake of brevity, if nothing else.

In solving the problem of deciding whether to have more ROS1 distributions or not, I hope this clarifies the values and goals of Open Robotics towards the non-sponsoring users, as a driving factor for the decision to make at hand.

suggesting that there has been embezzlement at Open Robotics

My post with the given statement has been censored btw. I was trying to say that when talking about the funding of ROS1 releases, it is not helpul to say that in the past Open Robotics has has spent (6 releases) x (337,000) ~= 2 million , but has received 0$ for that purpose. Because there is a gap of 2 million dollars in that calculation.

In solving the problem of deciding whether to have more ROS1 distributions or not, I hope this explains what additional information is required to explain the economical decision making.

@mikeferguson - that’s a very good point that bridging needs to be supported for a longer time. I would think that the Ubuntu 20.04 ROS2 LTS release could also support 18.04, just as the Bouncy release today supports both 18.04 and 16.04. I think that’s a reasonable request, maybe @gerkey can comment on whether that could be done to help with the transition.

All your points are spot on. As a commercial company just joining the “ROS” wave, we see absolutely no reason to do anything with ROS1. ROS2 on the other hand is very attractive for many of the reason that you point out.

FWI, I can’t speak for other commercial companies, but if we do what we think we are going todo, we are likely to spend about $1B on robot software development over the next 10 years. $0 will go to ROS1. Much of it is likely to go towards ROS2 functionality. That’s not immoral, its just good business. We don’t see ROS1 as a “commercially” viable technology base, at least not for our markets (which are personal defense and security robots.)

If ROS2 weren’t a thing, we’d likely spend our money on enhancing our own proprietary system and then releasing as much of it as we can as open source code.

I don’t believe that we are alone. ROS2 can become the foundation of machines serving a wide variety of commercial market segments that are each worth 10’s of billions of dollars. As a result, if the community can provide the courage, vision and know how to lead, then large sums of investment are likely to flow into ROS2 over the next couple of years.


OK, so that’s a coherent, evidence-based argument that I think I buy. That does kind-of set the clock running, though. Question: how much of ROS1 will we end up porting? Bonus points: How long will this take? Can we, as a community, reasonably do it over one LTS cycle?

At the end of the day. Development will go where money requires it to. There are many business leaders in this thread who have knowledge of this information of where they are allocating their resources towards. I think if one goes through and reads through the responses, in most cases it is clear whether or not they are interested in putting resources towards ROS1 willingly (or because of due diligence).

For an effort this large, its probably best to write some scripts that reasonably translates some code patterns into ROS2 code patterns. Either that, or provide a shim at a clever spot. Either that, or a giant blog post/cheat sheet from an expert who has done a ROS1->ROS2 transition of their code base.

Does anyone know of an existing ROS2 robot that has been transitioned from ROS1? I would be up to analyze some code and see if there is a potential static translation/best effort translation I could write a script for for most ROS nodes.

What I potentially see in this is a service (yes, $$) that helps businesses port their code from ROS1->ROS2 in a timely manner. Not everyone needs to go through this manually for all parts. For such a large community and a large open source code base - automation here is a winning strategy for all.

@gerkey @rgariepy @mikeferguson @wdsmart @gavanderhoorn Is anyone on your teams doing something like this? Are you guys allocating resources towards it? How many of you would utilise something like this?

Does anyone know of an existing ROS2 robot that has been transitioned from ROS1? I would be up to analyze some code and see if there is a potential static translation/best effort translation I could write a script for for most ROS nodes.

I have a Turtlebot3 on backorder essentially to learn how painful this transition from ROS1 -> ROS2 might be. Eventually, we want to test ROS2 as a platform on which to implement multi-robot cooperative intralogistics on AMRs that carry payloads up to 3 tons (so, a serious application involving safety and performance considerations - not a toy). Happy to report on my findings as they become available. At the moment, we are building our own software stack based on DDS which will take us through early prototypes. If ROS2 becomes available and fits our requirements, we will use it; otherwise we will continue with custom stack. Personally, I believe in giving back to the community. I have happily paid for open source software before to support their development. But I am afraid, it is not always my call.

1 Like

@mkhansen’s initial post surely was well-intended, but I don’t think @bmagyar talking about burning bridges came “out of the blue”. When members of the ROS2 TSC casually talk about stopping all further ROS1 releases, and OSRF makes no reassuring replies on this matter, I also get the feeling that this is premature, and people are planning to burn some bridges. Please don’t take this as an attack, I am trying to explain the emotions behind some of the reactions here.

My impression is that over the past few months, ROS2 has really started to gain some traction, which of course is great. There has been an influx of new developers from some big-name companies with lots of resources (again, this is great!), and of course they all focus on ROS2 (which is what I would do if I started from scratch today). Most people who are firmly in the ROS2 camp seem to take it as a given that there will be a transition from ROS1 to ROS2, and that this transition will be quick. This makes those of us who have been using ROS for years and have accumulated a large code base understandably uneasy. I don’t believe there will be a quick transition. It will probably be more like the python2/python3 transition, only slower. This sucks, but it’s a result of the decision to change everything all at once in ROS2, instead of the “ship of Theseus” way of transitioning.

I understand that OSRF cannot commit resources to ROS1 forever. But when that day comes, please let’s try to find a successor organization that takes over stewardship of ROS1. There are lots of companies that are built on ROS1. If these companies realize how serious the situation has become, maybe they will cooperate to commit some developer time to the maintenance of ROS1.

1 Like

Don’t pretend that you’re trying to have a constructive discussion here and that you were using “morally wrong” just for brevity’s sake. Throwing around words like “morally wrong”, “super villain” and “embezzlement” does not further a civil discourse, and it distracts from the points you’re trying to make (assuming you’re actually interested in an open exchange on the subject matter).


I’ve observed this phenomenon several times in the past. New company joins the “ROS wave”, spends lots of resources to build their system based on the state of the art in ROS, and sometimes even contributes some great stuff back. After this initial investment, the effort is redirected to maintenance, tailoring the code to specific customers, and sales. There is rarely a willingness to adopt whatever has become the new state of the art in ROS, if there is no clear benefit to the company’s use case.

There is nothing wrong with ROS1 for some markets, and there are successful companies based on it. As @Dejan_Pangercic pointed out, ROS2 provides some features that are required for other industries, and yours is probably one of them.

No, it hasn’t been censored. It was flagged as inappropriate by the community (and very rightly so, given how you’ve responded), but users can still read your comment. Accusing Open Robotics of embezzling funds, without any proof, is a new low point. I don’t understand what you’re trying to get out of this using these tactics.


@Martin_Guenther thanks a lot for bringing this up. I was not aware of this being the case and will make everything I can that we do it better in the future. Of course there has to be a firm transition plan and no divide.

@Martin_Guenther I appreciate your providing context and I’m not at all surprised by the strong responses that have been elicited by this discussion. We’re talking about a large and potentially high-impact change. I’m encouraged by the deeply felt reaction, as it confirms the significance of ROS in the global community.

With regard to reassuring replies from Open Robotics: we’ve (mostly) stayed out of the discussion on purpose, to keep the floor open for a broad sharing of opinions. Our team is internally conflicted on the question of when and how to stop releasing ROS 1. It’s a project that some of us have spent 10+ years, in some cases our entire professional careers to date, working on, so we’re loathe to let it go. But like almost everyone else working in this industry, we have more things that we’d like to do than we have time to do them.

It’s great to see specific concerns and concrete proposals like those raised by @ooeygui, @mikeferguson, and @mkhansen. Those comments are exactly the kind of thing that we can take into consideration when looking at the pros and cons of the available strategies.

1 Like

I’ve worked with many open source communities in the past. Based on those experiences, I think there are some really innovative ways we can reach a win-win status with this community. Look for that to play out over the next couple of years. The best way to judge things is based on actual outcomes, so while I respect your opinion and perspective, I would also request that you give us a chance to prove that we are good members of this community by our actions, deeds and works.

A post was split to a new topic: ROS2 Documentation