ROS2 Update

[Pedro-Roque]

Just opening up this issue since I couldn't find anything regarding Astrobee and ROS2. Are there plans for the port? At KTH we are starting a new lab in which we plan to use Astrobee-analogues and we are planning to go for ROS2 from the start, so we would be interested in contributing to this effort (tagging @marinagmoreira @bcoltin @trey0 ).

[trey0]

Hi, Pedro!

We are very interested in eventually migrating to ROS2, but there are a lot of complicated issues tied up with it.

A piece of good news is the Astrobee flight software team will have a small stream of new funding to study platform modernization, which can include considering both ROS2 and its Space ROS extensions. But I wouldn't expect to get to a fully supported ROS2 build for a while.

For one thing, our team is already burdened with supporting the software sim in Ubuntu 16.04, 18.04, and 20.04 (with their respective different ROS1 versions and third party library versions), so multiplying that sounds painful. There is an active effort preparing to migrate the Astrobee hardware units from 16.04 to 20.04, which should allow us to deprecate the older versions and simplify the code base a lot. It would be great if we could complete that simplification before investing seriously in ROS2 support.

There are also lots of open questions about how to do the migration. From my perspective, the theme of the migration should be to improve software quality by moving to the new framework whose core has a higher level of QA, and keeping the software stack as simple as possible for robustness and maintainability. I would probably advocate for moving to the most recent ROS2 version that runs on Ubuntu 22.04, due to its better maturity, even though that would make our overall ROS1-to-ROS2 jump bigger, and also against pursuing a hybrid build where ROS1 and ROS2 modules run side-by-side and communicate via a bridge, because I expect that might even be a step backward in terms of having more ways for things to go wrong. But these are all questions that need more study.

I think a realistic hope is to have a clear plan for this by say the end of February 2023. And it's great that you're raising the question now leading up to the next Astrobee Working Group meeting in October. We should probably use the AWG as an opportunity to ask about stakeholder needs and concerns relating to a possible migration. There's a lot of legacy code out there and we can't strand users who still have ISS activities left to run.

Something we hadn't considered is that outside developers might be able to provide a significant force multiplier for our team to help with the transition. That could make a big difference! So that's another place for more discussion. Thanks for raising this issue!

[Pedro-Roque]

Hi @trey0!

I see a very close alignment between your thoughts and ours here. We also do not believe that a good way forward is to still be tied to ROS1 since that is deprecated, and bridges would be another failure point that we wish to avoid. SpaceROS is on our minds too, but since there is no clear release yet (at least for public/academic users), we think that might go to the second plane. Right now the priority would be to go to ROS2+Ubuntu 22 (and perhaps even think about a way to make the dependence of Ubuntu 22 away - ROS2 on Arch, as then we could use lighter OSs both on the platforms and on our dev systems, but this is also second plane thought).

Indeed, having outside developers running the platform can have a significant contribution to the Astrobee - afterall, isn't that the benefit of Open-sourcing it? 😃 Since there exist already important guidelines in place (cpp format / PEP compliance , documentation standards), this shouldn't be a big hurdle.

On our side, we are 4 PhD's that will be using the software, and I believe across the Astrobee WG there are many more. Let's talk at the AWG, but probably until then we might start working on a tentative migration of a few modules. We will bring some ideas/points on how to go forward.

Cheers!

[marinagmoreira]

While we don't have anywhere better to put this, here are some notes from a meeting we had:

Migrating to ROS2 Recommendations:

• Use rolling version to get latest features (seems that a specific release might not be complete enough). rolling can be compiled for arm in 20.04 (rolling is advertised as for 22.04), so no OS upgrade necessary for now.
• Use docker to release to robot, less setup.
• Use lifecycle nodes from the start
• Use abstraction with rclcpp_lifecycle for things like: wrap up callbacks, scope time, diagnostics
• Pipelines CPU sets (apparently you can assign CPU's to certain pipelines such that nodes in a pipeline formation don't interfere with each other), measure latency
• Build system powerful but commands not intuitive, able to do things like linting/testing
• Comms use fastrtps for users (Apache 2) keep using rti for robot (better), ROS2 looks for which one is available, so possibly no more separate set of instructions.

Things to try

• data visualization: foxglove/webviz
• development env: vscode + ssh + docker images

Others

• Check what packages/libs are missing from ROS2/SpaceROS

[Pedro-Roque]

Awesome Marina, will use these as well for the meeting ahead, thanks! I'm also starting a ROS2 devcontainer folder here: https://github.com/DISCOWER/ros2_astrobee_ws @marinagmoreira

[trey0]

There is a lot of discussion about how to potentially support multiple ROS versions in one repo branch at #562 . Perhaps we can bring the discussion back to this main thread if that experimental PR is likely to be closed.

[marinagmoreira]

I found this thread that mentions agnostic .xml files https://github.com/ros-infrastructure/rosdep/issues/653 and I tested it using the same xml in ros1 and ros2 and works flawlessly, all we have to do is bump the package to format 3.

Tested example: https://github.com/marinagmoreira/astrobee/blob/ros2/astrobee/package.xml

[Pedro-Roque]

That's awesome, I looked for such an option but didn't come across that - that fixes the issue for XMLs, and we can keep what we had for CMakeLists. I also think regular meetings and dividing tasks would be good since we have overlapped @marinagmoreira (I had a devcontainer already hehe).

Suggestion: with PX4, there are DevCalls (weekly) that anyone can join. We can have higher frequency in the beginning and then get back to weekly :)

[trey0]

Tested example: https://github.com/marinagmoreira/astrobee/blob/ros2/astrobee/package.xml

Tested in ROS1 kinetic? :)

If so, it sounds great! The approach could be (1) rename package.xml to ros1-package.xml until the ROS2 coverage expands to that package, then (2) rename back to package.xml and use package format 3 with conditionals after that.

[trey0]

Wow, REP-149 is a great find, too. It sketches the idea of "universal packages" that compile under both ROS1 and ROS2. I had been looking for those but couldn't find them among all the migration tutorials. I just realized the conditional syntax in package.xml is something perfect to search on to find examples (see below).

I think these could be very useful to help us find the right patterns that enable universal support with minimum pain.

• https://github.com/luxonis/depthai-ros - Claims to support ROS1 Melodic up to ROS2 Galaxy
• https://github.com/mrpt-ros-pkg/pose_cov_ops - Found from useful discussion at https://discourse.ros.org/t/why-not-exposing-ros-version-in-the-ros-1-2-build-farms/25476
• https://gepgitlab.laas.fr/gepetto/example-robot-data/-/blob/master/package.xml

[marinagmoreira]

Tested example: https://github.com/marinagmoreira/astrobee/blob/ros2/astrobee/package.xml

Tested in ROS1 kinetic? :)

If so, it sounds great! The approach could be (1) rename package.xml to ros1-package.xml until the ROS2 coverage expands to that package, then (2) rename back to package.xml and use package format 3 with conditionals after that.

It works for kinetic, yes.

However, I don't think we should worry about ROS1 kinetic for this migration. We're not in a rush to merge with develop and supporting 4 platforms is too much for such a small team (even 3 now is time consuming -- e.g. I spent a few hours last week fixing a build error that only happened in melodic even though we prob don't have many users on it). My suggestion is to coincide this migration with the noetic robot migration and make a "last kinetic release".

[trey0]

I agree that we should try not to support too many platforms at once.

In particular, let's discuss dropping melodic support again. The only reason I'm aware of that we keep support for it is that it's the native install on the NASA-internal astrobeast server. What's blocking us from upgrading astrobeast and dropping melodic support? (The last time I suggested this, the response was that melodic support was not a big time sink, but maybe that's not the case?)

Unfortunately, I think kinetic support may be needed longer than any of us would like. It's not very well-defined when the facility team can end-of-life it. There may be important legacy users (e.g., Kibo-RPC) who especially value stability and want to hold off on upgrades for a while.

There is a proposed roadmap of ROS2 migration phases on the NASA-internal FFFSW wiki (same as in some PPTX slides we shared) https://babelfish.arc.nasa.gov/confluence/display/FFFSW/ROS1+To+ROS2+Migration . That roadmap calls for merging ros2 into develop when transitioning from "Experimental" phase to "Work-in-progress" phase. However, and this is important, that comes well before the transition to "Dual-support" phase. In other words, merging into develop would not signal that ROS2 is a supported platform. The objective of merging would be to make sure that ongoing improvements to the ROS1 version flow to the ROS2 version as well by default.

[marinagmoreira]

o do not believe that a good way forward is to still be tied to ROS1 since that is deprecated, and bridges would be another failure point that we wish to avoid. SpaceROS is on our minds too, but since there is no clear release yet (at least for public/academic user

Yeah I used the repo you created as a base :) but worked on simplifying the Docker image so it's not 14Gb just for the base ROS install. Also that image doesn't include gazebo :(

What time would it be good for you? I'm thinking either 8AM or 9AM PST that translates to 4PM or 5PM in Sweden, depending on your nominal workday schedule. (My calendar is free any day of the week for that time.)

[Pedro-Roque]

That works well for me, Wednesday would be a good day if that works for you?

I was about to add the Gazebo stuff in since but I started checking how to migrate the code from the old Gazebo and then I never did 🫣 If you have that PR somewhere / you are going to PR to that repo, I'd be in to check it out!

[marinagmoreira]

That works well for me, Wednesday would be a good day if that works for you?

I was about to add the Gazebo stuff in since but I started checking how to migrate the code from the old Gazebo and then I never did 🫣 If you have that PR somewhere / you are goingf to PR to that repo, I'd be in to check it out!

Great, that works for me :)

Let me get the PR in today, I'm a little late on that (docker stuff is always sooo slow :/ )

[trey0]

Here's the simplest approach yet for disabling colcon build of packages that will eventually become universal packages (ROS1+ROS2), but that don't yet compile under ROS2: if you place a COLCON_IGNORE file in a folder, it will be ignored by colcon package discovery.

Here's one place the feature is mentioned: https://colcon.readthedocs.io/en/released/reference/discovery-arguments.html

[trey0]

Another note relevant to enabling a universal package to condition on ROS version: You can add <depends>ros_environment</depends> in your package.xml and it will define some standard ROS variables like $ROS_VERSION in your environment.

It seems like it defines the variables in your shell environment when you source setup.bash (you would only need to add it to one package.xml file in the workspace to get this effect). I'm not sure if it defines them in other contexts as well, like during build, or when executing files with rosrun or ros2 run.

Anyway, this might be convenient for keeping our environment management approach more standard.

Looks like it does the same thing under ROS1 and ROS2: https://github.com/ros/ros_environment/tree/noetic/env-hooks https://github.com/ros/ros_environment/tree/rolling/env-hooks

[trey0]

if you place a COLCON_IGNORE file in a folder, it will be ignored by colcon package discovery.

I just learned to my surprise that the noetic version of catkin "helpfully" respects COLCON_IGNORE markers as well, so it turns out this is not a good way to mark packages as ROS1-only.

However, given we have the autogen symlink script, an alternative approach that is arguably just as easy is to rename any ROS1-only package.xml file to package.ros1.xml. Then the autogen script will skip symlinking it when ROS_VERSION=2, colcon package discovery won't find the package, and colcon won't try to build it.

If there are no objections, I could easily submit a PR that removes the COLCON_IGNORE marker files and renames the corresponding package.xml files.

[bcoltin]

Use Marina's link above for the future. Closing this issue.