ROSoClingo:
A ROS package for ASP-based robot control⋆
Benjamin Andres1, Philipp Obermeier1, Orkunt Sabuncu1, Torsten Schaub1,
and David Rajaratnam2
1{bandres,phil,orkunt,torsten}@cs.uni-potsdam.de
2daver@cse.unsw.edu.au
1University of Potsdam, 2University of New South Wales
Abstract. Knowledge representation and reasoning capacities are vital
to cognitive robotics because they provide higher level cognitive func-
tions for reasoning about actions, environments, goals, perception, etc.
Although Answer Set Programming (ASP) is well suited for modelling
such functions, there was so far no seamless way to use ASP in a robotic
environment. We address this shortcoming and show how a recently de-
veloped reactive ASP system can be harnessed to provide appropriate
reasoning capacities within a robotic system. To be more precise, we fur-
nish a package integrating the reactive ASP solver oClingo with the pop-
ular open-source robotic middleware ROS. The resulting system, ROSo-
Clingo, provides a generic way by which an ASP program can be used
to control the behaviour of a robot and to respond to the results of the
robot’s actions.
1
Introduction
Knowledge representation and reasoning capacities are vital to cognitive robotics
because they provide higher level cognitive functions for reasoning about actions,
environments, goals, perception, etc. Although Answer Set Programming (ASP)
is well suited for modelling such functions, there was so far no seamless way to
use ASP in a robotic environment. This is because ASP solvers were designed as
one-shot problem solvers and thus lacked any reactive capacities. So, for instance,
each time new information arrived, the solving process had to be re-started from
scratch.
In what follows, we address this shortcoming and show how a recently de-
veloped reactive ASP system [7,6] can be harnessed to provide knowledge rep-
resentation and reasoning capacities within a robotic system. This is possible
because such systems allow for incorporating online information into operative
ASP solving processes. We accomplish this by integrating our ASP approach
into the popular open-source middleware ROS1 (Robot Operating System; [12])
which has become a de facto standard in robotics over the last years. As such,
⋆This paper is also submitted at the Combined Planning Workshop RSS 2013.
1 http://www.ros.org
arXiv:1307.7398v1  [cs.RO]  28 Jul 2013
2
Andres et al.
ROS provides hardware abstraction and tools supporting the development of
robot applications.
To be more precise, we furnish a ROS package integrating the reactive ASP
solver oClingo with the popular open-source ROS robotic middleware. The re-
sulting system, called ROSoClingo, provides a generic method by which an ASP
program can be used to control the behaviour of a robot and to respond to
the results of the robot’s actions. In this way, the ROSoClingo package plays
the central role in fulfilling the need for high-level knowledge representation and
reasoning in cognitive robotics by making details of integrating a highly capa-
ble reasoning framework within a ROS based system transparent for developers.
In this regard, ROSoClingo can also function as an important component for
bridging the gap between high-level task planning and low-level motion plan-
ning. In what follows, we provide the architecture and basic functioning of the
ROSoClingo system. And we illustrate its operation via a case-study conducted
with the ROS-based TurtleBot2 simulation in a Gazebo3 simulation of an office
floor. The resulting work is publicly available4 and we are committed to submit
the ROSoClingo package to the public ROS repository.
The Golog programming language [10] is one of the most widely known ap-
proaches to the development of a declarative agent reasoning language. With a
formal semantics based on the Situation Calculus [11] it allows for the specifica-
tion of high-level agent behaviours for agents acting within dynamically changing
environments. The potential power of this approach was first shown on a real
robot with the implementation of the Golex system [9]. Golex extended Golog
with execution monitoring functionality to monitor and ensure the successful
execution of the primitive Golog actions.
With the success of Golog, further work has focused on extending ASP with
some of the expressive constructs found in Golog [13], thus allowing the powerful
search capabilities of modern reasoners to be combined with the programming
ease of Golog. The development of ROSoClingo can therefore be understood in
the context of allowing Golog, and other, ASP extensions for agent reasoning to
be directly applied to the high-level control of ROS based robots.
Finally, we list some related work which utilize ASP or other declarative
formalisms in cognitive robotics. The work in [3,2] uses ASP for representing
knowledge via a natural language based human robot interface. Additionally,
ASP is used for high level task planning. In [1,5] action language formalism and
ASP are used to plan and coordinate multiple robots for fulfilling an overall
task. They have also integrated task and motion planning with external calls
from action formalism to geometric reasoning modules [4]. All these works can
naturally and highly benefit from the usage of ROSoClingo. Having stated that,
ROSoClingo can be basically used in any autonomous robotics system in which
high-level reasoning tasks are essential and steep initial integration difficulties
are desired to be avoided.
2 http://turtlebot.com
3 http://gazebosim.org
4 http://www.cs.uni-potsdam.de/wv/ROSoClingo/index.html
ROSoClingo
3
Publishes 
Nodes
Subscriber 
Nodes
ROS topic
Fig. 1: ROS topics provide many-to-many asynchronous message passing.
2
Robot Operating System
ROS provides a middleware for robotic applications [12]. At its most basic level
this consists of a loosely-coupled communication framework for sending mes-
sages between processes. ROS defines a host and language independent TCP/IP
protocol for exchanging messages, thus allowing these processes to be written in
a variety of programming languages and to be distributed across multiple host
computers.
ROS standardises methods and structures for organising software into pack-
ages. Packages can contain a variety of components, from definitions of message
formats through to libraries and executable programs. Executable programs that
integrate into the ROS framework are instantiated as special processes known
as nodes.
There are two basic mechanisms for communications between nodes. The
publisher-subscriber mechanism provides for asynchronous comunications where-
by multiple nodes can broadcast messages on a named communication channel
(known as a topic), that are in-turn listened to by multiple subscribers (Figure 1).
Alternatively, ROS services provide for synchronous communication via a remote
procedure call (RPC) mechanism whereby one node can call a service provided
by another node.
All messages in ROS are strongly-typed, and all communications using topics
or services must use these types. ROS provides a number of primitive data types
(e.g., bool, int32, float32, string) as well as a list operator. These can be
combined to produce arbitrarily complex types in a similar manner to structs
in C and C++. These complex data types are defined as part of the ROS package
structure. To ease development and code maintenance ROS package names in-
herently correspond to namespaces of the same name and therefore the complex
data types are always defined with respect to a namespace. A typical ROS sys-
tem defines a number of common namespaces (e.g., std msgs, geometry msgs)
and data types (e.g., geometry msgs/Pose).
While ROS services allow for a simple RPC mechanism, they are not suitable
for more complex behaviours, such as situations where a task may take place
over an extended time frame, may be preempted, and may require feedback
throughout its life-cycle. ROS provides for such complex behaviour through the
actionlib framework (Figure 2). This framework allows a client-server interface
4
Andres et al.
cancel
Action
Client
API 
Action
Server
API 
Action Interface 
      topics
goal
status
result
feedback
Client Node 
Server Node 
Fig. 2: ROS actions provide preemptible client-server communications.
to be defined whereby an action client is able to set and cancel goals on an
action server. The action server in turn executes the goal and provides constant
feedback and progress of its attempts to fulfil the goal. While implemented using
ROS topics as a message transport mechanism, each action interface defines a
high-level API for client-server interaction.5
As a prototypical example of a ROS action, the move base package imple-
ments an action interface that provides path-planning and robot control func-
tionality for moving a robot around an environment. We now briefly outline this
package, to provide both a sense of how the actionlib framework works as well
as to provide details of an important module that we shall discuss later.
The move base package (Figure 3) provides a highly configurable ROS node
that is an essential component of the ROS navigation stack. The system requires
a number of data sources, such as laser sensor data, localisation information,
and map information. The laser sensor data is used to perform basic obstacle
avoidance, while localisation information allows the robot to know where it is
located within the map. A map consists of a 2-D occupancy grid that indicates
whether a point on the grid is occupied or free. Robot navigation within the
node takes place at two distinct levels. Global planning calculates the route from
the robot’s current location to a goal location, while local planning provides
for movement towards a general direction while allowing path flexibility to avoid
obstacles. A range of different global and local planning algorithms are supported
through a plugin architecture.
A navigation goal is specified in terms of a robot destination pose (i.e., posi-
tion and orientation). When a goal is sent to the move base server it computes
a path to that goal location and then successively generates the movement com-
mands for the robot base controller. If at some point the robot is unable to
proceed with its plan, for example due to a door being blocked, then the server
will undertake recovery behaviour and will re-plan accordingly. If the recovery
fails then the task will be aborted. Throughout this process the server provides
constant feedback as to the current location of the robot, as well as the status
5 For more extensive information on programming with the ROS actionlib framework
the interested reader is referred to http://www.ros.org/wiki/actionlib
ROSoClingo
5
move_base  
Action Interface
goal pose
status
current pose
 input
node 
map_server 
 
sensors 
odometry 
transforms 
 global
planner 
  local
planner 
robot base controller 
Fig. 3: ROS move base provide an action interface for robot movement.
of the navigation process, for example that the task has been aborted. Goals are
preemptible, so that a robot navigating towards some location will give up that
goal if it is given a new destination goal.
The action interface provided by the move base package is arguably the most
important ROS action service for mobile robots. Furthermore, with a complex set
of features, such as the possibility of failure, it serves to highlight the potential
complexity in trying to integrate logical reasoning with a real robotic systems.
Consequently, the move base package forms much of the integration work that
is outlined in the rest of this paper.
2.1
oClingo
A classical ASP system, such as gringo/clasp, is designed to solve problems in
an one-shot procedure: it takes a problem encoding as input, computes the an-
swer sets and terminates afterwards. Since this approach does not fully embrace
the needs of modern dynamic domains, such as robotics, a reactive ASP solver,
oClingo, was developed that additionally takes external data streams into ac-
count. Such a stream is represented there by an online progression, a sequence
of events, i.e., data updates and inquiries, given in the form of ASP ground facts
and integrity constraints. The general problem itself is described by a reactive
logic program, an ASP program that is partitioned into three parts: a base part
describing static knowledge, and an incremental as well as a volatile part which
both contain rule schemata based on a discrete time (integer) parameter. The
role of the incremental part is to symbolize accumulated knowledge over in-
creasing time, whereas the volatile part only holds information that specifically
concerns the current point in time. All in all, a reactive logic program formulates
the persistent knowledge and, thus, acts as the offline counterpart to an online
progression. We will further illustrate these concepts by examples in Section 4.
Technically, oClingo relies and expands on iClingo [8], an incremental ex-
tension of gringo/clasp, as well as on gringo/clasp itself. That is, the oClingo
system is initialized with a reactive logic program as input (Figure 4). After
6
Andres et al.
Fig. 4: Basic workflow between oClingo and a client application.
 Actionlib API 
 
Existing ROS
components 
move_base 
Other ROS
module 
Reasoning
layer 
Interface 
layer
 ROS topic base 
input/output 
in_rosoclingo
out_rosoclingo
 oClingo
 ROSoClingo Node
input feeder
 action extractor
 task plan
 query
 Action
 Goal
Cancel
 Status
Result
Feedback
Other 
interface
move_base 
interface
ASP program
3
4
2
5
6
1
Fig. 5: The general architecture and main workflow of ROSoClingo.
that, a client application can connect to oClingo and stream data formatted
as an online progression. For each incoming event oClingo instructs gringo to
add the contained clauses to the existing ground program. This addition of new
information is either temporarily (valid only for the current event) or persistent
depending on the lifetime annotation provided by the event for each clause. Sub-
sequently, oClingo invokes iClingo to compute all answers for the current ground
program, returns them to the client and waits afterwards for new events. The
oClingo system only terminates if explicitly requested by the client.
3
ROSoClingo
In this section we describe the general architecture and functionality of the
ROSoClingo package. With the help of reactive ASP, ROSoClingo provides a way
of handling high-level knowledge representation and reasoning tasks occurring
in autonomous robots running the ROS software.
Consider a task planning problem, a task that any autonomous robot should
be capable of performing. For instance, a robot is given a goal of moving from
the kitchen of a house to the living room in order to serve food. Even if the
ROSoClingo
7
request(Goal,C)
Specifying a Goal request at cycle C.
Cancellations are send in the same way.
action lib(A,P,C) Commanding actionlib A to run with parameters P at cycle C.
return(A,V,C)
Specifying the return value V of actionlib A run in cycle C.
Fig. 6: Keywords used for communicating between ROSoClingo and oClingo.
robot has many individual behaviours, like moving from one point to another or
holding food with the help of respective ROS packages, computing a complete
task plan requires high-level knowledge representation and reasoning capabili-
ties. There might even be more than one possible path to the living room, which
may require more elaborate planning and execution. The robot might, for in-
stance, need to first go to the hallway and then to the living room in case the
alternative path is blocked by an obstacle. The robotics developer can encode
such planning tasks in reactive ASP keeping only the interface requirements of
the underlying behaviour nodes in mind and avoiding implementation details
of their functionality (motion planning for example). Then, using the resulting
ASP encoding with the ROSoClingo package the developer can readily integrate
task planning while details of controlling and integrating oClingo within the
ROS middleware becomes transparent.
Figure 5 depicts the main components and workflow of the ROSoClingo sys-
tem. It consists of a three layered architecture. The first layer consists of the
core ROSoClingo component and the definition of an actionlib API. This API
allows other components to use the services provided by the ROSoClingo node.
The package also defines the message structure for communication between the
core ROSoClingo node and the various nodes of the interface layer. The inter-
face layer, on the other hand, provides the data translations between what is
required by the ROSoClingo node and any ROS components for which it needs
to integrate. This architecture provides for a clean separation of duties, with the
well-defined abstract reasoning tasks handled by the core node and the integra-
tion details handled by the interface nodes.
3.1
The ROSoClingo Core
The main ROSoClingo node is composed of the reactive answer set solver oClingo,
an action extractor, and an input feeder. Through its actionlib API, it can re-
ceive goal and cancellation requests as well as send result, feedback, and status
messages to a client node (marked by 1 in the figure). The reactive ASP program,
encoding the high-level task planning problem, is given to the ROSoClingo node
at system initialization (marked by 2). During initialization, ROSoClingo sets
the current logical time point to 1. This time point is incremented at the end of
each cycle.
A cycle of ROSoClingo’s workflow may start with a goal for the robot arriving
via the actionlib interface (marked by 1). For instance, commanding the robot
to go to the living room can be a goal request. This request is transformed into
8
Andres et al.
an input stream update before feeding to oClingo (marked by 3) by the input
feeder. oClingo receives the goal as a stream update and searches for an answer
set representing a task plan for the robot to follow. Each action of the plan, in
principle, should be executed by a respective ROS node. For instance, an action
of moving to the door connecting kitchen and hallway can be executed by the
move base ROS action node. The keywords of Figure 6 allow for a communica-
tion protocol between ROSoClingo and oClingo. The action extractor takes the
action at the current logical time point, prepares it as a goal request (marked by
4) and sends it to be executed by the respective ROS node (marked by 5). The
result of the execution is received by the input feeder component of the ROSo-
Clingo node (marked by 6). The communication between ROSoClingo and other
ROS nodes is detailed in Section 3.2. The result is processed and transformed
into a new input stream update for oClingo, which completes the current and
initiates a new cycle of ROSoClingo. The (un)successful result may generate new
knowledge for the robot about the world (for example, the fact that a doorway
is blocked or a new object is sensed). Additionally, the next input update in-
cludes a fact so that the action executed is committed by oClingo during further
searches for a plan.
Note that the ROSoClingo package supports multiple goal requests at a time.
Each time a new goal received, the input feeder appends the goal to a list and
feeds it to oClingo in the next cycle. The status of each goal is also tracked by
ROSoClingo.
3.2
Integrating with Existing ROS Components
The core ROSoClingo node needs to issue commands to, and receive feedback
from, existing robotics components. The complexity of this interaction is handled
by the nodes at the interface layer (Figure 5). Unlike the components of the
reasoning layer it is, unfortunately, not possible to define a single ROS interface
to capture all interactions that may need to take place. Firstly, there will need
to be data type conversions between the individual modules. For example, the
move base node expects a robot pose as its goal, while an action to move a robot
arm might require a more complex goal structure consisting of a set of joint-
trajectories. Turning ROS messages into a suitable set of oClingo statements
will therefore require data type conversions that are specific for each action or
service type.
A second complicating issue is that the level of abstraction of a ROS action
may not be at the appropriate level required by the ASP program. For example,
the pose goal for moving a robot consists of a Cartesian coordinate and orien-
tation. However, it is unlikely that one would want a logical reasoner to have
to reason about Cartesian coordinates. Instead one would hope to reason about
abstract locations and the relationship between these locations; for example that
the robot should navigate from the kitchen to the bedroom via the hallway. Fur-
thermore, the desired orientation of the robot when it arrives in the bedroom
may not be something that is of interest to the reasoner.
ROSoClingo
9
While it is not possible to provide a single generic interface to all ROS com-
ponents, it is however possible to outline a common pattern for such integration.
The rest of this section outlines the integration of ROSoClingo with ROS ac-
tions, and in particular the move base action outlined in Section 2. ROS actions
typically encapsulate the high-level behaviour and functionality of a robot, and
are therefore the most natural level at which a high-level robot controller would
expect to communicate with the rest of the robotic system. Furthermore, they
are arguably the most complex components of a ROS system. Consequently,
showing how ROSoClingo integrates with existing ROS actions encapsulates all
the complexity that one would expect of integration with any other ROS com-
ponent.
For each existing ROS component that needs to be integrated with ROSo-
Clingo there will need to be a corresponding interface component. In some cases
interface components can be combined into a single ROS node to communicate
with multiple lower-level ROS nodes, but in general one can imagine a mostly
one-to-one correspondence between nodes of these two layers.
An important consequence of our architecture is that every interface node
needs to read every message that is published by the ROSoClingo node on
the output topic. It is therefore important that the message format for the
out rosoclingo topic allows the interface components to easily parse the mes-
sages and discard those messages that are intended for a different component.
The inputs to, and outputs from, a running oClingo reasoner consist of sets
of facts. It is therefore the role of the ROS interface layer to perform any data
conversions between the ASP world of facts and the low-level ROS commands.
We adopt a straightforward message type (named rosoclingo/InterfaceIO)
to facilitate this process. This type consists of an interface name and a list of
text formatted facts.
When a message is sent from ROSoClingo to the interface layer, individual
interface components can quickly parse the interface name to determine the
intended recipient and discard non-relevant messages. On the other hand, when
sent from an interface component to the ROSoClingo node, the interface name
indicates the origin of the fact, which may be useful, even if only as a debugging
aid.
For the sake of simplicity and presentation it is useful to make some as-
sumptions, in showing how the system integrates with the move base action.
A common assumption in robotic applications is to identify tagged points with
an abstract location. For example some coordinate location specifying a point
in a bedroom, say (10.5,11.2), will be associated with the label “bedroom”.
Navigation can then take place with reference to the tagged locations. This tech-
nique works for a broad range of behaviours, such as sending the robot to specific
locations.
10
Andres et al.
Fig. 7: The mailbot simulation in progress as seen in Gazebo.
4
Case Study
We demonstrate the application of our ROSoClingo package on a mail delivery
scenario running ROS software. The scenario consists of a robot, whose task is
to pick up and deliver mail packages exchanged among offices [14]. Whenever a
mail delivery request is received, the robot has to go to the office requesting the
delivery, pick up the mail package, and go to the destination office in order to
do the delivery. In this scenario the robot is able to carry up to three packages
and handle multiple requests at a time. Delivery requests can also be cancelled
during task execution. If a request is cancelled when the package has already
been picked up, it is delivered back to its origin for disposal. The task has a
highly dynamic nature and requires reasoning capacity for detailed planning.
The robot we use is a TurtleBot, which is well supported within the ROS
community and commonly used for small delivery tasks. Offering a mobile plat-
form with an integrated Microsoft Kinect as a three dimensional sensor. Our
office building is provided by Gazebo, a simulator supported by ROS, able to
realistically simulate three dimensional environments. This allows us to run the
TurtleBot in a controlled, yet physically plausible environment, while avoiding all
too common problems associated with hardware, e.g. short battery life, defunct
components, etc.
We use the ROS move base action library for robot movement among offices.
For picking up and delivering packages, two dedicated action libraries are used
(pickup and deliver). Figure 7 shows the Gazebo environment used in our
case study. It consists of 4 consecutive offices on one floor; office1 to office4
appearing from left to right.
In our scenario the robot stands in front of office1 and after some time
receives a request to deliver a package from office3 to office2. This request is
ROSoClingo
11
Table 1: Task plans returned by oClingo for varying requests.
plan
1
2
3
step
1 action(move base,office2,1) action(move base,office2,1) action(move base,office2,1)
2 action(move base,office3,2) action(move base,office3,2) action(move base,office3,2)
3 action(pickup,1,3)
4 action(move base,office2,4)
action(pickup,2,4)
5 action(deliver,1,5)
action(move base,office4,5)
6
action(deliver,2,6)
later cancelled and a new request to deliver a package from office3 to office4
is issued.
Since there are no pending requests just after the start of the simulation,
oClingo returns an empty task plan. This results in ROSoClingo awaiting a new
request to be issued. When the first request is received, the input feeder trans-
forms said request into an input stream update for oClingo :
#step 1.
_request(goal(office3 ,office2 ,1) ,1).
#endstep.
The input stream update is enclosed in #step 1. and #endstep. directives.
The integer number following the #step represents the cycle the request is send
to oClingo. The keyword predicate _request identifies the transformed goal
request issued to ROSoClingo with its first parameter and the cycle the request
becomes active with its second. The parameters of goal state the sending office,
the destination office, and an unique package identifier, in that order.
oClingo now adapts the task plan to ensure the execution of the request
as shown in Table 1 under plan 1. In more detail the plan involves to use
the move base action library to move the robot from office1 over office2 to
office3 at the cycles 1 and 2, respectively. Then, the robot shall use the pickup
action library to pick up the package in cycle 3 and move back to office2 in
cycle 4. Lastly, the package is to be handed over by means of the deliver action
library in cycle 5. Note that both the pickup and the deliver action require
the package identifier as parameter.
ROSoClingo’s action extractor takes the task plan outputted as an answer set
by oClingo and publishes the action planned for the current (first) cycle on the
out rosoclingo topic as a rosoclingo/InterfaceIO message. The move base
interface reacts to the message, transforms the label office2 into a coordi-
nate location and sends the result of the action back to ROSoClingo via the
in rosoclingo topic.
In the next cycle the result is feed back into oClingo using the keyword pred-
icate _return. Assuming move base was successful, the input feeder generates
the following input stream update for the second cycle:
#step 2.
:- not _action(move_base ,office2 ,1).
12
Andres et al.
_return(move_base ,office2 ,1).
#endstep.
The integrity constraint after the input stream header enforces oClingo to include
the action just taken into future action plans. Otherwise, oClingo might abolish
actions taken in the past in order to minimize the task plan. The rest of the
cycle runs analogous to the first cycle shown. At sometime between the second
and third cycle ROSoClingo receives the cancellation of the first request:
#step 3.
:- not _action(move_base ,office3 ,2).
_request(cancel (1) ,3).
_return(move_base ,office3 ,2).
#endstep.
Here cancel(1) identifies the delivery to be cancelled via its package identifier.
This forces oClingo to change the task plan to the one presented under plan 2 in
Table 1. Since now there are no actions planned for the current (third) cycle the
robot waits idly at office3 for new requests. When ROSoClingo receives the
second request, the input feeder generates a new input stream update for oClingo
initiating the fourth cycle. The task plan generated by oClingo for satisfying
the request is shown in Table 1 under plan 3. Again, assuming the actions are
executed without complications the following cycles run analogous to the ones
above. After the sixth cycle the robot delivered the package to office4 and
enters the idle mode again, awaiting new requests.
5
Conclusion
Higher level cognitive functions such as reasoning about actions, environment,
goals, or perceptions are crucial in cognitive robotics. They necessitate knowl-
edge representation and reasoning capacities for autonomous robots. We de-
veloped a ROS package integrating oClingo, a reactive ASP solver, with the
robotics middleware ROS. The resulting system, called ROSoClingo, fulfils the
need for high-level knowledge representation and reasoning in cognitive robotics
by providing a highly expressive and capable reasoning framework. It also makes
details of integrating oClingo transparent for the developer. The developer does
not need to deal with parsing answer sets for actions or transforming other ROS
components’ results and external events considering oClingo requirements. Ad-
ditionally, for using move base, a widely used ROS package for navigation tasks,
ROSoClingo provides an interface layer which also functions as a guideline for
developing interfaces for other ROS components. Using reactive ASP and ROSo-
Clingo, one can control the behaviour of a robot within one framework and in
a fully declarative way. This is particularly important compared to Golog based
approaches where the developer should take care of implementation (usually in
Prolog) details of the control knowledge, and the underlying action formalism
separately. We illustrated the usage of ROSoClingo via a case-study conducted
ROSoClingo
13
with a ROS-based simulation of a robot delivering mail packages in an office
environment using Gazebo.
References
1. E. Aker, A. Erdogan, E. Erdem, and V. Patoglu. Causal reasoning for planning
and coordination of multiple housekeeping robots. In J. Delgrande and W. Faber,
editors, Proceedings of the Eleventh International Conference on Logic Program-
ming and Nonmonotonic Reasoning (LPNMR’11), volume 6645 of Lecture Notes
in Artificial Intelligence, pages 311–316. Springer-Verlag, 2011.
2. X. Chen, J. Ji, J. Jiang, G. Jin, F. Wang, and J. Xie. Developing high-level cogni-
tive functions for service robots. In W. van der Hoek, G. Kaminka, Y. Lesp´erance,
M. Luck, and S. Sen, editors, Proceedings of the Ninth International Conference on
Autonomous Agents and Multiagent Systems (AAMAS’10), pages 989–996. IFAA-
MAS, 2010.
3. X. Chen, J. Jiang, J. Ji, G. Jin, and F. Wang. Integrating NLP with reasoning
about actions for autonomous agents communicating with humans. In Proceedings
of the IEEE/WIC/ACM International Conference on Intelligent Agent Technology
(IAT’09), pages 137–140. IEEE, 2009.
4. E. Erdem, K. Haspalamutgil, C. Palaz, V. Patoglu, and T. Uras. Combining high-
level causal reasoning with low-level geometric reasoning and motion planning for
robotic manipulation.
In Proceedings of the IEEE International Conference on
Robotics and Automation (ICRA’11), pages 4575–4581. IEEE, 2011.
5. Esra Erdem, Erdi Aker, and Volkan Patoglu. Answer set programming for collabo-
rative housekeeping robotics: representation, reasoning, and execution. Intelligent
Service Robotics, 5(4):275–291, 2012.
6. M. Gebser, T. Grote, R. Kaminski, P. Obermeier, O. Sabuncu, and T. Schaub.
Stream reasoning with answer set programming: Preliminary report. In G. Brewka,
T. Eiter, and S. McIlraith, editors, Proceedings of the Thirteenth International
Conference on Principles of Knowledge Representation and Reasoning (KR’12),
pages 613–617. AAAI Press, 2012.
7. M. Gebser, T. Grote, R. Kaminski, and T. Schaub. Reactive answer set program-
ming. In J. Delgrande and W. Faber, editors, Proceedings of the Eleventh Inter-
national Conference on Logic Programming and Nonmonotonic Reasoning (LP-
NMR’11), volume 6645 of Lecture Notes in Artificial Intelligence, pages 54–66.
Springer-Verlag, 2011.
8. M. Gebser, R. Kaminski, B. Kaufmann, M. Ostrowski, T. Schaub, and S. Thiele.
Engineering an incremental ASP solver. In M. Garcia de la Banda and E. Pontelli,
editors, Proceedings of the Twenty-fourth International Conference on Logic Pro-
gramming (ICLP’08), volume 5366 of Lecture Notes in Computer Science, pages
190–205. Springer-Verlag, 2008.
9. Dirk H¨ahnel, Wolfram Burgard, and Gerhard Lakemeyer. GOLEX - bridging the
gap between logic (GOLOG) and a real robot. In Otthein Herzog and Andreas
G¨unter, editors, KI, volume 1504 of Lecture Notes in Computer Science, pages
165–176. Springer, 1998.
10. Hector J. Levesque, Raymond Reiter, Yves Lesp´erance, Fangzhen Lin, and
Richard B. Scherl. GOLOG: A logic programming language for dynamic domains.
J. Log. Program., 31(1-3):59–83, 1997.
14
Andres et al.
11. John McCarthy and Patrick J. Hayes.
Some philosophical problems from the
standpoint of artificial intelligence.
In B. Meltzer and D. Michie, editors, Ma-
chine Intelligence 4, pages 463–502. Edinburgh University Press, 1969. reprinted
in McC90.
12. M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler A., and
Ng. ROS: an open-source robot operating system. In ICRA Workshop on OSS,
2009.
13. Tran Cao Son, Chitta Baral, and Sheila A. McIlraith. Extending answer set plan-
ning with sequence, conditional, loop, non-deterministic choice, and procedure con-
structs. In Alessandro Provetti and Tran Cao Son, editors, Answer Set Program-
ming, 2001.
14. Michael Thielscher. Logic-based agents and the frame problem: A case for pro-
gression. In V. Hendricks, editor, First-Order Logic Revisited: Proceedings of the
Conference 75 Years of First Order Logic (FOL75), pages 323–336, 2004.