tum-vision / LDSO

DSO with SIM(3) pose graph optimization and loop closure
GNU General Public License v3.0
670 stars 236 forks source link

Does global pose graph help improve the estimation accuracy if no loop is detected? #62

Closed duyanwei closed 3 years ago

duyanwei commented 3 years ago

Thank you for releasing the code. Great work!

I've read in the code that a global optimization is called at the end of the running https://github.com/tum-vision/LDSO/blob/9b0c48cfd3b3ee95a8dbf1aef2371ed4fca6f81a/src/frontend/FullSystem.cc#L400, does it mean even if no loop is detected, a global optimization is still triggered? Does it help improve the final evaluation result compared to DSO?

On the other hand, two files are saved when running kitti data, which one is used for evaluation, is it the optimized one? https://github.com/tum-vision/LDSO/blob/9b0c48cfd3b3ee95a8dbf1aef2371ed4fca6f81a/examples/run_dso_kitti.cc#L410

Thanks.

mgladkova commented 3 years ago

Hi @duyanwei,

You are right regarding the global pose graph optimization (PGO) in the end of each run. In cases when no loop is detected, the estimated trajectory will not change significantly after PGO since only the odometry-based constraints are inserted into the graph. Please note that LDSO integrates features into DSO framework, so even for sequences without loops the estimated camera trajectory will differ between two systems.

I presume that reported numbers in the paper are based on the optimized trajectory (after loop closure and PGO), which corresponds to the call in line 409.

duyanwei commented 3 years ago

Thanks for the explanation.

NikolausDemmel commented 3 years ago

PS: I believe Mariia has it right. I also don't think it makes a big difference. It may just be a practical coding related reason that PGO is always run at least once. Maybe some output variables are only set after PGO, so if it is never run, they would not be set at all. Also, IIRC, if PGO is running and we get more loop closures, it doesn't stop PGO, but just stores the LC constraints for the next time PGO is run. I'm not sure it would by itself directly rerun PGO once the previous run is finished. So to ensure in the end the last PGO uses ALL constraints the were detected, it reruns it to be sure. Of course some bookkeeping could also solve this, to only rerun it if new constraints were added since the last run.