Reasoning for Autonomous Agents in Dynamic Domains

Stephan Opfer, Stefan Jakob and Kurt GeihsDistributed Systems Research Group, University of Kassel, Wilhelmshoher Allee 73, Kassel, Germany

{opfer, s.jakob, geihs}@uni-kassel.de

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 cleanup rooms require cognitive skills such as learning, planning, and reasoning. Especially reasoning in dynamicand human populated environments demands for novel approaches that can handle comprehensive and fluentknowledge bases. A promising approach is Answer Set Programming (ASP), offering multi-shot solvingtechniques and non-monotonic stable model semantics. Our objective is to equip multi-agent systems withASP-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 andchose topological path planning as our evaluation scenario. We utilised the Region Connection Calculus asunderlying formalism of our evaluation and investigated the scalability of our implementation. The resultsshow that our approach handles dynamic environments and scales up to appropriately large problem sizes.

1 INTRODUCTION

During the last decade autonomous robots started toplay an increasingly important role in our everydaylife. They are able to vacuum-clean our living room,mow the lawn, and clean the pool. Almost all carmanufacturers are developing autonomous cars. Au-tomated guided vehicles take care of the logisticsin production plants or parcel service centres. Au-tonomous and interactive toys become more and moreintelligent.

Figure 1: Domestic Service Robot PR2. (?)

In the research field of service robots, researchersfocus 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 thenumber 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 robotto handle dynamic environments. This is, because hu-man beings insert, remove, and displace objects inthe environment and are themselves moving obsta-cles from the robot’s point of view. In order to copewith this problem, the robot needs cognitive capabil-ities such as learning, planning, and reasoning. Fur-thermore, a suitable level of abstraction is necessaryto make reasoning about such complex and dynamicdomains more tractable. A robot that should fetch acup, for example, needs to know that a cup is usu-ally situated in a cupboard in the kitchen, but doesnot have to know the cup’s exact coordinates. Fur-thermore, it needs to reason about the reachability ofthe cup from its current position in the building, tak-ing locked doors, obstacles, and the topology of thebuilding into account.

A common way of tackling such problems is thesymbolic knowledge representation and reasoning ap-proach (Brachman and Levesque, 2003). Neverthe-less, our experience is that most benchmarks presenttoday1 are designed in a one-shot fashion, i.d., contin-uously solving one problem after another, without the

1http://www.satcompetition.org/ [Online; ac-cessed December 9, 2016]http://aspcomp2015.dibris.unige.it/ [Online; ac-cessed December 9, 2016]

possibility of using knowledge from previous prob-lems. 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 formulti-shot solving (Gebser et al., 2015). Further-more, such dynamic environments demand a highlydynamic multi-agent coordination framework that inour case is provided by ALICA – A Language for In-teractive Cooperative Agents (Skubch, 2013). In ourpreliminary work (Opfer et al., 2016) we captured thesemantics of ALICA programs within an ASP logicprogram, in order to detect common modelling errors.This forms the basis for integrating ASP with ALICAand allows us to extend it with a general solver in-terface. Through this interface ALICA programs canutilise ASP-based reasoning techniques which in turnmakes ALICA open for a wider set of application do-mains. Moreover, we had to extend the utilised ASPsolver with query semantics according to (Gelfondand Kahl, 2014). In our evaluation, we chose topolog-ical path planning as our scenario. Therefore, we for-mulated a simplified version of the common RegionConnection Calculus (Randell et al., 1992) in ASP,further denoted as RCC-4, and investigated the scala-bility of our RCC-4 formalisation in combination withour 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 inSection 3. Furthermore, the query semantics exten-sion is elaborated in Section 4. Section 5 provides thedescription of our evaluation scenario, whose resultsare presented in Section 6. Finally, we compare ourwork with other approaches in Section 7 and concludewith Section 8.

2 FOUNDATIONS

This section is divided into three subsections. In Sub-section 2.1 the focus is set on concepts of ALICAthat are necessary to understand in the context of thiswork. The same holds for Subsection 2.2 that is aboutthe syntax and semantics of ASP. In Subsection 2.3 anexplanation of the basic relations of the Region Con-nection Calculus 4 is given.

2.1 ALICA

The ALICA framework is designed to coordinate acooperative team of autonomous agents. Explainingall features of this framework is beyond the scope of

this work and we would like to point the interestedreader to the dissertation of Hendrik Skubch (Skubch,2013) and two supplementary publications (Skubchet al., 2011a; Skubch et al., 2011b). In this section,our goal is to explain the fundamental principles ofALICA and focus on the parts that we changed tomake a wider set of general problem solvers acces-sible from within an ALICA program.

The ALICA framework is distributed in the sensethat each agent in the team is running its own inde-pendent ALICA behaviour engine. Each behaviourengine determines the sequence of actions of the lo-cal agent while coordinating with other engines andtaking the current situation as well as a given ALICAprogram into account. Sometimes frameworks likeALICA are also denoted as sequencer (Gat, 1998).

Clean Up Pre: messy, Run: >

Tidy Up

1..∞

Z0 Z1

Z2

Z3

Z4

Drive Pick Up

Transport

Place Back

Post: in place

arrived

picked ∧ near dest.

dropped

picked

near dest.

droppedplaced

Inspect

1..2

Z4 Z5Search Identify

found

identified ∧ notified

Wipe Floor

0..2

Z6 Z7 Z8Drive Wipe Dry

arrived all wet

dried

Figure 2: Simple Clean Up Plan.

An ALICA program is a special tree, whose inte-rior nodes are plans and its leaf nodes are atomic be-haviours. The CleanUp plan in Figure 2 is an exam-ple of such an interior node. A plan can include sev-eral states (Z0. . . Z8) that are connected with guardedtransitions to create finite state machines (FSM). EachFSM is annotated with a task (Tidy Up, Wipe Floor,Inspect) and a pair of cardinalities for the minimumand maximum number of agents allowed in the cor-responding FSM. Each state of a plan, except for ter-minal states (Z4), can contain behaviours and plansthat represent leaf or interior nodes respectively on thenext level of the tree. In Figure 2 plans and behavioursare distinguished by the colour of their boxes, e.g.,state Z0 contains the plan Drive, which is blue, andstate Z1 contains the behaviour Pick Up, which is or-

ange. It is important to note that a plan, which is refer-enced in a state, is a complete plan like the Clean Upplan itself and therefore can include state machineswith other behaviours and plans.

The coloured circles on top of some states in Fig-ure 2 illustrate a possible global execution state of theplan. Each circle represents an agent. The red cir-cle, for example, could be the local agent executingthe Pick Up behaviour, while the other circles rep-resent other agents in the team, whose correspondingbehaviour engine have sent their execution state to thelocal agent.

In order to understand the extension of ALICA bya general problem solver interface, it is necessary tointroduce the notion of ALICA plan variables. Forsimplicity let us modify the Inspect state machinefrom Figure 2 to create a plan on its own.

Inspection Var: X

Inspect

0..1Z4 Z5 Z9

Search Classify Clean Var: X ′

found

in use

identified

done

Figure 3: Inspection Plan.

The purpose of this plan, as shown in Figure 3,could be the identification of coffee cups that shouldbe cleaned, because they are dirty and not used any-more. Therefore, an agent searches for coffee cups instate Z4 and switches to state Z5, in order to classifythem. For remembering which cup was found in stateZ4 the plan variable X can be set to the correspondingcup and thereby influence the agent’s behaviour dur-ing the rest of the plan execution. This influence caneven reach to deeper levels of the plan tree, as indi-cated by variable X ′ of the Clean plan in state Z9. It ispossible to define variable bindings over states in anALICA plan tree, e.g., stating that X denotes the samevariable as X ′. This allows to determine the agent’sbehaviour in the Clean plan, depending on which cupwas 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 contin-uous constraint satisfaction problems and, as it washardwired to ALICA, the applicability of ALICA forother domains was limited. Our extension of ALICAwith a general solver interface tackles this issue (seeSection 3).

2.2 Answer Set Programming

Answer Set Programming (ASP) is a declarative ap-proach for solving NP-search problems. It can beseen as the result of decades of research in the ar-eas of knowledge representation, logic programming,and constraint satisfaction. Thereby, its focus is onexpressivity, ease of use, and computational effec-tiveness (Brewka et al., 2011). An ASP program isspecified by a set of rules of the form a0← a1∧ . . .∧am∧ ∼ am+1∧ . . .∧∼ an. Each ai denotes a predicatep(t1, . . . , tk) with terms t1, . . . , tk build from constants,variables, and functions. Rules consist of three parts,namely the head a0 , the positive part a1 ∧ . . .∧ amand the negative part ∼ am+1∧ . . .∧∼ an of the body.The semantics of the default negation ∼ is that ofnegation-as-failure. That means, ∼ ai is consideredto hold, if it fails to prove that ai holds. Neverthe-less, ASP also provides classic negation ¬ai, whosesemantics is that ¬ai holds, if ai does not.

In order to create ASP programs, the rules haveto be transformed in the following way: ← is trans-formed to :-, ∧ are replaced by , and a rule is endedby a dot. The - in front of robot(X) stands forclassic negation ¬ and not in front to of broken(X)means default negation ∼. The ; is a syntacticshortcut for creating several rules at once. Rule 1,therefore, creates robot(chuck), robot(fox), androbot(lisa). Furthermore, Rules 1 and 2 have anempty body. So their heads are unconditionally true,and they are denoted as facts. Rule 3 makes use ofthe default negation ∼ and states that a robot candrive, as long as it cannot be proven, that it is broken(not broken(X)). Here X is a variable (starts withuppercase letter), which can be substituted with anyelement of the Herbrand universe of the given pro-gram.

1 robot(chuck; fox; lisa).2 broken(fox).3 canDrive(X):-robot(X),not broken(X).4 highFailureRate :- Working

= #count{X : canDrive(X)},Broken = #count{X : broken(X)},Working < Broken.

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

The Herbrand universe of the program in Listing 1only contains four constants (start with lower-case let-ter): {chuck, fox, lisa, highFailureRate}. Rule4 derives the constant highFailureRate, if there aremore broken robots than driving ones. As shown bythis rule, ASP is capable of handling integers andprovides aggregate functions like #count or #sumand arithmetic functions like < or +. The result of

this program will state, that there are three robotsof whom chuck and lisa can drive, the constanthighFailureRate does not occur.

State-of-the-art ASP solvers (Gebser et al., 2014;Leone et al., 2006) usually work in two steps. Firstthey ground the program and afterwards determineall stable models of the grounded program. A pro-gram, as well as every part of it, is grounded if itdoes not contain any variable. In order to create agrounded program, informally speaking, the variablesof each rule are replaced by each possible substitutionwith an element of the program’s Herbrand universe.The Herbrand universe of a program is constructedfrom all constants and functions occurring in the pro-gram. Grounding a program that way would increasethe number of rules enormously, therefore the utilisedgrounding algorithms try to keep the grounded pro-gram as small as possible, without altering the pro-grams meaning. For example, Rule 3 of Listing 1 willnot be part of the grounded program, if there is norobot available.

Solving a grounded program is often done withSAT solving techniques that are adapted to the sta-ble model semantics of ASP. A model in ASP is aset M of ground predicates that for every rule eithercontains the rules head (a0 ∈M), or does not includeall predicates of the positive part of the rule’s body({a1, . . . ,am} * M), or contains predicates from thenegative part of the rules body ({am+1, . . . ,an}∩M 6=/0). Informally speaking, a stable model is as small aspossible and contains predicates, only if they are jus-tified by facts. For a detailed introduction into stablemodel semantics see (Eiter et al., 2009).

In our approach we choose the Clingo 4.5.3 ASPsolver (Gebser et al., 2014), which introduces the no-tion of External Statements to ASP (Gebser et al.,2012; Gebser et al., 2015). External Statements incombination with program sections, explained lateron, are the key concepts for enabling the query seman-tics described in Section 4. The External Statementsare predicates marked with #external. These predi-cates are not removed from the body of a rule duringgrounding, even if they do not appear in the head ofany rule. Furthermore, they can be explicitly set totrue or false. An example for the use of ExternalStatements is given in Listing 2.

1 #external closed(lab,hall).2 c(lab,hall) :- not closed(lab,hall).3 dc(lab,hall) :- closed(lab,hall).

Listing 2: Modeling a door using an ExternalStatement.

This example is part of our evaluation scenariopresented in Section 5 and will be used in ASPVari-

ableQueries presented in Section 4.1. In this exampleclosed(lab, hall) is marked as an External State-ment and is therefore initially set to true. Given thepredicate closed(lab, hall), the head of Rule 3holds and the predicate dc(lab, hall) is part of thestable model. The head of Rule 2 cannot be derivedsince 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. How-ever, since this rule contains an External Statement,it stays part of the grounded logic program. There-fore, it is possible to change a logic program with-out another grounding step by using External State-ments. Furthermore, the size of the stable model doesnot change. For example, if the External Statementclosed(laboratory, hall) is set to true the lab-oratory and the hall are disconnected from each other.If it is set to false the predicate dc(lab, hall) nolonger holds but c(lab, hall) can be derived, thusthe rooms are connected.

Additionally, Clingo introduces program sec-tions (Gebser et al., 2014). Program sections are usedto divide a logic program into different parts, whichcan be grounded separately. An example is given inListing 3.

1 #program rcc4_composition_table.2 dc(X,Z):-pP(X,Y),dc(Y, Z),X != Z.3 #program rcc4_facts4 pP(office1 ,offices).5 dc(offices ,studentArea).

Listing 3: Usage of program sections.

This example contains two program sec-tions identified by the #program prefix, i.d.,rcc4_composition_table and rcc4_facts.Moreover, the order in which they aregrounded influences the facts, which ap-pear in the stable models. If the sectionrcc4_composition_table is grounded beforethe section rcc4_facts, the resulting model wouldonly contain the facts pP(office1, offices)and dc(studentArea, offices). If sectionrcc4_facts is grounded first, the model will con-tain these two facts before the program sectionrcc4_composition_table is grounded. Once thissection is grounded the model will additionallycontain the fact dc(office1, studentArea), sincethe body of this rule holds for the grounding of X byoffice1, 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

based on the Region Connection Calculus 8 presentedby Randell et al. in (Randell et al., 1992). We havebeen inspired to use RCC-4 instead of using RCC-8by the implementation of RCC-4, that is provided bythe QSRlib Foundation (Gatsoulis et al., 2016). Thesecalculi 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 isthe binary relation C(x,y), which expresses that twospatial regions of unknown size are connected. In-formally speaking, they share at least one commonpoint. Furthermore, C(x,y) is reflexive and symmet-ric. By using the C(x,y) relation four base relationsare defined and shown in Figure 4.

x y x

xx

y

yy

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 theyare connected (C), meaning they share a commonpoint, region or part of their border. Region x is aproper part (PP) of Region y, if y contains Region x,which means that Region x is connected to y and nopart of x is outside the border of y. Since this relationis not symmetric the inverse relation PPI is includedas well. Additionally, two regions are disconnected(DC) if they do not share a common point. By us-ing the composition table shown in Table 1 the transi-tive relations between Region x and z can be derived,given the relations between the pairs (x,y) and (y, z).Hereby, ∗ denotes that all four relations can hold. Forexample, if Region x is a proper part (PP) of Regiony 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 * DCPO PP

DCPO PP DC

PODCPOPPI

* PO PPDCPOPPI

PP DC DCPO PP PP *

PPIDCPOPPI

POPPI

PO PPPPI PPI

An example using RCC-4 to model a building isgiven in Section 5. Furthermore, the RCC-4 relations

can be used to model the relation of objects to eachother. For example, in the domain of domestic servicerobots RCC-4 can be used to model objects on a tablewithout defining their exact positions, e.g., a cup anda plate could be proper parts of the table and could bedisconnected from each other, if they are not touchingeach other.

3 EXTENDING ALICA WITH AGENERAL SOLVERINTERFACE

In this section we describe the extension of the AL-ICA framework with a general solver interface, inorder to integrate different solvers into the ALICAframework. By now, ALICA has only been able touse a gradient solver, which is able to solve non-linearcontinuous constraint satisfaction problems.

In order to use other solvers besides this solveran interface IConstraintSolver has to be created.This interface includes four classes and provides twoaccess methods. Every solver which is added by thisinterface has to inherit from the IConstraintSolverinterface. Furthermore, solvers constraint classesderived from the Variables interface with a setof constraints composed from different Terms. Fi-nally, the ProblemDescriptor encapsulates the con-straints, that have been build by using Terms andprovides possible restrictions for the range of theVariables. As already mentioned, the interface pro-vides two access methods. The first method is namedexistsSolution. This method checks if a solu-tion can be found and returns the corresponding truthvalue. The second method is named getSolution.Instead of checking if a solution can be found, thismethod actually calculates the solution for the givenVariables and ProblemDescriptor. The calcu-lated results are returned in a list of values definedby the solver. In this list the results are ordered in thesame way the Variables are ordered, when they aregiven to the solver, so that the caller of this methodcan find the requested values.

For example, the gradient solver returns continu-ous (double) values or an ASP solver could return aset of predicates. Furthermore, the Variables utilisethe hierarchy of ALICA plans. A Variable definedin a plan can be constrained by additional Terms, ifthe identical Variable is used by a plan lower inthe plan tree. For example, in the domain of servicerobots, the robot has to get a cup of coffee from thekitchen. Therefore, the robot’s navigation goal couldbe constraint to the area of the kitchen. In a plan,

deeper in the tree, the robot’s task could be definedin detail. This would add additional constraints tothe navigation goal, for example, that a robot has tobe in a specific area in front of the coffee machineto place the cup in the machine. This is an advantageof the ALICA framework, since additional constraintson a Variable only have to be considered if an agentreaches the specific plan. As a consequence of thishierarchy the time the solvers takes to finish can bereduced, since complex constraints have only to besolved if an agent reaches plans deep in the plan tree.

So far, the presented interface has been used tointegrate three different solvers. The first solver isthe gradient solver, which was a part of the originalALICA framework and has been adapted to the newinterface. 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 processfor a group of robots. This middleware uses the pre-sented interface to exchange variables and proposalsbetween agents.

4 EXTENDING CLINGO WITHQUERY SEMANTICS

This section is divided into two subsections. The cre-ated query structure is presented in Subsection 4.1.Furthermore, an ASPQuery’s workflow is depicted inSubsection 4.2.

4.1 Query Structure

To enable ASP queries a data structure is neededthat can be used by ALICA behaviours. This datastructure is named ASPQuery. Following the inter-face mentioned above, an ASPQuery forwards anASPTerm, which constraints an ASPVariable to thesolver. The ASPTerm provides six fields and allowsthe user to define a set of ASP rules, which are partof a given ASP program section. These rules are thenadded to the solver’s logic program and are used toderive knowledge from the stable models. Further-more, it is possible to add facts to the ASPTerm inorder to add further information to the stable modelsof the ASP solver. For example, to add informationreceived from other robots. Moreover, a dictionary isused to change the truth value of the logic program’sExternal Statements. Additionally, the lifetime of thequery is given, that denotes, how long a query shouldstay part of the solver’s logic program. To ensurethis functionality, each query utilises the informationgiven in the ASPTerm to create a unique External

Statement, that is added to each rule and fact. As longas the query’s lifetime is not expired this ExternalStatement is set to true and the rules and facts arepart of the logic program. Once the query’s lifetime isexpired, this External Statement is set to false, thusremoving the rules and facts form the logic program.As a last point, the query’s type is given. An ex-ample for the use of an ASPTerm is given in Listing 4.

1 term.rule(goalReachable(X) :-reachable(X,Y),g(X),s(Y).);

2 term.addFact(g(r1405B).);3 term.addFact(s(r1411).);4 term.programmSection(ds);5 term.externals(doors);6 term.lifeTime(1);7 term.type(Variable);

Listing 4: Example of an ASPTerm.

Listing 4 is part of an ASP navigation, which willbe explained in detail in Section 5. This example isused to query, if room r1405B can be reached from agiven starting point r1411. Therefore, a rule and twofacts are added to the program section ds (DistributedSystems). Since the resulting query will add rules andfacts to the ASP program, this query can change thestable models of the ASP solver. Therefore, the typeis set to ASPQueryType::Variable. Furthermore,External Statements and their truth values are added,which express if a specific door in the evaluation sce-narios is open or closed. Finally, the query’s lifetimeis 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 fieldsfor the derived classes. The list currentModels isa placeholder in which the solver’s stable models aresaved after the solving process is finished. Addition-ally, the dictionary ruleHeadValues maps the rulesheads of an ASP query to their grounded instancesin the stable models. Furthermore, it contains an

ASPTerm, that has been described above and encap-sulates the rules and facts, which should be added tothe solver’s logic program.

The first class derived from ASPQuery is the ASP-FactsQuery. In our approach the ASPFactsQuery pro-vides the query functionality described in (Gelfondand Kahl, 2014). Gelfond et al. present a querystructure that is used to check, if a ground predi-cate is part of the solver’s stable models. Hereby thequery returns true, if the predicate is part of the sta-ble models, false, if the classical negation is partof the stable models and unknown if neither is partof the stable models. Therefore, the ASPFactsQueryis used to filter the current stable models for givenfacts, which are saved in the list queryValues. Ifthere is a model that contains one of these facts, itis added to the factModelMap. Furthermore, the listfactsTruthValues is used to get the correspondingtruth 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 theASPVariableQuery, that is used to add rules andfacts to an ASP program in order to derive knowl-edge from the solver’s stable models. This kind ofqueries have the following form: query(X1, . . . ,Xn),where X1, . . . ,Xn are variables. The answer to thisquery is a sequence of ground terms t1, . . . , tn wherequery(t1, . . . , tn) is part of the solver’s stable models.In order to enable such kind of queries, the ASP-VariableQuery adds rules and additional facts to thesolver’s program, which are part of the ASPTerm.Hereby the rule heads have the form presented above.During the creation of this query, a unique ExternalStatement 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 thefacts are used as the head of the rule and the Exter-nal Statement as the body. The newly formed rulesare added to the solver’s logic program in the createdprogram section, which is then grounded. Once thesolver has finished the solving process, the results ofthe queried rules are returned to the querying ALICAbehaviour. As soon as the lifeTime of the query isexpired the External Statement is set to false, whichremoves the rules and facts from the solver’s programand the stable models.

4.2 Workflow of Queries

In order to use the described ASPTerm and ASP-Queries, the query structure has to be accessed by theALICA behaviours and has to be given to the ClingoASP solver. Therefore, a wrapper has been created,

that encapsulates the Clingo ASP solver. This wrap-per, named ASPSolverWrapper, is registered at theALICA framework by using the interface explained inSection 3 and can be used by ALICA behaviours. Thewrapper and its workflow are depicted in Figure 6.

Figure 6: Query Workflow.

As mentioned in Subsection 2.1, an ALICA pro-gram consists of a directed acyclic plan tree. TheASPTerms needed to formulate queries are created in-side the runtime conditions of such plans. Once theASPTerm is created (example given in Listing 4), itcan be used by an ALICA behaviour to formulate aquery. Thereby, the External Statements’ truth val-ues are given by a worldmodel class, which encapsu-lates data that was perceived by an agent or receivedfrom other agents, e.g., the state of a door. After theASPQuery has been formulated, it is registered at thewrapper, that passes it to the ASP solver Clingo. Incase of an ASPVariableQuery, the wrapper adds therules and facts to the solver’s ASP program. Addi-tionally, the ASPPlanTreeIntegrator parses the AL-ICA program’s plan tree to enable reasoning aboutits structure, which is done by rules given in back-ground knowledge files. These files, for example,contain rules to detect malformed ALICA programs.The corresponding ASP rules are presented in (Opferet al., 2016). The ASPPlanTreeIntegrator is only usedfor the first registered query, since the predicates staypart of the following stable models as soon as theyhave been grounded. Furthermore, this increases theruntime of the first query but reduces the runtime ofthe following queries, since this program section hasnot to be grounded any more. Once all program parts(queries, background knowledge, and plan structure)have been added, the Clingo module grounds andsolves the program. The hereby derived stable mod-els are passed to the registered queries and saved toenable further use by other parts of the ALICA frame-work, especially the ALICA behaviours. Finally, theresults are returned to the ALICA behaviour via twomethods defined by the created interface. The first

method is named existsSolution, which checks thetruth value of the query without returning stable mod-els or ground predicates. This method can for exam-ple be used in combination with an ASPFactsQuery,which checks if an ASP predicate is part of at leastone or all stable models, since the caller is only in-terested if the queried fact is part of the stable mod-els. The second method is named getSolution. Thismethod is used to return the derived stable models tothe querying ALICA behaviour. This method can forexample be used in combination with an ASPVari-ableQuery, where rules and facts are added. Since theASPVariableQuery adds additional rules and facts tothe ASP program the resulting stable models are re-turned to the querying ALICA behaviour. After theresults are returned, the ALICA behaviour can reactto the changes in the model. By returning the calcu-lated results to the ALICA behaviour, the workflow ofa query is finished and the queries lifetime is reducedby one. After this process, the ALICA behaviour cancreate the next query.

5 EVALUATION SCENARIO

Our approach of handling dynamic domains will beexplained by using the following scenario. The sce-nario is placed in the Distributed Systems Departmentof the University of Kassel. A map of this departmentwas created by using a TurtleBot produced by WillowGarage (?), which is a small service robot equippedwith a 3D camera sensor. Additionally, we equippedthe TurtleBot with a 2D laser scanner in order to cre-ate a map of the department. Our adapted version ofthe TurtleBot is shown in Figure 7 and an annotatedversion of the resulting map is shown in Figure 8.

Figure 7: Adapted Version of a TurtleBot.

This map consists of 19 rooms and is divided

into seven areas, which are highlighted in dif-ferent colours. These areas include from leftto right studentArea (red), mainHallA (black),workshop (green), offices (blue), mainHallB (pur-ple), utility (yellow) and organization (orange).Additionally, 56 points of interest (POI), examplesmarked with dots, are placed on this map, e.g.,different workplaces or the coffee machine. Therobot’s position is marked by a circle. The re-lations between the areas, rooms and POIs aremodelled using the Region Connection Calculus4. Hereby, a POI is a properPart of a spe-cific room and disconnected to all other rooms.Rooms are either partialOverlapping with otherrooms, properPart of areas or disconnected fromboth. Areas can either be partialOverlapping ordisconnected. By using these relations the Dis-tributed Systems Department has been modelled. Ad-ditionally, we used External Statements to modeldoors between two partialOverlapping rooms, asshown in Listing 2. The use of External Statementsenables our approach to change the ASP solver’s logicprogram without an additional grounding step afterthe initial grounding. This should decrease the run-time for answering ASPQueries and keep the mod-els’ size stable since no additional predicates haveto be added to open or close doors. Moreover, weimplemented an ALICA behaviour, which uses anASPFactsQuery to check if the robot’s goal position(cross) is reachable from its current position. Further-more, we implemented a simple path planning ap-proach relying on a transitive closure defined by thepredicate reachable(X,Y). The transitive closure tocheck if a goal is reachable is shown in Listing 5.

1 reachable(X,Y):-pO(X,Y),r(X),r(Y).2 reachable(X,Y):-pO(X,Y),a(X),a(Y).3 reachable(X,Y):-pP(X,Y),r(X),a(Y).4 reachable(X,Y):-reachable(Y,X),X!=Y.5 reachable(X,Z):-reachable(X,Y),

reachable(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 reachablefrom another room r(Y) or area a(Y) if they are par-tial overlapping pO(X,Y), which is defined by Rule 1& 2. Furthermore, a room is reachable from an areaif the room is a properPart (pP) of the area (Rule3). In addition, the reachable relation is symmetric(Rule 4) and transitive (Rule 5).

Figure 8: Map of the Distributed Systems Department.

6 EVALUATION

In this section the evaluation results are presented anddiscussed. Therefore, the presented evaluation sce-nario has been modelled in two ways. The first onepurely relies on modelling the department by facts,named noExt. The second way was presented in Sec-tion 5 is named Ext. Additionally, both ways of mod-elling the department use the transitive closure to en-able a simple path planning approach that is used tocheck if a room or POI is reachable from anotherroom, area, or POI. In Figure 8 the robot’s startingposition is marked by a circle and the goal is markedby a cross. The path leaves the studentArea and fol-lows mainHallA to reach mainHallB since the doorfrom mainHallA to the offices is closed. FrommainHallB the path will enter the offices throughdoor d and finally reaches the goal, which is situatedinside the utility area. Door d is the solely opendoor in mainHallB and is opened and closed via anExternal Statement to simulate a change in the envi-ronment.

To evaluate the wrapper and the implementedquery structure, we use the presented scenarios in thefollowing way: During the first step the logic programis grounded and a navigation query is solved. Herebytwo rooms are selected and checked if they are reach-able from each other, which is not possible in thisstep. The second step is a purely solving step to beable to compare the time needed. Step three is usedto “open a door”, which means either a new ground-ing step (noExt), the change of an External Statement(Ext) or to create a new solver instance. In this stepthe navigation between the rooms is possible. The laststep is a purely solving step again.

The evaluation results using model Ext, noExt,and instantiating a new solver are presented in Fig-ure 9. All measurements include grounding andsolving time and show a very low standard devia-tion of 2.8 ms for the initial grounding with Ext and0.18 ms when using noExt or instantiating a newsolver, which shows that the measured runtimes arestable and will not show significant variations in time.

Initial Ground Solve Open Door Solve0

20

40

60

80

100

120

External Statements No External Statements Instantiate new Solver

runt

ime

[ms]

Figure 9: Comparison of different modelling approaches.

The initial grounding and solving is the most timeconsuming operation and lasts 107.6 ms when usingExt and 47.4 ms when using noExt or a creating anew solver instance. This is caused by additionalsteps during the first grounding, which include theparsing of the ALICA plan tree and grounding the re-sulting predicates. Additionally, these steps includethe verification of the well-formedness of this plantree by ASP Rules and the parsing and grounding ofthe corresponding model of the Distributed SystemsDepartment map. The difference in time betweenthese two results is caused by the way the departmentis modelled. Without the use of External StatementsnoExt each connection between two rooms is mod-elled by a single predicate. When using Ext the con-nection between two rooms is modelled with an Ex-ternal Statement and two rules expressing that a doorcan be either opened or closed. This increases thelogic program’s size which causes a longer groundingand solving time. The test results, when using Ext,show no difference in runtime when solving or chang-ing the truth value of an External Statement. Both op-erations take roughly 13.8 ms. Additionally, the sta-ble model’s size is not affected by changing the truthvalue of an External Statement. In comparison, whenusing noExt or when using a new solver instance,solving and changing a door state differ in runtime.Solving without any change in the model will take6.5 ms when using noExt but changing a part of the

model will last 19.6 ms, since a new program sectionhas to be grounded. Furthermore, this increases tosize of the stable model’s size by 156 facts, which isthe number of relations between the rooms of the Dis-tributed Systems Department. In contrast to noExtcreating a solver differs in runtime regarding a changein the model, since a initial grounding step has to beperformed for every change resulting in an groundingtime of 47.4 ms.

Due to the fact that the ALICA framework stepfrequency is usually set to 30 Hz, an ALICA be-haviour can formulate up 30 queries per second. InFigure 10 all three methods for modelling the de-partment are compared with respect to the amount ofchanges per second.

0 5 10 15 20 25 300

5

10

20

30

40

50

External Statements No External Statements Instantiate new Solver

Number of Changes

runt

ime

[ms]

Figure 10: Comparison of measured time regarding changesin the model.

The x-axis shows the number of changes in themodel and the y-axis the queries average runtime in30 ALICA framework steps. Since there is no differ-ence in solving and changing a value when using Extthe blue line is constant. In comparison to this theruntime of noExt increases when changes are made,since a new program part has to be grounded for eachchange. Both lines intersect at 17 changes. Corre-sponding to this result, we may conclude that noExtis suitable, if the modelled scenario is stable and doesnot change often. In dynamic scenarios we suggestthe use of External Statements, since changes do notaffect the runtime. Furthermore, when using noExtthe stable model’s size increases with every changemade. In contrast, when using Ext, the models sizestays the same. Therefore, we recommend to usenoExt only for stable scenarios, since the model sizewill grow rapidly and will slow down the process ofhandling the models. This could be countered by dis-carding and creating a new ASPSolver instance aftera few changes. This method is depicted by the greenline, which intersects the blue line by six changes andis the slowest solution. Therefore, we suggest the useof Ext.

Additionally, we evaluated the scalability of the

Region Connection Calculus 4. Therefore, we usedthe navigation scenario presented in 4 and expandedthe number of rooms, starting from 100 rooms andending with 1700 rooms. Furthermore, we tested dif-ferent percentages of connection between the roomsranging from 25 % to 100 %. The results are shown inFigure 11 and 12.

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

0.5

1

1.5

2

2.5

3

3.5

4

25 50 75 100

Number of Rooms x100

runt

ime

[h]

1 2 3 4 5 60

0.51

1.52

2.53

3.54

4.55

Number of Rooms x100

runt

ime

[min

]

Figure 11: Runtime of the initial grounding.

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

400

800

1200

1600

25 50 75 100

Number of Rooms x100

runt

ime

[ms]

1 2 3 4 5 60

40

80

120

160

200ru

ntim

e [m

s]

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 stoppedat 1800 rooms with 100 % connection, since thegrounding step did not stop after four hours and wasaborted. Considering the exponential increase in run-time, we suggest not to use the Region ConnectionCalculus 4 for transitive closure based path planningin dynamic domains, if more than 600 regions haveto be considered. We suggest this number, since afteran initial grounding of roughly five minutes, the robotcan 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 anASP solver for the use in different robotics scenar-ios. These frameworks and further related work arepresented in this section.

One of these frameworks is DyKnow presentedin (Heintz et al., 2010). The ALICA framework pro-vides a domain independent framework to model thebehaviour of multiple agents. These agents can col-lect domain specific information and knowledge inan unspecified way and use these to adapt their be-haviours. In comparison to this DyKnow focuses onthe distributed collection and distribution of varyingkinds of data, that includes raw sensor values, pro-cessed sensor values or even predicates, which holdbetween objects recognised in the world. The neededprocesses to collect and to process the data are spec-ified with the knowledge processing language pro-vided in (Heintz et al., 2010). These processes pro-vide collected data respectively derived informationand knowledge which can be used by multiple agents.Furthermore, these processes can provide knowledgeabout objects and the relations between them, whichcould be passed to a solver to allow reasoning aboutthem. This can be compared to the knowledge basegiven in our wrapper and the domain specific knowl-edge given in ALICA behaviours. In contrast tothe ALICA framework DyKnow does not provide theuse of hierarchically constrained variables that can beused to formulate queries of increasing complexity toan ASP solver.

Another framework is KnowRob presentedin (Tenorth and Beetz, 2013). The central part of thisframework is the knowledge base. This knowledgebase provides a knowledge store and access methodsfor retrieving information saved in Prolog relations.The “virtual knowledge base” is an extension to arobot’s knowledge base by computation of abstractrepresentations only when the corresponding datais queried and by forwarding queries to parts of therobot which can provide better answers. In compari-son to the ALICA framework both use a declarativeprogramming language to create the knowledge base.Furthermore, queries can increase the knowledgebase during the computation of their answer. But incontrast to the ALICA framework with the includedASP wrapper KnowRob does not support multipleagents.

Furthermore, in (Gebser et al., 2015) one-shotsolving is compared with multi-shot solving based onExternal Statements. Hereby they used benchmarksgiven by the Fifth ASP Competition and support ourresults regarding External Statements in dynamic do-mains. Nevertheless, they always investigated Exter-nal Statements in the context of expanding universes.According to our knowledge, our work is the first in-vestigating the advantages of External Statements inthe context of dynamic universes of almost constantsize.

8 CONCLUSION AND FUTUREWORK

In this paper we presented the integration of theClingo ASP solver with the ALICA framework.Therefore, an interface has been created, that canbe used with several solvers. Additionally, the inte-grated ASP solver has been wrapped to enable queriesagainst resulting models and temporarily adding rulesand facts. Several tests have been performed in or-der to evaluate the runtime of a query. The resultsshowed that both ways of modelling (with or with-out External Statements) respond in less than 20 msand therefore can be considered as suitable for dy-namic domains. Nevertheless, we prefer to use Ex-ternal Statements, since they do not increase the sizeof the resulting stable models when the environmentchanges. Another option to avoid an increasing modelsize is to create a new solver instance whenever some-thing changes. However, this would significantlyincrease the query runtime, making this option un-favourable starting from 5 changes per second. There-fore, we propose the use of External Statements tomodel dynamic domains, such as human-populatedservice robotic domains. Furthermore, we evaluatedthe scalability of the Region Connection Calculus 4using the example of determining the transitive clo-sure of the reachability relation. From the results, wemay conclude that the calculus scales up to a numberof 600 regions, since after an initial grounding timeof roughly five minutes an agent can still query itsknowledge base at a rate of 5 Hz.

In our future work, we will further investigatethe performance of External Statements in dynamicdomains by applying the presented approach in var-ious scenarios. This investigation will be joinedwith knowledge-based collaboration between multi-ple agents. Currently each agent has its own knowl-edge base that is independent from all other knowl-edge bases. We want to allow agents to query knowl-edge bases of other agents. In the scenario from Sec-tion 5, for example, an agent that is unable to reachits destination could ask other agents for open doors,instead of searching for open doors by itself.

Another aspect of knowledge-based collaborationis about global consistent stable models. In ASP, it ispossible that several valid models exist, but it is oftendesirable that a team agrees on the same or a simi-lar model. Therefore, agents could exchange relevantparts or even complete models between each other, inorder to choose the local model that is most similar tothe parts received from other agents.

REFERENCES

Brachman, R. J. and Levesque, H. J. (2003). KnowledgeRepresentation and Reasoning. Morgan Kaufmann,Morgan Kaufmann Series in Artificial Intelligence.

Brewka, G., Eiter, T., and Truszczynski, M. (2011). AnswerSet Programming at a Glance. Communications of theACM, 54(12):92–103.

Eiter, T., Ianni, G., and Krennwallner, T. (2009). AnswerSet Programming: A primer. In Tessaris, S., En-rico Franconi, Eiter, T., Gutierrez, C., Handschuh, S.,Rousset, M.-C., and Schmidt, Renate A. Schmidt, ed-itors, Reasoning Web. Semantic Technologies for In-formation Systems, volume 5689. Springer, Berlin andNew York.

Gat, E. (1998). On Three-Layer Architectures. In Ko-rtenkamp, D., Bonasso, R. P., and Murphy, R., editors,Artificial Intelligence and Mobile Robots: Case Stud-ies of Successful Robot Systems, pages 195–210. MITPress, 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 ofthe 29th International Workshop on Qualitative Rea-soning, pages 36–41.

Gebser, M., Grote, T., Kaminski, R., Obermeier, P.,Sabuncu, O., and Schaub, T. (2012). Answer Set Pro-gramming for Stream Reasoning. In Eiter, T. andMcIlraith, S., editors, Proceedings of the ThirteenthInternational Conference on Principles of KnowledgeRepresentation and Reasoning (KR’12), volume 13,pages 613–617. AAAI Press.

Gebser, M., Janhunen, T., Jost, H., Kaminski, R., andSchaub, T. (2015). ASP Solving for Expanding Uni-verses. In Calimeri, F., Ianni, G., and Truszczyn-ski, M., editors, Proceedings of the 13th Interna-tional Conference on Logic Programming and Non-monotonic Reasoning, pages 354–367. Springer Inter-national Publishing.

Gebser, M., Kaminski, R., Kaufmann, B., and Schaub, T.(2014). Clingo = ASP + Control: Preliminary Report.In M. Leuschel and T. Schrijvers, editors, TechnicalCommunications of the Thirtieth International Con-ference on Logic Programming (ICLP’14).

Gelfond, M. and Kahl, Y. (2014). Knowledge Representa-tion, Reasoning, and the Design of Intelligent Agents:The Answer-Set Programming Approach. CambridgeUniversity Press, Cambridge, USA.

Heintz, F., Kvarnstrom, J., and Doherty, P. (2010). Bridgingthe Sense-Reasoning Gap: DyKnow – Stream-basedMiddleware for Knowledge Processing. AdvancedEngineering Informatics, 24(1):14–26.

Leone, N., Pfeifer, G., Faber, W., Eiter, T., Gottlob, G.,Perri, S., and Scarcello, F. (2006). The DLV Systemfor Knowledge Representation and Reasoning. ACMTransactions on Computational Logic, 7(3):499–562.

Opfer, S., Niemczyk, S., and Geihs, K. (2016). Multi-AgentPlan Verification with Answer Set Programming. In

Aßmann, U., Brugali, D., and Piechnick, C., editors,Proceedings of the Third Workshop on Model-DrivenRobot Software Engineering. ACM.

Randell, D. A., Cui, Z., and Cohn, A. G. (1992). ASpatial Logic based on Regions and Connection. InNebel, B., Rich, C., and Swartout, W., editors, Pro-ceedings of the 3rd International Conference on Prin-ciples of Knowledge Representation and Reasoning,volume 92, pages 165–176, San Francisco, CA, USA.Morgan Kaufmann.

Skubch, H. (2013). Modelling and Controlling of Behaviourfor Autonomous Mobile Robots. Springer Vieweg, 1edition.

Skubch, H., Saur, D., and Geihs, K. (2011a). ResolvingConflicts in Highly Reactive Teams. In Luttenberger,N. and Peters, H., editors, 17th GI/ITG Conference onCommunication in Distributed Systems (KiVS 2011),volume 17 of OpenAccess Series in Informatics (OA-SIcs), pages 170–175, Dagstuhl, Germany. SchlossDagstuhl–Leibniz-Zentrum fuer Informatik.

Skubch, H., Wagner, M., Reichle, R., and Geihs, K.(2011b). A Modelling Language for CooperativePlans in Highly Dynamic Domains. In van de Molen-graft, M. and Zweigle, O., editors, Special Issue onAdvances in Intelligent Robot Design for the RobocupMiddle Size League, volume 21, pages 423–433. Else-vier.

Tenorth, M. and Beetz, M. (2013). KnowRob: A Knowl-edge Processing Infrastructure for Cognition-EnabledRobots. International Journal of Robotics Research,32(5):566–590.

Witsch, A. (2016). Decision Making for Teams of MobileRobots. Dissertation, University of Kassel, Kassel,Germany.