No version for distro foxy. Known supported distros are highlighted in the buttons above.
No version for distro dashing. Known supported distros are highlighted in the buttons above.

Package Summary

Tags No category tags.
Version 0.1.0
License MIT
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/dorezyuk/gpp.git
VCS Type git
VCS Version master
Last Updated 2021-02-18
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

The gpp_plugin package offers a pipeline for running global planners together with auxiliary pre- and post-processing functions

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

As you may already know (see the concept), we call all plugins loaded by the GppPlugin as its child-plugins and group those child-plugins in three groups (pre-, global-, and post-planning groups).

Now its time to understand how each group is executed.

for plugin in plugins:
    success = plugin.run()
    if(!success && plugin.on_failure_break):
        return False
    elif(success && plugin.on_success_break):
        return True
return default_value

Above is a pythonic pseudo-code, showing the loop for each plugin-group. The "plugin" above has three attributes - the method run in line 2, which is just pseudo-code for executing the plugin. Additionally it has the members on_success_break and on_failure_break (lines 3 and 5). These members are specific to every child-plugin and allow you to customize the behavior of your pipeline. You may have "optional" child-plugins or might be satisfied if only one child-plugins returns a successful result.
Finally there is a third unknown value: default_value at the last line. This boolean value allows you to specify for each group what should happen, if the for-loop runs through without "preemptive" termination.

Behavior-Tree-Relation

You may set all the on_failure_break, on_success_break and default_value freely. Nonetheless, it's maybe important to highlight that you can implement sequence and selector nodes known from behavior-trees with the mentioned parameters.

If all child-plugins within one group have on_success_break set to true, on_failure_break. set to false and the default_value set to true, you will get a sequence-node. If you invert the values, the group will behave as a selector-node.

flag sequence selector
on_failure_break true false
on_success_break false true
default_value true false

Parameters

Now its time to look at how to define and load child-plugins and groups. The groups begin with the tags pre_planning, planning and post_planning. The child-plugins for those groups must be defined as a list. The order within this list defines later on the order of the execution. Every child-plugin in these lists must have a type and name tag. Additionally you can pass boolean on_failure_break and on_success_break. Finally you may provide a boolean default_value for each group.

Below an example

pre_planning:
    - {name: foo, type: bar, on_failure_break: True, on_success_break: False}
    - {name: baz, type: bum, on_failure_break: True, on_success_break: False}

pre_planning_default_value: True

We load in our pre-planning group two child-plugins with the names foo and baz. The on_failure_break, on_success_break and default_value are chosen such that the groups acts as a sequence node.

Below the detailed documentation. The <pre_planning|planning|post_planning> tag means here, that you can define the parameter under each of those groups.

~<name>\/ (list)

List, as defined above.

~<name>\/\/name (string)

Name of the plugin. The name will be passed to the child-plugin.

~<name>\/\/type (string)

Type of the plugin. For the pre_planning group it must be resolvable to a plugin implementing the gpp_interface::PrePlanningInterface. For the planning group must be resolvable to a plugin implementing either nav_core::BaseGlobalPlanner or mbf_costmap_core::CostmapPlanner. For the post_planning group it must be resolvable to a plugin implementing the gpp_interface::PostPlanningInterface.

~<name>\/\/on_failure_break (bool, true)

Value defining if the group should break its execution if this child-plugin fails.

~<name>\/\/on_succuss_break (bool, false)

Value defining if the group should break its execution if this child-plugin succeeds.

~<name>\/_default_value (bool, true)

Default outcome of the group.

Example

Now we put the things together and create a dummy example for the GppPlugin. It assumes you are u


# this is for move-base-flex.
plugins:
    - {name: gpp_plugin, type: gpp_plugin::GppPlugin}

gpp_plugin:
    # we first define the pre_planning group. lets say all child-plugins are
    # optional and we may continue even if all child-plugins fail.
    pre_planning:
        - {name: pre_planner_name1, type: pre_planner_type1, on_failure_break: false}
        - {name: pre_planner_name2, type: pre_planner_type2, on_failure_break: false}
    pre_planning_default_value: True
    # now we define the planning group: we run both planners and take the first
    # successful result. if all planners fail, we fail
    planning:
        - {name: planner_name1, type: planner_type1, on_failure_break: false, on_success_break: true}
        - {name: planner_name2, type: planner_type2, on_failure_break: false, on_success_break: true}
    planning_default_value: False
    # finally the pose_planning group: we say that the post_planner_name1 is required,
    # the post_planner_name2 is optional.
    post_planning:
        - {name: post_planner_name1, type: post_planner_type1, on_failure_break: true}
        - {name: post_planner_name2, type: post_planner_type2, on_failure_break: false}
    pose_planning_default_value: True

CHANGELOG

Changelog for package gpp_plugin

0.0.1 (2021-01-27)

  • use default values
  • use mbf-msgs for mbf related constants
  • update documentation
  • add gpp_update_map
  • add gpp_prune_path example
  • formatting
  • update docs
  • disable spam in the test
  • Dima/dev
  • adjust doc
  • update documentation
  • Dima/tags
  • fix in simulation
  • adjust doc
  • extend the PluginGroup
  • rename ManagerInterface to PluginGroup
  • adjust doc
  • add missing include
  • add tags
  • add doc for the build step
  • Dima/docs
  • adjust constants
  • add doc
  • fix func-check
  • add doc
  • unify clang-format file
  • add licence
  • extend test
  • cleanup
  • refactor runPlugins
  • add warning
  • Dima/add mbf interface
  • move util function back to cpp
  • formating
  • clean up
  • fix bugs
  • flip default interface
  • add mbf-interface support
  • enable ci
  • disable problematic test
  • fix test
  • add tests
  • formatting
  • init
  • Contributors: Dima Dorezyuk

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at answers.ros.org

No version for distro melodic. Known supported distros are highlighted in the buttons above.
No version for distro kinetic. Known supported distros are highlighted in the buttons above.
No version for distro ardent. Known supported distros are highlighted in the buttons above.
No version for distro bouncy. Known supported distros are highlighted in the buttons above.
No version for distro crystal. Known supported distros are highlighted in the buttons above.
No version for distro eloquent. Known supported distros are highlighted in the buttons above.
No version for distro lunar. Known supported distros are highlighted in the buttons above.
No version for distro jade. Known supported distros are highlighted in the buttons above.
No version for distro indigo. Known supported distros are highlighted in the buttons above.
No version for distro hydro. Known supported distros are highlighted in the buttons above.