Inseguridad en el consumo

4.2

Configuration and Parameter Management

Robotic applications need to be flexible, reconfigurable and adaptable to dif- ferent scenarios, robot platforms etc. The reuse of modules and components in large-scale software applications usually requires the adaptation and adjustment of a large set of parameters in order to successfully adjust the configuration, the behavior, and the performance of the autonomous mobile system to the new target environment. There are several sources of configuration parameters in robot control programs and robotic algorithms

• Different robot types vary in shape and sensor configuration, but also different robots of the same type tend to vary slightly. Some robots, for instance, are equipped with further sensor or actuator devices not present in the standard configuration. Also, damage and repair of a robot’s parts during its lifetime result in an individual robot which has its own unique configuration.

• Furthermore, the environment provides a complete set of parameters: lighting conditions, the shape and location of rooms and corridors, the positions of obstacles like tables or stairs. The list could be continued indefinitely. These parameters vary between different environments, but also tend to change slightly over time. Light bulbs are changed, cupboards added, tables moved etc.

• A third group of parameters is defined by the task the robot has to perform or by the scenario the robot is designed to operate in. Generalized tool boxes like planners or knowledge bases need to be populated with the relevant actions and objects, and a reactive execution engine needs to be configured with information on what actions to take in which situation. These sets of parameters can either be configured by hand, with the help of tool- supported methods, or fully autonomously. Nevertheless, configuration remains a crucial part of a robot’s setup for every scenario. Distributing these configu- ration parameters over a large-scale application in an unstructured manner or hard-coding them as constant values within the various modules can endanger the maintainability and adaptability of the resulting applications.

4.2.1 Related Work

Most large-scale software development environments offer facilities for configu- ration parameter management. But most of them rely on a simple ini-file based format that only provides simple key-value mapping and a partitioning of the configuration file into multiple sections (e.g. the KDE project, OROCOS@FAW [105]). Typically, only helper classes for parameter retrieval are provided. The Windows registry allows to define subtrees, keys, subkeys and typed entries for storing configuration data for both the system and installed applications. On

38 CHAPTER 4. MIRO INFRASTRUCTURE LAYER the other hand, structured or user-defined parameter types are not supported [84].

Especially Java-based applications also use XML-based configuration syntax [85]. The ORCA project [12] also uses an XML-based description language to specify the configuration of their components. Nevertheless, the parsing of the individual parameter values at program startup is supported by helper classes, but not otherwise automated.

Generally, hardly any stringent support for the editing of parameter values by end-users exists. The regedit for the Windows registry, for example, cannot provide its users with the names for subkeys that are processed by the ap- plication, but currently not present in the registry. This functionality is also missing in most robotic software environments. In consequence, the manual for the Carnegie Mellon Robot Navigation Toolkit (CARMEN), for instance, explicitly states that the provided list documenting the available parameters is probably not complete [6].

Interestingly, the KDE project recently incorporated a quite similar approach to parameter management as discussed in the following section [100]. But it does not provide extensibility by user-defined types as provided by the approach discussed here.

4.2.2 Design Constraints

Providing dedicated support for configuration management not only facilitates the adaptability of the software architecture itself. A convenient, structured approach of parameter handling can also encourage developers to model the parameters of modules explicitly and that way improve the maintainability and reusability of the resulting applications.

In a time-constrained environment such as robotics, parameter management does not have to introduce significant runtime overhead compared to hard- coded implementations in order to be acceptable on all levels of an application. The parameters are not unstructured sets, but structured according to the semantics of the module’s domain. For the management of the configuration options, this is valuable information and therefore needs to be representable. Because of their nature, configuration parameters need to be altered frequently and therefore need to be easily accessible. On the down side, this can also en- danger the stability of the deployed robot, because the wrong configuration can easily crash an application. Thus, ensuring the consistency and the syntactic correctness of configuration files is necessary in order not to introduce a new source of bugs which might be difficult to trace.

4.2. CONFIGURATION AND PARAMETER MANAGEMENT 39

Figure 4.3: Toolkit-supported configuration and parameter management.

4.2.3 Parameter Descriptions

In order to enhance the configurability and maintainability of robotics software, a sophisticated infrastructure for parameter and configuration management was developed. It is sketched in Figure 4.3. With the Miro parameter toolkit, the modules’ configuration parameters are separated into so-called parameter description files in an XML-based syntax. These allow describing parameter sets as arbitrarily complex structures that support aggregation, nesting, data types of variable lengths and single inheritance. A parameter description can specify properties such as its default value, the represented measure, or a verbatim description of the parameter.

Miro provides a compiler for translating these descriptions into a target pro- gramming language’s data structures and code for storing and parsing this data to and from configuration files. Currently, C++ is supported. A configuration file contains various instances of parameter sets as described in the parameter description files. It is based on an XML syntax, too. The application parses those files on startup to initialize the parameter data structures of its services. The basic syntactic correctness of configuration

Figure 4.4: The corre- sponding generic dialog. files can be ensured by validating it with its doc-

ument type definition (DTD). However, due to the extensible nature of parameter descriptions, it cannot ensure the correctness of the mapping of a parameter set in the configuration file to its specification in the corresponding parameter de- scription. Thus, for generic type-safe editing of configuration files, the GUI-based ConfigEditor has been provided. This editor will be covered in more detail in Section 7.1. Figure 4.4 shows the

dialog provided by the editor for the parameter example outlined in Figure 4.3. The editor dynamically generates this dialog from the parameter description at runtime and edits the configuration file example from Figure 4.3.

40 CHAPTER 4. MIRO INFRASTRUCTURE LAYER