ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Overlay octomap with devel branch (source) for ROS

asked 2013-01-20 11:31:23 -0600

anonymousSnowMan gravatar image

updated 2013-01-23 00:45:01 -0600

AHornung gravatar image

I have been attempting to test the new OpenMP implementation for OctoMap (provided by Armin in this question: ) due to the requirements of the point cloud that I'm trying to use.

I downloaded the latest branch from and then:

cd ../octomap-devel-openmp/octomap/
mkdir build && cd build
cmake ..

This completes with no problem, as does:

make test

My .bashrc file contains:

export LD_LIBRARY_PATH=/scratch/octomap-devel-openmp/lib:$LD_LIBRARY_PATH:/usr/local/lib
export ROS_PACKAGE_PATH=/scratch/octomap-devel-openmp:/scratch/src/octomap_mapping/octomap_server:$ROS_PACKAGE_PATH

Even still, octomap_server (which I have been editing in a non-standard location, hence the redirect) still finds the includes and libraries from the ros-fuerte-octomap install, which comes with ros-fuerte-octomap-ros which is a dependency of octomap_server.

I assume that I'm missing something with installing the octomap source from a development branch, but I can't work out what it is.

*EDIT1: Finally got back to trying to get octomap_server to build with the OpenMP development branch.

My CMakeLists.txt file is:

 15 #find_package(octomap 1.5)
 16 include(/scratch/octomap-devel-openmp/octomap/lib/cmake/octomap/octomap-config.cmake)
 17 include_directories(BEFORE /scratch/octomap-devel-openmp/octomap/include/octomap)
 18 link_directories(/scratch/octomap-devel-openmp/octomap/lib)
 19 link_libraries(octomap_server /scratch/octomap-devel-openmp/octomap/lib/ /scratch/octomap-devel-openmp/octomap/lib/
 21 #find_package(octomap REQUIRED)
 22 #include_directories(${OCTOMAP_INCLUDE_DIRS})
 23 #link_directories(${OCTOMAP_LIBRARY_DIRS})
 24 #link_libraries(${PROJECT_NAME} ${OCTOMAP_LIBRARIES})

Doing a make clean and then a make -d in the /build directory gives the error:

Considering target file `/scratch/octomap-devel-openmp/octomap/lib/'.
     Looking for an implicit rule for `/scratch/octomap-devel-openmp/octomap/lib/'.
     Trying pattern rule with stem `'.
     Trying implicit prerequisite `/scratch/octomap-devel-openmp/octomap/lib/,v'.
     Trying pattern rule with stem `'.
     Trying implicit prerequisite `/scratch/octomap-devel-openmp/octomap/lib/RCS/,v'.
     Trying pattern rule with stem `'.
     Trying implicit prerequisite `/scratch/octomap-devel-openmp/octomap/lib/RCS/'.
     Trying pattern rule with stem `'.
     Trying implicit prerequisite `/scratch/octomap-devel-openmp/octomap/lib/'.
     Trying pattern rule with stem `'.
     Trying implicit prerequisite `/scratch/octomap-devel-openmp/octomap/lib/SCCS/'.
     No implicit rule found for `/scratch/octomap-devel-openmp/octomap/lib/'.
     Finished prerequisites of target file `/scratch/octomap-devel-openmp/octomap/lib/'.
    Pruning file `/scratch/octomap-devel-openmp/octomap/lib/'.
    Pruning file `CMakeFiles/octomap_saver.dir/build.make'.
   Finished prerequisites of target file `../bin/octomap_saver'.
  Must remake target `../bin/octomap_saver'.
Putting child 0x00a4b990 (../bin/octomap_saver) PID 19787 on the chain.
Live child 0x00a4b990 (../bin/octomap_saver) PID 19787 
Linking CXX executable ../bin/octomap_saver
Reaping winning child 0x00a4b990 PID 19787 
Live child 0x00a4b990 (../bin/octomap_saver) PID 19789 
CMakeFiles/octomap_saver.dir/src/octomap_saver.o: In function `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::length() const':
/usr/include/c++/4.6/bits/basic_string.h:717: undefined reference to `octomap::AbstractOcTree::binaryFileHeader'
CMakeFiles/octomap_saver.dir/src/octomap_saver.o: In function `octomap::OccupancyOcTreeBase<octomap::OcTreeNode>::readBinary(std::basic_istream<char, std::char_traits<char> >&)':
/opt/ros/fuerte/include/octomap ...
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2013-01-20 23:03:57 -0600

AHornung gravatar image

updated 2013-01-23 00:36:38 -0600

Essentially, what you are trying to do is create an overlay of octomap on top of your installed version. First thing to understand is that "octomap" is no longer a regular ros package that gets found with "rosmake", so it does not need to be in your ROS_PACKAGE_PATH. There is no manifest.xml or package.xml in it (only some pre-built versions may contain it for packaging reasons).

Instead, octomap is a regular CMake package that octomap_server locates using CMake's FIND_PACKAGE mechanism in the CMakeLists.txt. For this octomap provides a file "octomap-config.cmake" that contains all the linker and compiler flags and dirs. ROS picks it up in /opt/ros/fuerte/lib/cmake/octomap since the setup.bash sets the variable $CMAKE_PREFIX_PATH.

You can manually specify the path for CMake by setting the variable "octomap_DIR" to the directory containing octomap-config.cmake (either build or install location, both should work) before compiling. E.g.:

export octomap_DIR=/scratch/octomap-devel-openmp/octomap/lib/cmake/octomap
rosmake octomap_server

This should then pick up the correct version, but I have also seen occasion where rosbuild preferred the installed version instead, I don't know why that happens.

To work around that, it may be necessary to remove the installed ros-fuerte-octomap, or try to use the version argument in CMake's find_package in octomap_server:

find_package(octomap 1.5 REQUIRED)

The installed version in Fuerte is 1.4, so CMake should skip over that one.

Update: Some remarks to your lines in CMakeLists: Don't include octomap-config.cmake, instead point the environment variable octomap_DIR to the directory containing it and use find_package. Your include_directories path is wrong, you need to remove the trailing "octomap". Otherwise is looks good. Here are the lines working for me:

find_package(octomap 1.5 REQUIRED)
include_directories(BEFORE ${OCTOMAP_INCLUDE_DIRS})

I found that CMakeLists.txt picks up the right paths (see the status message in the last line), but rosmake ignores it and uses its own path for headers and picks up liboctomap from LD_LIBRARY_PATH instead. Adding BEFORE to include_directories fixes the first problem, while the absolute library paths in link_libraries fixes the second. OctoMap will fix that in a new release.

However, you will now notice that octomap_server for fuerte will no longer compile since it relies on OctoMap 1.4 and the devel branches on github will aim for a 1.6 release. You will have more luck with the groovy version at (although the changes are small, and should be easy to apply).

edit flag offensive delete link more


Ah, yes, I was confused in thinking that it was a ROS-package. Unfortunately, neither of the suggested fixes had any luck for me, with octomap_server still seeming to use the ros-fuerte-octomap libraries, verified by 'ldd octomap_server_node'.

anonymousSnowMan gravatar image anonymousSnowMan  ( 2013-01-21 18:08:00 -0600 )edit

Removing ros-fuerte-octomap will solve that, but maybe you need other packages depending on it. You could also manually set the paths of "include_directories" and "link_directories" in CMakeList.txt in octomap_server. Or put the absolute paths to and in "link_libraries"

AHornung gravatar image AHornung  ( 2013-01-21 21:17:01 -0600 )edit

Indeed, octomap_server depends on ros-fuerte-octomap-ros, which is linked to ros-fuerte-octomap. If you could take a look at the EDIT1: section in the original posting, that would be appreciated. Still having issues in linking the openmp development branch to octomap_server.

anonymousSnowMan gravatar image anonymousSnowMan  ( 2013-01-22 15:13:09 -0600 )edit

I extended my answer, that should work better. Still, you could also remove ros-fuerte-octomap and ros-fuerte-octomap-ros, then build octomap, octomap_ros, and octomap_server yourself in a source overlay.

AHornung gravatar image AHornung  ( 2013-01-23 00:38:09 -0600 )edit

I just remembered that OctomapServer.cpp does not use OctoMap's insertScan functions, and hence will not be parallelized. It uses its own calls to computeRayKeys to deal with the ground plane (=not an obstacle). You would need to parallelize that in the same way as insertScan in OctoMap.

AHornung gravatar image AHornung  ( 2013-01-23 22:45:52 -0600 )edit

Question Tools

1 follower


Asked: 2013-01-20 11:31:23 -0600

Seen: 1,197 times

Last updated: Jan 23 '13