splintered-reality / py_trees_ros

ROS extensions and implementations for py_trees
Other
143 stars 40 forks source link

Usage of kwargs in setup? #209

Closed haudren-woven closed 1 year ago

haudren-woven commented 1 year ago

Hello,

First of all thank you for creating such a nice library!

I had a question regarding the usage of kwargs in the setup method on tree objects. In regular py_trees, one can pass arbitrary keyword arguments to the setup method. I was using this to pass an expensive to construct object to all behaviors in the tree. However the signature of setup in py_trees_ros.trees.BehaviorTree does not allow to pass arbitrary keyword arguments. This seemed like a minor inheritance violation since the ros version of the tree is more restrictive than the non-ros version, but I also notice that all examples in the doc do not use **kwargs in their setup at all.

Thus, how should I handle this sort of "global" initialization? I suppose the other way is to use a blackboard variable, but since it's used by pretty much every node in the tree, I'm a little worried it will clutter a lot the tree.

Thanks!

stonier commented 1 year ago

Oversight, I think.

This went in quite some time ago to handle non-ros use cases and we may just have forgotten to propogate it to the ros use case.

It's worth noting that ROS use cases typically do not need it since individual behaviours can easily setup indirectly from ros1/ros2 params. Having said that, you could have a ros tree with many non-ros behaviours that you'd like to configure (in which case the script building the tree would do ros param lookups and pass it in).

What setup are you doing that prefers kwarg injection over ros param lookup?

haudren-woven commented 1 year ago

Yes, so the issue is that I'm constructing an external connection to another (non-ROS) system, and I'd like to use it to send messages inside the behavior. I can of course work around that by constructing a ROS node that relays messages to that other system, but it's quite a lot of boilerplate for little benefit... So params wouldn't be enough since I need to share a Python object across the various states.

stonier commented 1 year ago

Tracked in #211, closed by #212.