Motivation
Robotic systems often need to be configured for different dynamic execution environments,
hardware, or non-functional properties, such as energy consumption. Configuration options, a.k.a.
features, can be used to enable, disable, and calibrate (i.e., tweak or fine-tune) different parts
of the system, ranging from whole subsystems over components to lines of code. While configuration
mechanisms are abundant in robotics, they are limited in expressiveness and the configuration files
are often distributed over the codebase in different artifacts, challenging the consistent declaration
and enforcement of dependencies. In addition, robotics systems require flexibility, since features need
to be activated or changed at different times in the lifecycle of the system, which can cause
intricate dependencies, especially when they depend on other static or dynamic features. To prevent
misconfiguration and undefined behavior, such configuration spaces need to be properly declared and
managed. We present featX, a model-based configuration technique. It uses and extends feature models,
but account for the specific needs in robotics. Specifically it allows declaring features, their
dependencies, as well as the allowed binding times and binding modes, while the configurator enforces
correct configuration and reconfiguration, considering intricate semantics of such models.
FeatX Binding Technique
Our proposed reconfiguration technique requires selecting and deselecting dependent features that may
be changeable (dynamic) or unchangeable (static) at compile time (early) or at runtime (late) i.e., time
and mode bindings.The ability to configure features either as static or dynamic, and parts of the
underlying semantics are inspired by the three-state-logic-based semnatics of the Linux Kconfig language.
Both time and mode binding are combined as follows:
Binding Combinations
1. static late - Feature loaded at compile or startup time and cannot be unloaded until program execution ends.
2. static late - Feature loaded at runtime but cannot be unloaded until program execution ends.
3. dynamic early - Feature is loaded and built into the system beforehand at compile/startup time
but can be reconfigured on demand at runtime.
4. dynamic late - Feature is loaded at runtime and can be reconfigured as many times as possible at runtime.
Binding Rationales
R1: If a feature is not selected than the feature on which it depends can have any configuration.
R2: If a feature is selected then the feature it depends on needs to be static while R3 also holds.
R3: If a feature is not only selected but also bound early this means that the feature it depends on
needs to also be bound early and R2 needs to hold.
R4: If a feature X is selected and excludes feature Y then feature Y is cannot be selected. However,
the binding time and binding mode are not restricted by this relation
Concrete Syntax of Feature and Configuration Entries
Feature Definition Entry
{
"name": "navigation",
"group": "",
"isOptional": false,
"includes": "",
"excludes": "",
"bindingTimeAllowed": "Early",
"bindingModeAllowed": "Static"
}
Configuration Entry
{
"name": "navigation",
"isSelected": true,
"bindingMode": "Static",
"bindingTime": "Early"
}
Check appendix for detailed abstract syntax and semantics
Example of a Robot Modelled in featX
Click here to download full featX model and configuration files of the robot above, based on the binding combinations and rationales stated.
See our demo video on how this example modelled in featX was used to control configuration and re-configuration in a warehouse simulation