Evaluate executive control frameworks

[nickswalker]

We've been discussing this for a couple of months. Now we're at decision time.

The last standing contenders are

• FlexBe
• RAFCON
• smach

I'll work with some of the simulation behaviors set up by @podshara @WxyElaine @EdanSneh, and discuss with folks who have read into the frameworks so we can hopefully make an appropriate choice by the time we need the inspection state machine.

[nickswalker]

To summarize past observations on these options:

• smach: very basic, code-based representation. Because states exist as Python classes, they can easily be created at runtime via metaprogramming. Not ROS dependent, but good wrappers around actionlib to make common uses simple. Visualization code is minimal and creaky. Authoring is through code. State machine level programming errors are usually caught by a runtime compile step. In use by many teams, including Villa and TUe.
• FlexBe: a heavy duty smach wrapper oriented towards shared control over a robot system. States are smach states, so they're still written as classes, but their execution is done in a polling paradigm (10hz calls to the execute method until the state decides it is done). State machines are persisted as generated Python code (example). Editing this code manually is dangerous as it may break the ability for the app to import it. An onboard execution manager projects a ROS interface for managing the run, and allows dynamic stopping/rerouting through states.
• RAFCON: States are written as standalone scripts with json metadata (example). State machines are stored as json files that describe the instantiation and connection of different states. Different levels of state hierarchy result in different levels of file system nesting. These files aren't exactly human readable, due to the use of IDs for unambiguous referencing of state instances. They provide a nice GUI for connecting and authoring state machines, as well as for interactively executing them. Nothing about this framework is tied to ROS. I've found one past @Home team that used RAFCON.

Updated thoughts:
Both FlexBe and RAFCON cross the threshold of making state machine authoring impossible without a GUI tool. I think this is a useful feature, as it'll stop some types of bugs. FlexBe keeps smach as the main state machine representation, which is double edged; it makes sure that the state machine is roughly human readable, but it does little for machine readability, as you'd still have to parse the source code to extract the structure and parameters. RAFCON state machines are hard to grok from the source code alone, but they're eminently machine readable with a nice JSON format.

I think we should use RAFCON, because we'll be able to build better tools around its representation.

Other factors:

• RAFCON's GUI is much nicer.
• They seem about equally popular, so there's a chance we'd be the largest public-facing user in both cases.

I've opened DLR-RM/RAFCON#31 to smooth over some grossness in how library states are stored, and will work towards implementing inspection with it.