Closed mikexyl closed 2 years ago
Hi. Since you write the problem occurs when compiled in debug, I suppose what happens is that the processes (i.e. the optimization) will be significantly slower and therefore unable to process the incoming frames in real-time and just fill up the queues until they are full and block. In order to avoid of that problem, you could back-play the data at a reduced rate such that system is able to catch up.
Regarding the LoopDetection::addKeyFrame, can you pinpoint where the blocking is happening?
I compile it in release, I logged to see it blocking. In my work, I don't need it to optimize and I don't have or need gps signal, so I simply removed optimization threads and all code after loop detection. made it work this way. By a second thought, I guess it blocked maybe because I didn't give it gps measurement. If this is the case, I think it's better to add some checks and logs
Did you still run into the blocking issue when you compiled in release (without removing the optimization)? The missing GPS measurements should not cause such an issue as they get inserted if available, otherwise the code proceeds without (you can also disable the GPS by setting the parameter gpsactive"agen-id" to false).
Closed - inactive
Hello, I am trying to adapt this repo in my work, but it feels like it's not really polished. In debug, I found the ThreadSafeQueue's methods like PushIfBlocking block very offen, feels like some lock issue. I need to changed them to nonblock one to make it work. And also LoopDetection::addKeyFrame blocks, won't return. Is this somehow I use this repo in a wrong way, or you hanve some futher update for it not yet pushed?