Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New ROS 2 port of cartographer_ros - tracking issue #1536

Open
MichaelGrupp opened this issue Oct 26, 2020 · 13 comments
Open

New ROS 2 port of cartographer_ros - tracking issue #1536

MichaelGrupp opened this issue Oct 26, 2020 · 13 comments

Comments

@MichaelGrupp
Copy link
Contributor

MichaelGrupp commented Oct 26, 2020

We plan to make a new ROS 2 port of cartographer_ros that is in sync with master.

There is already a port of cartographer_ros that is based on tag 1.0.0 of cartographer_ros, but hasn't been synchronized anymore besides minor fixes. Now that cartographer is maintained again as a community-driven project, we decided together with the OSRF that a new ROS2 port should be created here.

The rough plan so far:

  • We will archive a snapshot of the existing port on a read-only branch ros2-dashing-1.0.0. Studying the diff of this branch to the ROS1 release-1.0 branch will be very useful as a basis for an up-to-date port. ✔️
  • We will start a ros2-dashing branch because we can't have the ROS1 and ROS2 versions on the same branch. The goal is to be compatible with Dashing up to Foxy. master will remain the branch for ROS1 as it is right now. ✔️
  • Doing the largest bunch of work: the actual port. We see two possible strategies (open for discussion, see also ROS2 port of cartographer_ros (library & executables) #1557):
    • Create a new branch from master and apply similar changes like the ones that were added in the original ROS2 port.
    • Start with ros-dashing-1.0.0 and work your way up by cherry-picking each missing commit from master and adapting it to ROS2.
    • (my gut feeling is that the first one is easier, but this would need to be tried out)
  • Create pull requests, ideally multiple ones instead of one huge bulk change, and merge them into ros2-dashing.
  • CI will be set up once we reach a first working prototype.
  • Documentation needs to be reviewed and changed if required.
  • Demo data bagfiles should be made compatible with ROS2.
  • Once we reach a stable state, we want to do a release in coordination with OSRF.

Note: As this is currently just a rough plan, we will probably need to spawn new issues for refining some of the work packages (as "ros2" labeled issues).


This issue aims to provide an entry point for people who are interested to contribute, ideally with experience in ROS2 and Cartographer. Feel free to comment here.

@3473f
Copy link

3473f commented Oct 26, 2020

Would definitely love to get involved as I have been getting my hands dirty with the source code recently. Any leads on where to start would be appreciated.

@Serafadam
Copy link

Hi, I'd also like to help, for starters, I am currently using Cartographer in one of my projects, from the ros2 repository. If I want to move to ROS2 Foxy, I'll also need to upgrade rplidar repository to this distro. As for creating this version, will there be some kind of release? I'd rather not start working before some huge feature gets added. As for the way of working, I think the best would be to branch off the latest commit here, and base work on #1488.

How does that sound?

@MichaelGrupp
Copy link
Contributor Author

Hi @3473f and @Serafadam, thanks for joining the discussion! I have just updated the description with more details that we discussed this week in a maintainers meeting. Would be great if you can have a look and let us know what you think and if this is something you would like to contribute to.


As for creating this version, will there be some kind of release?

Yes, that's the goal. To have a new release and then in the future also more frequent releases.

As for the way of working, I think the best would be to branch off the latest commit here, and base work on #1488.

I also think so, as I wrote now in the description.

@3473f
Copy link

3473f commented Nov 7, 2020

Hi @MichaelGrupp, sorry for the late reply! that definitely sounds interesting. I have a lot of my plate in the next two weeks, after which I can start contributing regularly to this port.

Create a new branch from master and apply similar changes like the ones that were added in the original ROS2 port.

I'd rather follow this approach as well. The only case I'd find starting from the current ROS2 port useful is if it was a few commits behind, but it seems that Cartographer has changed a lot since then.

@airballking
Copy link

airballking commented Nov 11, 2020

@MichaelGrupp Great initiative! My team has good experience using Cartographer and wants to switch our current robot system from ROS1 to ROS2. Right now, Cartographer is the only dependency that is blocking this migration. So, we are willing to help. Let us know how we can contribute!

@MichaelGrupp
Copy link
Contributor Author

Hi, to give you an update: I actually started doing some things myself already:

I started it this way because this repo actually includes 3 ROS packages cartographer_{ros, ros_msgs, rviz} and the message package is needed for the others (and also rather easy to port).

Once these are merged (I plan to follow up in the next days), we can go on with porting the cartographer_ros package, which is the biggest one. Here it would be awesome if someone of you could do the deep-dive into to the code, I probably won't have so much time for this in the next weeks.

What do you think? Feel free to comment also on the open current pull requests of course.

@airballking
Copy link

@MichaelGrupp Sounds like a reasonable plan. Regarding deep-dive into cartographer_ros, do you already have an overview which nodes/scripts can be ported on their own? Those could end-up being individual items in a check-list and separate PRs. With such a list, it could be easier to commit to taking on individual items.

@MichaelGrupp
Copy link
Contributor Author

@airballking I like this idea. I opened an extra issue for this because it maybe goes a bit too much into detail for this tracking issue: #1557

@handmat78
Copy link

If you need IMU data ROS2 driver, SBG Systems has developed one: available on the repo

@doisyg
Copy link

doisyg commented May 5, 2021

* Create a new branch from `master` and apply similar changes like the ones that were added in the original ROS2 port.

This is the strategy that I applied here: #1622
I believe most of the work is done. Still needs extensive testing, parameter check, performance review and complementary features to be converted (rviz!)

@doisyg
Copy link

doisyg commented Nov 18, 2021

Rviz is now supported in ros2 galactic in our PR #1622 . Any suggestions on how to move forward with a proper ros2 galactic release ? Current ros2 bin release is from a very old version of both the library and the wrapper (with only cartographer_node working).
We are planning to discuss and add lifecycle support next.

@iLanceS
Copy link

iLanceS commented Sep 19, 2022

Is there a planning for Port it to Humble Hawksbill ?
@doisyg

@MichaelGrupp MichaelGrupp unpinned this issue Jan 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants