g2o: A General Framework for Graph Optimization in C++

What g2o solves, and who the README is talking to

The README frames the target problem narrowly: minimizing a nonlinear error function that can be represented as a graph. The stated examples are simultaneous localization and mapping and bundle adjustment, where the goal is the parameter configuration that best explains measurements corrupted by Gaussian noise. That is a least squares problem, and g2o is a solver framework for it.

The audience is implied by the requirements list rather than stated: a C++17 compiler, CMake, and Eigen3. If your pipeline is Python, the README points elsewhere, at the experimental pymem branch and at the separate g2o-python project for the pypi release of the bindings. The repository's own topics (c-plus-plus, cpp, slam, graph-optimization) confirm the centre of gravity.

The extensibility claim in the README is worth reading literally. It says a new problem typically can be specified in a few lines of code. That is a statement about the vertex and edge abstractions, not about the solver tuning you will still have to do.

Vertices, edges and the hyper-graph the solver actually sees

g2o's model is a hyper-graph. State variables become vertices, and each measurement or constraint becomes an edge connecting the vertices it involves. The README does not spell out the class hierarchy, but it does say the library is designed to be extensible and that the current implementation ships solutions to several variants of SLAM and BA, which is consistent with the repository layout: a g2o/ directory holding the core, plus benchmarks/ and unit_test/ at the top level.

The error function is nonlinear, so the solve is iterative. The README does not describe the linearization step, the linear solver selection, or the optimization algorithm choices in the text supplied here. Those details are pointed at, not reproduced: the README says a detailed description of how the library is structured and how to use and extend it can be found in doc/g2o.pdf, and that the API documentation can be generated as described in doc/doxygen/readme.txt. Treat those two files as the real specification. The README is a front door, not a manual.

One design detail is visible and matters for adoption: the README notes that the pymem branch switches to smart pointers instead of raw pointers. That phrasing implies the master branch uses raw pointers. If you are integrating g2o into a codebase with strict ownership rules, that is the kind of thing to confirm against the headers before you build on it.

Installing g2o and running a first build

There are three documented routes. On macOS with Homebrew, the README gives a single command that installs g2o with its dependencies, and states no manual compilation is necessary.

brew install g2o

On Ubuntu or Debian, the README lists the packages that resolve the dependencies, including the optional ones. Note that this installs the dependency set, not g2o itself.

sudo apt install libeigen3-dev libspdlog-dev libsuitesparse-dev qtdeclarative5-dev qt5-qmake libqglviewer-dev-qt5

For a source build, the README recommends an out-of-source build and gives this sequence. Binaries land in bin and libraries in lib, both under CMake's build folder.

mkdir build
cd build
cmake ../
make

The repository also ships a top-level Makefile that wraps the same thing. Its build/Makefile target echoes "Running cmake to generate Makefile", changes into build, runs cmake ../, and then the all target invokes make inside build. So `make` at the repository root works, but it assumes a build directory already exists.

On Windows with vcpkg, the README points at script\install-deps-windows.bat for dependencies, or script\install-additional-deps-windows.bat for the full set, and then gives a CMake invocation using G2O_BUILD_APPS, G2O_BUILD_EXAMPLES and the vcpkg toolchain file. The README's own snippet contains a typo in the examples flag (the space before -D is missing), so copy the flags deliberately rather than pasting blindly.

The licence is BSD, except where it is not

The README states g2o is licensed under the BSD License, then immediately lists exceptions. csparse_extension is LGPL v2.1+. g2o_viewer, g2o_incremental and slam2d_g2o are GPL3+. Bundled third-party code has its own terms: ceres headers for automatic differentiation are BSD, and a stripped freeglut is under the X-Consortium licence.

The CHOLMOD note is the one that catches people. The README says some CHOLMOD features may be licensed under the GPL, that the CHOLMOD library distributed with Ubuntu or Debian includes those GPL features, and that to avoid the GPL you may have to recompile CHOLMOD without them. It gives a concrete example: the supernodal factorization, licensed under GPL, is considered by g2o if it is available. In other words, the licence of your build can depend on how a system library was packaged, not on anything you wrote.

The top-level repository does not carry a single LICENSE file in the entries listed; the README directs readers to the doc folder for the full text of the licences. If licence clearance is part of your adoption process, that folder is where the actual text lives.

Where g2o is the wrong tool

The README's own performance claim is dated: it says g2o offers a performance comparable to implementations of state-of-the-art approaches for the specific problems, with the parenthetical (02/2011). That is the 2011 ICRA paper's framing, and the README does not update it. Anyone choosing a solver on today's benchmarks should treat that sentence as historical, not as a current comparison.

The more practical limits are structural. This is a C++ library with a CMake build and an Eigen dependency; there is no documented command-line solver in the README, and the Python path is explicitly described as an experimental branch. If your team works in Python and needs a supported binding today, g2o is the wrong default and the README says so by pointing at g2o-python.

Second, the licensing split means a blanket "it is BSD" assumption is unsafe. If you need one permissive licence across your whole dependency tree, the GPL3+ applications and the CHOLMOD packaging note are real obstacles, and the README does not offer a supported way around the latter beyond recompiling CHOLMOD yourself.

Third, the documentation surface is thin in the repository text. The README defers structure and usage to a PDF and API generation to a doxygen readme. There is no quickstart that walks from an empty file to a solved graph. Expect to read doc/g2o.pdf before you are productive.

g2o against Ceres and GTSAM

The two names that come up alongside g2o are Ceres and GTSAM, and the README gives a small, concrete hook for the first of them: the autodiff headers extracted from ceres are bundled inside g2o under g2o/autodiff, licensed BSD. That tells you the relationship is not purely competitive; g2o reuses Ceres' automatic differentiation headers rather than requiring Ceres as a dependency.

The difference in approach is in what the framework asks you to model. g2o is built around the hyper-graph: you define vertices and edges, and the library optimizes over that structure, with SLAM and bundle adjustment as the shipped variants. That is a narrower and more opinionated framing than a general-purpose nonlinear least squares library, where you hand over a residual function and let the solver treat it as an opaque cost. If your problem already looks like a pose graph, the graph framing saves you modelling work. If it does not, the framing is overhead.

The README does not compare g2o to GTSAM at all, and it makes no claim about relative accuracy or speed against either library. The only external comparison it offers is the 2011 statement about state-of-the-art approaches. Anything sharper than that has to come from your own measurements on your own problem.

Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-21. That is recent enough that describing it as actively maintained is defensible on the evidence here, but the release cadence tells a different story about stability. The three most recent releases are 20241228_git (2024-12-28), 20230806_git (2023-08-06) and 20230223_git (2023-02-26). Tags are date-stamped rather than versioned, which means there is no semantic version to reason about when you upgrade.

That has a direct cost. With date-named tags and no stated API stability policy in the README, moving from one tag to another is a code-review exercise, not a version bump. The repository does carry a .pre-commit-config.yaml and a .clang-format, so formatting and hook conventions are enforced, but that says nothing about interface churn.

CI is documented as covering Linux, macOS and Windows: the README shows badges for a Linux/Mac workflow and a win64 workflow, and states the CI pipeline runs with gcc, clang and MSVC. The primary development platform is stated as Linux, with experimental support for macOS, Android and Windows. That ranking matters if you build on Windows or Android: you are on the experimental path, and the README's Windows instructions lean on vcpkg.

Editorial conclusion

Use g2o when you are writing C++ and your problem is already a graph of vertices and edges over Eigen types, with SLAM or bundle adjustment as the usual cases. Do not pick it if you need a Python API today (the pymem branch is described as experimental, and the bindings live in a separate g2o-python project) or if you want a permissive licence across the whole build, since g2o_viewer, g2o_incremental and slam2d_g2o are GPL3+ and CHOLMOD as distributed by Ubuntu or Debian includes GPL features. Before you commit, verify two things yourself: whether the solver backend you intend to use is affected by the CHOLMOD licensing note, and whether the examples in doc/g2o.pdf match the API of the tag you check out, since the README does not promise API stability between releases.

Frequently asked questions

Official sources

1. Issues
2. RainerKuemmerle/g2o on GitHub
3. README
4. Releases