search

JakobEngel / dso

Direct Sparse Odometry
GNU General Public License v3.0
2.26k stars 903 forks source link

Bundle Adjustment in DSO-SLAM #154

Open AlexandrGraschenkov opened 6 years ago

AlexandrGraschenkov commented 6 years ago

In previous work (LSD-SLAM) G2O framework is used to perform BA. ORB-SLAM also uses this framework for optimization. Why in DSO-SLAM G2O framework is ignored and BA performed manually?

NikolausDemmel commented 5 years ago

I don't know for certain, but I believe the main reason to not use an NLSQ optimization framework like ceres or g2o was to squeeze maximum performance out of the implementation and achieve realtime performance.

It wouldn't surprise me if a naive implementation using something like g2o would be easily 10x slower. The manual implementation maxes use of the know structure of the problem, and allows fine control over when which Jacobians are re-evaluated, how the marginalization terms are computed, etc...

NikolausDemmel commented 5 years ago

PS: That being said, it would be interesting to see how much one could squeeze out of an implementation with ceres or g2o.

AlexandrGraschenkov commented 5 years ago

I thought about performance too. For g2o you need allocate\deallocate new memory, create lot of edges. It's take a time. Unfortunately no one can understand the optimization code in DSO now =) With g2o abstraction it much easier. Thank you @NikolausDemmel for answer!

Maybe anybody know how to understand how BA is performed? Where to start?

huziqi commented 2 years ago

PS: That being said, it would be interesting to see how much one could squeeze out of an implementation with ceres or g2o.

Thanks for your previous answer! I tried modifing DSO by adding ceres at backend optimization. The original manual implementation of optimization is unchanged. However, I found that ceres can't run properly which abort with 'double free or corruption'. When I disabled SSE in CMakeLists, the ceres may work fine, but the original backend optimization was down instead. Does it beacuse SSE conflicts with ceres? If so, does it mean DSO is not compatible with ceres? If not, may I get some suggestion on how to modify DSO in another way? Thank you very much!

NikolausDemmel commented 2 years ago

In principle, I don't see a reason you shouldn't be able to use Ceres with DSO.

It could be some kind of violation of the one definition rule due to different library versions or compile flags. Eigen is often a culprit. Make sure you compile both DSO and Ceres with the exact same Eigen version and compile flags (like -march=native).

What do you mean by "When I disabled SSE in CMakeLists"? It seems to me that the define ENABLE_SSE is set in cmake, but it appears unused. Also, SSE_FLAGS in cmake is used but never set.