search

nikolaradulov / SLAMFuse

SLAM performance evaluation framework
https://apt.cs.manchester.ac.uk/projects/PAMELA/
Other
8 stars 1 forks source link

Pangolin: path to libpangolin.so #1

Closed yuhaozhang7 closed 1 year ago

yuhaozhang7 commented 1 year ago

When I build pangolin inside the container, it records an absolute path to libpangolin.so in container to some file automatically, so if I am trying to run ‘make slambench APPS=lsdslam’ on host machine, by mounting the pangolin in container OR copy the pangolin in container into deps folder in host machine, it will try to find the ‘libpangolin.so’ by this absolute path “/library/pangolin/lib/libpangolin.so” which doesn’t exist on host machine.

In such case, the pangolin (pangolinA) needed by slambench container and the pangolin (pangolinB) build in algorithm container will have different path to libpangolin.so, I am not sure whether it gonna cause runtime error if we are trying to run slambench build by pangolinA with lsd-slam algorithm build by pangolinB.

Possible solution: Use container to populate the volume which contains all dependencies of algorithm that is not the dependencies of slambench, and the source code of slam algorithm. Then mount the dependencies and source code, and build the algorithm inside the slambench container. If we want use new algorithms, just discard the dependencies and source code of previous algorithm. For example, dependencies of lsd-slam are eigen3, suitesparse, g2o, opencv, pangolin. Since opencv and pangolin are also the dependencies of slambench, the volume of lsd-slam will have eigen3, suitesparse, g2o and its source code.

Other possible advantages:

  1. If libraries are needed by slambench itself, then we don't spend time to build it again inside algorithm container.
  2. To compile the algorithm, we can simply mount the deps and source code to particular location and then run 'make slambench APPS=***', rather than figuring out how to create a library of algorithm that can be used by slambench, without build a slambench.
yuhaozhang7 commented 1 year ago

pangolin

nikolaradulov commented 1 year ago

This process will be different for adding new algorithms going forward, as they will be built in separate containers using. They can't be made using 'make slambench APPS=***' as those are developer provided instruction. That being said the proposed solution will probably help us develop the plug-able volumes faster for the existing algorithms, potentially giving us less headaches. However I can think of the issues we might hit going forward:

  1. If the volumes for the new algorithms contain all the needed dependencies, but the volumes for the existing algorithms contain only the unique dependencies we need to create different cases for loading. This might lead to inconsistency in the user experience

  2. Figuring out how to create a library for slambench will be needed for future work so in reality we are not skipping steps, just delaying.

  3. Would it be possible to have a conflict of a static library version dependency between slambench and an algorithm. This probably shouldn't happen with the algorithms that are already in the application, but i believe it gives a good example as to why this shouldn't we the way to go for adding new algorithms.

nikolaradulov commented 1 year ago

Issue with the solution:

Eigen3 is needed by SLAMBench, meaning that the solution would hit dependency issues between ORBSLAM2 and ORBSLAM3. Having all the dependencies packed in the volume would solve it. For Static libraries the algorithm should be built in a separate container than the main SLAMBench tool, as in https://github.com/nikolaradulov/slambench/wiki/SLAMBench-and-containers