Enforcing KF Upper Limit and Server stops processing (devel code)

[manthan99]

Hi

I am facing the following errors while running the devel branch code

When I use more than one agent, which have a lot similar trajectory as seen in the attached picture, the server is unable to close the loop after some loop closures and stops to process (the htop command shows very low load and no thread is above 20-30%) with the last print screen message being -

Map: GBA finished - continue
!!! LOOP FOUND !!!
--- Lock threads
--- transform KFs/MPs
--- update matched MPs
--- optimize Ess grapgh
--- Launch GBA thread
LoopFinder: Wait for GBA to finish
-> Starting Global Bundle Adjustment
--> Optimizing Map 0 -- Contains Agents 0;1;
----> Loop KF: 235|1
----- Add KFs
----- Add MPs
----- Optimize
------> max Iterations: 20
------> vertices|edges: 1159|307065
------> Optimization Time: 162.947 [s]
----- Recover KFs
----- Recover MPs
----- done.

The whole terminal output has been attached in the attached txt file. When this occurs, the clients start having the print screen message as follows-

+++++ Enforcing KF upper limit +++++1.59585e+09 +++++ Enforcing KF upper limit +++++1.59585e+09

This problem is not faced while running the same bag files in the master branch (though the problem is that each of the loop closure is followed by the GBA instead of interruption which takes a lot of time)

Moreover the Essential Graph also doesn't seem to work as mentioned in #25 which is causing a lot of time for optimization(going up to several minutes(10+) for high KFs)

Rviz - visualization of the 2 trajectories

Note - There is a very high ATE since the final GBA are not performed and the server stops the processing

Full Server print screen txt- server_print.txt

[patriksc]

Dear Manthan

1) The client message comes from the fact that the server is not responding, so it cannot send Keyframes to the server anymore, and needs to erase them without having an acknowledgement from the server that these KFs arrived there

2) This problem must come from a deadlock in the code. I've checked the code, and I assume the problem could be that the "MapUpdate" lock is locked twice during Loop Closure (and also Map Merging), because with the changes in the devel branch, the Loop Closure thread is now waiting for the GAB thread to finish. However, the problem does not occur during our tests and with our datasets, so we cannot reproduce it.

I suggest to try commenting out the following lines:

LoopFinder: Line 886: while(!mpMap->LockMapUpdate()){usleep(params::timings::miLockSleep);} Line 1019: mpMap->UnLockMapUpdate();

And also in MapMerger 632: while(!pFusedMap->LockMapUpdate()){usleep(params::timings::miLockSleep);} 765: pFusedMap->UnLockMapUpdate();

Please let me know whether this solves the problem on your dataset. Otherwise, please try to find out where the deadlock occurs, so that we can investigate the problem further.

Kind regards Patrik

[manthan99]

Hii

Thank you very much for your reply. I tried on multiple sequences and the problem seems to have solved. Commenting out the lines solves the issue.

[flyover-26]

@manthan99 hi! Have you tested this system using camera? I find it easy to lost tracking if I move camera a little bit faster. Looking forward to your reply!