FlexBE

Getting Started

The following tutorials will help you to familiarize with FlexBE and learn to effectively use it. Since FlexBE is very versatile and offers a lot of options depending on what you want to realize, it is not required to complete all of the tutorials before starting to work productively. After you have a general understanding of how things work (the first block of the tutorials), feel free to just use and explore FlexBE on your own. Come back here to learn more about certain details whenever required.

Missing advanced tutorials will be completed soon. Please simply contact me for support until then.

Basic Tutorials (recommended, ordered)

• System Configuration
• Creating a New Behavior
• Using the Statemachine Editor
• Execution of a Behavior
• Developing Basic States

Advanced Tutorials (choose as required, independent)

• Developing Actionlib States
• The State Lifecycle
• Writing State Tests Using flexbe_testing
• State Design Discussions
• Behavior Design Discussions
• Parallel State Execution
• Advanced GUI Tools
• Running Behaviors Without Operator
• Integrate Data Input for Behaviors
• Behavior Synthesis Interface

Component Overview

The behavior engine itself consists of the following ROS packages:

• flexbe_core
  Contains the core part of the behavior engine, such as the state inheritance chain and proxy publishers/subscribers.
• flexbe_input
  Provides a communication channel between the onboard behavior executive and any custom user interface for providing data during runtime.
• flexbe_mirror
  Models the running oboard behavior on operator-side and abstracts from the communication protocol by providing complete information.
• flexbe_msgs
  Message definitions for communication between FlexBE packages.
• flexbe_onboard
  Implements the onboard behavior executive and handles the application of runtime modifications.
• flexbe_states
  Provides a collection of system-independent default states to be used in any behavior.
• flexbe_testing
  A unit-testing framework for single states.
• flexbe_widget
  Provides utility scripts, e.g., to run the user interface, start behaviors, or create a new behaviors repo.

Furthermore, the following ROS packages are recommended or expected to reside in the high-level control repository for your project:

• flexbe_behaviors (required)
  Holds all the behavior manifests and refers available behaviors. This packages is generated automatically when you use the create_repo script.
• flexbe_[project]_states
  Similar to flexbe_states, you can create such a package holding all your custom implemented states and test cases.
• flexbe_launch
  It is recommended to bundle all custom nodes and configuration files for behavior execution in launch files if things get more complex.
• behavior_[name]
  Each behavior is generated as an own ROS package. In the Configuration view of the user interface, you can set a namespace for your behaviors if required.

Communication

The following figure gives an overview of all ROS topics involved in communicating between the onboard behavior executive and the ROS nodes running at the operator control station (OCS).

Evaluation of Behavior Logfiles

All behaviors record their execution in log files located in a "~/logs/" folder on the robot. These textfiles have a structure which can be evaluated by an online tool for FlexBE Logs. This tool currently is in a prototype stage and will be linked here as soon as it approved for public release. For now, in addition to the online tool for evaluation, a simple evaluation script is available for generating tables based on the respective log file:

rosrun flexbe_widget evaluate_logs