ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Load plugin where base class exists in another project

asked 2017-06-27 14:08:09 -0500

jlack gravatar image

updated 2017-06-28 08:48:20 -0500

I'm having some trouble loading a plugin and decided to open an issue to see if it's even possible. I am creating package_B where i'm creating a class that implements a plugin base class that exists in package_A.

Also, somewhere in package_A, they call loader->createInstance(plugin_type). When plugin_type equals the plugin i've created in package_B, it fails saying the plugin doesn't exist. But when the plugin type is one of the plugins created/exported from package_A, it works just fine. I feel like maybe pluginlib isn't built to do what i'm trying to make it do. Thoughts?

<?xml version="1.0"?>
<package format="2">
<description>The test package</description>

<maintainer email="">Jordan Lack</maintainer>



    <test plugin="${prefix}/plugins.xml" />

And here's my CMakeLists.txt

cmake_minimum_required(VERSION 2.8.3)

find_package(catkin REQUIRED hmi_cmake hardware_interface roscpp cmake_modules pluginlib 

find_package(TinyXML REQUIRED)
find_package(Boost REQUIRED)
find_package(Eigen3 REQUIRED)

# check c++11 / c++0x
check_cxx_compiler_flag("-std=c++0x" COMPILER_SUPPORTS_CXX0X)
    set(CMAKE_CXX_FLAGS "-std=c++0x")
else ()
    message(FATAL_ERROR "The compiler ${CMAKE_CXX_COMPILER} has no C++11 support. Please use a 
different C++ compiler.")
endif ()

    INCLUDE_DIRS include
    CATKIN_DEPENDS hardware_interface roscpp pluginlib transmission_interface
    DEPENDS TinyXML Boost Eigen3

include_directories(include ${catkin_INCLUDE_DIRS} ${TinyXML_INCLUDE_DIRS} ${Boost_INCLUDE_DIRS} 

add_library(${PROJECT_NAME} src/sensor_parser.cpp src/transmission_interface_loader.cpp)
target_link_libraries(${PROJECT_NAME} ${catkin_LIBRARIES} ${TinyXML_LIBRARIES} ${Boost_LIBRARIES})

install(DIRECTORY include/${PROJECT_NAME}/


install(FILES plugins.xml

add_library(test_plugins test/test_plugins.cpp)
target_link_libraries(test_plugins ${catkin_LIBRARIES} ${PROJECT_NAME})

install(TARGETS test_plugins

And finally my plugins.xml

    <library path="lib/libtest_plugins">
    <class type="test_namespace::TestActuatorPlugin" base_class_type="test_namespace::Actuator">
            An actuator plugin for unit testing

    <class type="test_namespace::TestImuPlugin" base_class_type="test_namespace::Imu">
            An imu plugin for unit testing
    <class type="test_namespace::TestForceTorquePlugin" base_class_type="test_namespace::ForceTorque">
            A force/torque plugin for unit testing
    <!--This next plugin is the one that ros_control can't load-->
    <class type="test_namespace::MyRequisiteProvider" base_class_type="transmission_interface::RequisiteProvider">
            A force/torque plugin for unit testing
edit retag flag offensive close merge delete


I can confirm if I build ros_control from source and put my plugin in ros controls ros_control_plugins.xml it loads successfully. I feel like it has to be possible with my plugin in a different package. Isn't that how Gazebo loads other peoples Gazebo plugins? oh package_A is ros_control

jlack gravatar image jlack  ( 2017-06-27 14:58:14 -0500 )edit

If I understand the description of your setup correctly then this should be fully supported, but whether it'll be succesful depends on your package.xml and CMakeLists.txt being correct. Could you edit your question and include both? Use the Preformatted Text (101010) button.

gvdhoorn gravatar image gvdhoorn  ( 2017-06-28 02:16:42 -0500 )edit

ok @gvdhoorn I have added the requested bits.

jlack gravatar image jlack  ( 2017-06-28 08:51:00 -0500 )edit

In order to be considered a plugin for something, your plugin needs a run_depend on that something. I can't really say whether that is the case here. See #q163476 for a related question.

gvdhoorn gravatar image gvdhoorn  ( 2017-06-28 10:16:14 -0500 )edit

Since this is package.xml format 2, the <depend> tag should mean both <build_depend> and <run_depend> I believe. However your link raised a different question. In my package.xml, should my export line be<transmission_interface plugin="${prefix}/plugins.xml" />?

jlack gravatar image jlack  ( 2017-06-28 11:14:01 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2017-06-28 11:36:30 -0500

jlack gravatar image

Ok I finally figured out what's going on. The problem is in the package.xml, since the base class for my plugin lives in transmission_interface, the export line in the package.xml needs to read

    <transmission_interface plugin="${prefix}/plugins.xml" />

The pluginlib documentation does state this is the case. I just hadn't read that part.

edit flag offensive delete link more


re: depend being both run_ and build_ depend: you're right, that is correct.

re: export line: that was going to be my next comment.

Glad you got things to work.

gvdhoorn gravatar image gvdhoorn  ( 2017-06-28 13:12:27 -0500 )edit

Question Tools


Asked: 2017-06-27 14:08:09 -0500

Seen: 645 times

Last updated: Jun 28 '17