State Machines
and
BehaviorTrees
How to write unmaintenable and not reusable code
- Give a little of intelligence to each of your nodes
- Hard-code values in your C++ code
- In general, use ROS Nodes, params, topics and actions without asking you why uou are doing it
What Herman would say...
The 5Cs of the separation of concerns
The goal of a State Machine framework is to
ISOLATE and CENTRALIZE
the Coordination from the rest of the code.
This considerably improves:
- Re-usability
- Maintanability
- Debugging
BehaviorTrees are an alternative way to write state machines
Differences:
- They have primitives that simplifies the relationships between states/actions
- Geometrical representation has a semantic meaning
Main elements of BT
The actions are only the leaf of the tree
Any node can have the state
FAILS, SUCCESS, RUNNING
Composite Node: Sequence
"Execute the sequence of actions until one FAILS.
If all SUCCEED, the Sequence SUCCEEDS.
If any FAILS, the sequence FAILS"
Composite Node: Selector
"Execute the sequence of actions until one SUCCEEDS.
If all FAIL, the Selector is FAILS.
If any SUCCEEDS, the sequence SUCCEEDS"
Decorators
Node with a single child. It is a front-end to the child.
For example:
- Inverter
- RepeatUntilTrue
- Repeat_N_Times
- AlwayTrue, AlwaysFalse
- Etc.
Naturally suited for hierarchical composition
Naturally suited for hierarchical composition
If you think this is complicated, imagine if this "intelligence" was hidden inside several ROS nodes...
Why I like them... (#IMHO)
- They allow me to easely express fallback strategies
- Are intrinsically hierarchical
- Decorator "palette" is very useful.
State Machines
By Davide Faconti
