splintered-reality / py_trees_ros

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

Weird selector issue constant tick #206

Closed ShrutheeshIR closed 1 year ago

ShrutheeshIR commented 1 year ago

Hello, thanks for this great package! I'm not sure if this issue is a py_trees issue or the py_trees_ros issue. I'm trying to use a selector node, with a ros service instead of an action client, (sort of as a precondition). The service is similar to the actions.py file, but just creating the necessary call changes.

I've inherited the service class, and then changed the status in the update by using the an attribute that is always returned by my service response_object.service_result as :

    def update(self):
        status = super().update()
        if status != py_trees.Status.RUNNING:
            status = py_trees.Status.SUCCESS if self.response_object.service_result else py_trees.Status.FAILURE
        return status

I can see that this update works fairly well.

I have a selector node S, of two conditions, A and B. Here is the sequence of actions that happens:

  1. S is ticked, and thus A is ticked. Since A has not sent any goal => a goal is sent. Thus status of S and A is RUNNING.
  2. S is ticked, status of S is RUNNING 2.1 A is ticked, and A returns failure (which is correct since my condition fails). In the update, status FAILURE is set and returned. A is set to be terminated with status FAILURE 2.2 B is ticked. It is first initialized with goal, and then goal is sent. Status of B is RUNNING Here's where it fails
  3. S is ticked, status of S is RUNNING. 3.1 A is ticked. Because of L437. Why should a failed node be ticked? This sets A to be RUNNING again, and the entire thing crumbles. This thus invalidates the goal B and is stuck in a loop.

I'm not sure if I am doing something wrong here.

Thanks

stonier commented 1 year ago

Discussion continuing in https://github.com/splintered-reality/py_trees/issues/412.