BehaviorTree.ROS2 icon indicating copy to clipboard operation
BehaviorTree.ROS2 copied to clipboard

Having a Service node and Action node within the same ReactiveSequence

Open rebeccaRossRobotics opened this issue 1 year ago • 4 comments

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?

rebeccaRossRobotics avatar Feb 19 '24 11:02 rebeccaRossRobotics

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.

facontidavide avatar Apr 05 '24 12:04 facontidavide

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?

pepeRossRobotics avatar Apr 09 '24 15:04 pepeRossRobotics

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 avatar Apr 24 '24 13:04 facontidavide

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!

facontidavide avatar Apr 24 '24 13:04 facontidavide