Page - 36 - in Proceedings of the OAGM&ARW Joint Workshop - Vision, Automation and Robotics

Fig.7. The result of auserdefinedquery isdepicted in thispop-upwindow. III. EXAMPLE SCENARIO Before we discuss the related research, we will discuss a simple running example, showing the different steps of a configuration. If one wants to know the minimal set of required components, necessary to implement a robot that canopenadooronecanuseourprogramthroughperforming the following steps: • In order to identify the necessary components (hard- ware as well as software) using our program, first the ontology stated in section II-A, using the Source tab as depicted in Figure 1 must be loaded. After the loading process is done, the program has identified the capabilities and components, defined in the given ontologies. For the example, we use the ontology of [6] which contains all necessary capabilities. • Now the capability ”Open a door“ should be available for selection in the Capabilities tab. It can be selected, by using the Add button at the bottom of the tab and selecting it in the newly created combo box as depicted in Figure 2. • The program analyses the given situation online. There- fore, now, the user can already check for the necessary components to achieve the task in the Overview tab. If one has already components in mind which should be used, one may define them in the Available Components Tab. Assumed there is a ”Pr2Arm“ component that should be used. One can add these components before or after checking the necessary components. • Now the user may want to check the necessary com- ponents to implement this task. If the ”Pr2Arm“ was added in advance the output of the Overview tab will be as depicted in Figure 3. There is also a possibility to add available components directly from within this overview. For this one may simply right-click the de- sired component and click the pop-up menu (Figure 4) • Alternatively one may also check all possible con- stellations to implement this task by looking at the Compositions tab as depicted in Figure 5. Optionally, custom SPARQL queries on the loaded model may be performed using the query tab. An example query to retrieve all available capabilities of the loaded model is depicted in figure 6. The result (all available capabilities) is shown in a pop-up as shown in Figure 7. IV. LIMITATIONS OF THE APPROACH The approach presented allows an easy specification of the robotics requirements and its resulting configuration. Additionally, one can generate a minimal configuration for the robot. These calculations are based on an ontology which describes the necessary dependencies to perform a task. Due to this specification, one may encounter several problems. First, the ontology used in the example specifies the requirement for a home like an environment. The require- ments may differ in a factory environment or on a planetary mission. To cope with this problem one could argument the requirements with a specification which environment the robot is operating in. Thus, one could add the information of the environment to the ontology to derive the proper set of requirements. Another important limitation is the abstraction of the ontology. Let’s consider the example which specifies that one needs a robotic arm to fulfill the task. Thus, one can choose an arbitrary arm which may not be possible in practice as the arm does not allow to create enough force to perform the task or is too heavy to be placed on the robot. To tackle this problem one need to add additional constraints which need to be considered like the force which needs to be applied, maximum weight, .... Such constraints may not be simply integrated into the ontology reasoning. Instead one may add an additional layer of reasoning to check these constraints. Thus, one could find a configuration per the ontology and afterward check the additional constraints to rule out not applicable configurations. V. RELATED RESEARCH We start our discussion of related research with the seman- tic robot description language (SRDL) published in [7]. The description language allows describing the capabilities of the robot as well as the hardware and software components. Furthermore, dependencies of the capabilities and the com- ponents can be described. This description allows the robot to check if the dependencies are met for a specific capability. Additionally, the robot can enumerate all components which aremissing fora specificcapability.Thus, thefirst step foran automatic configuration of the robot is possible. To use this description in a robotic system SRDL was integrated into a general knowledge base for a robot through KnowRob [8]. This integration was used in the RoboEarth language [6] to allow an easy transfer of action recipes to perform a task. With the help of the SRDL, the robot could check if a certain action recipe to perform a task can be used. In this paper, we used SRDL as a basis for our tool to allow the derivation of a minimal configuration. Thus, instead of just checking if a robot can perform a capability our tool also allows getting 36