Version 7 (modified by vmatare, 7 years ago) (diff)



The Behavior Engine (BE) is a layer for development, execution, and monitoring of robot behaviors.

Information on the ROS port of the BE can be found at

The general idea is to have a fawkes thread maintain a user-defined hybrid state machine which is implemented in a LUA framework. The current state is maintained in the fawkes thread, which periodically re-evaluates transition conditions and advances the state accordingly. The BE is split into a purely reactive layer (the Skiller) and a higher-level layer (the Agent), which is meant to implement long-shot and strategic decisions. The main difference between them is the agent's ability to execute multiple skills concurrently in a single state. For a more in-depth conceptual description of the BE see this presentation.

The luadoc for the entire BE is currently in the GIT branch containing the new skiller backported from ROS.


Developing A Behavior Engine for the Fawkes Robot-Control Software and its Adaptation to the Humanoid Platform Nao
Diploma thesis describing the original Behavior Engine for Fawkes and its design principles.
A Lua-based Behavior Engine for Controlling the Humanoid Robot Nao
Conference paper describing the BE more concise, but less practical.
HERB 2.0: Lessons Learned from Developing a Mobile Manipulator for the Home
Journal article describing the bi-manual mobile manipulator HERB 2.0. Section V describes the BE ported to ROS.


Skills are aggregated into a common Skillspace, which needs to be defined in the /skiller/skillspace setting, for example:

INSERT INTO "config" VALUES('/skiller/skillspace','string','test','Skill space');

The skillspace is then initialized as a LUA module with the regular search order, usually in src/lua/skills. Since a skillspace will normally be comprised of multiple skills, it's common practice to put the skillspace module into a folder, e.g. src/lua/skills/test/, containing an init.lua which pulls in the other skill modules, e.g.:

-- init.lua: require all skill modules. Make sure the load order reflects their dependencies.
-- [...]

State types with required and optional arguments:

Skill Class Required Args Optional Args
JumpState? none none
SkillJumpState skills, final_to fail_to