search

rst-tu-dortmund / costmap_converter

A ros package that includes plugins and nodes to convert occupied costmap2d cells to primitive types
133 stars 104 forks source link

ROS2: Can't load Costmap Converter Plugins #20

Open dkuenster opened 4 years ago

dkuenster commented 4 years ago

With the current ROS2 and Navigation2 master I am unable to load any of the costmap converter plugins. I'm using the "ros2" branch of this repo and "ros2-master" of the TEB planner.

This is the error message I'm getting:

[controller_server-9] [INFO] [1590755915.374223651] [controller_server]: The specified costmap converter plugin cannot be loaded. All occupied costmap cells are treaten as point obstacles. Error message: MultiLibraryClassLoader: Could not create object of class type costmap_converter::CostmapToLinesDBSRANSAC as no factory exists for it. Make sure that the library exists and was explicitly loaded through MultiLibraryClassLoader::loadLibrary()

costmap_converterloader.getDeclaredClasses() returns:


[controller_server-9] Available Plugins: costmap_converter::CostmapToDynamicObstacles
[controller_server-9] Available Plugins: costmap_converter::CostmapToLinesDBSMCCH
[controller_server-9] Available Plugins: costmap_converter::CostmapToLinesDBSRANSAC
[controller_server-9] Available Plugins: costmap_converter::CostmapToPolygonsDBSConcaveHull
[controller_server-9] Available Plugins: costmap_converter::CostmapToPolygonsDBSMCCH

costmap_converterloader.isClassAvailable("costmap_converter::CostmapToLinesDBSRANSAC") returns true

but costmap_converterloader.getRegisteredLibraries() returns nothing.

dkuenster commented 4 years ago

The Problem seems to be related to http://wiki.ros.org/class_loader#Caution_of_Linking_Directly_Against_Plugin_Libraries. teb_local_planner directly links against the costmap_converter library containing the plugins.

If you restructure the code so that the base class of the plugins "BaseCostmapToPolygons" lives in the teb_local_planner package and remove linking against the costmap_converter library, it works again. costmap_converter then depends on teb_local_planner, instead of the other way round. This is the way it was done for the plugins of DWB for example.

croesmann commented 4 years ago

Thanks, I haven't dived in much yet, but it seems a bit cumbersome to move the plugins into the teb_local_planner package. For DWB it makes sense, because the plugins really belong to DWB, but in this case the plugins can be used completely independent from the teb_local_planner. E.g. also for the mpc_local_planner package.

dkuenster commented 4 years ago

You don't need to move all the plugins, just the base class of the plugins, so that you can instantiate the plugin loader without diretly linking against the library containing the actual plugins. The only problem then is that costmap_converter depends on the package using the plugins.

This is rather big breaking change however and requires changes in both repositories.