pluginlib usage for registering plugins

[emersonknapp]

Is your feature request related to a problem? Please describe.

Right now, users need to provide (potentially long) explicit lists of plugin libraries to load, in order to extend the available node inventory.

navigation2 is one such user, that employs a fairly complex strategy to make sure all available plugins are loaded by the factory

• Its CMake renders a list of plugin library names to a header file as a compile-time constant
• That value is then used at runtime https://github.com/emersonknapp/navigation2/blob/main/nav2_bt_navigator/src/bt_navigator.cpp#L67 to load the plugins by name, with an optional parameter that contains a list of extra plugins that the user has requested

Describe the solution you'd like

Instead of all this extra accounting, we can increase flexibility by a lot by using pluginlib.

I have already built a fully functional solution, available at https://github.com/polymathrobotics/behaviortree_cpp_pluginlib/tree/main/behaviortree_cpp_pluginlib - this eliminates most of the complexity of getting arbitrary plugins into a behavior tree factory.

The package works fine standalone as it is, but I believe users would be served better by including this functionality in the behaviortree.cpp core and recommending it as the default plugin pattern. Do you agree? If so, how do you think that code fits into this repository?

1. Allows distributed export of any number of extensions, within a single library
2. Allows automatic discovery and loading of plugins by the factory, without any behaviortree.cpp-specific special accounting

See the README for the usage pattern proposed here.

Describe alternatives you've considered

One could write a custom plugin system with discovery, but it would be reinventing a lot of wheels that pluginlib/classloader already provide.

[Edwardius]

I second this, our team is using BT.CPP with many custom nodes, and having something to register nodes conveniently would be life-changing.

[robin-mueller]

Sounds very familiar. @emersonknapp your registration workflow with behaviortree_cpp_pluginlib looks very similar to what I've done: https://autoapms.github.io/auto-apms-guide/tutorial/implementing-behavior-tree-nodes#implementing-custom-behavior-tree-nodes

I believe sticking to pluginlib when using BehaviorTree.CPP together with ROS is the way forward. However, I don't know about that if the application is not tied to ROS.

[emersonknapp]

That's a fair point - this has usage outside ROS. Looking at your solution there, yeah very similar - but one key behavior that I wanted was that you don't need to link against the plugin-providing CMake target, because you discover it at runtime.

Making the distributed registration macro is definitely an incremental improvement though! Possibly we could contribute that core bit here, and have the pluginlib registration sit separate.