Catkin_lint error with nodelet plugin
Hello,
I am trying to clean my CmakeList.txt
and package.xml
of my project and I've found the tool catkin_lint
, which is really useful. I could clean most of the warning and errors I initially get.
I have no issue with my project when compiling and/or running it but yet the command catkin_lint -W2 src/
always give me those errors :
kobuki_node: error: nodelet plugin file 'plugins/nodelet_plugins.xml' is not installed to ${CATKIN_PACKAGE_SHARE_DESTINATION}
kobuki_safety_controller: error: nodelet plugin file 'plugins/nodelet_plugins.xml' is not installed to ${CATKIN_PACKAGE_SHARE_DESTINATION}
yocs_velocity_smoother: error: nodelet plugin file 'plugins/nodelets.xml' is not installed to ${CATKIN_PACKAGE_SHARE_DESTINATION}
For my project I use those three nodelets and also a cmd_vel_mux
. The difference between the nodelet cmd_vel_mux
and the three other nodelets is that I added the packages kobuki_node
, kobuki_safety_controller
and yocs_velocity_smoother
directly to my src/
folder (because I needed to modify them) and not cmd_vel_mux
so I think it's the reason of my issue but I can't find it when comparing the CmakeList.txt
.
Here's mine for the kobuki_node
:
cmake_minimum_required(VERSION 2.8.3)
project(kobuki_node)
find_package(catkin REQUIRED COMPONENTS
angles
diagnostic_msgs
diagnostic_updater
ecl_exceptions
ecl_sigslots
ecl_streams
ecl_threads
geometry_msgs
kobuki_driver
kobuki_ftdi
kobuki_keyop
kobuki_msgs
nav_msgs
nodelet
pluginlib
roscpp
rospy
sensor_msgs
std_msgs
tf)
catkin_package(
INCLUDE_DIRS include
LIBRARIES kobuki_ros kobuki_nodelet
CATKIN_DEPENDS
angles
diagnostic_msgs
diagnostic_updater
ecl_exceptions
ecl_sigslots
ecl_streams
ecl_threads
geometry_msgs
kobuki_driver
kobuki_ftdi
kobuki_keyop
kobuki_msgs
kobuki_safety_controller
nav_msgs
nodelet
pluginlib
roscpp
rospy
sensor_msgs
std_msgs
tf
)
include_directories(include ${catkin_INCLUDE_DIRS})
add_subdirectory(src)
install(DIRECTORY image
DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
)
install(DIRECTORY include/${PROJECT_NAME}/
DESTINATION ${CATKIN_PACKAGE_INCLUDE_DESTINATION}
)
install(DIRECTORY launch
DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
)
install(DIRECTORY param
DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
)
install(DIRECTORY plugins
DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
)
install(PROGRAMS scripts/getOdom2D.py
scripts/getYaw.py
DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}
)
#This is what I thought could solve the issue
install(FILES plugins/nodelet_plugins.xml
DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
)
Do you have an idea how to get rid of those error maessages ?
Are you linking directly against anything in
kobuki_safety_controller
?Or are you just using that nodelet and load it into a nodelet manager?
If you're not linking against that library, then it should not appear in your
find_package(catkin ..)
statement and should only be anexec_depend
.You're right I'm just using the nodelet with a nodelet manager, I've edited the code but the issue is still the same.
You still have it listed in your
CATKIN_DEPENDS
.The same goes for all the other nodelets you're using. None of them are
build_depend
s, so none of them should appear in yourCMakeLists.txt
.Also: you can merge all the
install(DIRECTORY ..)
statements into a single one.Edit: are you linking
kobuki_driver
? If not, remove that as well.I'd review everything that you have in your
CMakeLists.txt
: anything that you don't link against -> remove. It's only anexec_depend
.I must say that re-reading your question I understand less and less: are you editing the
CMakeLists.txt
of your own work or of the pkgs that come from the Kobuki repositories?Well I added the packages from the Kobuki repositories in my workspace and I've modified only the source files (minor edits) but not the
CMakeLists.txt
. And I was surprised to see errors when runningcatkin_lint
so I wanted to correct them.The original package (
kobuki_node
) does in fact appear to link those nodelets, so that's probably why they are listed in thefind_package(catkin ..)
andcatkin_package(..)
calls.If these are not issues in your own package(s), I would suggest to report them and/or fix and PR them.
Okay I will do that then, thank you for the support.