Rosbag support for TUM datasets

lplana commented 4 years ago

This pull request is not ready to be merged.

Pending tasks:

[x] TUM / TUM-ROSBAG merge -- make TUMROSBAGReader of type TUMReader and override GenerateSLAMFile -- pass 'use_rosbag' parameter
[ ] update CMakeLists so that ROS-related targets are added only if ROS is found -- make sure that non-rosbag datasets can be processed without ROS setup

lplana commented 4 years ago

I think that I understand the issues with intrinsic and distortion parameters, so:

restructured the header file to show the parameters, including default values,
added comments pointing to the source of the parameter values used,
added comments to explain relationships between some parameters and image properties.

mihaibujanca commented 4 years ago

Nice work. A few suggestions (i can try looking into how some of these might be done):

We may be able to pass a param rather than duplicate the code for datasets which can be built with either ROS bags or the old day. i.e make ./datasets/TUM-ROSBAG/freiburg2/rgbd_dataset_freiburg2_pioneer_360.slam might be doable with just make ./datasets/TUM/freiburg2/rgbd_dataset_freiburg2_pioneer_360.slam -use_ros or something like this. Similarly, rather than having a TUM-ROSBAG target in the Makefile, it may simply be easier to have a condition on that parameter and call dataset generator with tum or tum-rosbag appropriately
./include/TUM-ROSBAG.h may not be necessary and the code could simply be in TUM.h. I'm not yet sure about this and whether it would make the code dirty. In any case TUMROSBAGReader should be of type TUMReader and we can override GenerateSLAMFile, as the rest of the methods / parameters are the same.
I'll have a go at making sure that in CMakeLists, the TUM-ROS target is only added if ROS is found

lplana commented 4 years ago

All good suggestions.

Just note that the functions are not quite the same. TUM datasets do not have grey images, so rgb images are used in place of grey ones. These requires different processing between the tgz dataset (which already provides separate rgb images) and the rosbag dataset. The rosbag has a combined rgb/grey processing function.

I'll get on with the EuRoC MAV datasets. I'll do it in a similar way to what I did and then apply any changes needed following your suggestions.

mihaibujanca commented 4 years ago

Yes, but those functions are separate from the class itself - so the cpp file is enough and the class can be derived from TUMReader

mihaibujanca commented 4 years ago

Also need to add documentation regarding which ROS packages are relevant to this PR

mihaibujanca commented 4 years ago

In order to get make ./datasets/TUM-ROSBAG/freiburg1/rgbd_dataset_freiburg1_360.slam to run, I needed to first go to my ROS workspace an use source setup.bash.

I believe that the main thing this does (but there might be others) is add the correct paths to PATH and LD_LIBRARY_PATH. This may be appropriate to ask of users if needed but will need to be documented.

Thus it seems like link_directories(TUM-ROSBAG PRIVATE ${ROS_LINK_DIRS}) is not enough for linking. Not least, this seems to also affect dataset-generator, as building any other dataset without source setup.bash results in an error caused by libclass_loader.so (which is part of ROS).

Please see below:

(base) ¯\_(ツ)_/¯ ~/Projects/slambench2:make ./datasets/TUM/freiburg1/rgbd_dataset_freiburg1_xyz.slam
mkdir -p datasets/TUM/freiburg1
cd datasets/TUM/freiburg1  &&  wget "http://vision.in.tum.de/rgbd/dataset/freiburg1/rgbd_dataset_freiburg1_xyz.tgz"
URL transformed to HTTPS due to an HSTS policy
--2020-04-16 12:36:49--  https://vision.in.tum.de/rgbd/dataset/freiburg1/rgbd_dataset_freiburg1_xyz.tgz
Resolving vision.in.tum.de (vision.in.tum.de)... 131.159.19.110, 2a09:80c0:18::1110
Connecting to vision.in.tum.de (vision.in.tum.de)|131.159.19.110|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 448204271 (427M) [application/x-gzip]
Saving to: ‘rgbd_dataset_freiburg1_xyz.tgz’

rgbd_dataset_freiburg1_xyz.tgz     100%[================================================================>] 427.44M  9.31MB/s    in 43s     

2020-04-16 12:37:33 (10.0 MB/s) - ‘rgbd_dataset_freiburg1_xyz.tgz’ saved [448204271/448204271]

mkdir datasets/TUM/freiburg1/rgbd_dataset_freiburg1_xyz.dir
tar xzf datasets/TUM/freiburg1/rgbd_dataset_freiburg1_xyz.tgz -C datasets/TUM/freiburg1/rgbd_dataset_freiburg1_xyz.dir
if [ ! -e ./build/bin/dataset-generator ] ; then make slambench ; fi
./build/bin/dataset-generator -d tum -i datasets/TUM/freiburg1/rgbd_dataset_freiburg1_xyz.dir/* -o datasets/TUM/freiburg1/rgbd_dataset_freiburg1_xyz.slam -grey true -rgb true -gt true -depth true -acc true
./build/bin/dataset-generator: error while loading shared libraries: libclass_loader.so: cannot open shared object file: No such file or directory
Makefile:381: recipe for target 'datasets/TUM/freiburg1/rgbd_dataset_freiburg1_xyz.slam' failed
make: *** [datasets/TUM/freiburg1/rgbd_dataset_freiburg1_xyz.slam] Error 127

lplana commented 4 years ago

I cannot reproduce your problem. I don't source any ROS setup files and the compilation works for every dataset type that I tried.

Maybe I have a cmake find configuration that finds the ROS packages without the setup.

I'll look into it.

lplana commented 4 years ago

Can you suggest a proper way to document the required ROS packages? I don't really know.

The 4 required ROS packages are listed in CMakeLists.txt:

set(ROS_LIBS cpp_common roscpp_serialization rostime rosbag_storage)

mihaibujanca commented 4 years ago

Can you suggest a proper way to document the required ROS packages? I don't really know.

The 4 required ROS packages are listed in CMakeLists.txt:
set(ROS_LIBS cpp_common roscpp_serialization rostime rosbag_storage)

Perhaps @bbodin can advise too, but my suggestion would be to put it in the README for datasets. I will also make a tutorial at some point and mention this. If users open any issues and it's confusing we can add it to the main README later on.

mihaibujanca commented 4 years ago

I cannot reproduce your problem. I don't source any ROS setup files and the compilation works for every dataset type that I tried.

Maybe I have a cmake find configuration that finds the ROS packages without the setup.

I'll look into it.

What is the output of echo $LD_LIBRARY_PATH in your terminal?

lplana commented 4 years ago

What is the output of echo $LD_LIBRARY_PATH in your terminal?

plana@spinn-rain:~/devel/slambench2$ echo $LD_LIBRARY_PATH

plana@spinn-rain:~/devel/slambench2$

mihaibujanca commented 4 years ago

Oh now I'm really confused

lplana commented 4 years ago

I should have alerted you to the fact that I tailored CMakeLists.txt to the ROS setup in my machine. This needs to be sorted in the right way (which I don't know):

set(ROS_INCLUDE_DIRS /opt/ros/kinetic/include)
set(ROS_LIBS cpp_common roscpp_serialization rostime rosbag_storage)
set(ROS_LINK_DIRS /opt/ros/kinetic/lib)
link_directories(TUM-ROSBAG PRIVATE ${ROS_LINK_DIRS})

lplana commented 4 years ago

In any case TUMROSBAGReader should be of type TUMReader and we can override GenerateSLAMFile`, as the rest of the methods / parameters are the same.

I've had a go at deriving TUMROSBAGReader from TUMReader.

`./include/TUM-ROSBAG.h` may not be necessary and the code could simply be in `TUM.h`. I'm not yet sure about this and whether it would make the code dirty.

Have a look at the latest ./include/TUM-ROSBAG.h. Can be easily merged into ./include/TUM.h. Not sure about the cleanliness though, you're the expert.

mihaibujanca commented 4 years ago

I should have alerted you to the fact that I tailored CMakeLists.txt to the ROS setup in my machine. This needs to be sorted in the right way (which I don't know):
set(ROS_INCLUDE_DIRS /opt/ros/kinetic/include)
set(ROS_LIBS cpp_common roscpp_serialization rostime rosbag_storage)
set(ROS_LINK_DIRS /opt/ros/kinetic/lib)
link_directories(TUM-ROSBAG PRIVATE ${ROS_LINK_DIRS})

Yep this was after I already modified those paths.

Perhaps something like this might help with finding ROS dependencies: Similar to https://github.com/rpng/open_vins/blob/master/ov_core/CMakeLists.txt

find_package(catkin QUIET COMPONENTS roscpp rosbag) # any other components
include_directories(${catkin_INCLUDE_DIRS})
target_link_libraries(target PUBLIC|PRIVATE ${catkin_LIBRARIES})

lplana commented 4 years ago

Perhaps something like this might help with finding ROS dependencies: Similar to https://github.com/rpng/open_vins/blob/master/ov_core/CMakeLists.txt
find_package(catkin QUIET COMPONENTS roscpp rosbag) # any other components
include_directories(${catkin_INCLUDE_DIRS})
target_link_libraries(target PUBLIC|PRIVATE ${catkin_LIBRARIES})

I'm working on it. A caveat is that it is possible to install the ROS libraries without the catkin build system. This would not spot those libraries. On the other hand, it seems unlikely that a user would want rosbag support without having ROS installed, with catkin in place.

lplana commented 4 years ago

Perhaps something like this might help with finding ROS dependencies: Similar to https://github.com/rpng/open_vins/blob/master/ov_core/CMakeLists.txt
find_package(catkin QUIET COMPONENTS roscpp rosbag) # any other components
include_directories(${catkin_INCLUDE_DIRS})
target_link_libraries(target PUBLIC|PRIVATE ${catkin_LIBRARIES})

When cmake finds the catkin environment, the recipe for target 'lib/libTUM-ROSBAG.so' fails with the following message:

/usr/bin/ld: ../../../lib/libslambench-io.a(DepthSensor.cpp.o): relocation R_X86_64_32 against `_ZN9slambench2io11DepthSensor10kDepthTypeB5cxx11E' can not be used when making a shared object; recompile with -fPIC ../../../lib/libslambench-io.a: error adding symbols: Bad value

It expects relocatable/position-independent code, when the catkin environment is on. Not sure how to progress with this. Will carry on digging. Any help much appreciated.

lplana commented 4 years ago

I think that the issue building lib/libTUM-ROSBAG.so is now sorted. The latest CMakeLists.txt should allow cmake to compile correctly with or without rosbag support. To get rosbag support the user has to setup the ROS enviroment (usually sourcing path-to-ros-top-level/setup.bash) before building SLAMBench.

mihaibujanca commented 4 years ago

I'm getting the following error: fatal error: tf/tf.h: No such file or directory

ros-version-tf is thus also a dependency. I don't think anything needs to be modified in CMakeLists.txt, since after installing the package, everything ran smoothly.

mihaibujanca commented 4 years ago

When trying to build make ./datasets/TUM/freiburg2/rgbd_dataset_freiburg2_pioneer_slam3.slam use_rosbag, it is first checked whether or not ./datasets/TUM/freiburg2/rgbd_dataset_freiburg2_pioneer_slam3.slam exists. If it does, the command returns <dataset> is up to date.

When use_rosbag is passed, we should be checking whether or not the dataset exists in the TUM-ROS directory

mihaibujanca commented 4 years ago

One of my worries regarding users having to execute setup.bash prior to using TUM-ROS is that the following scenario is not only possible, but likely, when wanting to build multiple sequences at the same time:

Execute source setup.bash to load the necessary paths etc
Successfully build slambench as well as the ROS-TUM library
Builds a sequence
Open a new terminal and attempt to build a sequence
This will produce an error complaining about either libraries or headers not being found

lplana commented 4 years ago

When use_rosbag is passed, we should be checking whether or not the dataset exists in the TUM-ROS directory

We are. What may have happened is that there is no TUM-ROS directory any longer. I thought that the idea was to process the dataset in the same TUM directory. I could go back to having separate directories TUM and TUM-ROS.

lplana commented 4 years ago

ros-version-tf is thus also a dependency. I don't think anything needs to be modified in CMakeLists.txt, since after installing the package, everything ran smoothly.

I missed it in the dependencies. I'm looking into upgrading to tf2, which is a more recent implementation. I'll add it to the list of dependencies.

lplana commented 4 years ago

One of my worries regarding users having to execute setup.bash prior to using TUM-ROS is that the following scenario is not only possible, but likely, when wanting to build multiple sequences at the same time:
* Execute `source setup.bash` to load the necessary paths etc

* Successfully build slambench as well as the ROS-TUM library

* Builds a sequence

* Open a new terminal and attempt to build a sequence

* This will produce an error complaining about either libraries or headers not being found

This one I don't really know what to do about, without bringing catkin in, which we don't want to do. ROS can be installed anywhere, or not at all. I'll carry on looking for a way forward.

mihaibujanca commented 4 years ago

When use_rosbag is passed, we should be checking whether or not the dataset exists in the TUM-ROS directory

We are. What may have happened is that there is no TUM-ROS directory any longer. I thought that the idea was to process the dataset in the same TUM directory. I could go back to having separate directories TUM and TUM-ROS.

My bad, I just got confused. You're right, users won't want to have both rosbags and the .zip build.

mihaibujanca commented 4 years ago

One of my worries regarding users having to execute setup.bash prior to using TUM-ROS is that the following scenario is not only possible, but likely, when wanting to build multiple sequences at the same time:
* Execute `source setup.bash` to load the necessary paths etc

* Successfully build slambench as well as the ROS-TUM library

* Builds a sequence

* Open a new terminal and attempt to build a sequence

* This will produce an error complaining about either libraries or headers not being found
This one I don't really know what to do about, without bringing catkin in, which we don't want to do. ROS can be installed anywhere, or not at all. I'll carry on looking for a way forward.

I just tried the following, I think it significantly narrows down the issue. Basically I think all that is needed is to set up the PATH and the LD_LIBRARY_PATH correctly.

open a new terminal, source setup.bash
copy the output of echo $PATH and echo $LD_LIBRARY_PATH
open a different terminal, set the PATH and LD_LIBRARY_PATH to the ones copied
building TUM-ROS, as well as a dataset using the library should work now

mihaibujanca commented 4 years ago

For the case when TUM-ROS is not built but a user tries to run make ./datasets/TUM/freiburg2/rgbd_dataset_freiburg2_pioneer_slam3.slam use_rosbag The error that comes up is "Data format not found".

Instead, we should check if the ROS version of the dataset was built and fail with "ROS not enabled for this dataset. Please rebuild with ROS dependencies" or something along those lines

lplana commented 4 years ago

I just tried the following, I think it significantly narrows down the issue. Basically I think all that is needed is to set up the PATH and the LD_LIBRARY_PATH correctly.

This is correct. This is how I got started. The problem is to determine how to set the PATH and the LD_LIBRARY_PATH variables properly. We cannot assume that every system has the same settings. Even less so if it is a Windows or MAC OS system.

I'm looking into creating a FindROS.cmake file that will provide cmake with hints of places where ROS modules can be found. This might be our best option.

lplana commented 4 years ago

For the case when TUM-ROS is not built but a user tries to run make ./datasets/TUM/freiburg2/rgbd_dataset_freiburg2_pioneer_slam3.slam use_rosbag The error that comes up is "Data format not found".

Instead, we should check if the ROS version of the dataset was built and fail with "ROS not enabled for this dataset. Please rebuild with ROS dependencies" or something along those lines

This is the existing error message shown when the requested data format is not found. I didn't want to mess with it. I'll change it so that it provides more information, as you suggest.

lplana commented 4 years ago

One of my worries regarding users having to execute setup.bash prior to using TUM-ROS is that the following scenario is not only possible, but likely, when wanting to build multiple sequences at the same time:
* Execute `source setup.bash` to load the necessary paths etc

* Successfully build slambench as well as the ROS-TUM library

* Builds a sequence

* Open a new terminal and attempt to build a sequence

* This will produce an error complaining about either libraries or headers not being found

I can't reproduce this problem. Once I build SLAMBench with ROS support, I don't have to setup the ROS environment (setup.bash) for it to process tum-rosbag datasets. I've tried in different terminals and checking that PATH and LD_LIBRARY_PATH are not setup with any ROS-related directories. In fact, LD_LIBRARY_PATH is always empty.

I just checked and the dataset-generator executable stores full paths to the shared libraries, so it should not depend on LD_LIBRARY_PATH to find them.

lplana commented 4 years ago

One of my worries regarding users having to execute setup.bash prior to using TUM-ROS is that the following scenario is not only possible, but likely, when wanting to build multiple sequences at the same time:

I modified CMakeLists.txt so that it uses ROS environment, if it is setup, to find ROS packages. If the environment is not setup, then it looks for packages in the standard ROS installation location "/opt/ros". This should work either if the user has sourced setup.bash or, if ROS was installed in the standard location, without the need to source setup.bash.

mihaibujanca commented 4 years ago

One of my worries regarding users having to execute setup.bash prior to using TUM-ROS is that the following scenario is not only possible, but likely, when wanting to build multiple sequences at the same time:
* Execute `source setup.bash` to load the necessary paths etc

* Successfully build slambench as well as the ROS-TUM library

* Builds a sequence

* Open a new terminal and attempt to build a sequence

* This will produce an error complaining about either libraries or headers not being found
I can't reproduce this problem. Once I build SLAMBench with ROS support, I don't have to setup the ROS environment (setup.bash) for it to process tum-rosbag datasets. I've tried in different terminals and checking that PATH and LD_LIBRARY_PATH are not setup with any ROS-related directories. In fact, LD_LIBRARY_PATH is always empty.

I just checked and the dataset-generator executable stores full paths to the shared libraries, so it should not depend on LD_LIBRARY_PATH to find them.

If I don't execute setup.bash first, I'm getting the following error:

./build/bin/dataset-generator: error while loading shared libraries: libclass_loader.so: cannot open shared object file: No such file or directory

In my case, libclass_loader.so is stored in /opt/ros/melodic/lib/libclass_loader.so.

I just checked and the dataset-generator executable stores full paths to the shared libraries, so it should not depend on LD_LIBRARY_PATH to find them.

Please see ldd below

(base) ¯\_(ツ)_/¯ ~/Projects/slambench2:ldd build/bin/dataset-generator 
    linux-vdso.so.1 (0x00007fffeff6b000)
    libyaml-cpp.so.0.5 => /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5 (0x00007f16f352f000)
    libOpenCL.so.1 => /usr/local/cuda-10.1/lib64/libOpenCL.so.1 (0x00007f16f3328000)
    libcudart.so.10.1 => /usr/local/cuda-10.1/lib64/libcudart.so.10.1 (0x00007f16f30ac000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f16f2e8d000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f16f2c89000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f16f2a81000)
    libopencv_imgcodecs.so.3.4 => /home/mihai/Projects/slambench2/deps/opencv/lib/libopencv_imgcodecs.so.3.4 (0x00007f16f2688000)
    libopencv_core.so.3.4 => /home/mihai/Projects/slambench2/deps/opencv/lib/libopencv_core.so.3.4 (0x00007f16f18e2000)
    libcpp_common.so => /opt/ros/melodic/lib/libcpp_common.so (0x00007f16f16d7000)
    libroscpp_serialization.so => /opt/ros/melodic/lib/libroscpp_serialization.so (0x00007f16f14d4000)
    librostime.so => /opt/ros/melodic/lib/librostime.so (0x00007f16f12b4000)
    librosbag_storage.so => /opt/ros/melodic/lib/librosbag_storage.so (0x00007f16f1043000)
    libboost_system.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 (0x00007f16f0e3e000)
    libboost_filesystem.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.65.1 (0x00007f16f0c24000)
    libboost_regex.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.65.1 (0x00007f16f091c000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f16f0593000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f16f01f5000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f16effdd000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f16efbec000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f16f3a98000)
    libopencv_imgproc.so.3.4 => /home/mihai/Projects/slambench3/deps/opencv/lib/libopencv_imgproc.so.3.4 (0x00007f16ef613000)
    libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f16ef3ab000)
    libwebp.so.6 => /usr/lib/x86_64-linux-gnu/libwebp.so.6 (0x00007f16ef142000)
    libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f16eef10000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f16eecf3000)
    libconsole_bridge.so.0.4 => /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.4 (0x00007f16eeaee000)
    libclass_loader.so => not found
    librosconsole.so => not found
    libroslib.so => not found
    libtinyxml2.so.6 => /usr/lib/x86_64-linux-gnu/libtinyxml2.so.6 (0x00007f16ee8da000)
    libroslz4.so => /usr/lib/x86_64-linux-gnu/libroslz4.so (0x00007f16ee6d6000)
    libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f16ee4c6000)
    libicui18n.so.60 => /usr/lib/x86_64-linux-gnu/libicui18n.so.60 (0x00007f16ee025000)
    libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f16edc6d000)
    liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f16eda51000)
    libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f16ebea8000)

mihaibujanca commented 4 years ago

@lplana Looking again, it's strange that these appear

 libclass_loader.so => not found
 librosconsole.so => not found
 libroslib.so => not found

since other ROS libraries are found

libcpp_common.so => /opt/ros/melodic/lib/libcpp_common.so

As mentioned before, executing setup.bash solves this problem, but I am not sure how

lplana commented 4 years ago

As it stands, cmake should find all required libraries for the ros packages listed as dependencies. The packages themselves tell cmake their dependencies. It is inconsistent that some libraries are found and others aren't.

I don't see this issue with kinetic. None of your missing libraries is listed as a dependency for the ROS packages we use in kinetic. I'll check melodic and maybe I can understand the problem.

mihaibujanca commented 4 years ago

I also need to point out that if ROSBAG-TUM was built and the ros-related libraries are not found, any dataset, regardless of whether it's ROS or not will fail.

This may seem obvious in the context or this PR (the libraries are linked to dataset-generator), but it can be confusing to someone who is trying to build a dataset which isn't related to ROS.

lplana commented 4 years ago

Could you please let me know the OS and ROS versions/distributions that you're using?

How can you build tum-rosbag without the libraries? cmake tries to find the libraries before building and skips tum-rosbag support if it doesn't find all of them.

I believe that SLAMBench ROS dependencies are different for different ROS distributions. ROS packages themselves have different dependencies. I need to update CMakeLists.txt to reflect these different dependencies based on the ROS distribution.

mihaibujanca commented 4 years ago

@lplana I'm using Ubuntu 18.04 / ROS melodic.

How can you build tum-rosbag without the libraries? cmake tries to find the libraries before building and skips tum-rosbag support if it doesn't find all of them.

The scenario here would be different: Suppose a user builds SLAMBench with ROS support enabled and successfully builds the TUM-ROSBAG datasets. A few days later the user attempts to build the ICL-NUIM datasets. They would not expect source setup.bash to be a required step before doing so, since they aren't building anything related to ROS. Yet, because dataset-generator was built with ROS support, this will fail. Instead, the user would need to rebuild dataset-generator without ROS support in order to be able to build any dataset without executing source setup.bash

mihaibujanca commented 4 years ago

I don't see this issue with kinetic. None of your missing libraries is listed as a dependency for the ROS packages we use in kinetic. I'll check melodic and maybe I can understand the problem.

Could you please compare my output from above with what you get when executing ldd build/bin/dataset-generator?

Might help narrow down the issue

lplana commented 4 years ago

I have to say that I have not been able to reproduce the issues you raise.

I never source setup.bash, neither for build nor for execution.

Trying to get an error, I built with ROS support and then removed the ROS installation altogether. In this case I did get an error during execution, but I think that this has to be expected behaviour.

I'll try to setup a machine with 18.04 and melodic. Maybe I'll be able to understand the problem.

lplana commented 4 years ago

Could you please compare my output from above with what you get when executing ldd build/bin/dataset-generator?

Might help narrow down the issue

plana@spinn-rain:~/devel/slambench2$ ldd build/bin/dataset-generator linux-vdso.so.1 => (0x00007fff80d53000) libyaml-cpp.so.0.5 => /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5 (0x00007f97add4f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f97adb4b000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f97ad92e000) libopencv_highgui.so.2.4 => /home/plana/devel/slambench2/deps/opencv/lib/libopencv_highgui.so.2.4 (0x00007f97ad5e9000) libopencv_core.so.2.4 => /home/plana/devel/slambench2/deps/opencv/lib/libopencv_core.so.2.4 (0x00007f97ad144000) libcpp_common.so => /opt/ros/kinetic/lib/libcpp_common.so (0x00007f97acf3c000) libroscpp_serialization.so => /opt/ros/kinetic/lib/libroscpp_serialization.so (0x00007f97acd39000) librostime.so => /opt/ros/kinetic/lib/librostime.so (0x00007f97acb0c000) librosbag_storage.so => /opt/ros/kinetic/lib/librosbag_storage.so (0x00007f97ac8c3000) libboost_system.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x00007f97ac6bf000) libboost_filesystem.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x00007f97ac4a7000) libboost_regex.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.58.0 (0x00007f97ac19f000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f97abe1d000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f97abb14000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f97ab8fe000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f97ab534000) /lib64/ld-linux-x86-64.so.2 (0x00007f97adfcc000) libopencv_imgproc.so.2.4 => /home/plana/devel/slambench2/deps/opencv/lib/libopencv_imgproc.so.2.4 (0x00007f97ab024000) libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f97aadcb000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f97aaba6000) libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x00007f97aa931000) libjasper.so.1 => /usr/lib/x86_64-linux-gnu/libjasper.so.1 (0x00007f97aa6dc000) libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007f97aa091000) libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007f97a9ddc000) libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f97a9b89000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f97a9878000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f97a965e000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f97a9456000) libconsole_bridge.so.0.2 => /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.2 (0x00007f97a9251000) libroslz4.so => /opt/ros/kinetic/lib/libroslz4.so (0x00007f97a904c000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f97a8e3c000) libicui18n.so.55 => /usr/lib/x86_64-linux-gnu/libicui18n.so.55 (0x00007f97a89da000) libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f97a8646000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f97a8424000) libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007f97a8216000) libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f97a8012000) libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f97a7e05000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f97a7acb000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f97a78c5000) libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f97a76a0000) libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f97a738c000) libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f97a716a000) libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f97a6de2000) libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f97a6bcc000) libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f97a6980000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f97a673d000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f97a6533000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f97a6330000) libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f97a6120000) libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f97a5f15000) libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f97a5d0b000) libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f97a5b08000) libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f97a5905000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f97a56f3000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f97a54eb000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f97a527b000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f97a5063000) libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f97a35ac000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f97a3302000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f97a30e0000) libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f97a2e38000) libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f97a2c34000) libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f97a2a2a000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f97a2808000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f97a25ed000) libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f97a238f000) libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f97a2186000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f97a1f5d000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f97a1d59000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f97a1b53000) libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f97a192d000) libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f97a1725000)

mihaibujanca commented 4 years ago

Looking at what libraries get included, it seems like all of them come from rosbag_storage_LIBRARIES:

CPP COMMON LIBRARIES  /opt/ros/melodic/lib/libcpp_common.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.4

ROSCPP SERIALIZATION LIBRARIES  /opt/ros/melodic/lib/libroscpp_serialization.so;/opt/ros/melodic/lib/librostime.so;/opt/ros/melodic/lib/libcpp_common.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.4

ROSTIME LIBRARIES  /opt/ros/melodic/lib/librostime.so;/opt/ros/melodic/lib/libcpp_common.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.4

============= LIBS HERE =================
ROSBAG STORAGE LIBRARIES:  /opt/ros/melodic/lib/librosbag_storage.so;/opt/ros/melodic/lib/libclass_loader.so;/usr/lib/libPocoFoundation.so;/usr/lib/x86_64-linux-gnu/libdl.so;/opt/ros/melodic/lib/librosconsole.so;/opt/ros/melodic/lib/librosconsole_log4cxx.so;/opt/ros/melodic/lib/librosconsole_backend_interface.so;/usr/lib/x86_64-linux-gnu/liblog4cxx.so;/usr/lib/x86_64-linux-gnu/libboost_regex.so;/opt/ros/melodic/lib/librostime.so;/opt/ros/melodic/lib/libcpp_common.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.4;/opt/ros/melodic/lib/libroslib.so;/opt/ros/melodic/lib/librospack.so;/usr/lib/x86_64-linux-gnu/libpython2.7.so;/usr/lib/x86_64-linux-gnu/libboost_filesystem.so;/usr/lib/x86_64-linux-gnu/libboost_program_options.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libtinyxml2.so;/opt/ros/melodic/lib/libroslz4.so;/usr/lib/x86_64-linux-gnu/liblz4.so

Perhaps that particular package has different dependencies in ROS melodic and ROS kinetic?

lplana commented 4 years ago

Perhaps that particular package has different dependencies in ROS melodic and ROS kinetic?

This shouldn't be an issue, given that cmake finds the specific dependencies listed by the package itself. As I mentioned earlier, these can vary according to ROS distro.

After digging a bit more (hopefully not my own grave), I think that the problem was a missing ROS package (pluginlib) required by melodic. I re-structured the datasets CMakeLists.txt in a way that clarifies dependencies and adds the required package only if the ROS distribution found is melodic.

Could you please check if you notice any changes? I still don't have access to a 18.04/melodic system.

mihaibujanca commented 4 years ago

Now it's very weird: I can build slambench with ROS support enabled but when trying to execute dataset-generator, I get the same error about the libraries not being found. The output of ldd hasn't changed.

This looks strange so I'll try to install ROS on my laptop as well and see if I can reproduce the issue. The laptop has Ubuntu 20.04 not 18.04 though so it might not work super well.

lplana commented 4 years ago

I added a standard link library directory, based on ROS distribution. This should help cmake find the libraries that it's looking for. The directory comes from ROS environmental variables, if set, or standard distribution directories, if setup.bash has not been sourced.

mihaibujanca commented 4 years ago

The issue still seems to be there, but seems like adding /opt/ros/melodic/lib to LD_LIBRARY_PATH solves it, please see below. I'm confused as to why the other libs in the same directory don't get resolved.

(base) ¯\_(ツ)_/¯ ~:cd Projects/slambench2/
(base) ¯\_(ツ)_/¯ ~/Projects/slambench2:ldd build/bin/dataset-generator 
    linux-vdso.so.1 (0x00007ffd5ab96000)
    libyaml-cpp.so.0.5 => /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5 (0x00007fa3db1b1000)
    libOpenCL.so.1 => /usr/local/cuda-10.1/lib64/libOpenCL.so.1 (0x00007fa3dafaa000)
    libcudart.so.10.1 => /usr/local/cuda-10.1/lib64/libcudart.so.10.1 (0x00007fa3dad2e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa3dab0f000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa3da90b000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa3da703000)
    libopencv_imgcodecs.so.3.4 => /home/mihai/Projects/slambench2/deps/opencv/lib/libopencv_imgcodecs.so.3.4 (0x00007fa3da30a000)
    libopencv_core.so.3.4 => /home/mihai/Projects/slambench2/deps/opencv/lib/libopencv_core.so.3.4 (0x00007fa3d9564000)
    libcpp_common.so => /opt/ros/melodic/lib/libcpp_common.so (0x00007fa3d9359000)
    libroscpp_serialization.so => /opt/ros/melodic/lib/libroscpp_serialization.so (0x00007fa3d9156000)
    librostime.so => /opt/ros/melodic/lib/librostime.so (0x00007fa3d8f36000)
    librosbag_storage.so => /opt/ros/melodic/lib/librosbag_storage.so (0x00007fa3d8cc5000)
    libboost_system.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 (0x00007fa3d8ac0000)
    libboost_filesystem.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.65.1 (0x00007fa3d88a6000)
    libboost_regex.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.65.1 (0x00007fa3d859e000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa3d8215000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa3d7e77000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa3d7c5f000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa3d786e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa3db71a000)
    libopencv_imgproc.so.3.4 => /home/mihai/Projects/slambench3/deps/opencv/lib/libopencv_imgproc.so.3.4 (0x00007fa3d7295000)
    libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fa3d702d000)
    libwebp.so.6 => /usr/lib/x86_64-linux-gnu/libwebp.so.6 (0x00007fa3d6dc4000)
    libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007fa3d6b92000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa3d6975000)
    libconsole_bridge.so.0.4 => /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.4 (0x00007fa3d6770000)
    libclass_loader.so => not found
    librosconsole.so => not found
    libroslib.so => not found
    libtinyxml2.so.6 => /usr/lib/x86_64-linux-gnu/libtinyxml2.so.6 (0x00007fa3d655c000)
    libroslz4.so => /usr/lib/x86_64-linux-gnu/libroslz4.so (0x00007fa3d6358000)
    libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fa3d6148000)
    libicui18n.so.60 => /usr/lib/x86_64-linux-gnu/libicui18n.so.60 (0x00007fa3d5ca7000)
    libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007fa3d58ef000)
    liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fa3d56d3000)
    libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007fa3d3b2a000)
(base) ¯\_(ツ)_/¯ ~/Projects/slambench2:export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/ros/melodic/lib
(base) ¯\_(ツ)_/¯ ~/Projects/slambench2:ldd build/bin/dataset-generator 
    linux-vdso.so.1 (0x00007ffe58bf9000)
    libyaml-cpp.so.0.5 => /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5 (0x00007f2c5bf8e000)
    libOpenCL.so.1 => /usr/local/cuda-10.1/lib64/libOpenCL.so.1 (0x00007f2c5bd87000)
    libcudart.so.10.1 => /usr/local/cuda-10.1/lib64/libcudart.so.10.1 (0x00007f2c5bb0b000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2c5b8ec000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2c5b6e8000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2c5b4e0000)
    libopencv_imgcodecs.so.3.4 => /home/mihai/Projects/slambench2/deps/opencv/lib/libopencv_imgcodecs.so.3.4 (0x00007f2c5b0e7000)
    libopencv_core.so.3.4 => /home/mihai/Projects/slambench2/deps/opencv/lib/libopencv_core.so.3.4 (0x00007f2c5a341000)
    libcpp_common.so => /opt/ros/melodic/lib/libcpp_common.so (0x00007f2c5a136000)
    libroscpp_serialization.so => /opt/ros/melodic/lib/libroscpp_serialization.so (0x00007f2c59f33000)
    librostime.so => /opt/ros/melodic/lib/librostime.so (0x00007f2c59d13000)
    librosbag_storage.so => /opt/ros/melodic/lib/librosbag_storage.so (0x00007f2c59aa2000)
    libboost_system.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 (0x00007f2c5989d000)
    libboost_filesystem.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.65.1 (0x00007f2c59683000)
    libboost_regex.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.65.1 (0x00007f2c5937b000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2c58ff2000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2c58c54000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2c58a3c000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2c5864b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2c5c4f7000)
    libopencv_imgproc.so.3.4 => /home/mihai/Projects/slambench3/deps/opencv/lib/libopencv_imgproc.so.3.4 (0x00007f2c58072000)
    libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f2c57e0a000)
    libwebp.so.6 => /usr/lib/x86_64-linux-gnu/libwebp.so.6 (0x00007f2c57ba1000)
    libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f2c5796f000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2c57752000)
    libconsole_bridge.so.0.4 => /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.4 (0x00007f2c5754d000)
    libclass_loader.so => /opt/ros/melodic/lib/libclass_loader.so (0x00007f2c57326000)
    librosconsole.so => /opt/ros/melodic/lib/librosconsole.so (0x00007f2c570f0000)
    libroslib.so => /opt/ros/melodic/lib/libroslib.so (0x00007f2c56edd000)
    libtinyxml2.so.6 => /usr/lib/x86_64-linux-gnu/libtinyxml2.so.6 (0x00007f2c56cc9000)
    libroslz4.so => /opt/ros/melodic/lib/libroslz4.so (0x00007f2c56ac4000)
    libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f2c568b4000)
    libicui18n.so.60 => /usr/lib/x86_64-linux-gnu/libicui18n.so.60 (0x00007f2c56413000)
    libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f2c5605b000)
    libPocoFoundation.so.50 => /usr/lib/libPocoFoundation.so.50 (0x00007f2c55cb2000)
    librosconsole_log4cxx.so => /opt/ros/melodic/lib/librosconsole_log4cxx.so (0x00007f2c55a97000)
    librosconsole_backend_interface.so => /opt/ros/melodic/lib/librosconsole_backend_interface.so (0x00007f2c55895000)
    liblog4cxx.so.10 => /usr/lib/x86_64-linux-gnu/liblog4cxx.so.10 (0x00007f2c554cc000)
    librospack.so => /opt/ros/melodic/lib/librospack.so (0x00007f2c55289000)
    liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f2c5506d000)
    libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f2c534c4000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f2c53252000)
    libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007f2c5301d000)
    libaprutil-1.so.0 => /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 (0x00007f2c52df2000)
    libboost_program_options.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1 (0x00007f2c52b71000)
    libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007f2c525f4000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f2c523ed000)
    libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f2c521b5000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f2c51f83000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f2c51d80000)

lplana commented 4 years ago

The issue still seems to be there, but seems like adding /opt/ros/melodic/lib to LD_LIBRARY_PATH solves it, please see below. I'm confused as to why the other libs in the same directory don't get resolved.

I'm also confused. In the latest commit I added /opt/ros/DISTRO/lib to the link directories path, which I thought would do the same as LD_LIBRARY_PATH.

mihaibujanca commented 4 years ago

I also think that should work but perhaps it only adds the path at compile time and LD_LIBRARY_PATH ensures they are found at runtime? It still doesn't explain why the other ones are found

lplana commented 4 years ago

The others are found because they are listed with absolute paths in the package configuration file that cmake uses to find them. The absolute path is stored in the dataset-generator executable.

mihaibujanca commented 4 years ago

But if I print out the libraries when building, they contain the full path:

ROSBAG STORAGE LIBRARIES: /opt/ros/melodic/lib/librosbag_storage.so;/opt/ros/melodic/lib/libclass_loader.so;/usr/lib/libPocoFoundation.so;/usr/lib/x86_64-linux-gnu/libdl.so;/opt/ros/melodic/lib/librosconsole.so;/opt/ros/melodic/lib/librosconsole_log4cxx.so;/opt/ros/melodic/lib/librosconsole_backend_interface.so;/usr/lib/x86_64-linux-gnu/liblog4cxx.so;/usr/lib/x86_64-linux-gnu/libboost_regex.so;/opt/ros/melodic/lib/librostime.so;/opt/ros/melodic/lib/libcpp_common.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.4;/opt/ros/melodic/lib/libroslib.so;/opt/ros/melodic/lib/librospack.so;/usr/lib/x86_64-linux-gnu/libpython2.7.so;/usr/lib/x86_64-linux-gnu/libboost_filesystem.so;/usr/lib/x86_64-linux-gnu/libboost_program_options.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libtinyxml2.so;/opt/ros/melodic/lib/libroslz4.so;/usr/lib/x86_64-linux-gnu/liblz4.so

lplana commented 4 years ago

Could you source setup.bash and run pkg-config --libs rosbag_storage?

This should list the libraries that cmake would look for to build rosbag_storage.

pamela-project / slambench

Rosbag support for TUM datasets #37