Discussion on ROS to ROS2 transition plan

General
62

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
63

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
64

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
65

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
66

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?

67

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
68

@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
69

I’m just going to point something out because perhaps there was a bit of misunderstanding in the strategy and approach I took. Shaking and poking the internet bear is an effective strategy for rallying the internet troops. It’s a known effect that when you claim the opposite on the internet that will inspire those to post what is actually going on/the opposite. Contradiction and conflict on the internet is your friend. I understand your political position though - it’s probably not something you can do, (but I can, and so I did). We now have a substantial list of posters who have demonstrated what has been done in regards to migration of nodes and entire systems.

It appears that it has been done. The efforts are being tackled by a correct approach by Amazon recognizing that automation was the way to solve it and I would expect nothing less by them given their talent pool. See https://github.com/awslabs/ros2-migration-tools/tree/master/ros2_migration/porting_tools

Other big institutions that managed to do this are the Toyota Research Institute (who have gobbled up amazing amounts of ROS talent). Solid work there after reviewing this https://roscon.ros.org/2018/presentations/ROSCon2018_supercharging_the_jaguar4x4.pdf

I’d be interested on the size of teams which are allocated to achieving such efforts. Perhaps someone from TRI/Chris Lalancette (Open Robotics), Robotis (Turtlebot) or Amazon could touch to those?

For onlookers… I do suggest to review the above examples in code and perhaps their Wikis to extract a system wide transition plan and potentially create a generic rubric. Add them to GitHub - ros2/ros2: The Robot Operating System, is a meta operating system for robots. and GitHub - ros2/ros2: The Robot Operating System, is a meta operating system for robots.

As a community I wholely believe with the above resources we’ve all collected in this thread - it’s totally possible to create a common community transition plan that we all work through by following the initial efforts of TRI, Amazon, and robotis…

70

One thing you could do to get an idea of what companies are contributing to ROS would be to look at all the known packages and see which have author or maintainer emails that are from companies. That would give you an idea of, for example, how much time Clearpath is putting in to maintaining open source software used beyond their own business.

71

This page is probably the best way to get that info. ROS packages for Kinetic - 2021-06-01 22:32:58 -0800

I was curious as well so i just hacked up a quick script so I could visualize who maintains what. The script can be found here (and you can change it for each distribution if you’d like by modifying the ‘site’ variable in the file)

The result is this:

figure_1-1
figure_1-12318×1277 187 KB

1 Like
72

Thanks, @TheDash, that’s definitely a useful facet of it, but unfortunately this is just a fraction of what’s actually out there.

I started digging earlier this year, and I’ve been working on getting GitHub to index published ROS code along with their BigQuery dataset. Right now it also only captures a fraction of published code (albeit a different one).

The next step would be to take one or more of these segmentations, classify the different groups and then describe their needs, resources, and how they interact. It sounds like there still isn’t anyone who has done this.

@wdsmart maybe we could scrounge up some funding for such an analysis?

73

I am going to regret joining this conversation, considering the not-very-constructive direction it took, anyway, here we go.

@jbohren I find your comments well-intentioned but a little naive. It believe that it is obvious that OSRF should prioritize its clients over the entire capital C “Community”.

And let me add (spoiler alert: cynic comments coming) that dozens of universities/companies/startups could (and maybe “ought to”) donate money to OSRF, but they will never consider doing that.
If you have been in robotics for more than 10 years, like me, you will recognize the incredible value that Willow Garage and later OSRF created for the entire community. But when something is free on the internet, it is easy to forget that.

I think that ORSF did and is doing a pretty good job trying to do what is “morally right” for its community, whatever that means.

I may disagree with some technical decisions related to ROS1 and I am very happy with the technical direction that ROS2 took and I will be happy to see Melodic become the last long-term release, in favour of ROS2.

4 Likes
74

Haha, is that how my comments read? I definitely wasn’t suggesting that Open Robotics changes its priorities. I think Open Robotics should chase all the money it can find.

What I’m saying is that members of the community need to understand what their relationship is to Open Robotics, so that they understand how they need to contribute and how the ROS and ros2 strategy relate to their needs and project timelines. It should be extremely clear what the trades are between using both given a certain project context and timeline, and right now, I don’t think that’s the case.

When I say “maybe it’s worth taking another look” at the business relationships between Open Robotics and members of the community (as well as between community members themselves) it’s because such an analysis might reveal a market with people who have money and who are willing to spend it. They might also reveal people with time and who are willing to spend it. Additionally, if someone comes onto this forum and says “why isn’t Open Robotics focusing on X, because I need X” such a comment can be grounded in one of these market segments.

Wait, who’s forgetting that?

75

Hello,

I am not a specialist but seems reasonable the idea of spending more effort to ROS2 and forgoing non-LTS versions of ROS1, therefore the adhesion of no-LTS versions is not that much. A 4.5 years plan sounds more than reasonable for that.

76

@jbohren-hbr If I misunderstood your tone and message, I apologize :slight_smile:

I hope at the end of this long (and somehow exhausting) discussion, OSRF will define a roadmap that defines how they will use their limited resource to maintain either ROS1 or ROS2 and I personally hope that more and more effort is put in ROS2.

In my personal opinion, users should just accept that Melodic is the last LTS release and that they have 5 years to switch to ROS2.

3 Likes
77

No apology necessary.

Last LTS release or last LTS release supported by OpenRobotics?

78

It is not up to me to decide that :wink: .

Said that, my answer would be: “the last LTS created and supported by OpenRobotics aaaaand I don’t see who else has the capacity, time, desire, interest and money to continue the support ROS1 once a better alternative, i.e. ROS2, will be eventually available”.

Let’s not forget, by the way, that EOL of Melodic is 2023. Let’s be ambitious! :stuck_out_tongue:

Many of us don’t see in ROS2 a valid alternative yet, but I want to believe that this can change.
By valid alternative, I mean that the return of investment of switching from ROS1 to ROS2 is either bad or uncertain.

79

Using ROS 1 and ROS 2 side by side using https://github.com/ros2/ros1_bridge works perfectly as we have detailed in our ROSCon talk

Taken from GitHub - ros2/ros1_bridge: ROS 2 package that provides bidirectional communication between ROS 1 and ROS 2

  • “support is limited to only the message/service types available at compile time of the bridge”
  • “topics will only be bridged when matching publisher-subscriber pairs are active for a topic on either side of the bridge”
  • “building the ROS 1 bridge can consume a tremendous amount of memory”
  • “first building everything else as usual, then coming back to build the ROS 1 bridge”
  • " CMAKE_PREFIX_PATH must not contain paths from ROS 1 which would overlay ROS 2 packages"
  • “The bridge will be built with support for any message/service packages that are on your path and have an associated mapping between ROS 1 and ROS 2”
  • " This can be done by adding explicit dependencies on the message/service packages to the package.xml of the bridge"

That’s a lot of hoops to jump through, wouldn’t call it “works perfectly”. Just saying.

80

Regarding your points:

  1. I think most people using ROS1 don’t really care, they just want it to work, which for the most part it does. I mean just look how everyone is polling for input at arbitrary intervals, as long as it works somehow people are happy.
  2. Same concern as above, I think most people don’t care and forcing them to think about lifecycles is not going to help the transition. Maybe this is optional, haven’t looked into it too much, if it is then disregard the comment.
  3. Fair point, as long as it’s optional, no complaints here.
  4. Based on my experience with RTI DDS it is quite a bit slower than TCPROS, unless you are sending binary blobs, which is what the official RTI performance benchmark is doing to show good numbers. In any case if you want to send/receive messages larger than 64K you need to adjust a lot of QoS settings behind the scenes and prepare for high memory consumption (I’ve seen it use ~10GB before with complex and nested data structures).
  5. What do you do if a node sends a request to another node which happens to run in the same Executor and thus on the same thread? Allowing the grouping of multiple nodes inside a single thread will open up the possibility of dead-locks. And again forcing people to sit down will make them re-think twice about moving to ROS2.
81

@Hugo @Dejan_Pangercic

You two are clearly looking at ROS from two completely different point of view.

If you don’t need real-time and QoS, of course you will not have any reason to move to ROS2.

In the particular case of lifecycle management (point 3) ), I personally believe that without it very awful code is inevitable.

But again, if you are interested in the proof-of-concept, who cares?

This is not a a discussion about ROS2 vs ROS1 and if it was, it would be clearly “ROS1 is sufficient for academic and hobbyists use, ROS2 is trying to solve multiple important issues that many industries are very concerned about”.

About point 5), people that do need real-time requirements are (or must be) aware about the problem of priority inversion; the operative system itself helps avoiding it.

As far as i know, message passing is one of the best design patterns to avoid dead-locks.
Furthermore, real-time applications are multi-threaded and single process, not single thread as you mentioned.