Reconfigurable multi-robot systems are flexible to form composite agents which can be com-posed according to task requirements. This flexibility arises from a high degree of modularity and thus from the standardisation of interfaces which permit the extension of the hardware.
While the hardware interface enables the physical linkage, the robot control software (and ar-chitecture) has to support the extension of the reconfigurable multi-robot system. Section2.3 outlines an incremental mission design approach as a practical example to show an obvious benefit of an open extensible reconfigurable multi-robot systems. However, the real benefit is foreseen in the flexibility to adapt during robot operations. The configuration options and thus the options for adaptation increase with the number of atomic agents that participate in a robotic organisation.
Handling a large number of atomic agents, however, suffers from a combinatorial challenge.
Feasible coalition structures have to be identified and one, ideally the optimal with respect to
the current requirements, has to be selected. The application of a reconfigurable multi-robot system hence easily turns into an optimisation problem, which is defined by the available set of agents and the goal of the organisation. Chapter 4deals with this optimisation problem as part of a planning approach, which requires a model of the organisation as prerequisite to work with organisation states. This model not only serves as basis for planning, but also allows system designers to analyse a robotic organisation with respect to its properties and functionalities.
The organisation model also embeds practical considerations. To achieve a scalable manage-ment approach of a reconfigurable multi-robot system a high degree of standardisation at mul-tiple levels of hardware and software is required. The definition of the physical compatibility and enabling a connection viaEMIsis only one enabling requirement. This section therefore outlines the central design decision for the organisation modelMoreOrg, where the main ob-jective of the model lies in reflecting the merging of multiple atomic agents to reason with and maintain a scalable, open extensible agent architecture.
The modelling approach splits into three levels as depicted in Figure 3.4: (1) organisation level. (2) (general) agent level, and (3) atomic agent level. Each level corresponds to a distinct decomposition view of a robotic organisation. Inference has to be used to characterise the agents at all layers. Atomic agents are primarily defined by static properties and static resource assignments. However, they also comprise properties which depend upon other properties and functionalities that are inferred from the existence of hardware and software resources. The overall set of properties for both composite as well as atomic agents is, however, unified as result of their shared definition as general agent. For instance, whether an atomic agent is mobile depends upon the existence of a power source in combination with the functionalities locomotion, mapping, and localisation (see also Figure3.8). Either an atomic agent already encompasses all required functionalities, or a composite agent gathers these functionalities by combination of multiple atomic agents.
Figure 3.4:Characterisation of the robotic organisation at its different decomposition levels.
Ontology-based Modelling
Semantic technologies have a wide range of applications and have already been adopted by robotic practitioners to design robot architectures. Available standards and tools make an ap-plication of semantic technologies attractive, since they allow for a scalable approach and sup-port knowledge exchange through the use of standardised representation formats. Drawbacks
can be observed in the general overhead for rather small or performance critical applications, so that the use of domain-specific model-based approaches still remains a viable alternative.
Extensibility and scalability result from the ability to process new facts coming from new atomic agent types and the combination of new with the existing knowledge. The use of a domain specific implementation based on a standard programming language is one avail-able option to achieve knowledge-based reasoning. As Russell and Norvig (2003, p.241) state:
“What programming languages lack is any general mechanism for deriving facts from other facts” and they “lack the expressiveness required to handle partial information”. Even without the need to derive new facts, the use of programming languages for knowledge representation is restricting, e.g., there is neither a standard mechanism to extract information about the class hierarchy, nor a standard way to manipulate this class hierarchy. Hence, even for limited sce-narios where a knowledge exchange or update between multiple agents is required, the use of a commonly agreed representation is beneficial.
To guarantee an openly extensible system, MoreOrg is based on an ontological database in combination with usingDLas foundation for reasoning. An additional custom reasoning ap-proach tackles particular needs to model reconfigurable multi-robot systems. The usage of the ontological database is an integral part ofMoreOrgand exploits available standardisation.
Figure3.5illustrates the general architecture of the model implementation. The ontological de-scription of atomic agents is a static part of the database and usesOWL 2(W3C OWL Working Group2012) as standard technology. Inference is required to compute agent and organisation properties andMoreOrgrelies on a generic and a domain specific reasoning part. The generic reasoner is mainly used to identify the modelling of class and property hierarchies, and to identify resource relations. Meanwhile, the domain specific reasoning identifies suitable agent for a particularly requested functionality. The following paragraphs discuss some of the design decisions and features of developed organisation modelling approach.
Figure 3.5: General architecture of the organisation model.
Modular Ontology Structure Modularisation of ontologies can be seen as a best practice to manage common knowledge and domain specific knowledge. The common knowledge is de-fined in a so-calledupper ortopontology which is detailed by adding domain specific
ontolo-gies. The ontological description for the organisation model is likewise modularised, so that the knowledge database can be decomposed according to the modularity of a reconfigurable multi-robot system. Each atomic agent provides its own ontological description, so that an ex-tension of the knowledge base can be easily performed when new agents enter the organisation.
Figure3.5depicts the base level in the ontological description, which represents all commonly shared concepts and properties to define reconfigurable multi-robot systems. An example for an ontological description is provided in Figure3.8and in AppendixB.
For any presented evaluation in this thesis the base ontology contains only the minimum knowledge required to perform the evaluations. Any extension and inclusion of general, e.g., common sense ontologies, has to be performed at this base level.
The organisation level ontology is a single ontology which imports all descriptions of atomic agents. It comprises organisational specific concepts and restrictions, e.g., property constraints can be used to detail the relation between atomic agent types. MoreOrgdoes not apply social norms, i.e., it lacks a normative level which is found in organisation models like MOISE+
or OMNI (as discussed in Section 3.1). It considers restrictions only for the structural and functional levels.
The organisation modelling approach can support centralised and distributed approaches by maintaining a modular structure. Any chosen agent control architecture still needs to take care that an agent acquires information from other agents and syncs available information.
This might be needed to account for a dynamically changing system where agents can enter and leave the organisation, Hence, depending upon the final application context a frequent update of the organisation level ontology might be necessary. This includes a discovery and data collection process for available atomic agents.
Meta-modelling The organisation model uses a meta-modelling approach and focuses on the description of atomic agent types. Meta-modelling is one of the improvements ofOWL 2over its predecessorOWL 1. OWL 2permits the use of the meta-modelling featurepunning (Gol-breich, E. K. Wallace, and Patel-Schneider2012), which relaxes a previously strict separation between class names and names of individuals. As a result, a class name might also be used as name for an individual, which can be used to describe class characteristics by making asser-tion to the correspondingly named individual. In addiasser-tion to this meta-modelling capability OWL 2 allows the property qualification of cardinality restrictions, i.e., the relation between instances of particular classes can be constrained.
The ontology encodes class inheritance, properties of classes, and qualified cardinality con-straints, which is sufficient to define the resource structure of atomic agents. The use of a cardinality-based representation in combination with using the meta-modelling feature pun-ning is a flexible and scalable approach to model agent types. The ontology specifies the maxi-mum number of associated resources using qualified maximaxi-mum cardinality constraints for each atomic agent type. The qualification refers to hardware and software resources. Since (general) agents’ capabilities depend only upon the availability of these resources, this description is the basis for the mapping between available resources and functionality of an agent type. Each atomic agent type’s ontology can encode the decomposition of an agent type down to a custom level of detail. Figure3.6depicts the class hierarchy of the base ontology, with the core classes described in Table3.5.
The hierarchy of properties used inMoreOrg is shown in Figure3.7. Data properties are
as-Table 3.5:Class descriptions.
Name Description
Agent The parent class for all agent types
PhysicalEntity The parent concept for hardware components
Capability Represents an ability of an agent (instance) to perform some function.
Software components or drivers might be required to establish a certain capability for the actual robot. They are, however, not directly available to other robots.
Service A function (offer) to benefit other clients (including the agent itself) Functionality The parent and wrapping concept forServiceandCapability.
Check-ing the availability of aFunctionalityis essential for the planning ap-proach outlined in Chapter4. It permits the identification of agent suit-able to perform a task.
Interface An interface might be a hardware or software interface, permitting to establish inter- and intra-agent connections.
sociating numeric types with class instances. The selected set of properties enables a basic characterisation of atomic agent, e.g., mass and typical (nominal) speed for operation, where immobile agents have a speed of 0 m/s.
Although only computed dynamically, a composite agent is likewise characterised by prop-erties. The quantification of properties, however, is performed on the basis of heuristics and policies to allow for a systematic inference and attribution. Section3.5.1provides the details of this inference. The object propertyhasis used to relate resources to subcomponents, e.g., to define how many physical entities a atomic agent has. It is therefore the most often used object property. The object propertyhasis transitive, so that any child class inherits the components of a parent class. The object propertycompatibleWithallows to declare the compatibility of interface classes among each other. The object propertycompatibleWithis symmetric, i.e., for interface classesAand Bthe following holds: AcompatibleWithB ⇐⇒ BcompatibleWith A. The object propertyhasTransportCapacityallows to restrict the number of resources of a particular class which can be transported by using property qualification.
The ontology-based representation allows to characterise atomic agent types using a set of data and object properties, and the organisation model allows to subsequently infer properties for composite agent types (see Section 3.5.1) and the overall organisation. Figure 3.8 shows a related presentation usingDL, where thehasproperty is used to define requirements on other resources.
Qualified Cardinality Constraints The general ontology design inMoreOrgis similar to the KnowRob approach developed by Tenorth and Beetz (2013). A significant distinction, how-ever, is the use of qualified cardinality constraints inMoreOrgto encode resource dependen-cies. KnowRob uses the property constraint owl:someValuesFrom to encode a dependency, which is equivalent to a minimum cardinality of one for a particular resource. Furthermore, in KnowRob an agent’s available resources are explicitly listed, which corresponds to specifying a minimum and maximum cardinality of one for an available resource.
Using (qualitative) cardinality constraints inMoreOrghas the advantage of making the number of resources that an atomic agent type provides directly quantifiable. The alternative represen-tation, which is equivalent to KnowRob’s approach, has to relate a set of resource instances with
Figure 3.6:Class hierarchy excerpt of the base ontology.
(a)Data properties. (b)Object properties.
Figure 3.7:Property hierarchies of the base ontology.
Capability ⊑Functionality⊑Resource⊑ ⊤ Service ⊑Functionality⊑Resource⊑ ⊤
MoveT o ⊑Capability
ImageP rovider ⊑Service
MoveT o ≡ ≥1.has.Locomotion
⊓ ≥1.has.Localization
⊓ ≥1.has.Mapping
⊓ ≥1.has.P owerSource ImageP rovider ≡ ≥1.has.Camera
⊓ ≥1.has.P owerSource LocationImageP rovider ≡ ≥1.has.ImageP rovider
⊓ ≥1.has.MoveT o
ARobot ≡ Agent
⊓ ≤1.has.Locomotion
⊓ ≤1.has.Localization
⊓ ≤1.has.Mapping
⊓ ≤4.has.Camera
⊓ ≤2.has.EmiActive
⊓ ≤4.has.EmiP assive
⊓ ≤1.has.P owerSource
Figure 3.8:Organisation model excerpt of aDL-based description of an atomic agent concept ARobot. The example associates a functionality namedLocationImageP roviderwith the agent concept, reflecting the ability to take images at different locations.
a given atomic agent type. Figure3.8illustrates the essential use of minimum and maximum cardinality constraints inMoreOrg, i.e.,≥n.R.Cand≤n.R.C, with cardinalityn, relation/prop-ertyR, and concept/classC. Minimum cardinality constraints define resource requirements, whereas maximum cardinality constraints encode resource availability. An agent comes with a maximum number of available resources and is viewed as a resource provider. In contrast, functionality is defined by its minimum required number of resources.
While cardinality constraints make subcomponents of resources countable, minimum and maximum cardinality constraints are also a means to deal with model changes. Real robots suffer for example from an outage of a hardware or software component. This loss of a compo-nent can be modelled by adding a (now lower) maximum cardinality constraint. This measure, however, prevents a usage of this new robot type as substitute where the parent type is actually required. As a consequence, as soon as an agent looses a component, it effectively changes its type.
Reasoning MoreOrgdoes account for two levels of reasoning: (a) a generic reasoning which is based on DL, and (b) the domain specific reasoning built on top of the generic reasoning and additionally applying model-based reasoning. The generic reasoning can be achieved by an existing OWL 2related reasoner. The domain specific reasoning is a contribution of this thesis. It focuses on reconfigurable multi-robot systems and adds organisational reasoning.
It enables a model-based approach for reasoning with composite agents which is based on qualified cardinality constraints.
Joining two agents results in a merge of the related resources, so that the resulting composite agent can be described with a set of cardinality restrictions. The respective cardinalities of the atomic agents are summed. MoreOrgintroduces an algebra to deal with functionality and property inference of composite agent types.
For each resource conceptrthe following summation rule holds:
cardmax(r,A) =ˆ ∑
ˆ a∈Aˆ
γAˆ( ˆa)·cardmax(r,a)ˆ , (3.1) where cardmax(r,a) is the maximum cardinality of resource conceptˆ r for a given agent type a. The equivalent operation applies for the summation of minimum cardinality restrictionsˆ cardmin(r,a). This model-based approach uses information about an agent type and interpretsˆ the maximum resource cardinalities as indication of its nominal resource composition. An equivalent approach which does rely on the explicit association with resource instances re-quires to count all available instances:
card(r, A) =∑
a∈A
card(r, a) , (3.2)
wherecard(r, a) is the exact cardinality of a resource conceptr for a given agent. The former min, max cardinality approach has the advantage of a compact representation, which can di-rectly use the specified cardinality. The latter can didi-rectly link resource instances to system re-sources, which thereby leads to an exact description of an agent. It requires, however, to count the associated resource to identify (exact) resource cardinalities. The model-based approach in combination with min and max cardinalities has been selected for use inMoreOrg, since it provides a concise and flexible representation which permits the direct reasoning with agent
compatibleW ith ⊑ObjectP roperty
ElectronicalInterf ace ⊑Interf ace⊑ ⊤
MechanicalInterf ace ⊑Interf ace⊑ ⊤
ElectroMechanicalInterf ace ≡MechanicalInterf ace⊔ElectronicalInterf ace
EmiP assive ⊑ElectroMechanicalInterf ace
EmiActive ⊑ElectroMechanicalInterf ace
EmiActive(EmiActive) EmiP assive(EmiP assive)
compatibleW ith(EmiActive, EmiP assive)
Figure 3.9: Knowledge base example to account for interface compatibility.
types. Furthermore, it is open for a complementary application of the mentioned approach of using resource instances.
Interface Compatibility As described in Chapter 2.2 the use of an EMI is the distinctive feature of a reconfigurable multi-robot system compared to a standard multi-robot system. The design of these interfaces varies. For instance, in the case of this thesis’ reference system three different coupling mechanisms exists. These involve gendered interfaces, so that connections of atomic agents are limited to compatible interfaces.
The initial description and definitions which are provided in Chapter 2.4 do not embed in-terface compatibility (and thus link space), and only describe combinations of atomic agents in agent space. In order to define link compatibility MoreOrg models interface classes, in combination with the object property compatibleWith, which permits the definition of the compatibility between two interface classes.
In general, the organisation model assumes incompatibility. Two interface types are only com-patible if explicitly specified. Figure3.9lists an example which focuses on the representation of theEMIof the reference system. Note that the feature of previously mentionedpunningis used to define a classEmiActivewith a corresponding instanceEmiActive, as well as a class EmiPassivewith a corresponding instanceEmiPassive. This enables the definition of compat-ibility on the interface instances. Yet, the class based definition of interfaces inMoreOrgis not restricted to the interfaces mentioned here. It can account for an interface concept as soon as it is described in the ontology along with the list of compatible interfaces (see Section3.3.1).
As shown in Section 3.1 the consideration of interface compatibility reduces the number of feasible composite agents. While the search space in link space is orders of magnitudes larger compared to considering agent space, MoreOrgprovides a heuristic search approach to sup-port to the identification of feasible agents. To verify the feasibility of a composite agent More-Orgsearches for a suitable link assignments using a constraint-based programming approach.
Section3.3.1details the approach.
Implementation Notes FaCT++ (Tsarkov and Horrocks2006) has been used for the actual implementation to provide the general reasoning capabilities forDL. The use of FaCT++ per-mits to check for subsumption, enumerate subclasses and subproperties, and it can account for symmetric and transitive properties. The domain specific reasoning uses an in-memory representation of the ontology, and for that purpose a C++-library (owl_api) has been imple-mented based on the work of Horridge and Bechhofer (2011). This library provides additional
functionality to support the reasoning with qualified cardinality constraints, and hence serves as backend in the implementation ofMoreOrg.