Robotics StackExchange | Archived questions

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

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!!
  <davidvlu@gmail.com>, Michael Ferguson <mfergs7@gmail.com>, Aaron Hoy
  <ahoy@fetchrobotics.com>' 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/matt/auxiliary_ros_repo/devel/lib/move_base/move_base: symbol lookup error: /opt/ros/indigo/lib//libtrajectory_planner_ros.so: undefined symbol: _ZNK10costmap_2d12Costmap2DROS12getRobotPoseERN2tf7StampedINS1_9TransformEEE
[move_base-1] process has died [pid 28774, exit code 127, cmd /home/matt/auxiliary_ros_repo/devel/lib/move_base/move_base odom:=odometry/filtered __name:=move_base __log:=/home/matt/.ros/log/151f464e-8bf7-11e9-9284-e8b1fc8ba78b/move_base-1.log].
log file: /home/matt/.ros/log/151f464e-8bf7-11e9-9284-e8b1fc8ba78b/move_base-1*.log
all processes on machine have died, roslaunch will exit
shutting down processing monitor...
... shutting down processing monitor complete
done

So my questions are:

  1. Do I need to include the entire Melodic nav stack? or just specific packages?
  2. What might cause these undefined symbol errors?
  3. How do rosdep depends and rqt_dep read the package dependencies? I'm trying to use these tools to debug the issue, but their documentation is scant, and they don't seem to line up with what the CMakeList.txt file should be including.

Updates

  1. Running VERBOSE=1 catkin_make doesn't reveal any obvious problems. But here is the file just in case someone else can spot anything amiss.

  2. On closer inspection the catkin_make output includes this warning:

    WARNING: Target "sinusoid_path_planner" requests linking to directory "/home/matt/auxiliary_ros_repo/src/navfn/include".  Targets may link only to libraries.  CMake is dropping the item.

I do want the compiler to link in this local copy of navfn and I'm not sure if this warning means that the compiler is ignoring my order and not linking it properly. And I'm not sure if I should even be seeing this warning since the CMakeLists.txt file for the navfn package explicitly creates a navfn library with the line

    add_library (navfn src/navfn.cpp src/navfn_ros.cpp)

  1. Compiling the workspace with the entire Melodic nav stack produces an error related to the bullet_dynamics_library which the map_server package requires. If I compile with everything other than map_server the code compiles and runs provided I don't make any calls to other global planners. The minute I invoke the navfn constructor navfn::NavfnROS::NavfnROS(), the code fails to run (still compiles just fine) with this error:

    /home/matt/auxiliary_ros_repo/devel/lib/move_base/move_base: symbol lookup error: /home/matt/auxiliary_ros_repo/devel/lib//libsinusoid_path_planner.so: undefined symbol: _ZN5navfn8NavfnROSC1Ev
[move_base-1] process has died [pid 17044, exit code 127, cmd /home/matt/auxiliary_ros_repo/devel/lib/move_base/move_base odom:=odometry/filtered __name:=move_base __log:=/home/matt/.ros/log/abf32ed2-8c97-11e9-befb-e8b1fc8ba78b/move_base-1.log].
log file: /home/matt/.ros/log/abf32ed2-8c97-11e9-befb-e8b1fc8ba78b/move_base-1*.log

  2. On a whim I added navfn to the package.xml file, using the <build_depend> and <exec_depend> macros to try and force the compiler to include the navfn package, but this doesn't seem to work as nothing changes. This is one of the reasons I'm not convinced this isn't an implementation error (in which case see this separate ROS question), because I would have thought that this would force the compiler to link the navfn package to the rest of the code.

Asked by M@t on 2019-06-10 22:28:04 UTC

Comments

symbol lookup error: /opt/ros/indigo/lib//libtrajectory_planner_ros.so

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.

Asked by gvdhoorn on 2019-06-11 03:07:24 UTC

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.

Asked by gvdhoorn on 2019-06-11 03:10:13 UTC

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.

Asked by M@t on 2019-06-11 04:15:56 UTC

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 the last release of navigation from Melodic in a workspace:

rosinstall_generator --rosdistro=melodic --deps --tar navigation

Asked by gvdhoorn on 2019-06-11 04:23:54 UTC

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.

Asked by gvdhoorn on 2019-06-11 04:26:11 UTC

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).

Asked by M@t on 2019-06-11 18:12:42 UTC

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 plugin properly. Directly invoking the ctor may not actually be supported
  • the package manifest is used for two thnigs: build order and deps ..

Asked by gvdhoorn on 2019-06-12 02:54:34 UTC

.., 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.

Asked by gvdhoorn on 2019-06-12 02:55:26 UTC

Thanks for the thorough answer @gvdhoorn! Seems that I don't understand CMake as well as I thought I did, so I'd better do some more revision before tackling the problem again. I'll keep chipping away at the linking issues as/when I can.

Asked by M@t on 2019-06-16 16:17:12 UTC

Answers