What is the rationale behind the thread spawing in PoseEstimation?

[geoeo]

I have a few question regarding the threading in PoseEstimation class.

Looking at the code in pose_estimation.cpp, it seems 1) Threads are spawned a lot regarding the GeoReferncer. Why was this decision made? Is it that crucial to be "unblocked" in the process() function?

2) Furthermore, why does PoseEstimation (as the only stage class?) do its IO in a separate thread? I think Orthtorectifiction does this in the same thread as process() for example

Thanks for any insights. Best

[laxnpander]

Hey,

this is code I wrote during my master thesis 5 years ago. I do think there is a lot of sketchy stuff in there I simply have no time to fix or rewrite. But anyway, to your questions: 1) Not sure how long the georeferencing takes, but I guess I didn't want to block the thread, therefore the spawning and detaching. Pose estimation is the most crucial part of the whole pipeline (good pose = good map), which is why there is a lot of optimisation I thought was necessary. 2) I guess same as 1), pose estimation is crucial. The other stages fall into place after that. I didn't really care if the map was slightly delayed. But if pose estimation is blocked for a few milliseconds, the visual SLAM has it tougher.

Cheers

[geoeo]

Thanks for your quick reply.

The reason im asking is that Im seeing the map generation being non-deterministic (at least with open v-slam) with no dropped frames, as far as logging is concerned. So im wondering if its the locking behavior in the pose estimation or if there are some random sampling procedures (e.g. RANSAC) going on in the vslam library

[laxnpander]

@geoeo Jeah, pretty sure the latter is the case. OpenVSLAM has at least 3-4 threads running simultaneously. There is no way two executions are identical.

[geoeo]

Thanks for the insight!. Will close this