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

GN vs Ceres Optimization #12

Closed
louis-wiesmann opened this issue Mar 11, 2022 · 4 comments
Closed

GN vs Ceres Optimization #12

louis-wiesmann opened this issue Mar 11, 2022 · 4 comments

Comments

@louis-wiesmann
Copy link

Hello, thanks for this great work!
I saw that the default optimization (in default_config.yaml) is using the Gauss Newton optimization and for the robust configs Ceres is used. The Jacobians for the rotation look for me like an approximation. Is this true, and if yes do you think the approximation error is relevant?

Is Ceres mainly used for the robust loss functions or also to get better Jacobians by the autodiff?

Thanks and best regards,
Louis

@pdell-kitware
Copy link
Collaborator

Hello Louis,

Thanks for the feedback !

For now GN does indeed perform some approximation on the jacobian, plus defines a rigid outlier rejection (based on a distance). It does not really affects precision metrics, but seriously impacts robustness. On driving datasets, this has no effect
(For KITTI, KITTI-CARLA, KITTI-360, our published results used GN, but we obtained similar results with Ceres), but on datasets such as NCLT it does.

There is however (currently) a significant gain in runtime with the GN implementation, with respect to the mono threaded Ceres implementation (with multiple threads the difference is less significant).

Note: for branch dev currently I would recommand using Ceres, as default,
because we introduced a lot of changes, I need to fix the GN implementation which now handles poorly the initialization.

@louis-wiesmann
Copy link
Author

Thanks a lot for the answer! What do you mean with robustness? When you have outliers, or under big rotation changes?

@pdell-kitware
Copy link
Collaborator

Both.

Basically ICP-based registrations (like the one in CT-ICP or LOAM) will fail in a number of cases.
They typically require precise initialization to have correct initial neighbor associations, and slide towards the optimal pose.

Furthermore you need geometrically informative neighbor associations which will help you converge towards this optimal.
You can think of geometric featureless or ambiguous environments such as tunnels, or parking lots, which are intrinsically complicated for Lidar odometries.

The robustness (which I don't really know yet how to properly quantify) of the system basically describes how poor of an initialization you can tolerate to have a precise SLAM, and how you handle these complicated environments.

@louis-wiesmann
Copy link
Author

Okay, thanks a lot. This was very helpful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants