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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

Package Description

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

Additional Links

No additional links.

Maintainers

  • Dima Dorezyuk

Authors

No additional authors.

GppPlugin

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

Now its time to understand how each group is executed.

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

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

Behavior-Tree-Relation

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

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

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

Parameters

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

Below an example

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

pre_planning_default_value: True

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

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

~<name>\/<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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Messages

No message files found.

Services

No service files found

Recent questions tagged gpp_plugin at Robotics Stack Exchange