Abstract

This tutorial will show you how to use configuration files within bundles and how to apply configurations to compositions and components.

Presentation

Configuration files are YAML files in which the properties are listed and some values are assigned to them. For instance, when looking at the interface of the random motion generator:

[...er/bundles/tutorial]% rock-inspect --show-tasks tut_brownian                
==========================================================
Task name:  tut_brownian::Task
defined in tut_brownian
----------------------------------------------------------

  ------- tut_brownian::Task ------
  no documentation defined for this task context model
  subclass of RTT::TaskContext (the superclass elements are displayed below)
  Ports
    [out]cmd:/base/MotionCommand2D
    [out]state:/int32_t
  No dynamic ports
  Properties
    max_angular_speed:/double, default: 0.314159265358979
    max_speed:/double, default: 1.5
    min_speed:/double, default: 0.5
    straight_duration:/double, default: 5
    turn_duration:/double, default: 5
  No attributes
  No operations

We have 5 properties that configure our component. Let’s use a non-default value for the max_speed.

First, let’s use a tool to generate a file filled with default values. To do this, we first create configuration directory for our oroGen components in bundles/tutorials and then use the tool oroconf to generate default configuration files with the option:

mkdir -p config/orogen

oroconf extract tut_brownian::Task --save config/orogen/

The YAML files in config/orogen/ must follow the modelname.yml template to be picked up by the system. In this case, the generated file has automatically be called tut_brownian::Task.yml

Have a look at the freshly created config/orogen/tut_brownian::Task.yml, and compare it to the values reported by rock-inspect.

Start a controller with ‘random’ deployed by default

rock-roby run scripts/rockRoby3.rb random

Have a look at the configuration values:

rock-display brownian

Defining multiple configurations

In the configuration files, one can define multiple configuration blocks by giving them names. Let’s add two new configurations. Change config/orogen/tut_brownian::Task.yml to look like:

 --- name:default
 # no documentation available for this property
 max_angular_speed: 0.314159265358979
 # no documentation available for this property
 max_speed: 1.5
 # no documentation available for this property
 min_speed: 0.5
 # no documentation available for this property
 straight_duration: 5.0
 # no documentation available for this property
 turn_duration: 5.0
 --- name:slow
 max_speed: 0.5
 min_speed: 0
 --- name:fast
 max_speed: 4
 min_speed: 2

The general concept here is that, by default, the ‘default’ configuration is applied. Configuration overlays can then be selected, where the parameters defined by some sections are overriden by other. For instance, the ‘default,slow’ configuration contains all values from default except for max_speed and min_speed that are set to the values in the ‘slow’ configuration.

When defining a deployable task or adding it, a configuration is selected with

define('random', Cmp::RockControl).use(TutBrownian::Task.use_conf('default', 'slow'))

One can also define configurations on compositions. Composition configurations forward configurations to children. For instance, the following declaration announces that Cmp::RockControl has a ‘slow’ configuration, in which the ‘cmd’ child (the Srv::CommandGenerator) should be configured with ‘default,slow’. The configuration of the RockTutorialControl task is left open.

composition 'RockControl' do
  # Any command generator
  add Srv::CommandGenerator, :as => "cmd"
  # And one rock
  add RockTutorial::RockTutorialControl, :as => "rock"
  # Create any unique possible connection. If ambiguities
  # exist, an error is generated
  autoconnect

  conf 'slow', 'cmd' => ['default', 'slow']
end

Advanced The configurations are part of the deployment constraints. This means, in practice that if two deployments request a task to be deployed with two different configurations, the deployment will fail.

There is, for now, no ways to select configurations from the shell.

Summary

In this tutorial you learned:

• how to generate configuration files
• how they are used by the system management layer (in particular, how the “default” section is picked up automatically)

The next tutorial will introduce you to handling some more complex setups.