Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags.

Plugin Description Inheritance

Basic Inheritance

The plugin manager supports complex plugin definitions using an entire inheritance tree. For this purpose the tag import is used to signal to import all properties from the parent which may be overwritten afterwards by local values if given. The import tag applies also recursively. The example yaml config file used here can be extended to:

# PLUGIN DESCRIPTION FILE
my_concrete_plugin:
  type_class_package: my_concrete_plugins_pkg
  type_class: my_concrete_plugins_ns::MyConcretePlugin
  base_class_package: my_interface_plugins_pkg
  base_class: my_interface_plugins_ns::MyInterfacePlugin
  params:
    my_int: 42
    my_float: 3.14
    my_array: [1, 2, 3]

my_concrete_plugin_2:
  import: my_concrete_plugin    # Import properties from 'my_concrete_plugin'
  params:
    my_int: 2                   # Override param 'my_int'
    my_bool: True               # Adding new param

my_concrete_plugin_3:
  import: my_concrete_plugin_2  # Import properties from 'my_concrete_plugin_2'
  params:
    my_int: 3                   # Override param 'my_int' again!
    my_float: 4.2               # Override param 'my_float'

Application to Plugin Sets

In order to provide more convenient usage of the plugin system, the plugin manager supports to load namely plugin sets. A plugin sets is a composition of multiple plugins to be active (instantiated) when this set is loaded.

A plugin set is given as yaml file and must be loaded into the same namespace as the plugin manager lives. Such a plugin set has followig structure:

# PLUGIN SET FILE
plugin_sets:                            # Do not remove this line, all plugin sets ...
                                        # ... have to be loaded into this namespace
  my_plugin_set_A:                      # Name of first plugin set
    my_concrete_plugin: none            # Using my_concrete_plugin as is ...
                                        # ... (defined by plugin description config)
    my_plugin_1:                        # Name of customized plugin (import syntax)
     import: my_concrete_plugin         # Inherit properties from my_concrete_plugin ...
                                        # ... (defined by plugin description config)
     params:                            # Define/override additional parameters ...
                                        # ... (see plugin parameters)
       my_int: 1024                     # Overload 'my_int' with new value (previously 42)

    ...

  my_plugin_set_B:                      # Name of second plugin set
    my_concrete_plugin:                 # Using my_concrete_plugin as is (override syntax)..
                                        # ... (defined by plugin description config) ...
      params:                           # ... but overriding some params ...
        my_int: 256                     # ... e.g. here 'my_int'  (previously 42)

  ...

Note: Inheritance of plugin descriptions works as well within plugin sets.

This plugin set config file must be loaded into the same namespace as the plugin manager, e.g. via rosparam tag in a launch file (assuming it is located at config/plugin_sets.yaml):

   1 <rosparam file="$(find my_concrete_plugins_pkg)/config/plugin_sets.yaml" command="load" />

Plugin set can be simply loaded by calling directly one of following methods on the plugin manager:

   1 bool vigir_pluginlib::PluginManager::loadPluginSet(const std::vector<msgs::PluginDescription>& plugin_descriptions);
   2 bool vigir_pluginlib::PluginManager::loadPluginSet(const std::string& name);

The first one just handles the given list of plugin descriptions as plugin set while latter just loads the named plugin set as specified by the plugin set config file loaded into the rosparam server. Alternatively ros topics, service and action server are available as listed here.

Note: The plugin manager detects the difference of requested plugin set and all already instantiated plugins. Thus, it will spawn only new plugins and delete all instantiated plugins which are not given in the plugin set. All other plugins will not be touched.