State Machines

and

BehaviorTrees

How to write unmaintenable and not reusable code 

1. Give a little of intelligence to each of your nodes
2. Hard-code values in your C++ code
3. 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:

1. They have primitives that simplifies the relationships between states/actions
2. 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)

1. They allow me to easely express fallback strategies
2. Are intrinsically hierarchical
3. Decorator "palette" is very useful.