graphslam-engine: Integrate with 3rd party optimization Libraries

[bergercookie]

Goal: Add support for optional usage of other optimization modules. The following optimization modules are suggested:

• g2o
• iSAM/iSAM2

[jlblancoc]

Good! Just recall that any code fragment making use of an optional lib must be properly guarded with #ifdef's to ensure compilation without it.
I'm sure you knew it, but I need to insist ;-)

[jbriales]

Hi guys, I was currently looking into the possible addition of a new optimization procedure in the context of graphslam. Since you have been working with the related classes more recently than me, do you have any quick insight in which would be the best approach to wrap e.g. g2o? Just some simple hints to take as a reference for exploring the code would be most useful! :)

[bergercookie]

Hi @jbriales,

Happy to know you are interested in helping on this. I am not familiar to how g2o works or optimizes the graph, however I can make a quick overview on what needs to be implemented for a functional GraphSLAM Optimizer class to be used as part of the mrpt-graphslam library (or any corresponding application).

The main class executing graphSLAM is the CGraphSlamEngine which in turn delegates graph-related tasks to 3 other classes most notably:

• a NodeRegistrationDecider class
• a EdgeRegistrationDecidder class
• a GraphSLAM Optimizing class/framework.

Each one of theses classes must abide to its corresponding interface all of which are described here. So during the execution of graphSLAM CGraphSlamEngine code calls the interface classes which in turn come down to implementation calls to the corresponding decider or graphSLAM optimizer class that has been selected by the user.

Currently only one optimization framework is availeble CLevMarqGSO which is another wrapper around the graphslam::optimize_spa_levmarq method.

So to wrap it up, you'd have to implement the CGraphSlamOptimizer interface with wrappers around the optimization methods of g2o and/or conversion methods for passing the data (graph nodes/edges, perhaps a graph object itself) from MRPT CNetworkOfPoses form to its g2o counterpart.

P.S. I am still tinkering with the library from my fork since I am implementing a multi-robot graphSLAM algorithm so in case you spot a bug or try to modify any existing code there, check that fork in case I have already made any modification. It might even make sense to fork that branch instead (graphslam-devel2) just so that we minimize the git conflicts that would arise when we try and merge it.

Let me know if you need further assistance on this.
Cheers,
Nikos

[jbriales]

Thanks for the detailed answer @bergercookie, this is just what I needed to get on track :)
I do not expect to get into this anytime soon yet, but I'm preparing a GSOC project in this direction. So it will be good to keep these notes for future reference.

Best,
Jesus

[jlblancoc]

Hi! Just as a clarification on introducing new dependencies into MRPT: I'll be glad to have g2o as an **optional** external dependency to MRPT, as a first step. In the past I also pondered including g2o as a graph-slam solver, but haven't found the motivation / time to do it. If it ends up being really useful, g2o could be included via CMake external_project (as I want to include ASSIMP soon), so the user just checks the option "BUILD_G2O" and the sources are downloaded/cloned-in, configured, compiled, etc. automatically. Just thinking aloud about things which are really far ahead, though... ;-)

[jbriales]

Good to hear it though @jlblancoc :)
When you say automatically, it means really automatic? I didn't know about the ExternalProject tool, but it seems really powerful :)

[jlblancoc]

Yes, automatic... I just used it a few days ago in another project and I'm really happy with it : https://github.com/jlblancoc/daq-ensayos-traccion/blob/master/CMakeLists.txt#L23 El 21 feb. 2017 5:07 p. m., "Jesus Briales" <notifications@github.com> escribió:

…

Good to hear it though @jlblancoc <https://github.com/jlblancoc> :) When you say *automatically*, it means really *automatic*? I didn't know about the *ExternalProject* <https://cmake.org/cmake/help/v3.2/module/ExternalProject.html> tool, but it seems really powerful :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#317 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFPj2uUbjj6lMq4-bWA6Aiu1SaEZyyFAks5rewu_gaJpZM4Jrada> .

[jolting]

Awesome.

Just a thought...what about manifest file similar to a gemlock in the Ruby which pins dependency versions, but in this case saving the git hash for the version that we should build against. Reproducing builds might be tricky if we always fetch master branch from some 3rd party repo.

Also it would be useful to by default use the system package first and fail over to ExternalProject. They already packages up libg2o for ros-kinetic and it would be nice to pick that up automatically when building against ROS.

[jlblancoc]

Totally agree with both points, Hunter. My plan with libassimp was exactly that, to detect it as system package first, then if not found download the latest stable version. How to keep a centralized list of external projects' stable versions is an open (future!) problem, yet...

[jolting]

Agreed, for now we should just remember to pin a the version on a release.
ExternalProject_Add has a field for GIT_TAG which can be a git hash.

Basically, if .external.cmake file does not exist then fetch master of each project and record git hashes in .external.cmake by executing the git command in each directory[1]. If .external.cmake exists use git hashes from .external.cmake by including this file. Periodically regenerating .external.cmake should be trivial.

1. http://xit0.org/2013/04/cmake-use-git-branch-and-commit-details-in-project/

[jlblancoc]

I'm afraid this one is outdated by now... :-(
Closing it...

(Done in other external packages/projects outside of mrpt)