[Poll] Kinetic users: Kinetic EOL in April, what is your migration plan?

+1 for Noetic/Foxy hybrid

3 Likes

Sorry I don’t think I can add that without changing the existing poll results, or at least I’m afraid to try it unless someone assures me it won’t reset them.

Thanks for the additional info though, I think a Noetic/Foxy hybrid should probably be marked as “Noetic” for this purpose as it seems like that is the immediate first step before moving to Foxy over time.

@marguedas - do you have a list of the repos you’re aware of that are still python2 based? I think this would be a good thing to post for the community for tracking down and soliciting help in migrating them to python3

Flagging for folks interested in Foxy on Ubuntu 20.04: it appears that some packages and devices still target Eloquent and/or 18.04. Two specific examples:

2 Likes

Unfortunately I do not, I tend to patch them as I encounter them. But if there is a community thread to aggregate them I’ll gladly post there the now ones I find that I’m not at liberty to patch on the fly.

A few ones are pending review if anyone is interested in trying those in Noetic:

Edit
A quick look at the current state of desktop full there seem to still be plenty of installed files that have a Python 2 shebang line. This is far from capturing the python2/3 incompatibilities as some of these files may not even be scripts so their shebang line may never be used. And much code in these packages or others may contain python2-only code regardless of their shebang lines. But that is a place to start I suppose.

$ docker run -it --rm osrf/ros:noetic-desktop-full
# cd /opt/ros/noetic/lib
# apt update && apt upgrade -y
# grep -r "env python$" | wc -l
105
2 Likes

Thanks @marguedas this is helpful. I don’t want to get too sidetracked on the python3 topic, so I think that should be a separate thread, or a meta-issue in github somewhere with a list of all 105 files you have there. I’m not sure where that meta-issue should be filed, maybe @Katherine_Scott can help with figuring that out?

2 Likes

So far we have over 40 responses, with ROS 2 Foxy in the lead! We’d love more feedback, so we’re going to keep this poll open until 12/18.

Please keep the responses coming!
:robot:

Many robotic projects use Nvidia Jetson boards which are still on Ubuntu 18.04.
This is a big limitation choosing to move to ROS Noetic or ROS2 Foxy, so ROS Melodic and ROS2 Eloquent are the best choice now to guarantee compatibility with most of the platforms.

1 Like

AFAIK Eloquent is EOL as of last month, so probably Dashing.

However, Foxy builds and runs fine on 18.04, assuming you have your own build and packaging setup.

Yes, but noetic and melodic taken together come out to 51% of respondents planning on staying on ROS1. I find this concerning, but not at all surprising. It would be good to understand better where the resistance to switching to ROS2 is coming from. I’m purposefully not calling it “upgrading” since it’s really a different system. Do people think it is too heavy of a lift to switch, not possible yet because important packages are not yet migrated, or just not worth it?

Personally I’m concerned that if migrating to ROS2 is perceived as too difficult (rightly or wrongly), then we risk seeing more and more people going their own way again, building their own robotics stacks again just like during the pre-ROS days. I think it behooves us as a community to ponder how to avoid that. I’m assuming I’m not saying anything here that OSRF has not already been thinking about for a while, but these poll results suggest to me that whatever the plan is to avoid such a rupture, more work remains to be done.

1 Like

@chfritz - yes I noticed that even though Foxy is in the lead it’s still less than half. I think that goes to show there will be people using ROS for a few more years. I hope it doesn’t mean that things become too fractured like you mentioned. I don’t think that will happen since Noetic is the last ROS LTS, and eventually (2025) that will EOL too. Everyone should be moved to ROS 2 by then. That feels like a long time from now but I remember when Kinetic came out (still have my T-shirt), and now it’s EOL, so I have some hope that the community will converge by that point!

Agree with your statement. My two cents on why people aren’t jumping on the bandwagon:

  • new system that people have to learn and it isn’t super easy to learn for people familiar or not familiar with ROS1
  • roboticists kinda get the advantages of ROS2, but they can get things done with ROS1 so why put in a ton of effort to switch (I tried for the open source rover and it took long enough for other big changes to get merged in which I then would have to keep converting to ROS2 as well, also while convincing people to make ROS2 the standard)
  • Packages in ROS2 either don’t exist or aren’t mature yet. As recent as yesterday, a colleague of mine was disappointed he was basically forced to use ROS1 (or both with ros bridge) because one single crucial package didn’t exist in ROS2 (I forget which one, I think a vendor specific driver)

My hot take: Similar to how a lot of people didn’t jump on Python3 until know (or still haven’t), sadly enough I think a proper switch to ROS2 will only happen after ROS Noetic reaches EOL. It can be sped up by releasing new packages only in ROS2 that have a significant advantage. Haven’t used it myself, but I can see nav2 being one of those.

P.S. @mkhansen I think folks have been ‘planning’ on switching to a newer version but it’s one of those things that just gets pushed on the backlog so I’d take those responses with a grain of salt. Who’s going to honestly admit that they will likely just be on Kinetic well past EOL? :wink: I think data from Indigo might provide good insight.

2 Likes

There’s some truth in that, but there are also many other packages that are significantly higher quality and more capable than in ROS1. Hardware specific drivers I think are always going to lag until enough customers demand it, but I have a hard time finding any other significant packages missing. Many of those people think are missing are actually there, just not released yet to debians or are in a new repository.

I’ve done some analytics on the number of packages in ROS1 vs ROS2 after hearing that comment a few times. While it is true that ROS2 has significantly less packages than ROS1, all of the top installed packages were included or had better analogs. I sampled a subset of the packages that don’t appear in ROS2 and I only found a small handful of missing ones that I thought were sufficiently generally used that it would represent a major loss of capability. Remember that anyone can release a package, so the bottom 30% of packages are installed less than 1,000 times over their entire lifetimes in all distributions combined (for benchmark, the most installed package is TF2 ROS at a bit over 3.3 million installs).

I had posted a survey of missing packages that people felt were important to move to ROS 2, responses are below. There are still remarkable few major packages on that list. Some of those listed are genuinely missing and generally used, but most are very simple pieces of software that porting would take merely hours if users actually wanted them enough.

Not to say there are not gaps, but I think at this point those gaps are widely over-blown and the actual amount of effort to port 1-2 packages you may need to ROS2 is surprisingly small (and probably a good experience for developers to do to learn ROS2 so they can hit the ground running).

4 Likes

I think the true issue is that the gap is perceived to be much larger than it actually is and I think this is because of the difficulty of accessing good online resources. For instance, there may be higher quality packages in ROS2 compared to their ROS1 counterparts but identifying the correct ROS2 package you need is not always straightforward.

The ROS2 docs are also less beginner friendly than ROS wiki, which I think still drives new users to start with ROS1. To make matters worse, ROS wiki keeps on coming up in search results when looking for ROS2 related issues. In fact Googling pretty much anything related to ROS2 is a nightmare because the search results will mainly be related to ROS1.

1 Like

I agree that it’s mostly a perception issue, but also want to emphasize the second part of that bullet point, which you didn’t include in your quote:

one single crucial package didn’t exist in ROS2

It looks like 6 people filled out the poll. I’d say that’s hardly representative of the community - especially since the majority of ROS users don’t visit Discourse (citation needed). And that’s again I think where the discrepancy lies. As ROS devs we wouldn’t consider a single package to be an issue, but for the everyday user, the roboticist who has a lot to think about already, that could be enough to postpone a switch to ROS2. The same argument (majority doesn’t visit/engage with Discourse, mostly hardcore users) could be used to argue that the percentage of people who will stick with ROS1 might be much higher.

Add in @hadiTab’s points and you might have an explanation of why it’s going slower than you’d expect. Again not saying that I think that people should stick with ROS1, just trying to pitch in my thoughts so we can figure out a way to make the switch happen faster.

Apologies for being that guy, but I believe this seems to miss the point a bit.

Yes, if you already know what you are doing with ROS 2, porting those 1 or 2 missing packages should not take that long.

But if we’re considering users here who currently have a ROS 1 system working and then start looking at ROS 2, a missing package is a missing package, and those simply increase the cost of even considering to use ROS 2 (this came up in other threads, such as Comepetion run by Sellafield: Standardised robotic control architecture for Sellafield - #9 by gavanderhoorn).

The same problem existed in ROS 1 in many industrial applications.

Talking to engineers in companies, one of the first things they did was to see whether the hardware they were using or intended to use was supported by existing ROS packages. Almost always, most things were supported, but “one or two packages were missing”. My response: “well, adding those one or two packages should not take that long”. Their response: “well, they are missing, and therefore mean more work”.

This was one of the motivations for starting our ROSin project: increase the set of available packages (just for hardware drivers for instance) to get around the chicken-and-egg problem. Cost to start is high because components are missing, components stay missing as due to the high cost those packages don’t get created.

This may indeed be an important factor.

Adding “ROS 2” to a query does help a bit, but yes, fi ROS Answers is also mixed ROS 1 and ROS 2.

2 Likes

Some parts of ROS aren’t even released for ROS Noetic yet, so let’s not rush anything :smiley:

I have to say I found it “interesting” when people using things like nav2 only stated ROS2 should be the default even before MoveIt was released. Now MoveIt has been released in the meantime but there is still ROS-I and the drivers for industrial manipulators that need to follow (AFAIK)

[1] https://github.com/ros-industrial/industrial_core/pull/258

In education, we use rosserial (with 8 bits processors) to make some small robots, but in ros2 these package is not available(I understand the reasons of micro-ros). This change generates that students would come with new skills to the course to build some robot.
The same happen with other tools like ign-gazebo, the change from virtual machines to docker environment, and many new good practices, which make it really difficult to combine learning ros and learning robotic theory.

I think 6 must be a typo? There are over 60 responses at this point. I do however agree this poll is unscientific and probably doesn’t represent the entire ROS community. It’s just a data point with large error bars around it.

I must be looking at the wrong thing or don’t have full access. This is what I’m seeing :slight_smile: