No version for distro humble showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro jazzy showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro kilted showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro rolling showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro ardent showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro bouncy showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro crystal showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro eloquent showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro dashing showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro galactic showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro foxy showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro iron showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro lunar showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro jade showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro indigo showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro hydro showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro kinetic showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

No version for distro melodic showing noetic. Known supported distros are highlighted in the buttons above.
Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange

Package symbol

gpp_plugin package from gpp repo

gpp_prune_path gpp_update_map gpp_interface gpp_plugin

ROS Distro
noetic

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
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

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>\/<pre_planning|planning|post_planning> (list)

List, as defined above.

~<name>\/<pre_planning|planning|post_planning>\/name (string)

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

~<name>\/<pre_planning|planning|post_planning>\/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>\/<pre_planning|planning|post_planning>\/on_failure_break (bool, true)

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

~<name>\/<pre_planning|planning|post_planning>\/on_succuss_break (bool, false)

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

~<name>\/<pre_planning|planning|post_planning>_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

File truncated at 100 lines see the full file

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

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange