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

[gavanderhoorn]

@smac

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).

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.

@hadiTab

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.

This may indeed be an important factor.

@hadiTab

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.

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

[simonschmeisser]

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

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

[olmerg]

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.

[mkhansen]

@Achllle

It looks like 6 people filled out the poll . I’d say that’s hardly representative of the community

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.

[Achllle]

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

[mkhansen]

Ah, OK, we’re talking about 2 different things. I was referring to the Poll that started this thread. You’re referring to Steve’s survey of packages from a few months ago.

[smac]

@olmerg

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).

CC @Jaime_Martin_Losa this is an extension of the discussion we had on supporting things like Unos and Megas, which are still very commonly used. If micro-ros can’t support those, we probably need serial introduced into the embedded ecosystem.

@Achllle

It looks like 6 people filled out the poll

Sure, I don’t think there’s value in overly dissecting that, I didn’t place a particularly large evidential burden on that. I’ve provided other evidence points as well. There’s a reason that I also looked into the installs of all packages over lifetimes that tells a very clear story.

@gavanderhoorn I think we’ve had a similar discussion in other threads, so I’m going to just leave it as: agree to disagree. The idea of a company (excluding researchers from this comment) that is unwilling to do even minimal dependency management is ultimately asking for a rude awakening when their systems start dying in the field after updates. I can understand not wanting to port all of their drivers, but if they’re purely relying on apt install ros-<distro>-realsense-ros for their product and uninterested in the code/internal versioning, that’s a really not good sign.

In regards to the perception of ROS2 problem, alot of that starts with people here taking the time to become more acquanted with the current state of the world in ROS2-land before making statements that continue to perpetuate that narrative. Obviously I’m on the other side of that coin where I’m “ra-ra-ra go ROS2”, but if we all agree that there’s a bit of a perception issue, I think that starts right here with the types of users that are active on Discourse.

[FraFin]

@smac and @olmerg micro-ROS, as it is, is not fit for the MCUs you’re mentioning (like the Arduino Uno) due to memory constraints. However, Micro XRCE-DDS does (see the memory footprint of the latter compared with that of micro-ROS). In our 2021 roadmap, we have in mind to provide a light version of micro-ROS made of just a thin layer on top of the middleware. This would carry out a subset of minimal functionalities (pub/sub of basic types, with no implementation for higher-level concepts such as the executors), and is intended to fill up that void space in the ROS 2 ecosystem which in ROS is covered by rosserial.

[gavanderhoorn]

@smac

Obviously I’m on the other side of that coin where I’m “ra-ra-ra go ROS2”, but if we all agree that there’s a bit of a perception issue, I think that starts right here with the types of users that are active on Discourse.

I’ve been on “your side” of the coin for the past 9 years Steve.

There isn’t much opinion in my post, I’m just reporting what I hear and read.

[lucas.labarussiat]

Hey guys ! Just wanted to jump in to give the perspective of someone new to ROS here.

Actually I am not that proficient, neither in ROS nor in any programming language in general. I mean, I get the logic behind it and I am able to adapt some code to my needs, but I feel like I am far from being able to build something on my own, not even talking about optimizing code or good practices.

I am currently in the process of building a quadrupedal robot, which I intend to use to give mechatronics classes. To this end, I decided to use ROS because I heard about it a while ago and since then I was convinced it would be helpful if I wanted to become a roboticist.

Now I have to say I went through the tutorials, but I am still uncomfortable with ROS. I found some really nice packages for quadrupedal robots which almost are plug and play solutions (like champ or quadruped_ctrl, I also gave Towr a try).

I am following this discussion quite eagerly, because of course I would like to switch to ROS2. I read some articles about the advantages it offers compared to ROS1, and I’d like to be sure my robot will be embedded with a state-of-the-art solution as well as one easy to maintain in the future.

But actually the packages mentioned above are all based on Melodic (AFAIK), and I mean, they are quite enough for what I intend to do. And mostly I don’t have the slightest idea about :

• how do I know if the packages already exist on ROS2
• if not, what would need to be done to port them on ROS2

The only thing I can think of on the latest is :

• deleting my ROS1 installation and have a clean one using only ROS2
• try git-cloning these packages and compiling them
• tracking the errors that come up during compilation and wandering the forums if needed to fix them one by one

I guess this isn’t how you do it, and I would actually need to follow some tutos about ROS2 basics and how to port a package from ROS1 to ROS2 (I’ve already come across some videos but please feel free to point me to the right direction).

But in the end I am still wondering if I would be able to do it, and if this is worth the time, considering the packages already offer a really nice base for what I intend to do, and that I also have tons of work to get done on the robot and the curriculum.

Anyway, I wanted to give my perspective here, as someone who has just recently obtained his engineering degree and who happens to be a newbie in ROS : pondering these questions takes time and it can feel intimidating.

If you have any thoughts you want to share or any advice to give, I’ll be glad to read it

[130s]

@mkhansen

If you respond with ‘Melodic’ I’d love to hear the reason you’re going to Melodic instead of Noetic. Is it due to Python2 vs Python3 or something else?

The following is my opinion toward the decision my team made (i.e. The following doesn’t represent the decision the team made):

• Yes Py2 vs Py3 was a huge factor.
  • Indeed I’ve been seeing issues in Noetic that are rooted in Python version.
  • There was/is a confusion in me and/or in my team that all Python-based software would need to be converted to Py3 on Ubuntu 20.04. I still don’t know if that is true. But we wouldn’t favor breaking many Python-based S/W so went safer with 18.04.
• Timing…At the moment where my team was making a decision, Noetic was just out of cradle so it was hard to tell whether it would get enough traction so that community effect helps the software to solidify (now, it seems it has been getting popularity at least by looking at metrics.ros.org). We were just not sure if we could afford that issues even when we knew those were going to be fixed quickly.

I’ve been on “your side” to advocate latest and community-based development, but then working in a small startup where there’s only limited resource to spend on migration but fortunately there are customers’ immediate needs to fill, I’m pulled toward to “the other side” sadly. I’ve been and will be trying to make a balance in between.

[DLu]

Shameless plug for ROS Clock

[Kasper_Jeppesen]

Long time ROS1 use here (8ish years) in the research community (RTO, not university). We have been working with ROS2 for a little while now trying out different things (mainly related to the nav2 stack), but my general feeling is that I’m “fighting” ROS2 much more than ROS1 - perhaps just due to the novelty of it - which takes time away from what I want to research or develop.

When I say fighting, I mean those things that have become parts of your “subconscious debugging toolbox” like dealing with the CLI interfaces, timing issues (use_sim_time, tf lookup), RVIZ vs RVIZ2, new parameter concept, missing tooling that you have become accustomed to, not fully understanding the DDS structure, QoS profiles and so much more.

While I understand these things will get better over time, it is still a big source of frustration when you feel so at home with ROS1 - and because ROS2 is still not that widely adopted you don’t have the same backlog of 10 years of ros-answers, discourse, ros-wiki and other sources of information to debug these issues.

When you are doing R&D type things or projects that have a short life span (i.e. not making a product) then it feels natural to gravitate towards the system you are used to because you feel so much more efficient. Personally I am becoming more comfortable with ROS2, but a lot of my colleagues are quite hesitant in jumping in for these and other reasons.

A few examples of some ROS2 frustrations I’ve had:
rviz2 is extremely prone to crashing when doing simple things such as changing fixed frames or adding new topics - often without any immediately apparent reason. Also your scrool-wheel-zoom muscle memory betrays you at least once a minute :shakes fist:

So many tf and message issues - dropping message due to reason: unknown and frame published by <no authority available> etc.

The CLI interface for simple things such as interacting with topics is much more cumbersome to use than ros1. In ROS1 I would use ´rostopic info´ and immediately know who the pubs and subs are - in ROS2 all I get is a pub and sub count.

Auto completing messages when doing a CLI publish, service call, or sending an action goal are largely useless for nested message types - but admittedly the you get used to the yaml syntax, even for deeply nested messages, after a while or you start asking yourself why use the CLI for this

[ReaddyEddy]

Thanks, as someone just dipping his toe into ROS in a research context it’s very useful to get that sort of perspective. I’m a veteran of similar battles with using media frameworks in Java and Python. We have a ROS hardware driver that’s only supported under ROS 1.x at two specific versions and two versions of Ubuntu. So I was wondering which path to go down. You’ve convinced me 1.x is the only viable route for the time being. One just doesn’t have time to engage with all the nuances of environment changes when the environment is only a small part of the project.

[Christopher_Flesher]

I was looking at alternatives to rosserial when upgrading to ROS2 and ended up using simpleRPC, a protocol to talk between Arduino -> python that is extremely easy to use. It has support for different hardware interfaces (serial, ethernet, RS485, etc.).

[gbiggs]

@Kasper_Jeppesen

because ROS2 is still not that widely adopted you don’t have the same backlog of 10 years of ros-answers, discourse, ros-wiki and other sources of information to debug these issues.

You didn’t have 10 years of ROS Answers, etc. when you started with ROS 1, either. You say you’ve been using it for 8 years. The first release of ROS 1 was not much before that.

You should treat ROS 2 the same way you treated ROS 1 when you first started with it. Yes, many of the concepts are the same, but there are a lot of new concepts and a lot of changes as well. It’s a new tool and it requires learning, just like any new tool.

@Kasper_Jeppesen

rviz2 is extremely prone to crashing when doing simple things such as changing fixed frames or adding new topics - often without any immediately apparent reason

We can’t fix crashes without bug reports.

@Kasper_Jeppesen

So many tf and message issues - dropping message due to reason: unknown and frame published by <no authority available> etc.

Likewise, if you don’t tell us we can’t fix it.

@Kasper_Jeppesen

The CLI interface for simple things such as interacting with topics is much more cumbersome to use than ros1. In ROS1 I would use ´rostopic info´ and immediately know who the pubs and subs are - in ROS2 all I get is a pub and sub count.

We want to know if something has poor usability, or isn’t as easy as it was in ROS 1. Even better is you would help us figure out the ideal way to achieve a task, and not just assume that ROS 1 is best.

@Kasper_Jeppesen

Auto completing messages when doing a CLI publish, service call, or sending an action goal are largely useless for nested message types - but admittedly the you get used to the yaml syntax, even for deeply nested messages, after a while or you start asking yourself why use the CLI for this

Yes, command lines have their limits - unfortunately for those of us who hate to take our hands off the keyboard!

[Kasper_Jeppesen]

I wasn’t trying to start a sermon about why you should stay with ROS1 instead of ROS2, and that’s certainly not my personal plan - I’m using ROS2 a lot since I’m in mobile robotics and want to use Nav2. I was just trying to relay some of the frustrations that I’ve personally felt as a recent convert, and some of the complaints that my colleagues, who are hesitant to switch, have voiced.

A lot of my colleagues don’t have the same ROS1 background as I do, so they rely more heavily on things such as the backlog of rosanswers and the help of more experienced ROS1 people. So if the ROS system is only 25% of a project they are doing, they would rather stay with ROS1 at the moment. This is why most of our projects only did a kinetic > melodic migration, some projects switched to Noetic, and only some trailblazers switched to ROS2 (E.g. some of my projects which relied on Nav2).

If you were building a product end-to-end I suspect it would be different, but if you are only interested in ROS because your crazy AI system needs to interact with a sensor and output some stuff to a robot manipulator, you don’t really care that much about the underlying ROS stuff - you just want it to work the way it used to.

About the bug reports, you are of course completely right - there’s just been so much new stuff to learn in a very hectic time period that it’s felt a bit overwhelming. I’ll definitely try to get some proper crash reports and make some issues of the most common ones I’ve found.

Some one earlier in the thread (maybe Steve?) said that more people would likely be tempted to switch to ROS2 when suddenly ROS2 offers something that doesn’t exist in ROS1 and has higher quality/flexibility/etc. and I completely agree. For me it’s been Nav2 which pushed me to switch (or make a dual ros system) and hopefully in the future more great packages / frameworks like this will push other people to switch.

[Jeremie]

Hi,

Just to let you know that we are running the poll again on Twitter in the light of the recently announced ROS ESM.

I wonder if some of you will change their answer .