Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export plugins to share directory & register CrossDoor plugin #804

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

MarqRazz
Copy link
Contributor

This PR is proposing to export the plugins to the package_name/share directory to make it easy for other ROS packages to find the plugins. It also adds the registration function to the CrossDoor example.

@facontidavide
Copy link
Collaborator

looks goot to me. waiting for CI to become green

// a plugin that can be loaded at run-time
BT_REGISTER_NODES(factory)
{
static CrossDoor cross_door;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you think of a better pattern to show here that keeps this object in scope (same thing here)? I plan to make lots of Behaviors that share objects (to keep them from being duplicated across multiple behaviors in the tree) and feel like there might be a better way than making them static.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, I don't believe this is a good pattern. You should probably create the object "outside" and pass it as an argument.

Let me think about it and propose a different pattern

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To continue with my general executor I'm proposing here I think we would need the option to transfer the ownership to the factory, or something else within BT.CPP, to keep if from requiring prior knowledge of objects the Behaviors need while loading plugins.

I'm not sure how similar this situation is but one pattern that comes to mind is in MTC. When assembling tasks you create an object to store stages and then add/move unique pointers the user creates to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants