ROS 1 vs ROS 2

[rbridges12]

Here's my current pros/cons list for ROS 1 vs ROS 2. not in any particular order, pros of ROS 1 pretty much overlap with cons of ROS 2 and vice versa. Please add any thoughts or ideas (especially @ankithu). I will continue to update this and we will discuss this during tomorrow's meeting if we have time.

ROS 1

Pros

• has lots of documentation and support, making it relatively easy to debug issues and learn concepts
• has lots of mature, well developed packages available to use
• Currently still the dominant platform in industry, used by researchers at U of M, so if we want help this is the platform they use

Cons

• will eventually grow more out of use compared to ROS 2
• some documentation and packages are really old and are meant for unsupported ancient versions of ROS, which can cause confusion when debugging/trying to solve a problem
• Has to be run on Ubuntu 20.04 linux (also kinda works on arch 🤓), making dev environments for many members hard
  • workarounds include dual boot for windows (and non M1 macs?), possibly docker containers, ARM Ubuntu on a VM for M1 Macs
  • These workarounds will probably be good enough, but it will probably be quite a headache dealing with all this shit

ROS 2

Pros

• Will become the industry standard for ROS, ROS 1 is at end of life in 2025
• bleeding edge, lots of new package development is being done for ROS 2 (for example the ROS 2 navigation stack)
• many additional features that are slight improvements over ROS 1
  • identical python and cpp interfaces
  • modern c++17 and python3
  • no master server making multi machine setup easier
  • quality of service stuff for communications
• Cross platform support for Mac and Windows
  • hard to say how realistic this is given all of our current and potential dependencies, but definitely is very beneficial if this allows us to effectively have identical environments on all 3 platforms, will make onboarding easier
• Still has decent package support, probably good enough for our use case (?)
  • gazebo
  • rviz
  • robot_localization
  • ZED wrapper
  • ARUCO
  • state machine lib (YASMIN)
  • just to name a few of the main ones we currently use

Cons

• We’ve already made a lot of progress in both functionality and documentation in ROS 1, so switching will be a pretty large setback
• Pretty much all of the ROS knowledge on the team currently, both from working on mrover and from non mrover work, is in ROS 1
• debugging and researching stuff on our own is going to be much harder, which will make our work harder and will make onboarding and managing ROS beginners harder bc it will actually be kinda hard to google stuff (which people already struggle with enough)
• Switching over to ROS and rewriting all of our code is already gonna be difficult enough, so it may not be in our best interest to make it even more difficult by switching to ROS 2
  • we could always do a year with ROS and then make the transition to ROS 2, which would probably be much less work than this year’s transition
• new doesn't necessarily mean good
• Latest versions are only supported on 22.04, which I don’t think we want to switch to yet (jetson doesn't even officially support 20.04 yet)
• Hard to say if the other URC teams' advice is worth taking considering we didn't get any actual justification from them on why to use ROS 2

[ankithu]

Thanks Riley I think thats a really good overview.

With regards to YASMIN (smach doesn't seem to have ROS2 support at least in its ROS package I think the library itself is ROS independent ) transferring to it would be very easy because it seems almost identical to smach in how you set up and run state machines.

The way I see it, the biggest reason to move to ROS 2 is just that it is as Riley said, the bleeding edge. There are some communication-specific changes I read about and smaller things that are documented here: http://design.ros2.org/articles/changes.html that potentially make the system better but as far as I can see not to the extent of giving us a competitive advantage.

The biggest reason to not move to ROS 2 (in my view) is the knowledge that we already have on the team of ROS 1. Also, the documentation just seems to be a lot worse for ROS 2 things. Just anecdotally I seem to have to append ROS 2 to all my searches to get ROS 2 specific results which is kind of annoying. I don't think we're going to have much of a problem from the package side of things as at least from what I've checked there is support for ROS 2 or there are very similar/equivalent ROS 2 packages for pretty much everything we're doing (at least currently).

I think that not going with ROS 2 for reasons of team knowledge and/or documentation would be a perfectly valid thing to do as these are things that should theoretically only get better with time and make the switch easier in future years (it will have to happen eventually). I also think that switching to ROS 2 right now would almost definitely make the overall effort we spend porting systems less in aggregate (it'd be one bigger switch as opposed to one big switch and one smaller switch). My vote would probably be to stick with ROS 1 for now given all this information but I don't really think there's a right or wrong answer here.

[niwhsa9]

[zwgold]

After reading this, here's my viewpoint: As much as I want us to use the "best" available software, (one that enables us to do the most without having to reinvent the entire wheel) I think staying with ROS 1 is going to be the prudent move. A lot of the cons under ROS 2 concern me more than the ROS 1 ones. (latest ROS 2 is only for Ubuntu 22.04, though see below for something on that; the issue with jetsons, the lack of knowledge of ROS 2 on the team as of now, and our timeframe to try and learn it being fairly small, the progress we've made already) Some of the cons for ROS 1 can be mitigated, even if it is a pain to do. I'd also prefer not to scrap the current progress everybody has made in favor of using a system that, even if URC teams had supported it, may be more cumbersome to deal with. If possible, if any URC teams that had used ROS 2 are going to CIRC, it might be a good idea to discuss with them the merits of ROS 2 and why they went with it.

One thing is if we end up getting through our backlog and most of our URC critical tasks throughout the year, we can have members with less work/critical tasks focus on trying out ROS 2 and documenting their procedures, changes, and whatever else they can find. It would give us a bit of a head start if we end up changing over to ROS 2 after this year.

In summary: My vote is to stick with ROS 1. ROS 2 is definitely a bleeding edge and can be amazing for us in the future. But given the timeframe, the current state of our progress, and the concerns of ROS 2 that, in my view, outweigh the benefits given our situation, I would have to shy away from it for now. (save for any potential progress other members can do during the year) Great work @rbridges12 with these findings and write-up.

[rbridges12]

After meeting about this, we've decided to stick with ROS 1 this year for many of the reasons listed above.