# Package "ompl" does not follow the version conventions [closed]

Hi all!

I'm trying do implement a base_global_planner plugin with RRT algorithm, for that I'm using the ompl package. The code compiles with no errors, and I followed the steps for registering the plugin but when I launch move_base I get the following error:

[FATAL] [1405968490.244759123, 1.315000000]: Failed to create the rrt_planner/RRT_Planner planner, are you sure it is properly registered and that the containing library is built? Exception: Failed to load library /home/mateus/catkin_ws/devel/lib/librrt_planner.so. Make sure that you are calling the PLUGINLIB_EXPORT_CLASS macro in the library code, and that names are consistent between this macro and your XML. Error string: Could not load library (Poco exception = /home/mateus/catkin_ws/devel/lib/librrt_planner.so: undefined symbol: _ZTVN4ompl4base13SO2StateSpaceE)


The macro is set as:

 PLUGINLIB_EXPORT_CLASS(rrt_planner::RRT_Planner, nav_core::BaseGlobalPlanner)


The xml file:

<library path="librrt_planner">
<class name="rrt_planner/RRT_GlobalPlanner" type="rrt_planner::RRT_GlobalPlanner" base_class_type="nav_core::BaseGlobalPlanner">
<description>
A implementation of a grid based planner using RRT
</description>
</class>
</library>


CMakeLists

cmake_minimum_required(VERSION 2.8.3)
project(rrt_planner)

find_package(catkin REQUIRED COMPONENTS
roscpp
costmap_2d
geometry_msgs
nav_core
nav_msgs
pluginlib
tf
angles
)

find_package(
ompl
)

catkin_package(
INCLUDE_DIRS include
LIBRARIES rrt_planner
CATKIN_DEPENDS
roscpp
costmap_2d
geometry_msgs
nav_core
nav_msgs
pluginlib
tf
angles
DEPENDS system_lib ompl
)

include_directories(
include
${catkin_INCLUDE_DIRS}${ompl_INCLUDE_DIRS}
)

src/rrt_planner.cpp
)

${catkin_LIBRARIES}${ompl_LIBRARIES}
)


The package.xml

<?xml version="1.0"?>


<package> <name>rrt_planner</name> <version>0.0.0</version> <description>The rrt_planner package</description>

<maintainer email="mateus@todo.todo">mateus</maintainer>

<buildtool_depend>catkin</buildtool_depend>
<build_depend>angles</build_depend>
<build_depend>boost</build_depend>
<build_depend>costmap_2d</build_depend>
<build_depend>eigen_conversions</build_depend>
<build_depend>geometry_msgs</build_depend>
<build_depend>nav_msgs</build_depend>
<build_depend>nav_core</build_depend>
<!--<build_depend>ompl</build_depend>-->
<build_depend>pluginlib</build_depend>
<build_depend>roscpp</build_depend>
<build_depend>tf</build_depend>

<run_depend>angles</run_depend>
<run_depend>boost</run_depend>
<run_depend>costmap_2d</run_depend>
<run_depend>eigen_conversions</run_depend>
<run_depend>geometry_msgs</run_depend>
<run_depend>nav_msgs</run_depend>
<run_depend>nav_core</run_depend>
<run_depend>ompl</run_depend>
<run_depend>pluginlib</run_depend>
<run_depend>roscpp</run_depend>
<run_depend>tf</run_depend>

<export>
<nav_core plugin="${prefix}/rrt_planner_plugin.xml" /> </export>  </package> I could not detect any error in the above code. So I think that the problem may be related with a warning I get when running catkin_make. The warning is the following: WARNING: Package "ompl" does not follow the version conventions. It should not contain leading zeros (unless the number is 0).  Is my assumption correct? If so how can I solve that warning? edit retag reopen merge delete ### Closed for the following reason the question is answered, right answer was accepted by Procópio close date 2016-04-28 11:13:42.182819 ## Comments I got a [WARNING] for the same (ompl isn't following the naming convention) while compiling https://github.com/ros-industrial-con... ( 2015-03-22 13:09:35 -0500 )edit ## 2 Answers Sort by » oldest newest most voted The error you're receiving indicates that a symbol from the OMPL library couldn't be found. This usually means that you're not linking against OMPL correctly in your CMakeLists Try linking against ${OMPL_LIBRARIES} instead of \${ompl_LIBRARIES}.

more

Thank you, it worked.

( 2014-07-22 04:16:34 -0500 )edit

For historical reasons, the convention for the OMPL version is non-standard: https://github.com/ros-gbp/ompl-relea...

This was done so that we have unique version numbers and can release OMPL for ROS outside of the regular OMPL release cycle. In the meantime things have stabilized much more, so I think we could start adopting a standard version. That said, we should probably switch to the debian package for OMPL directly (although, even for indigo, that is a bit old now).

more