How to compile a non-native Navigation Stack with your workspace?

asked 2019-06-10 22:28:04 -0500

M@t gravatar image

updated 2019-06-11 18:26:30 -0500

Problem (TL;DR)

I am running ROS Indigo on Ubuntu 14.04. For historical reasons I had to install PCL 1.8 and remove PCL 1.7. I now need to write a custom global planner, and it seems that I need to link in packages from the Navigation Stack (specifically navfn). However, ROS Indigo was built with PCL 1.7, and it's nav stack packages won't compile without it. So I am trying to compile my workspace with the ROS Melodic nav stack, as this was the first navigation stack to support PCL 1.8 and I need some help debugging the errors I am getting.

Problem (full)

As above. My custom planner is largely based on the Writing A Global Path Planner As Plugin in ROS tutorial, with some minor changes to fix problems in the tutorial code.

IF I compile the code without linking navfn, and if I do not include any nav stack packages in my workspace, my code compiles and the tutorial code successfully plots a path. The problems only occur when I try linking to packages from the navigation stack.

Relevant system information:

I believe that in order to use the navfn planner from within my custom planner, I need to link it (and some other nav stack packages like costmap_2d) in the CMakeLists.txt file, as shown:

find_package(catkin REQUIRED COMPONENTS roscpp rospy std_msgs sensor_msgs roslaunch nav_core navfn costmap_2d)

However, when I do this, I get the following warning which suggests that the ROS Indigo nav stack won't work without PCL 1.7.

CMake Error at /opt/ros/indigo/share/costmap_2d/cmake/costmap_2dConfig.cmake:106 (message):
  Project 'costmap_2d' specifies '/usr/include/pcl-1.7' as an include dir, 
  which is not found.  It does neither exist as an absolute directory nor in 
  '/opt/ros/indigo//usr/include/pcl-1.7'.  Ask the maintainer 'David V.  Lu!!
  <>, Michael Ferguson <>, Aaron Hoy
  <>' to fix it.
Call Stack (most recent call first):
  /opt/ros/indigo/share/nav_core/cmake/nav_coreConfig.cmake:165 (find_package)
  /opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:76 (find_package)
  sinusoid_path_planner/CMakeLists.txt:14 (find_package)

To get around this, I followed this ROS Answers question here. I have already changed my CMakeList.txt file to explicitly set the PCL include paths to point to the PCL 1.8 installation. And I added what I think are the necessary packages from the ROS Melodic nav stack to my workspace, specifically costmap_2d, global_planner, move_base, nav_core, navfn. This will compile and even run, but always fails at some point with a reference to undefined symbols. E.g:

[ INFO] [1560222901.684840650, 1520.648000000]: odom received!
[ INFO] [1560222909.218170347, 1526.300000000]: Publishing navfn path
/home ...
edit retag flag offensive close merge delete


symbol lookup error: /opt/ros/indigo/lib//

this seems to suggest that at least some parts of the navigation stack are still linked to the old Indigo version.

It may not be absolutely necessary, but just to be on the safe side you might want to build all parts of the nav stack in your workspace.

How did you select the pkgs from the nav stack that you want to build from sources? Manually?

Have you tried using rosinstall_generator?

Edit: oh, I only just now saw your three questions. Re those:

  1. all of it -- for now at least
  2. inconsistent linking, probably
  3. dependency information comes from package manifests (ie: package.xml), nothing else. But I wouldn't bother with those. Just use rosinstall_generator.
gvdhoorn gravatar image gvdhoorn  ( 2019-06-11 03:07:24 -0500 )edit

And an additional comment: do you actually need PCL 1.8 for your planner? Or is that a requirement for something else?

If you don't need it: could you perhaps use Docker containers to isolate the Indigo navstack? If all you need are topic/service/action connections, that could definitely work.

gvdhoorn gravatar image gvdhoorn  ( 2019-06-11 03:10:13 -0500 )edit

Thanks for the great suggestions @gvdhoorn! No I don't need PCL 1.8 for this planner, only for a different package entirely. I selected the parts of the Melodic nav stack to integrate based on why I thought was necessary/what I saw in rqt_dep. I'll play around with Docker and rostinstall_generator then report back.

On a side note, I don't suppose there is a catkin command which displays the filepath of every include/depended-on file it compiles? That would help narrow down where each file is coming from.

M@t gravatar image M@t  ( 2019-06-11 04:15:56 -0500 )edit

No I don't need PCL 1.8 for this planner, only for a different package entirely.

would it then not make sense to isolate that package in a container? If I understand you correctly you could then use the regular PCL and all compiled artefacts from Indigo again.

On a side note, I don't suppose there is a catkin command which displays the filepath of every include/depended-on file it compiles? That would help narrow down where each file is coming from.

well, you could run VERBOSE=1 catkin_make .., but again, that sounds like a work-around to me. Or a rather convoluted way to do what you want.

My first approach would be isolation using containers. Either the pkg that needs PCL1.8 or your navstack.

if that's infeasible, use rosinstall_generator. This command (just an example) would get you a .rosinstall file with everything needed to build ...(more)

gvdhoorn gravatar image gvdhoorn  ( 2019-06-11 04:23:54 -0500 )edit

Note: the command is just an example to get you started. There are too many pkgs in that set (ie: things like geometry_msgs) that are probably not needed. A good first try could be to keep only those packages that come from the ros-gbp/navigation-release repository.

gvdhoorn gravatar image gvdhoorn  ( 2019-06-11 04:26:11 -0500 )edit

PCL 1.8 is really important for a few other packages I use, and this is likely to be the only one where I will use the nav stack as anything other than a black box. So I would much rather make a contained build for this package. I'm still getting my head around rosintall_generator. But in the meantime, have a quick look at Update #2, which suggests that catkin/cmake is ignoring the local version of navfn (exactly what I don't want the compiler to do).

M@t gravatar image M@t  ( 2019-06-11 18:12:42 -0500 )edit

I have a feeling you're mixing up a bunch of things:

  • the CMake error you post states that you're tring to link against an include directory. You cannot link a directory, only a library or object files. I don't see how that shows anyone is ignoring anything.
  • as I wrote in my comments here (and in #q289264): you only need to build packages from source when introducing a new version of a dependency if they actually depend on that dependency and/or are transitively linked against it (ie: dependency of dependency depends on the new version). I don't believe that is the case with map_server.
  • I'm confused in any case, as the Melodic version of the navstack is supposedly completely PCL-free: #q286938.
  • (this should probably go into your other question, but) I believe you'd need to use the pluginlib infrastructure to load the navfn ...
gvdhoorn gravatar image gvdhoorn  ( 2019-06-12 02:54:34 -0500 )edit

.., both of which the compiler knows nothing about. CMake takes care of build ordering (well, Catkin, but still). Only the CMakeLists.txt will determine what gets linked to what.

gvdhoorn gravatar image gvdhoorn  ( 2019-06-12 02:55:26 -0500 )edit