BehaviorTree / BehaviorTree.ROS2

BehaviorTree.CPP utilities to work with ROS2
Apache License 2.0
139 stars 58 forks source link

Having a Service node and Action node within the same ReactiveSequence #49

Open rebeccaRossRobotics opened 6 months ago

rebeccaRossRobotics commented 6 months ago

I'm currently refactoring our behavior trees to use these base classes in our merge to BTV4. Currently I've reached an issue where we have this ReactiveSequence

             <Sequence>
                <SubTree ID="DisableStopOnObstacle" _autoremap="true"/>
                <ReactiveSequence>
                    <Sequence>
                        <SubTree ID="CheckEStop" _autoremap="true"/>
                        <SubTree ID="CheckContinueMissionDocking" _autoremap="true"/>
                    </Sequence>
                    <DockingAction
                        action_name="/docking_action_server"
                        distance="-0.1"
                        linear_speed="0.03"
                        stop_at_charger="false"
                        stop_at_mag_marker="false"
                        target_id="{docking_id}"
                        allowed_time="30"
                        failure_if_no_success = "true"
                        level="{level}"
                        message="{message}"
                    />
                </ReactiveSequence>
            </Sequence>

Both the Subtrees CheckEStop and CheckContinueMissionDocking are service node calls. In our BT3.8 implementation this sequence would work because the service node calls would wait until the service had responded and then only return SUCCESS or FAILURE. However with this Service Node implementation a service node can now return RUNNING when waiting for a response. This is meaning that we cannot have a Service node and Action node within the same Reactive Sequence.

Is this expected behavior? If so, is there a way to have a service node and action node within the same Reactive Sequence?

facontidavide commented 5 months ago

That is very bad practice, in my opinion. You don't know at which frequency the Reactive node is running. It can be easily 100 Hz.

Requesting a state through ROS Services at that frequency seems very inefficient. You should reconsider your architecture, in my opinion.

pepeRossRobotics commented 4 months ago

Hello, just chipping in.

We currently have our own ways to throttle the number of service calls per second regardless of the loop execution frequency. This has cause us pain in the past.

What I think is the core of the issue is that the BTROS2 Service Node returns RUNNING which means that if we want to use a ROS2 service as a condition in a Reactive Sequence we would need to wrap the service call to wait until a response is given (and have a timeout in case service hangs). This could be in the form of having a bt_service_node_blocking.hpp version for this cases, or maybe other solution.

Just out of curiosity, what alternative do you recommend (when using a BT) to the use case of an navigation action server that needs to be checking for a condition using a service in case it needs to finish executing?

facontidavide commented 4 months ago

Just out of curiosity, what alternative do you recommend (when using a BT) to the use case of an navigation action server that needs to be checking for a condition using a service in case it needs to finish executing?

The problem is the frerquency at which you are checking this. Basically you are using ROS services to do polling, i.e. asking over and over again the value of a variable or state.

I think you should reason about why you implemented teh conditions in the first place.

In the case of the e-stop, I would rather use a ROS Topic Publisher that immediately updates any change in the state of the e-stop and substitute your service client for a ROS Topic Subscriber, using our wrapper.

facontidavide commented 4 months ago

Also, in version 4.6 of the library, I am introducing a new concept of "global blackboard". This could be a potential use case to solve this problem.

More details soon!