Reasoning for Autonomous Agents in Dynamic Domains

Stephan Opfer, Stefan Jakob and Kurt Geihs

Distributed Systems Research Group, University of Kassel, Wilhelmsh

oher Allee 73, Kassel, Germany

Keywords:

Answer Set Programming, Region Connection Calculus, Spatial Reasoning, Multi-shot Solving.

Abstract:

In contrast to simple autonomous vacuum cleaners, multi-purpose robots that fetch a cup of coffee and clean

up rooms require cognitive skills such as learning, planning, and reasoning. Especially reasoning in dynamic

and human populated environments demands for novel approaches that can handle comprehensive and ﬂuent

knowledge bases. A promising approach is Answer Set Programming (ASP), offering multi-shot solving

techniques and non-monotonic stable model semantics. Our objective is to equip multi-agent systems with

ASP-based reasoning capabilities, enabling a team of robots to cope with dynamic environments. Therefore,

we combined ALICA - A Language for Interactive Cooperative Agents - with the ASP solver Clingo and

chose topological path planning as our evaluation scenario. We utilised the Region Connection Calculus as

underlying formalism of our evaluation and investigated the scalability of our implementation. The results

show that our approach handles dynamic environments and scales up to appropriately large problem sizes.

1 INTRODUCTION

During the last decade autonomous robots started to

play an increasingly important role in our everyday

life. They are able to vacuum-clean our living room,

mow the lawn, and clean the pool. Almost all car

manufacturers are developing autonomous cars. Au-

tomated guided vehicles take care of the logistics in

production plants or parcel service centres. Autono-

mous and interactive toys become more and more in-

telligent.

Figure 1: Domestic Service Robot PR2. (Wang, 2010).

In the research ﬁeld of service robots, researchers

focus on multi-purpose robots, instead of single-

purpose ones. Figure 1 shows a state-of-the-art ser-

vice robot, which can do everyday household tasks.

The variety of those tasks tremendously increases the

number of elements relevant for the robot’s environ-

mental representation and therefore, poses new chal-

lenges to the research community. Operating in hu-

man populated environments, e.g., requires the robot

to handle dynamic environments. This is, because hu-

man beings insert, remove, and displace objects in

the environment and are themselves moving obsta-

cles from the robot’s point of view. In order to cope

with this problem, the robot needs cognitive capabili-

ties such as learning, planning, and reasoning. Furt-

hermore, a suitable level of abstraction is necessary

to make reasoning about such complex and dynamic

domains more tractable. A robot that should fetch a

cup, for example, needs to know that a cup is usu-

ally situated in a cupboard in the kitchen, but does

not have to know the cup’s exact coordinates. Furt-

hermore, it needs to reason about the reachability of

the cup from its current position in the building, ta-

king locked doors, obstacles, and the topology of the

building into account.

A common way of tackling such problems is the

symbolic knowledge representation and reasoning ap-

proach (Brachman and Levesque, 2003). Neverthe-

less, our experience is that most benchmarks present

today

are designed in a one-shot fashion, i.d., con-

tinuously solving one problem after another, without

http://www.satcompetition.org/ [Online; accessed De-

cember 9, 2016]

http://aspcomp2015.dibris.unige.it/ [Online; accessed De-

cember 9, 2016]

340

Opfer S., Jakob S. and Geihs K.

Reasoning for Autonomous Agents in Dynamic Domains.

DOI: 10.5220/0006297603400351

In Proceedings of the 9th International Conference on Agents and Artiﬁcial Intelligence (ICAART 2017), pages 340-351

ISBN: 978-989-758-220-2

the possibility of using knowledge from previous pro-

blems. Our contribution is to enable multi-agent sys-

tems to continuously reason about dynamic environ-

ments by utilizing Answer Set Programming (ASP) –

a non-monotonic knowledge representation and rea-

soning formalism (Gebser et al., 2014), suitable for

multi-shot solving (Gebser et al., 2015). Further-

more, such dynamic environments demand a highly

dynamic multi-agent coordination framework that in

our case is provided by ALICA – A Language for

Interactive Cooperative Agents (Skubch, 2013). In

our preliminary work (Opfer et al., 2016) we cap-

tured the semantics of ALICA programs within an

ASP logic program, in order to detect common mo-

delling errors. This forms the basis for integrating

ASP with ALICA and allows us to extend it with a ge-

neral solver interface. Through this interface ALICA

programs can utilise ASP-based reasoning techniques

which in turn makes ALICA open for a wider set of

application domains. Moreover, we had to extend

the utilised ASP solver with query semantics accor-

ding to (Gelfond and Kahl, 2014). In our evalua-

tion, we chose topological path planning as our sce-

nario. Therefore, we formulated a simpliﬁed version

of the common Region Connection Calculus (Randell

et al., 1992) in ASP, further denoted as RCC-4, and

investigated the scalability of our RCC-4 formalisa-

tion in combination with our integration of ASP with

ALICA.

The remainder of this paper is structured as fol-

lows. Section 2 introduces ALICA, ASP, and RCC-4.

The integration of ALICA with ASP is described in

Section 3. Furthermore, the query semantics exten-

sion is elaborated in Section 4. Section 5 provides the

description of our evaluation scenario, whose results

are presented in Section 6. Finally, we compare our

work with other approaches in Section 7 and conclude

with Section 8.

2 FOUNDATIONS

This section is divided into three subsections. In Sub-

section 2.1 the focus is set on concepts of ALICA

that are necessary to understand in the context of this

work. The same holds for Subsection 2.2 that is about

the syntax and semantics of ASP. In Subsection 2.3 an

explanation of the basic relations of the Region Con-

nection Calculus 4 is given.

2.1 ALICA

The ALICA framework is designed to coordinate a

cooperative team of autonomous agents. Explaining

all features of this framework is beyond the scope of

this work and we would like to point the interested re-

ader to the dissertation of Hendrik Skubch (Skubch,

2013) and two supplementary publications (Skubch

et al., 2011a; Skubch et al., 2011b). In this section,

our goal is to explain the fundamental principles of

ALICA and focus on the parts that we changed to

make a wider set of general problem solvers acces-

sible from within an ALICA program.

The ALICA framework is distributed in the sense

that each agent in the team is running its own inde-

pendent ALICA behaviour engine. Each behaviour

engine determines the sequence of actions of the lo-

cal agent while coordinating with other engines and

taking the current situation as well as a given ALICA

program into account. Sometimes frameworks like

ALICA are also denoted as sequencer (Gat, 1998).

Clean Up

Pre: messy, Run: >

Tidy Up

1..∞

Drive

Pick Up

Transport

Place Back

Post: in place

arrived

picked ∧ near dest.

dropped

picked

near dest.

dropped

placed

Inspect

1..2

Identify

found

identiﬁed ∧ notiﬁed

Wipe Floor

0..2

Drive

Wipe

Dry

arrived all wet

dried

Figure 2: Simple Clean Up Plan.

An ALICA program is a special tree, whose in-

terior nodes are plans and its leaf nodes are atomic

behaviours. The CleanUp plan in Figure 2 is an ex-

ample of such an interior node. A plan can include

several states (Z

. . . Z

) that are connected with guar-

ded transitions to create ﬁnite state machines (FSM).

Each FSM is annotated with a task (Tidy Up, Wipe

Floor, Inspect) and a pair of cardinalities for the mini-

mum and maximum number of agents allowed in the

corresponding FSM. Each state of a plan, except for

terminal states (Z

), can contain behaviours and plans

that represent leaf or interior nodes respectively on

the next level of the tree. In Figure 2 plans and beha-

viours are distinguished by the colour of their boxes,

e.g., state Z

contains the plan Drive, which is blue,

Reasoning for Autonomous Agents in Dynamic Domains

341

and state Z

contains the behaviour Pick Up, which is

orange. It is important to note that a plan, which is

referenced in a state, is a complete plan like the Clean

Up plan itself and therefore can include state machi-

nes with other behaviours and plans.

The coloured circles on top of some states in Fi-

gure 2 illustrate a possible global execution state of

the plan. Each circle represents an agent. The red ci-

rcle, for example, could be the local agent executing

the Pick Up behaviour, while the other circles repre-

sent other agents in the team, whose corresponding

behaviour engine have sent their execution state to the

local agent.

In order to understand the extension of ALICA by

a general problem solver interface, it is necessary to

introduce the notion of ALICA plan variables. For

simplicity let us modify the Inspect state machine

from Figure 2 to create a plan on its own.

Inspection

Var: X

Inspect

0..1

Classify

Clean

Var: X

found

in use

identiﬁed

done

Figure 3: Inspection Plan.

The purpose of this plan, as shown in Figure 3,

could be the identiﬁcation of coffee cups that should

be cleaned, because they are dirty and not used any-

more. Therefore, an agent searches for coffee cups in

state Z

and switches to state Z

, in order to classify

them. For remembering which cup was found in state

the plan variable X can be set to the corresponding

cup and thereby inﬂuence the agent’s behaviour du-

ring the rest of the plan execution. This inﬂuence can

even reach to deeper levels of the plan tree, as indica-

ted by variable X

of the Clean plan in state Z

. It is

possible to deﬁne variable bindings over states in an

ALICA plan tree, e.g., stating that X denotes the same

variable as X

. This allows to determine the agent’s

behaviour in the Clean plan, depending on which cup

was found in the Inspection plan.

ALICA as presented in (Skubch, 2013) only pro-

vided one solver for assigning values to plan vari-

ables. The given solver addresses non-linear conti-

nuous constraint satisfaction problems and, as it was

hardwired to ALICA, the applicability of ALICA for

other domains was limited. Our extension of ALICA

with a general solver interface tackles this issue (see

Section 3).

2.2 Answer Set Programming

Answer Set Programming (ASP) is a declarative ap-

proach for solving NP-search problems. It can be

seen as the result of decades of research in the areas

of knowledge representation, logic programming, and

constraint satisfaction. Thereby, its focus is on ex-

pressivity, ease of use, and computational effective-

ness (Brewka et al., 2011). An ASP program is spe-

ciﬁed by a set of rules of the form a

← a

∧ . . . ∧

∧ ∼ a

m+1

∧ . . . ∧ ∼ a

. Each a

denotes a predicate

p(t

, . . . , t

) with terms t

, . . . , t

build from constants,

variables, and functions. Rules consist of three parts,

namely the head a

, the positive part a

∧ . . . ∧ a

and the negative part ∼ a

m+1

∧ . . . ∧ ∼ a

of the body.

The semantics of the default negation ∼ is that of

negation-as-failure. That means, ∼ a

is considered

to hold, if it fails to prove that a

holds. Neverthe-

less, ASP also provides classic negation ¬a

, whose

semantics is that ¬a

holds, if a

does not.

In order to create ASP programs, the rules have to

be transformed in the following way: ← is transfor-

med to :-, ∧ are replaced by , and a rule is ended by

a dot. The - in front of robot(X) stands for classic

negation ¬ and not in front to of broken(X) means

default negation ∼. The ; is a syntactic shortcut for

creating several rules at once. Rule 1, therefore, crea-

tes robot(chuck), robot(fox), and robot(lisa).

Furthermore, Rules 1 and 2 have an empty body. So

their heads are unconditionally true, and they are de-

noted as facts. Rule 3 makes use of the default nega-

tion ∼ and states that a robot can drive, as long as it

cannot be proven, that it is broken (not broken(X)).

Here X is a variable (starts with uppercase letter),

which can be substituted with any element of the Her-

brand universe of the given program.

1 r o b o t ( chuc k ; f o x ; l i s a ) .

2 b r ok e n ( fo x ) .

3 c a n D r i ve (X) :− r o b o t (X) , n o t b r o ke n (X) .

4 h i g h F a i l u r e R a t e :− Working

= # c o u n t {X : c a n D r i ve (X) } ,

Bro ken = # c o u n t {X : b r ok e n (X) } ,

Working < B roke n .

Listing 1: Robots can drive, as long as they are not broken.

The Herbrand universe of the program in Listing 2.2

only contains four constants (start with lower-case let-

ter): {chuck, fox, lisa, highFailureRate}. Rule

4 derives the constant highFailureRate, if there are

more broken robots than driving ones. As shown by

this rule, ASP is capable of handling integers and

provides aggregate functions like #count or #sum

and arithmetic functions like < or +. The result of

this program will state, that there are three robots

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

342

of whom chuck and lisa can drive, the constant

highFailureRate does not occur.

State-of-the-art ASP solvers (Gebser et al., 2014;

Leone et al., 2006) usually work in two steps. First

they ground the program and afterwards determine

all stable models of the grounded program. A pro-

gram, as well as every part of it, is grounded if it does

not contain any variable. In order to create a groun-

ded program, informally speaking, the variables of

each rule are replaced by each possible substitution

with an element of the program’s Herbrand universe.

The Herbrand universe of a program is constructed

from all constants and functions occurring in the pro-

gram. Grounding a program that way would increase

the number of rules enormously, therefore the utilised

grounding algorithms try to keep the grounded pro-

gram as small as possible, without altering the pro-

grams meaning. For example, Rule 3 of Listing 2.2

will not be part of the grounded program, if there is

no robot available.

Solving a grounded program is often done with

SAT solving techniques that are adapted to the sta-

ble model semantics of ASP. A model in ASP is a

set M of ground predicates that for every rule either

contains the rules head (a

∈ M), or does not include

all predicates of the positive part of the rule’s body

({a

, . . . , a

} * M), or contains predicates from the

negative part of the rules body ({a

m+1

, . . . , a

} ∩ M 6=

0). Informally speaking, a stable model is as small as

possible and contains predicates, only if they are jus-

tiﬁed by facts. For a detailed introduction into stable

model semantics see (Eiter et al., 2009).

In our approach we choose the Clingo 4.5.3 ASP

solver (Gebser et al., 2014), which introduces the no-

tion of External Statements to ASP (Gebser et al.,

2012; Gebser et al., 2015). External Statements in

combination with program sections, explained later

on, are the key concepts for enabling the query seman-

tics described in Section 4. The External Statements

are predicates marked with #external. These predi-

cates are not removed from the body of a rule during

grounding, even if they do not appear in the head of

any rule. Furthermore, they can be explicitly set to

true or false. An example for the use of External

Statements is given in Listing 2.2.

1 # e x t erna l c l o sed ( lab , h a l l ) .

2 c ( lab , hall ) : - not clo s e d ( lab , h a l l ) .

3 dc ( lab , hall ) :- close d ( lab , hall ) .

Listing 2: Modeling a door using an External Statement.

This example is part of our evaluation scenario

presented in Section 5 and will be used in ASPVaria-

bleQueries presented in Section 4.1. In this example

closed(lab, hall) is marked as an External State-

ment and is therefore initially set to true. Given the

predicate closed(lab, hall), the head of Rule 3

holds and the predicate dc(lab, hall) is part of the

stable model. The head of Rule 2 cannot be derived

since closed(lab, hall) is set to be true. Usually,

during the grounding procedure Rule 2 would be re-

moved, because its body cannot be derived. Howe-

ver, since this rule contains an External Statement,

it stays part of the grounded logic program. The-

refore, it is possible to change a logic program wit-

hout another grounding step by using External State-

ments. Furthermore, the size of the stable model does

not change. For example, if the External Statement

closed(laboratory, hall) is set to true the labo-

ratory and the hall are disconnected from each other.

If it is set to false the predicate dc(lab, hall) no

longer holds but c(lab, hall) can be derived, thus

the rooms are connected.

Additionally, Clingo introduces program secti-

ons (Gebser et al., 2014). Program sections are used

to divide a logic program into different parts, which

can be grounded separately. An example is given in

Listing 2.2.

1 # p r o gram r c c4 _ com p os i ti o n_t abl e .

2 dc (X ,Z ) :- pP ( X, Y ) , dc (Y , Z) ,X != Z.

3 # p r o gram rc c 4_fa c ts

4 pP ( off i c e 1 , off i c es ).

5 dc ( off i c e s , st u den t Area ) .

Listing 3: Usage of program sections.

This example contains two program secti-

ons identiﬁed by the #program preﬁx, i.d.,

rcc4_composition_table and rcc4_facts.

Moreover, the order in which they are

grounded inﬂuences the facts, which ap-

pear in the stable models. If the section

rcc4_composition_table is grounded before

the section rcc4_facts, the resulting model would

only contain the facts pP(office1, offices)

and dc(studentArea, offices). If section

rcc4_facts is grounded ﬁrst, the model will con-

tain these two facts before the program section

rcc4_composition_table is grounded. Once this

section is grounded the model will additionally

contain the fact dc(office1, studentArea), since

the body of this rule holds for the grounding of X by

office1, Y by offices, and Z by studentArea.

2.3 Region Connection Calculus

In this section the base relations of the Region Con-

nection Calculus 4 (RCC-4) are shown, which is ba-

sed on the Region Connection Calculus 8 presented

by Randell et al. in (Randell et al., 1992). We have

Reasoning for Autonomous Agents in Dynamic Domains

343

been inspired to use RCC-4 instead of using RCC-8

by the implementation of RCC-4, that is provided by

the QSRlib Foundation (Gatsoulis et al., 2016). These

calculi are commonly used in qualitative spatial rea-

soning and will be used to model our evaluation sce-

narios in Section 5. The foundation of the relations is

the binary relation C(x,y), which expresses that two

spatial regions of unknown size are connected. In-

formally speaking, they share at least one common

point. Furthermore, C(x,y) is reﬂexive and symme-

tric. By using the C(x,y) relation four base relations

are deﬁned and shown in Figure 4.

PO(x,y)

PP(x,y)

PPI(x,y)

DC(x,y)

Figure 4: RCC-4 base relations.

Two regions are partially overlapping (PO), if they

are connected (C), meaning they share a common

point, region or part of their border. Region x is a

proper part (PP) of Region y, if y contains Region x,

which means that Region x is connected to y and no

part of x is outside the border of y. Since this relation

is not symmetric the inverse relation PPI is included

as well. Additionally, two regions are disconnected

(DC) if they do not share a common point. By using

the composition table shown in Table 1 the transitive

relations between Region x and z can be derived, gi-

ven the relations between the pairs (x,y) and (y, z).

Hereby, ∗ denotes that all four relations can hold. For

example, if Region x is a proper part (PP) of Region

y and Region y is disconnected (DC) from Region z,

it can be derived that Region x is disconnected (DC)

from Region z.

Table 1: RCC-4 Composition Table.

DC PO PP PPI

DC *

PO PP

PPI

* PO PP

PPI

PP DC

PO PP

PP *

PPI

PO PP

PPI

An example using RCC-4 to model a building is

given in Section 5. Furthermore, the RCC-4 relations

can be used to model the relation of objects to each

other. For example, in the domain of domestic service

robots RCC-4 can be used to model objects on a table

without deﬁning their exact positions, e.g., a cup and

a plate could be proper parts of the table and could be

disconnected from each other, if they are not touching

each other.

3 EXTENDING ALICA WITH A

GENERAL SOLVER

INTERFACE

In this section we describe the extension of the

ALICA framework with a general solver interface, in

order to integrate different solvers into the ALICA

framework. By now, ALICA has only been able to

use a gradient solver, which is able to solve non-linear

continuous constraint satisfaction problems.

In order to use other solvers besides this solver

an interface IConstraintSolver has to be created.

This interface includes four classes and provides two

access methods. Every solver which is added by this

interface has to inherit from the IConstraintSolver

interface. Furthermore, solvers constraint classes

derived from the Variables interface with a set

of constraints composed from different Terms. Fi-

nally, the ProblemDescriptor encapsulates the con-

straints, that have been build by using Terms and

provides possible restrictions for the range of the

Variables. As already mentioned, the interface pro-

vides two access methods. The ﬁrst method is na-

med existsSolution. This method checks if a solu-

tion can be found and returns the corresponding truth

value. The second method is named getSolution.

Instead of checking if a solution can be found, this

method actually calculates the solution for the given

Variables and ProblemDescriptor. The calcula-

ted results are returned in a list of values deﬁned by

the solver. In this list the results are ordered in the

same way the Variables are ordered, when they are

given to the solver, so that the caller of this method

can ﬁnd the requested values.

For example, the gradient solver returns continu-

ous (double) values or an ASP solver could return a

set of predicates. Furthermore, the Variables utilise

the hierarchy of ALICA plans. A Variable deﬁned

in a plan can be constrained by additional Terms, if

the identical Variable is used by a plan lower in the

plan tree. For example, in the domain of service ro-

bots, the robot has to get a cup of coffee from the

kitchen. Therefore, the robot’s navigation goal could

be constraint to the area of the kitchen. In a plan, dee-

per in the tree, the robot’s task could be deﬁned in

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

344

detail. This would add additional constraints to the

navigation goal, for example, that a robot has to be in

a speciﬁc area in front of the coffee machine to place

the cup in the machine. This is an advantage of the

ALICA framework, since additional constraints on a

Variable only have to be considered if an agent rea-

ches the speciﬁc plan. As a consequence of this hier-

archy the time the solvers takes to ﬁnish can be redu-

ced, since complex constraints have only to be solved

if an agent reaches plans deep in the plan tree.

So far, the presented interface has been used to

integrate three different solvers. The ﬁrst solver is

the gradient solver, which was a part of the original

ALICA framework and has been adapted to the new

interface. Additionally, an ASP solver, which is pre-

sented in this work, is integrated by using this inter-

face. Furthermore, Witsch presents in (Witsch, 2016)

a middleware that enables a decision making process

for a group of robots. This middleware uses the pre-

sented interface to exchange variables and proposals

between agents.

4 EXTENDING CLINGO WITH

QUERY SEMANTICS

This section is divided into two subsections. The cre-

ated query structure is presented in Subsection 4.1.

Furthermore, an ASPQuery’s workﬂow is depicted in

Subsection 4.2.

4.1 Query Structure

To enable ASP queries a data structure is needed that

can be used by ALICA behaviours. This data struc-

ture is named ASPQuery. Following the interface

mentioned above, an ASPQuery forwards an ASP-

Term, which constraints an ASPVariable to the sol-

ver. The ASPTerm provides six ﬁelds and allows the

user to deﬁne a set of ASP rules, which are part of a

given ASP program section. These rules are then ad-

ded to the solver’s logic program and are used to de-

rive knowledge from the stable models. Furthermore,

it is possible to add facts to the ASPTerm in order

to add further information to the stable models of the

ASP solver. For example, to add information received

from other robots. Moreover, a dictionary is used to

change the truth value of the logic program’s External

Statements. Additionally, the lifetime of the query is

given, that denotes, how long a query should stay part

of the solver’s logic program. To ensure this functio-

nality, each query utilises the information given in the

ASPTerm to create a unique External Statement, that

is added to each rule and fact. As long as the query’s

lifetime is not expired this External Statement is set

to true and the rules and facts are part of the logic

program. Once the query’s lifetime is expired, this

External Statement is set to false, thus removing the

rules and facts form the logic program. As a last point,

the query’s type is given. An example for the use of

an ASPTerm is given in Listing 4.1.

1 te r m . r u l e ( go a lRe a cha b le ( X ) :-

re a c habl e ( X ,Y ) , g (X ) ,s (Y ) .) ;

2 te r m . a ddFac t ( g( r 1 405B ) .) ;

3 te r m . a ddFac t ( s( r 1 4 1 1 ) .) ;

4 te r m . pr o gra mmS e cti o n ( ds ) ;

5 te r m . ext e rnal s ( doors ) ;

6 te r m . lif e Time (1) ;

7 te r m . t y p e ( V aria b l e );

Listing 4: Example of an ASPTerm.

Listing 4.1 is part of an ASP navigation, which

will be explained in detail in Section 5. This example

is used to query, if room r1405B can be reached from

a given starting point r1411. Therefore, a rule and

two facts are added to the program section ds (Dis-

tributed Systems). Since the resulting query will add

rules and facts to the ASP program, this query can

change the stable models of the ASP solver. The-

refore, the type is set to ASPQueryType::Variable.

Furthermore, External Statements and their truth va-

lues are added, which express if a speciﬁc door in the

evaluation scenarios is open or closed. Finally, the

query’s lifetime is given.

The class model of the possible query types is de-

picted in Figure 5.

Figure 5: Classmodel of ASPQueries.

The base class ASPQuery provides three ﬁelds for

the derived classes. The list currentModels is a pla-

ceholder in which the solver’s stable models are saved

after the solving process is ﬁnished. Additionally, the

dictionary ruleHeadValues maps the rules heads of

an ASP query to their grounded instances in the stable

models. Furthermore, it contains an ASPTerm, that

has been described above and encapsulates the rules

and facts, which should be added to the solver’s logic

program.

Reasoning for Autonomous Agents in Dynamic Domains

345

The ﬁrst class derived from ASPQuery is the ASP-

FactsQuery. In our approach the ASPFactsQuery pro-

vides the query functionality described in (Gelfond

and Kahl, 2014). Gelfond et al. present a query

structure that is used to check, if a ground predi-

cate is part of the solver’s stable models. Hereby the

query returns true, if the predicate is part of the sta-

ble models, false, if the classical negation is part

of the stable models and unknown if neither is part

of the stable models. Therefore, the ASPFactsQuery

is used to ﬁlter the current stable models for given

facts, which are saved in the list queryValues. If

there is a model that contains one of these facts, it

is added to the factModelMap. Furthermore, the list

factsTruthValues is used to get the corresponding

truth value for each queried predicate. This list con-

tains true for a positive predicate, false for a predi-

cate with classical negation and unknown otherwise.

The second class derived from ASPQuery is the

ASPVariableQuery, that is used to add rules and

facts to an ASP program in order to derive know-

ledge from the solver’s stable models. This kind of

queries have the following form: query(X

, . . . , X

where X

, . . . , X

are variables. The answer to this

query is a sequence of ground terms t

, . . . , t

where

query(t

, . . . , t

) is part of the solver’s stable models.

In order to enable such kind of queries, the ASPVari-

ableQuery adds rules and additional facts to the sol-

ver’s program, which are part of the ASPTerm. He-

reby the rule heads have the form presented above.

During the creation of this query, a unique External

Statement and program section are created. This Ex-

ternal Statement is added to the rules’ bodies. Addi-

tionally, the facts are expanded to rules, in which the

facts are used as the head of the rule and the Exter-

nal Statement as the body. The newly formed rules

are added to the solver’s logic program in the created

program section, which is then grounded. Once the

solver has ﬁnished the solving process, the results of

the queried rules are returned to the querying ALICA

behaviour. As soon as the lifeTime of the query is

expired the External Statement is set to false, which

removes the rules and facts from the solver’s program

and the stable models.

4.2 Workﬂow of Queries

In order to use the described ASPTerm and ASPQue-

ries, the query structure has to be accessed by the

ALICA behaviours and has to be given to the Clingo

ASP solver. Therefore, a wrapper has been created,

that encapsulates the Clingo ASP solver. This wrap-

per, named ASPSolverWrapper, is registered at the

ALICA framework by using the interface explained in

Section 3 and can be used by ALICA behaviours. The

wrapper and its workﬂow are depicted in Figure 6.

Figure 6: Query Workﬂow.

As mentioned in Subsection 2.1, an ALICA pro-

gram consists of a directed acyclic plan tree. The AS-

PTerms needed to formulate queries are created in-

side the runtime conditions of such plans. Once the

ASPTerm is created (example given in Listing 4.1),

it can be used by an ALICA behaviour to formulate

a query. Thereby, the External Statements’ truth va-

lues are given by a worldmodel class, which encap-

sulates data that was perceived by an agent or recei-

ved from other agents, e.g., the state of a door. Af-

ter the ASPQuery has been formulated, it is registe-

red at the wrapper, that passes it to the ASP solver

Clingo. In case of an ASPVariableQuery, the wrap-

per adds the rules and facts to the solver’s ASP pro-

gram. Additionally, the ASPPlanTreeIntegrator par-

ses the ALICA program’s plan tree to enable reaso-

ning about its structure, which is done by rules gi-

ven in background knowledge ﬁles. These ﬁles, for

example, contain rules to detect malformed ALICA

programs. The corresponding ASP rules are presen-

ted in (Opfer et al., 2016). The ASPPlanTreeIntegra-

tor is only used for the ﬁrst registered query, since the

predicates stay part of the following stable models as

soon as they have been grounded. Furthermore, this

increases the runtime of the ﬁrst query but reduces the

runtime of the following queries, since this program

section has not to be grounded any more. Once all

program parts (queries, background knowledge, and

plan structure) have been added, the Clingo module

grounds and solves the program. The hereby deri-

ved stable models are passed to the registered que-

ries and saved to enable further use by other parts of

the ALICA framework, especially the ALICA beha-

viours. Finally, the results are returned to the ALICA

behaviour via two methods deﬁned by the created in-

terface. The ﬁrst method is named existsSolution,

which checks the truth value of the query without

returning stable models or ground predicates. This

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

346

method can for example be used in combination with

an ASPFactsQuery, which checks if an ASP predi-

cate is part of at least one or all stable models, since

the caller is only interested if the queried fact is part

of the stable models. The second method is named

getSolution. This method is used to return the deri-

ved stable models to the querying ALICA behaviour.

This method can for example be used in combination

with an ASPVariableQuery, where rules and facts are

added. Since the ASPVariableQuery adds additional

rules and facts to the ASP program the resulting sta-

ble models are returned to the querying ALICA be-

haviour. After the results are returned, the ALICA

behaviour can react to the changes in the model. By

returning the calculated results to the ALICA behavi-

our, the workﬂow of a query is ﬁnished and the que-

ries lifetime is reduced by one. After this process, the

ALICA behaviour can create the next query.

5 EVALUATION SCENARIO

Our approach of handling dynamic domains will be

explained by using the following scenario. The sce-

nario is placed in the Distributed Systems Department

of the University of Kassel. A map of this department

was created by using a TurtleBot produced by Wil-

low Garage (WillowGarage, 2010), which is a small

service robot equipped with a 3D camera sensor. Ad-

ditionally, we equipped the TurtleBot with a 2D laser

scanner in order to create a map of the department.

Our adapted version of the TurtleBot is shown in Fi-

gure 7 and an annotated version of the resulting map

is shown in Figure 8.

Figure 7: Adapted Version of a TurtleBot.

This map consists of 19 rooms and is divi-

ded into seven areas, which are highlighted in

different colours. These areas include from left

to right studentArea (red), mainHallA (black),

workshop (green), offices (blue), mainHallB (pur-

ple), utility (yellow) and organization (orange).

Additionally, 56 points of interest (POI), examples

marked with dots, are placed on this map, e.g.,

different workplaces or the coffee machine. The

robot’s position is marked by a circle. The re-

lations between the areas, rooms and POIs are

modelled using the Region Connection Calculus

4. Hereby, a POI is a properPart of a speci-

ﬁc room and disconnected to all other rooms.

Rooms are either partialOverlapping with other

rooms, properPart of areas or disconnected from

both. Areas can either be partialOverlapping or

disconnected. By using these relations the Distri-

buted Systems Department has been modelled. Addi-

tionally, we used External Statements to model doors

between two partialOverlapping rooms, as shown

in Listing 2.2. The use of External Statements enables

our approach to change the ASP solver’s logic pro-

gram without an additional grounding step after the

initial grounding. This should decrease the runtime

for answering ASPQueries and keep the models’ size

stable since no additional predicates have to be ad-

ded to open or close doors. Moreover, we implemen-

ted an ALICA behaviour, which uses an ASPFact-

sQuery to check if the robot’s goal position (cross)

is reachable from its current position. Furthermore,

we implemented a simple path planning approach re-

lying on a transitive closure deﬁned by the predicate

reachable(X,Y). The transitive closure to check if a

goal is reachable is shown in Listing 5.

1 rea c h abl e ( X ,Y ): - pO (X ,Y ) ,r (X ) ,r ( Y) .

2 rea c h abl e ( X ,Y ): - pO (X ,Y ) ,a (X ) ,a ( Y) .

3 rea c h abl e ( X ,Y ): - pP (X ,Y ) ,r (X ) ,a ( Y) .

4 rea c h abl e ( X ,Y ): - rea c habl e (Y ,X ) ,X != Y .

5 rea c h abl e ( X ,Z ): - rea c habl e (X ,Y ) ,

re a c habl e (Y ,Z ) , X !=Y ,Y !=Z ,X != Z .

Listing 5: Transitive closure of reachable relation.

Hereby, a room r(X) or area a(X) is reachable

from another room r(Y) or area a(Y) if they are par-

tial overlapping pO(X,Y), which is deﬁned by Rule 1

& 2. Furthermore, a room is reachable from an area

if the room is a properPart (pP) of the area (Rule

3). In addition, the reachable relation is symmetric

(Rule 4) and transitive (Rule 5).

6 EVALUATION

In this section the evaluation results are presented and

discussed. Therefore, the presented evaluation sce-

nario has been modelled in two ways. The ﬁrst one

Reasoning for Autonomous Agents in Dynamic Domains

347

Figure 8: Map of the Distributed Systems Department.

purely relies on modelling the department by facts,

named noExt. The second way was presented in

Section 5 is named Ext. Additionally, both ways of

modelling the department use the transitive closure to

enable a simple path planning approach that is used

to check if a room or POI is reachable from another

room, area, or POI. In Figure 8 the robot’s starting

position is marked by a circle and the goal is mar-

ked by a cross. The path leaves the studentArea

and follows mainHallA to reach mainHallB since the

door from mainHallA to the offices is closed. From

mainHallB the path will enter the offices through

door d and ﬁnally reaches the goal, which is situated

inside the utility area. Door d is the solely open

door in mainHallB and is opened and closed via an

External Statement to simulate a change in the envi-

ronment.

To evaluate the wrapper and the implemented

query structure, we use the presented scenarios in the

following way: During the ﬁrst step the logic program

is grounded and a navigation query is solved. Hereby

two rooms are selected and checked if they are reacha-

ble from each other, which is not possible in this step.

The second step is a purely solving step to be able to

compare the time needed. Step three is used to “open

a door”, which means either a new grounding step

(noExt), the change of an External Statement (Ext)

or to create a new solver instance. In this step the na-

vigation between the rooms is possible. The last step

is a purely solving step again.

The evaluation results using model Ext, noExt,

and instantiating a new solver are presented in Fi-

gure 9. All measurements include grounding and

solving time and show a very low standard devia-

tion of 2.8 ms for the initial grounding with Ext and

0.18 ms when using noExt or instantiating a new sol-

ver, which shows that the measured runtimes are sta-

ble and will not show signiﬁcant variations in time.

The initial grounding and solving is the most

time consuming operation and lasts 107.6 ms when

using Ext and 47.4 ms when using noExt or a crea-

ting a new solver instance. This is caused by additi-

onal steps during the ﬁrst grounding, which include

Initial Ground Solve Open Door Solve

100

120

External Statements No External Statements Instantiate new Solver

runtime [ms]

Figure 9: Comparison of different modelling approaches.

the parsing of the ALICA plan tree and grounding

the resulting predicates. Additionally, these steps in-

clude the veriﬁcation of the well-formedness of this

plan tree by ASP Rules and the parsing and groun-

ding of the corresponding model of the Distributed

Systems Department map. The difference in time

between these two results is caused by the way the

department is modelled. Without the use of Exter-

nal Statements noExt each connection between two

rooms is modelled by a single predicate. When using

Ext the connection between two rooms is modelled

with an External Statement and two rules expressing

that a door can be either opened or closed. This incre-

ases the logic program’s size which causes a longer

grounding and solving time. The test results, when

using Ext, show no difference in runtime when sol-

ving or changing the truth value of an External State-

ment. Both operations take roughly 13.8 ms. Additi-

onally, the stable model’s size is not affected by chan-

ging the truth value of an External Statement. In com-

parison, when using noExt or when using a new sol-

ver instance, solving and changing a door state differ

in runtime. Solving without any change in the model

will take 6.5 ms when using noExt but changing a part

of the model will last 19.6 ms, since a new program

section has to be grounded. Furthermore, this incre-

ases to size of the stable model’s size by 156 facts,

which is the number of relations between the rooms

of the Distributed Systems Department. In contrast to

noExt creating a solver differs in runtime regarding

a change in the model, since a initial grounding step

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

348

has to be performed for every change resulting in an

grounding time of 47.4 ms.

Due to the fact that the ALICA framework step

frequency is usually set to 30 Hz, an ALICA beha-

viour can formulate up 30 queries per second. In

Figure 10 all three methods for modelling the de-

partment are compared with respect to the amount of

changes per second.

0 5 10 15 20 25 30

External Statements No External Statements Instantiate new Solver

Number of Changes

runtime [ms]

Figure 10: Comparison of measured time regarding changes

in the model.

The x-axis shows the number of changes in the

model and the y-axis the queries average runtime in

30 ALICA framework steps. Since there is no diffe-

rence in solving and changing a value when using Ext

the blue line is constant. In comparison to this the

runtime of noExt increases when changes are made,

since a new program part has to be grounded for each

change. Both lines intersect at 17 changes. Corre-

sponding to this result, we may conclude that noExt

is suitable, if the modelled scenario is stable and does

not change often. In dynamic scenarios we suggest

the use of External Statements, since changes do not

affect the runtime. Furthermore, when using noExt

the stable model’s size increases with every change

made. In contrast, when using Ext, the models size

stays the same. Therefore, we recommend to use

noExt only for stable scenarios, since the model size

will grow rapidly and will slow down the process of

handling the models. This could be countered by dis-

carding and creating a new ASPSolver instance after

a few changes. This method is depicted by the green

line, which intersects the blue line by six changes and

is the slowest solution. Therefore, we suggest the use

of Ext.

Additionally, we evaluated the scalability of the

Region Connection Calculus 4. Therefore, we used

the navigation scenario presented in 4 and expanded

the number of rooms, starting from 100 rooms and

ending with 1700 rooms. Furthermore, we tested dif-

ferent percentages of connection between the rooms

ranging from 25 % to 100 %. The results are shown in

Figure ?? and 12.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

0.5

1.5

2.5

3.5

25 50 75 100

Number of Rooms x100

runtime [h]

0.5

1.5

2.5

3.5

4.5

Number of Rooms x100

runtime [min]

Figure 11: Runtime of the initial grounding.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

400

800

1200

1600

25 50 75 100

Number of Rooms x100

runtime [ms]

2 3 4

120

160

200

runtime [ms]

Number of Rooms x100

Figure 12: Runtime of the solve step.

As you can see, both runtimes increase exponen-

tially with rising percentage and number of rooms.

Hence, the collection of evaluation data was stop-

ped at 1800 rooms with 100 % connection, since the

grounding step did not stop after four hours and was

aborted. Considering the exponential increase in run-

time, we suggest not to use the Region Connection

Calculus 4 for transitive closure based path planning

in dynamic domains, if more than 600 regions have

to be considered. We suggest this number, since after

an initial grounding of roughly ﬁve minutes, the robot

can react to changes in the knowledge base with 5 Hz,

which we consider suitable for a dynamic domain.

7 RELATED WORK

Besides the ALICA framework other domain inde-

pendent frameworks could be used to integrate an

ASP solver for the use in different robotics scenarios.

These frameworks and further related work are pre-

sented in this section.

One of these frameworks is DyKnow presented

in (Heintz et al., 2010). The ALICA framework pro-

vides a domain independent framework to model the

behaviour of multiple agents. These agents can col-

lect domain speciﬁc information and knowledge in

an unspeciﬁed way and use these to adapt their be-

haviours. In comparison to this DyKnow focuses on

the distributed collection and distribution of varying

Reasoning for Autonomous Agents in Dynamic Domains

349

kinds of data, that includes raw sensor values, pro-

cessed sensor values or even predicates, which hold

between objects recognised in the world. The needed

processes to collect and to process the data are spe-

ciﬁed with the knowledge processing language pro-

vided in (Heintz et al., 2010). These processes pro-

vide collected data respectively derived information

and knowledge which can be used by multiple agents.

Furthermore, these processes can provide knowledge

about objects and the relations between them, which

could be passed to a solver to allow reasoning about

them. This can be compared to the knowledge base

given in our wrapper and the domain speciﬁc kno-

wledge given in ALICA behaviours. In contrast to

the ALICA framework DyKnow does not provide the

use of hierarchically constrained variables that can be

used to formulate queries of increasing complexity to

an ASP solver.

Another framework is KnowRob presented in (Te-

north and Beetz, 2013). The central part of this fra-

mework is the knowledge base. This knowledge base

provides a knowledge store and access methods for

retrieving information saved in Prolog relations. The

“virtual knowledge base” is an extension to a robot’s

knowledge base by computation of abstract represen-

tations only when the corresponding data is queried

and by forwarding queries to parts of the robot which

can provide better answers. In comparison to the

ALICA framework both use a declarative program-

ming language to create the knowledge base. Further-

more, queries can increase the knowledge base during

the computation of their answer. But in contrast to the

ALICA framework with the included ASP wrapper

KnowRob does not support multiple agents.

Furthermore, in (Gebser et al., 2015) one-shot

solving is compared with multi-shot solving based

on External Statements. Hereby they used bench-

marks given by the Fifth ASP Competition and sup-

port our results regarding External Statements in dy-

namic domains. Nevertheless, they always investiga-

ted External Statements in the context of expanding

universes. According to our knowledge, our work is

the ﬁrst investigating the advantages of External Sta-

tements in the context of dynamic universes of almost

constant size.

8 CONCLUSION AND FUTURE

WORK

In this paper we presented the integration of the

Clingo ASP solver with the ALICA framework. The-

refore, an interface has been created, that can be used

with several solvers. Additionally, the integrated ASP

solver has been wrapped to enable queries against re-

sulting models and temporarily adding rules and facts.

Several tests have been performed in order to eva-

luate the runtime of a query. The results showed

that both ways of modelling (with or without Exter-

nal Statements) respond in less than 20 ms and there-

fore can be considered as suitable for dynamic dom-

ains. Nevertheless, we prefer to use External State-

ments, since they do not increase the size of the re-

sulting stable models when the environment changes.

Another option to avoid an increasing model size is

to create a new solver instance whenever something

changes. However, this would signiﬁcantly increase

the query runtime, making this option unfavourable

starting from 5 changes per second. Therefore, we

propose the use of External Statements to model dy-

namic domains, such as human-populated service ro-

botic domains. Furthermore, we evaluated the sca-

lability of the Region Connection Calculus 4 using

the example of determining the transitive closure of

the reachability relation. From the results, we may

conclude that the calculus scales up to a number of

600 regions, since after an initial grounding time of

roughly ﬁve minutes an agent can still query its kno-

wledge base at a rate of 5 Hz.

In our future work, we will further investigate

the performance of External Statements in dynamic

domains by applying the presented approach in va-

rious scenarios. This investigation will be joined

with knowledge-based collaboration between multi-

ple agents. Currently each agent has its own know-

ledge base that is independent from all other know-

ledge bases. We want to allow agents to query kno-

wledge bases of other agents. In the scenario from

Section 5, for example, an agent that is unable to re-

ach its destination could ask other agents for open

doors, instead of searching for open doors by itself.

Another aspect of knowledge-based collaboration

is about global consistent stable models. In ASP, it is

possible that several valid models exist, but it is often

desirable that a team agrees on the same or a simi-

lar model. Therefore, agents could exchange relevant

parts or even complete models between each other, in

order to choose the local model that is most similar to

the parts received from other agents.

REFERENCES

Brachman, R. J. and Levesque, H. J. (2003). Knowledge

Representation and Reasoning. Morgan Kaufmann,

Morgan Kaufmann Series in Artiﬁcial Intelligence.

Brewka, G., Eiter, T., and Truszczy

nski, M. (2011). Answer

set programming at a glance. Communications of the

ACM, 54(12):92–103.

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

350

Eiter, T., Ianni, G., and Krennwallner, T. (2009). Ans-

wer Set Programming: A primer. In Tessaris, S., En-

rico Franconi, Eiter, T., Gutierrez, C., Handschuh, S.,

Rousset, M.-C., and Schmidt, Renate A. Schmidt, edi-

tors, Reasoning Web. Semantic Technologies for Infor-

mation Systems, volume 5689. Springer, Berlin and

New York.

Gat, E. (1998). On Three-Layer Architectures. In Kor-

tenkamp, D., Bonasso, R. P., and Murphy, R., edi-

tors, Artiﬁcial Intelligence and Mobile Robots: Case

Studies of Successful Robot Systems, pages 195–210.

MIT Press, Cambridge, USA.

Gatsoulis, Y., Alomari, M., Burbridge, C., Dondrup, C.,

Duckworth, P., Lightbody, P., Hanheide, M., Hawes,

N., Hogg, D. C., and Cohn, A. G. (2016). QSRlib:

A Software Library for Online Acquisition of Quali-

tative Spatial Relations from Video. In Bredeweg, B.,

Kansou, K., and Klenk, M., editors, Proceedings of

the 29th International Workshop on Qualitative Rea-

soning, pages 36–41.

Gebser, M., Grote, T., Kaminski, R., Obermeier, P., Sa-

buncu, O., and Schaub, T. (2012). Answer set pro-

gramming for stream reasoning. In Eiter, T. and McIl-

raith, S., editors, Proceedings of the Thirteenth Inter-

national Conference on Principles of Knowledge Re-

presentation and Reasoning (KR’12), volume 13, pa-

ges 613–617. AAAI Press.

Gebser, M., Janhunen, T., Jost, H., Kaminski, R., and

Schaub, T. (2015). ASP Solving for Expanding Uni-

verses. pages 354–367. Springer International Publis-

hing.

Gebser, M., Kaminski, R., Kaufmann, B., and Schaub, T.

(2014). Clingo = ASP + Control: Preliminary Report.

In M. Leuschel and T. Schrijvers, editors, Technical

Communications of the Thirtieth International Con-

ference on Logic Programming (ICLP’14), volume

14(4-5).

Gelfond, M. and Kahl, Y. (2014). Knowledge representa-

tion, reasoning, and the design of intelligent agents:

The answer-set programming approach. Cambridge

University Press, Cambridge, USA.

Heintz, F., Kvarnstr

om, J., and Doherty, P. (2010). Brid-

ging the Sense-Reasoning Gap: DyKnow – Stream-

based Middleware for Knowledge Processing. Advan-

ced Engineering Informatics, 24(1):14–26.

Leone, N., Pfeifer, G., Faber, W., Eiter, T., Gottlob, G.,

Perri, S., and Scarcello, F. (2006). The DLV System

for Knowledge Representation and Reasoning. ACM

Transactions on Computational Logic, 7(3):499–562.

Opfer, S., Niemczyk, S., and Geihs, K. (2016). Multi-Agent

Plan Veriﬁcation with Answer Set Programming. In

Aßmann, U., Brugali, D., and Piechnick, C., editors,

Proceedings of the Third Workshop on Model-Driven

Robot Software Engineering. ACM.

Randell, D. A., Cui, Z., and Cohn, A. G. (1992). A Spatial

Logic based on Regions and Connection. In Nebel, B.,

Rich, C., and Swartout, W., editors, Proceedings of the

3rd International Conference on Principles of Know-

ledge Representation and Reasoning, volume 92, pa-

ges 165–176, San Francisco, CA, USA. Morgan Kauf-

mann.

Skubch, H. (2013). Modelling and Controlling of Behaviour

for Autonomous Mobile Robots. Springer Vieweg, 1

edition.

Skubch, H., Saur, D., and Geihs, K. (2011a). Resolving

Conﬂicts in Highly Reactive Teams. In Luttenberger,

N. and Peters, H., editors, 17th GI/ITG Conference on

Communication in Distributed Systems (KiVS 2011),

volume 17 of OpenAccess Series in Informatics (OA-

SIcs), pages 170–175, Dagstuhl, Germany. Schloss

Dagstuhl–Leibniz-Zentrum fuer Informatik.

Skubch, H., Wagner, M., Reichle, R., and Geihs, K.

(2011b). A Modelling Language for Cooperative

Plans in Highly Dynamic Domains. In van de Mo-

lengraft, M. and Zweigle, O., editors, Special Issue on

Advances in Intelligent Robot Design for the Robocup

Middle Size League, volume 21, pages 423–433.

Tenorth, M. and Beetz, M. (2013). KnowRob: A Know-

ledge Processing Infrastructure for Cognition-Enabled

Robots. International Journal of Robotics Research,

32(5):566–590.

Wang, J. (2010). PR2 at the Intelligent Autonomous

Systems Group, Technical University Munich.

https://www.ﬂickr.com/photos/jiuguangw/5136649984

[Online; accessed December 9, 2016].

WillowGarage (2010). Turtlebot Website.

http://www.turtlebot.com/ [Online; accessed No-

vember 8th, 2016.].

Witsch, A. (2016). Decision Making for Teams of Mobile

Robots. Dissertation, University of Kassel, Kassel,

Germany.

Reasoning for Autonomous Agents in Dynamic Domains

351