Catkinizing for Hydro

[bit-pirate]

Looking through the stack deps, I have found the below stacks/packages which haven't been catkinized yet. We would need to contact the maintainers to check, if and when these get catkinized.

• map_store (kforge): currently no development happening
• navigation (github): looks like they are preparing
• slam_gmapping (github): currently no development happening

That's it I would say.

[bit-pirate]

According to Jorge, the navigation stack is currently under heavy development and there are plans to get it catkinized for Hydro.

For map_store and slam_gmapping I have contacted Dave Hershberger. There are no official maintainers for these stacks and he has been the last one committing to each of them. Let's see, if there are any plans for catkinizing these. Maybe we have to allocate some time to help on this.

[mikeferguson]

Just a note, slam_gmapping will be a fun one to catkinize, since it uses the old "download a tarball from wg, and build it", which I don't think exists in catkin....

[chadrockey]

Ugh, yeah those are terrible. Sicktoolbox used automake and the tarball method. I ended up forking it entirely to github and just creating a cmake version that included all of the patches.

[mikeferguson]

Yeah, I think that was the same thought for gmapping. Also just a note, before Vincent departed Willow, he did talk with the gmapping authors and got their blessing to create a github fork, hosted here: https://github.com/ros-perception/gmapping

[jack-oquin]

Segbot has similar conversion requirements.

[hershwg]

@vrabaud Do you have an opinion on the catkin-ization of https://github.com/ros-perception/gmapping ?

Is there a problem with making it a catkin project directly?

http://ros.org/wiki/bloom/Tutorials/ReleaseThirdParty This bloom doc makes it sound like it's not that hard to release a non-catkin package with bloom in such a way that it plays nicely with catkin. Sounds like all we need to do is add a package.xml file and modify the makefiles such that it gets installed.

I don't have feelings for this one way or another, I just want us to find the easiest way forward.

I think map_store should be easy to catkinize. I can probably get to it in the next week or two.

[jack-oquin]

@piyushk and I released a patched-up libfreenect as a 3rd-party package. It was more difficult than we expected, but seems to work OK now.

It is a reasonable solution for the kind of problem you describe.

[piyushk]

I'll add my two cents here. IMO the easiest way forward is @hershwg's first suggestion of making the fork a catkin project directly. gmapping has not changed in the last 5 years, and it's not clear if a 3rd party release that maintains ties to the original SVN repository has any benefit. Additionally, in terms of SLAM approaches, it is pretty old. I am not sure how relevant it will be a couple of years down the line.

When @jack-oquin and I patched libfreenect, it had CMake set up already and the patches were relatively minor. There were subsequent problems in releasing those patches into both the groovy and hydro release. Given that gmapping will require far more significant patches to setup CMake, and it's not clear if anybody has time to maintain the stack - I am not sure if doing a 3rd party release is the best option.

[bit-pirate]

Out of curiosity, is there an alternative to gmapping out there - something less outdated and easier to be catkinized?

[rgariepy]

Karto and Hector are similar and not difficult to work with, not sure how
hard they are to catkinize. I had someone here do a comparison study
throughout our office, but it's not yet done to my standards. In general,
gmapping seems to be the slowest, middling in robustness, and awful wrt
memory usage.

-Ryan

On Mon, Jun 24, 2013 at 7:50 PM, Marcus Liebhardt
[email protected]:

Out of curiosity, is there an alternative to gmapping out there -
something less outdated and easier to be catkinized?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-19944316
.

[tfoote]

There are two parts to gmapping which are currently conflated. There's the
external 3rdparty package, and then the ROS interface.

Hector is probably the best alternative. I expect it will be converted in
the future. But I believe the authors are pretty busy at the moment with
another project.

On Mon, Jun 24, 2013 at 4:58 PM, rgariepy [email protected] wrote:

Karto and Hector are similar and not difficult to work with, not sure how
hard they are to catkinize. I had someone here do a comparison study
throughout our office, but it's not yet done to my standards. In general,
gmapping seems to be the slowest, middling in robustness, and awful wrt
memory usage.

-Ryan

On Mon, Jun 24, 2013 at 7:50 PM, Marcus Liebhardt
[email protected]:

Out of curiosity, is there an alternative to gmapping out there -
something less outdated and easier to be catkinized?

—
Reply to this email directly or view it on GitHub<
https://github.com/turtlebot/turtlebot_apps/issues/41#issuecomment-19944316>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-19944636
.

[vrabaud]

the gmaping fork we created on GitHub (with Giorgio's approval) is just the 3rd party one. We could catkinize it if necessary. And it include the patches (and more) that we did in the hacky rosmake version.
Now, there is still the slam_gmapping one: that should be trivial too. Let me try to do both tonight.

[jack-oquin]

I think we do want a catkinized version of gmapping. Despite its age and lack of activity, it has been useful for many in the ROS community.

The main reason Piyush and I used bloom 3rd-party packaging for libfreenect is because we did not want to take over maintaining it. We wanted to keep the option of replacing it with some newer "official" version, should the upstream developers choose to release one. We check out a more recent level from the upstream repository that has additional fixes we need. Then we add package.xml as a patch. Unfortunately, many more patches are needed to get things working.

If gmapping is not actively maintained any longer, it will almost certainly be easier to maintain the package.xml, CDMakeLists.txt and other ROS files directly in the source repository. We can declare it "end-of-life" and only change it to fix bugs.

[vrabaud]

sounds good, Should I merge slam_gmapping and gmapping ? make more sense to me to keep them as two packages.

[mikeferguson]

I would keep them as two separate packages -- it's more inline with the ROS "thin-wrapper" ideal...

[piyushk]

+1 for separate packages. The github gmapping repository will be useful if someone wants to use gmapping through cmake. Since it should be relatively easy to patch this upstream repository, the third party release (aka ros--gmapping) should be relatively painless.

In case you don't have a reference already, take a look at libsegwayrmp and segway_rmp. It's a bit cleaner than libfreenect. The corresponding release repos are under the same organization.

[vrabaud]

ok guys, I kept them separate and I catknized them. This is a first draft: gmapping + slam_gmapping compile for me on Ubuntu Raring gcc 4.8.
slam_gmapping is fully catkinized.
gmapping is not: there are some folders that are just for GUI's I think. I'll do that later.

I'd be more than happy to have another official maintainer as I now have 51 packages to maintain :)

[bit-pirate]

@hershwg already started catkinizing map_store.

[mikeferguson]

FYI ros-perception/slam_gmapping#6

[hershwg]

OK, https://github.com/ros-planning/map_store is catkinized and passes its test. I haven't actually used it, so please let me know if there are https://github.com/ros-planning/map_store/issues . I'll do a release if it works for you.

[bit-pirate]

@corot let's test the map_store some time soon, so that @hershwg can proceed with the release.

[corot]

map_store works like a dream.....

[hershwg]

@corot thanks! map_store release process is done on my end, now we wait for build farm etc.

[corot]

All catkinized and ready to release