This paper introduces a ROS Multi Ontology References (ARMOR) service, a general-purpose and scalable interface between robot architectures and OWL reasoners. ARMOR addresses synchronization and communication issues among heterogeneous and distributed software components. As a guiding scenario, we consider a prototyping approach for the use of symbolic reasoning in human-robot interaction applications.
The challenge of sharing and communicating information is crucial in complex
human-robot interaction (HRI) scenarios. Ontologies and symbolic reasoning are
the state of the art approach for a natural representation of knowledge,
especially within the Semantic Web domain, and it has been adopted to achieve high
expressiveness [
The Robot Operating System (ROS) is a de facto standard for robot software
development, which allows for modular and scalable robot architecture designs.
Currently, some approaches exist to integrate a semantic representation in ROS,
such as the KnowRob [
on ad hoc reasoning solutions, significantly limiting their scope. We argue that this fact affects the study of different approaches to semantics in Robotics. For instance, it limits our capability to explore novel semantic representations of perceptions, which offers similar but not equivalent beliefs. We lack a standardized general framework to work with ontologies, natively supporting symbolic logic and advanced reasoning paradigms.
The Ontology Web Language (OWL)2 is a standard representation
supporting several reasoning interfaces, e.g., Pellet [
For this purpose, we propose the ROS Multi Ontology References3 (ARMOR). ARMOR is an open source service which manipulates and queries multiple OWL ontologies. It provides access to a set of dynamic ontologies, handling also the synchronizations among different components in the architecture. Therefore, it is a convenient tool for managing knowledge representation supported by advanced reasoners. 2
Figure 1 shows a schematic representation of ARMOR. It interfaces the OWL
API [
«knowledge base»
Ontology references 1 «library» a Multi Ontology References (AMOR) «class» Injected
Service F injected response «ROSjava package» a ROS Multi Ontology References (ARMOR) «interface» «realization»
AMOR OWL Enquirer Enquirer «interface»
AMOR Manipulator «ROS service»
ARMOR interface F injected request «implements»
«depends» «realization»
OWL Manipulator | qmuaenriypulation F injected request «engine»
OWL Reasoner «factory»
OWL
API | scoolnustiisotnency F injected response The core library, referred to as AMOR, contains a map of instantiated ontologies, where the key is a unique name identifier used to access the corresponding ontology in a thread-safe manner. AMOR provides several common operations, such as those to create individuals, assign their properties, make them disjointed and classify them, to name a few. Furthermore, AMOR ensures complete accessibility to the OWL API6 features for compatibility and extendability purposes. For example, AMOR allows for invoking reasoners by specifying their OWLReasoner factory, i.e., the unique package of its Java implementation, which assures compatibility with all OWL reasoners.
In the current implementation, we interface several properties that are useful to tune the AMOR behaviour, e.g., the buffering of the manipulations or a continuous reasoner update, using the standard ROS Parameter Server, as well as parameters for debugging purposes such as toggling a Graphical User Interface (GUI) for visualising ontology states on-line. 2.2
The ARMOR Interface The ARMOR interface is based on a ROS message structure (i.e., a triple) for the use of the AMOR functionalities from any node in the architecture, even when the development language is different from Java (e.g., Python7 and C++ are the most common languages in Robotics development). Such a message is composed of: 1. the client name, which is used by the service to identify different callers, 2. the reference name, indicating the operation’s target reference, and
3. the command to execute, i.e., add, remove, replace, query, load, mount, etc.8 Each of those commands may be further refined by: (a) the primary and secondary specifiers, which augment command labels, e.g., add(individual, class ) or remove(individual, property ), and (b) the arguments, a list of entities in the reference parameterising the command, e.g., hadd(class ) "Sphere"i, or even hadd(property,individual ) "hasNorth" "LivingRoom" "Corridor"i. An ARMOR call is based on one or more messages with the same structure. When such a request is sent, the service manipulates or queries the ontology with the given directives. Then, it returns whether the ontology is consistent, eventual error codes with their description, and the names of the queried entities, if requested. In other words, the interfaces | and in Figure 1, and F can be defined for each specific injected service, if any.
One advanced feature of ARMOR is the possibility of flexibly synchronising all operations. This follows a mounting/unmounting paradigm, where one or more nodes identified by the same client name can prevent other nodes from manipulating a given ontology, in order to ensure manipulation consistency. On the contrary, queries are always allowed, except during reasoning time. Calls to busy ontologies will report a mounting issue, and the user can choose how to handle this situation. 3
We are currently using ARMOR in different applications, but here we mention
only two of them. The first is aimed at implementing a dynamic PDDL problem
generator. This approach uses descriptions of the predicates and objects in a
tabletop scenario to infer unsatisfied norms and consequently generate goals [
The second application is a system to learn by demonstrations the
arrangement of objects in the robot’s workspace by mapping their properties into the
TBox. In particular, we used an injected service10 in ARMOR for performing
scene learning and classification in a scenario where a robot explains its beliefs
to a human, which might want to correct it through dialogues [
This paper introduces the ARMOR service to manipulate OWL ontologies and query their reasoners in a ROS-based architecture. ARMOR services are available through a flexible message allowing for the direct access OWL features from any component of the architecture. It ensures synchronisation between client calls and flexibility through procedure injection. Also, ARMOR allows for an easy interface between robotic architectures and OWL representations, and we practically showed it during a tutorial presented at the ROS Development
Conference 201811. The tutorial is focused on the control of mobile robots based on a topological environment representation and SLAM.