offline viewer does not optimize

[changh95]

Describe the bug

I have a large-scale map created using glim_rosbag in /tmp/dump. There were some drift in Z-direction, which the loop could not be closed automatically during reconstruction stage. I tried using glim_offline_viewer to explicitly make a loop constraint.

But the app only says 'optimizing...' but does not actually do any optimization. I can still click and drag on the viewer, so surely there isn't any background processing going on.

If the optimization could not be performed, there should be at least some warning/error messages in the terminal.

One reason behind this bug could be that my factor graph was broken in the first place, due to errors like #65 . I had hidden errors (i.e. errors which are only shown in raw terminal, but not in iridescence viewer), like Warning: Levenberg-Marquardt giving up because cannot decrease error with maximum lambda which I presume it's from GTSAM.

To Reproduce Steps to reproduce the behavior:

1. Use glim_offline_viewer to open offline viewer, and then load a map.
2. Find two factors where a loop could be closed.
3. Following the instructions in the tutorial, assign 'loop begin' and 'loop close', align two point clouds, and then create factor.
4. 'optimizing...' message pops up the viewer terminal.
5. But no optimization actually takes place.

Expected behavior

• Optimization should be performed.
• If optimization is mathematically not possible, then there should be error messages visible in the viewer.

Screenshots

Environment (please complete the following information):

• CPU/GPU: Core i9-14900K, RTX 3090
• OS: Ubuntu 20.04
• ROS: ROS2 Humble docker by koide3.
• CUDA: 12.2
• Build with CUDA: ON

[koide3]

Thanks for reporting the issue. I thinks the problem stems from the corrupted linear system as you pointed out. I'm thinking to implement a mechanism to prevent the error in https://github.com/koide3/glim/issues/65 and a tool to fix corrupted graphs in offline_viewer, and I would be glad if you could provide example bag and/or dump files to reproduce the issue.

[changh95]

@koide3 Sure, I'll send you a link to google drive for the dump file via email.

[CharlieV5]

Thanks for reporting the issue. I thinks the problem stems from the corrupted linear system as you pointed out. I'm thinking to implement a mechanism to prevent the error in #65 and a tool to fix corrupted graphs in offline_viewer, and I would be glad if you could provide example bag and/or dump files to reproduce the issue.

Hi! Same here when I used glim_offline_viewer to try optimization but nothing happened after adding loop and hitting the optimize button, without any warnings. I use Ubuntu 20.04 and no GPU.

[koide3]

@CharlieV5 If possible, could you share your dump file? I'm considering to implement a tool to fix this error in offline_viewer.

[changh95]

@koide3 I wish I could send you my dump file - but since you made the fix on indeterminant linear system error (https://github.com/koide3/glim/pull/92), I am no longer able to reproduce the same error :smiling_face_with_tear: (I guess my issue is solved?) The bug on viewer only appeared when I loaded a dump file with broken graph (which was made with indeterminant linear system error). I am thinking that the GTSAM in offline viewer could not solve a broken graph, hence no optimization could be taken.

[koide3]

Yes, the graph corruption issue is fixed by #92, and newly created maps should not cause this issue (hopefully). But, it would be good if we could fix an already created dump data on the offline viewer. I think I can revert the program and create a corrupted dump file from the bag files you previously provided to test the new feature.

[CharlieV5]

@CharlieV5 If possible, could you share your dump file? I'm considering to implement a tool to fix this error in offline_viewer.

I have send the dump file to your e-mail.

[koide3]

@CharlieV5 Thanks a lot for providing the dump data. It seems like the dump data is corrupted and many factors are lost. I implemented automatic detection and recovery of graph corruptions, and confirmed that the dump data can be successfully loaded with https://github.com/koide3/glim/pull/100.

Could you check if it works on your side?

[CharlieV5]

@CharlieV5 Thanks a lot for providing the dump data. It seems like the dump data is corrupted and many factors are lost. I implemented automatic detection and recovery of graph corruptions, and confirmed that the dump data can be successfully loaded with #100.

Could you check if it works on your side?

Hi! I have git-pull the latest version of code and it works fine now! Thank you! And I find that when I choose No on this dialog at the very beginning it will do no optimization at all. Only when I choose Yes it can do optimization as I wish. I think that's why it does no optimization as I mentioned above.