How to call a global planner from within a custom planner?
Problem (TL;DR)
I am trying to write a custom global planner that can alternate between the another global planner (here navfn
), and a custom algorithm of my own. The errors I am getting suggest a linker error, but I could also be incorrectly calling and using the navfn
code. I would appreciate it if someone with more knowledge than me could confirm whether my implementation is correct or not.
Problem (full)
As above. My repository, including all necessary .h, .cpp, .xml and CMakeList files is here. The code is largely based off the ROS tutorial on writing a custom planner. It seems that this method relies on writing overloaded versions of functions that move_base
can call. I would like someone more knowledgeable than me to confirm that my implementation is correct, specifically:
The definition of the
navfn
object from the class definition in the custom sinusoidpathplanner.h file:navfn::NavfnROS* navfn_planner = NULL;
The initalization of the
navfn
class from within my custom plannerinitalize
function, as written in the sinusoidpathplanner.cpp filenavfn_planner = new navfn::NavfnROS(); navfn_planner->initialize(name, costmap_ros);
Calling the
navfn::NavfnROS::makePlan
function from within themakePlan
function of my custom planner, again in sinusoidpathplanner.cpp:navfn_planner->makePlan(start, goal, plan);
I've seen several other questions from people trying to do something similar (1, 2, 3) , but so far I haven't found any working pre-existing code. So hopefully an answer to this question can help those people as well.
Relevant system information:
- OS: Ubuntu 14.04
- ROS version: Indigo Igloo
- PCL version: PCL 1.8
The code in my linked repository compiles on my system but fails with this error:
[ INFO] [1560163720.835616531, 3720.674000000]: Created global planner sinusoid_path_planner/GlobalPlanner
/opt/ros/indigo/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 16479, exit code 127, cmd /opt/ros/indigo/lib/move_base/move_base odom:=odometry/filtered __name:=move_base __log:=/home/matt/.ros/log/28c5f010-8b68-11e9-a9ae-e8b1fc8ba78b/move_base-1.log].
log file: /home/matt/.ros/log/28c5f010-8b68-11e9-a9ae-e8b1fc8ba78b/move_base-1*.log
all processes on machine have died, roslaunch will exit
shutting down processing monitor...
... shutting down processing monitor complete
done
De-mangling the symbol name with c++filt
indicates that this is failing at the navfn::NavfnROS::NavfnROS()
call. The "missing symbol" error is usually a linker problem. But as I've said, my implementation could also be wrong, and I would greatly appreciate someone confirming if this is the case or not.
Asked by M@t on 2019-06-10 05:56:38 UTC
Answers
I've posted this on #q325252 as well, but I believe Navfn is a plugin, so it should be loaded using the pluginlib
infrastructure. wiki/pluginlib has a short example that shows how to do that, but the move_base
code of course also does that: here. It's a bit more abstracted than the example on the wiki page, but you should be able to figure it out.
You cannot just use the loader(s) from move_base
afaik, so you'd have to instantiate one as part of your own planner, but that should-just-work.
Directly instantiating such a plugin should be possible, but might require some more careful use of libraries (ie: which should be linked, etc).
In the end you'd have a planner plugin that loads a planner plugin, but that should not be a problem.
Asked by gvdhoorn on 2019-06-12 03:00:35 UTC
Comments
This is the kind of answer I was looking for! So my suspicion that it's not as simple as constructing and calling another planner is correct.
Asked by M@t on 2019-06-16 16:20:24 UTC
Well it's just a 'guess' (I'm not entirely sure it'll resolve your missing symbol problems) and it's not actually that difficult :)
Asked by gvdhoorn on 2019-06-17 02:04:10 UTC
Comments
You'll need to show us your
CMakeLists.txt
.Plugins need to link against the libraries from which they are (attempting to) import(ing) symbols.
Are you linking to the Navfn libraries?
Asked by gvdhoorn on 2019-06-10 06:52:02 UTC
Sorry, I linked my repo above, but didn't make it clear enough that this included all the necessary files like the CMakeList.txt file. When I explicitly link
navfn
it just changes the nature of the error message, hence why I wanted to confirm that the way I am calling navfn is correct.Asked by M@t on 2019-06-10 16:09:27 UTC
Also, like I said there are some compatibility issues I am trying to work around, which are confounding the problem. But that needs to be discussed in its own question (which I will put up as soon as I can) as I want the focus of this question to be on whether the implementation of
navfn
is correct or not. I feel like this should have been something clearly and explicitly addressed in the tutorial, and that there should be a standard way of initializing and calling planners like this. But I haven't found any documentation clearly explaining this, other than some allusions to being able to call a global planner as a standalone package.Asked by M@t on 2019-06-10 17:57:04 UTC
to what exactly?
Asked by gvdhoorn on 2019-06-11 02:47:27 UTC
Sorry, forgot to add the link to the separate question - which you've already found. I've edited this question to redirect as necessary.
Asked by M@t on 2019-06-11 04:10:17 UTC