py_trees icon indicating copy to clipboard operation
py_trees copied to clipboard

Loss of visibility when invalidating

Open stonier opened this issue 6 years ago • 1 comments

There are two cases for marking the status of a behaviour as INVALID:

  1. A higher priority interrupt
  2. A decorator or a parallel also sets INVALID on a running child if they themselves have gone to completion.

Subsequently, this overloaded definition causes problems when attempting to understand (especially visually) the state of a tree.

FYI @naveedhd

stonier avatar Jan 14 '19 02:01 stonier

The first case is not an issue - priority interrupt invalidation happens on the next tick and subsequently the executed behaviour has an opportunity for it's preceding status to be visualised.

Decorators and parallels however, can invalidate on the same tick as the one that executed the behaviour, leaving no opportunity for the result of that behaviour to be visualised. Logically it has to occur on the same tick to avoid leaving dangling runners, but this does cause a problem for debugging and introspection.

Classic example of why you cannot wait until the next tick to invalidate a parallel's running children on completion.

# Tick N - Parallel is Running
[-] Sequence with Memory [R]
  /-/ Parallel on One Success [R]
    --> Child 1 [R]
    --> Child 2 [R]
  --> Child 3 [-]

# Tick N+1 - Parallel Completes, leaving a runner behind
[-] Sequence with Memory [R]
  /-/ Parallel On One Success [S]
    --> Child 1 [R]
    --> Child 2 [S]
  --> Child 3 [R]

# Tick N+2 - Sequence skips straight to child 3
# Parallel runner has no chance to be invalidated
[-] Sequence with Memory [R]
  /-/ Parallel On One Success [S]
    --> Child 1 [R]
    --> Child 2 [S]
  --> Child 3 [R]

stonier avatar Jan 14 '19 02:01 stonier