Code Generation

Dynamical System Graph Coordination Components Project generation artifacts Dynamical System C++ GraphML SCXML

Motion Primitive Coordination

Graph Components

Project

CMake

Figure 8.4.: Code generation from higher abstraction languages down to the genera- tion artifacts. Solid arrows indicate the model-to-model transformations; dashed arrows indicate the model-to-text transformations generating exe- cutable code and system visualization.

models instantiated from the deployment descriptors are made available in a repository, available in the file system and loaded from deployment descriptors. Since they are available as language concepts, they are available in the code completion. Fig. 8.3 shows an example, where an Adaptive Module is added to a Reaching Controller and in addition to the default Adaptive Module concept, the specific Adaptive Modules from the repository are suggested. Accordingly, Dynamical Systems and Criterions from the repository are suggested when editing the respective parts of the model.

A similar mechanism was used and implemented outside this work to create all Data Types of the Types DSL, by parsing the data type descriptions of the Robotics System Types (RST) library.

8.4. Code Generation

In addition to supporting the user with modeling motion primitive architectures and motion primitive based applications, one of the main goals of this work is to make these models executable on robot platforms, i.e. support the software development through automation. There are different usage patterns to achieve this with DSLs [Mernik et al., 2005, Spinellis, 2001]. The toolchain introduced with this work uses code gener- ation in order to make the models executable for the reasons discussed in Section 6.3. Code generation in this work is realized by chaining model-to-model transformations (M2Ms) and model-to-text transformations (M2Ts). While this the transformations are already discussed from a developer’s perspective in Section 6.4, this section now discusses generation of all software artifacts provided to the user of the toolchain.

In MPS, code generators are defined as part of the DSL transformations by either defining M2M transformations to MPS base languages or with the TextGen aspect, as discussed in Section 6.4. Fig. 8.4 provides an overview of the M2M and M2T trans-

Chapter 8. Toolchain

Figure 8.5.: Auto-generated visualization of the coordination of the running example. The white boxes represent the composite states, the blue boxes the states.

formations. Gray boxes and dashed arrows refer to the M2M transformations already discussed in Section 6.4.2, black boxes and solid arrows show the M2T transformations. The adapter languages (cf. Section 6.3) are left out for the sake of clarity.

8.4.1. System Visualization

The first type of generated artifacts during development of the presented approach was system-level visualization. This served as an early validation of the introduced models and provided a good overview on existing motion primitive architectures modeled with early iterations of the introduced metamodel and DSLs as demonstrated by Nordmann and Wrede [2012].

Code generation for the system visualization is based on the Graph DSL, to which M2M transformations exist from the Motion Primitive DSL as well as from the Coordi- nation DSL as shown in Fig. 8.4 so that a graph-like system visualization is generated representing the Circuit as well as the State Machine. The Graph DSL generator therefore targets MPS’ XML base language, similar to the generation of State Chart XML (SCXML) as discussed in Section 6.4.3.

Result of this code generation step are two GraphML files, the first one visualiz- ing the structural architecture, the Adaptive Components, Adaptive Modules, and Spaces, the second one visualizing the behavioral aspects, the State Machine, its States and Transitions. As an example, Fig. 8.5 shows the auto-generated visual- ization of the coordination of the running example. The white boxes represent the composite states, the blue boxes the states. Layouting was done with yed, a free-to- use GraphML editor that provides powerful auto-layouting features.

8.4.2. Executable code

The different code generators generating the executable GPL code act as the imple- mentor of the components [V¨olter et al., 2013] so that the motion primitive experts do not have to do the implementation by themselves. For this reason, the code generators proposed in this work target the generation of the entire executable code so that no additional manual implementation has to be done (NFR8).

8.4. Code Generation

Figure 8.6.: MSM transformation rule of the Primitive Coordination DSL for the Robot Converged Condition.

8.4.2.1. SCXML Code

Generation of SCXML code from the Coordination DSL is already introduced in Sec- tion 6.4. In the presented toolchain, however, the user designs the coordination by additionally using the Primitive Coordination DSL for the motion primitive specific aspects. Fig. 8.6 shows an exemplary transformation rule for one of the Primitive Coordination DSL Conditions: RobotAffected. When the code generator transforms the Coordination DSL model, the State Machine with the contained States, conc- Transs and Dynamical Systems to SCXML, it will find and execute the according transformation rules when a Primitive Coordination DSL concept is found.

Result of this code generation step is an SCXML file, which performs the intended coordination of the motion primitives when executed with the SCXML engine intro- duced in Section 7.2.2. The rule shown in Fig. 8.6 reduced the Robot Converged Condition to SCXML code that is configured to receive a particular Data Type over a particular Scope, and checking it with the RobotConvergedFilter, which is part of the SCXML engine.

8.4.2.2. C++ Code

The generators for the executable C++ code are M2T transformations as part of the Component DSL. These generators generate two different kinds of C++ artifacts: i) C++ components representing Adaptive Modules, Criterions, Mappings, and Dyna- mical Systems, each with a header and an implementation file, and ii) a C++ main file instantiating and configuring the components properly.

The Circuit is mapped to the C++ main file instantiating and configuring its con- tained components properly. Since the Motion Primitive DSL model is already mapped to Component DSL models as introduced in Section 6.4, the concepts are already quite close to the generated code so that the M2T rules are not complex. Fig. 8.7 shows a small snippet from the TextGen rules that generate the component instantiation and configuration. Code generation at this point is mainly looping over all components of the Component DSL model, mixing static C++ code and properties from the Com- ponent DSL model, e.g., component names, port names and types, and scopes. For the models from the component repository not only the component instantiation and configuration is generated, but also preprocessor commands to include the required headers according to the specification inside their deployment descriptors.

Chapter 8. Toolchain

Figure 8.7.: Snippet of the TextGen rules for C++ main file generation. The M2T transformation loops over all components of the Component DSL model, mixing static C++ code and properties from the Component DSL model, e.g., component names, port names and types, and scopes.

pings, and Dynamical Systems that are specified in the DSL into according C++ headers and implementation files. All models from the component repository are ignored at this point, as their just need to be instantiated and configured.

The Adaptive Modules, Criterions, and Mappings are transformed into compo- nents inheriting from according libamarsi abstractions; cf. Section 7.2.1. These files contain the business logic, e.g., the component for the Adaptive Module contains the C++ code to handle state changes, incoming data, forwarding it to the Dynamical System and publishing the output of the Dynamical System. The Dynamical Sys- tem is transformed to a C++ class. The code generated from the Dynamical System Expression must fit into the surrounding C++ code, which is achieved fitting the gen- erated C++ code into the code skeleton provided by the libamarsi Dynamical System interface.

8.4.2.3. Project Configuration

To be able to easily compile and execute the generated C++ code, according CMake files are generated to check dependencies, build, and install the experiment specified by the motion primitive expert. This is done by code generators from the Project DSL.

The M2M transformations from the Motion Primitive DSL to the Project DSL already include all dependencies from the component repository elements according to their deployment descriptors, which specify their CMake dependencies and file system paths. Proper M2T transformations transform the Project DSL model into CMake files that model all dependencies and include the paths of the software artifacts from the component repository.