DONE --- condition should probably just call fiacre external, not hippo task.

DONE --- when a seq or fb is halted, what should be the next child? fix it in the code... because for now, I think it is "undefined"

--- add a loop keyword for top BT to execute them repeatedly... (but is this a good idea?).

DONE --- the success or failure cannot be reached is misleading in the frac trace... change the model to avoid it
    (based on the halted behavior).

--- Not clear if the RateController implementation is correct... a
    local counter is not quite following the main tick, as the node may not be ticked each time... May be
    better to add a timer process on the side which flip a shared flag with its own counter.

--- Cleanup in drone.c the rqstid and the halting... things seem to mix up with rqstid == -1 or not.

--- spit get_SV_value in arg list when we have a $sv variable
    also spit the function in hippo_app_functions.c (or ask again Bernard or PEH)

---- properly handle input and output args to btnode.
 - args should be defined in proper Fiacre struct...
 - they can be passed to subtree and result can also be returned back... but what can we do with these results? just pass them to other BTs?
 - BT are not properly handling args and values... and have no functions for this... 

DONE --- implement the ros2 nav2 new nodes:
  - control nodes
    - Recovery, 2 sons a and b, when a fail, b attempted... if b succeed, back to a... when both fails, the node
      fails. Node succeeds when *a* succeeds. (# of retries can be specified)
    - PipelineSequence, when a child returns running, restart from the beginning of the seq. If any returns
      failure, fails and halt any running. Success progress and is kept in memory of the Pileline.
      If the last node succeed, then success (and halt any runnings).
    - RoundRobin ex, a, b and c tick each of them in turn. A child running, back to this child. a child fail,
      try the next one. One return success, on the next call, tick the next
      node... keep going until all nodes return failure. Success lead to next node on the next call. (I do
      not see how something could be running and thus halted on success, nor failure... )
  - decorator nodes
    - RateController passes the tick only when rate has been reached, running othewise.
    - SingleTrigger (not done because does not show in the examples)

DONE --- use halt instead of kill as others (e.g. Armando Tacchella) are using halt. No need to add confusion on something already "unclean".

DONE --- add some verif "target" with the halted state.

DONE ---- btn returned status is accessible from anywhere. btn_name.rstatus can be used in Eval expression. BTN name must be unique, for example camera_track in the drone example.

DONE ---- handling the running left running (when a "running" child has been left running...), e.g. in // branch and upward

DONE - kill (pass somehow a kill flag to kill them, and wait for failure).

DONE --- variables... $global based on state variable (enumeration and int), they can be passed in :args , they can be set, computed, etc in expr using Fiacre "compatible" expression.

DONE --- eval expression (similar to condition) with simple computation... 
 Eval node (like condition), just eval the expression and set the .res

DONE --- Graphical trace of the BT execution.

DONE ---- handling the running left running (when a "running" child has been left running...), in // branch

DONE For // branch, as soon as failure or success have been decided, how do
we handle the running left (if any).  if the :wait flag is true (1),
retick the running, and loop until each running return either success
or failure (this is done without returning from the current bt) if the
:wait flag is false, we do not wait (running branches), if the bt is
run again, this could/would be rather messy. The kill should help solving the pb.

DONE ---- success/failure with x children

Parallel and ParallelAll now properly report succes and failure
according to the :success needed number (all for ParallelAll), when
some running are reported, only these are called again.

DONE ---- 1 Fiacre tick per BT cycle or 1 tick per node or 1 per ation (the default)

Set the semantics of BT/Fiacre time ticks.

- BT, only the top level tree increment the tick, the rest of the tree
  is in the same tick (do not use this when model checking)
- ACTION, add to the previous item that Action AND Condition takes one tick (this will
  ensure that sequences of action/condition are properly executed in the order they are defined.
- NODE, we increment by one tick for each NODE traversed/executed

Beware, BT will probably create problems with sequences, or fallback
executing too many nodes in no time, destroying the semantics of
sequences and fallbacks.
