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:
- OS: Ubuntu 14.04
- ROS version: Indigo Igloo
- PCL version: PCL 1.8
- Repository: (includes all relevant files): here. My custom planner is declared in sinusoid_path_planner.h. The source code is in sinusoid_path_planner.cpp and compilation/linking is determined by the CMakeLists.txt file.
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 ...
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:
package.xml), nothing else. But I wouldn't bother with those. Just userosinstall_generator.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.
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 withDockerandrostinstall_generatorthen 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.
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.
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.rosinstallfile with everything needed to build ...(more)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 theros-gbp/navigation-releaserepository.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).
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
- 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
(more)map_server.pluginlibinfrastructure to load the navfn ....., both of which the compiler knows nothing about. CMake takes care of build ordering (well, Catkin, but still). Only the
CMakeLists.txtwill determine what gets linked to what.