Infinite loop when checking requirement satisfaction fails in wait_atstart

[devis12]

Hi, I believe that with the last commits an error has been introduced and it concerns the following file plansys2_executor/behavior_tree/wait_atstart_req_node.cpp. I think that when the check fails, it should return BT::NodeStatus::FAILURE;.

I'll attach below an example with pddl domain, actions implemented as in your simple_example, commands to be given at start in the plansys2_terminal and at some point in the execution (e.g. after the first put_on_carrier successfully completes) to make the second put_on_carrier execution fail. If you use the current latest version from the master branch, it'll loop over the failed check requirements. With the modification suggested above, the problem does not arise: maybe other does, I apologize in that case for the wrong suggestion, but I currently don't have a full, detailed picture of everything that's happening under the hood when the generated bt is executed.
Commands are in the pddl folder of the attacched ROS2 rclcpp pkg (note: give the two below run in a second plansys2_terminal in the timespan specified above).
Hope this helps!

blocksworld_raw.zip

[fmrico]

Hi @devis12

This BT node was designed not to check but for waiting (returning RUNNING) until the requirements are ready.

Why do you think that the behavior previous to the last commits was different?

Thanks!!

[jjzapf]

Hi @devis12. I made some of the recent commits and would like to help fix this problem if there is a new bug. Could you provide your terminal output for the launch and plansys2_terminal terminals? I was not able to replicate the error you are seeing. On my machine, the example was able to successfully finish. I've provided the outputs for my terminals for comparison.

launch_terminal.txt
plansys2_terminal.txt

[devis12]

Hi, sorry for the delay in the answer, but github did not send me any email notification as I'm used to.

Ok @fmrico I understand, but what is supposed to happen then when the requirements are never going to be satisfied? I think the plan should just fail (or at least after a number of checks)... Otherwise you'd have an infinite loop at that point.

@jjzapf I provide you with the logs of the launch file, the first plansys2_terminal and the second one in which I change at run time the position of the carrier_a in order to make the requirement at start of (gripper_put_on_carrier gripper_a box_a1 carrier_a base_a) fail. I don't think you did as I suggested above, since your plan execution is successful (it's supposed to fail!).
NOTE: the check at some point stops looping, simply because I press ctrl+C

launch.txt
psys2_terminal_1.txt
psys2_terminal_2.txt

Additional note which I forgot to mention: I typically work on a plansys2 instance with groot monitoring disabled

[devis12]

To give you a little bit more of context, as you @fmrico probably already know, at the University of Trento we're working on a BDI framework for ROS2 and PlanSys2 invests a really important role in the computations and executions of plans. We were working on a demo with webots and we've realized of this issue which I've never encountered before in similar scenarios; I've simply "solved" it just with the above suggested modification, but as I've understood (and I imagined also at the time) is not the way to go.

Here the video of the demo https://www.youtube.com/watch?v=zB2HvCR5H9E (in the second run, you see that the gripper is forced to replan... without the modification above, it just got stuck)

[fmrico]

Hi @devis12

@jjzapf and @roveri-marco and I are having a meeting this week related to this issue.

By now, the subtree that executes a single action is using a BT node WaitAtStartReq. Maybe we could change WaitAtStartReq for a custom BT that fails after a timeout...

I am very happy to see your videos, and see that PlanSys2 is useful for your research 😃