Integrating golog++ and ROS

for Practical and Portable High-level Control

Maximillian Kirsch, Victor Matar

, Alexander Ferrein

and Stefan Schiffer

Mobile Autonomous Systems and Cognitive Robotics Institute (MASCOR),

FH Aachen University of Applied Sciences, Eupener Str. 70, 52066 Aachen, Germany

Keywords:

Reasoning about Action and Change, GOLOG, Robot Operating System, ROS.

Abstract:

The ﬁeld of Cognitive Robotics aims at intelligent decision making of autonomous robots. It has matured over

the last 25 or so years quite a bit. That is, a number of high-level control languages and architectures have

emerged from the ﬁeld. One concern in this regard is the action language GOLOG. GOLOG has been used in

a rather large number of applications as a high-level control language ranging from intelligent service robots

to soccer robots. For the lower level robot software, the Robot Operating System (ROS) has been around

for more than a decade now and it has developed into the standard middleware for robot applications. ROS

provides a large number of packages for standard tasks in robotics like localisation, navigation, and object

recognition. Interestingly enough, only little work within ROS has gone into the high-level control of robots.

In this paper, we describe our approach to marry the GOLOG action language with ROS. In particular, we

present our architecture on integrating golog++, which is based on the GOLOG dialect Readylog, with the

Robot Operating System. With an example application on the Pepper service robot, we show how primitive

actions can be easily mapped to the ROS ActionLib framework and present our control architecture in detail.

1 INTRODUCTION

In mobile robotics, the recent years have been marked

by notable progress in recognition, manipulation and

planning algorithms. The advent of robotics frame-

works and middlewares has caused a consolidation

of software stacks, with the Robot Operating System

(ROS) emerging as the de-facto standard. The most

noteworthy achievement of ROS is the growth of a

lively community that shares re-usable components

with well-deﬁned interfaces.

The ﬁeld of high-level control, however, has not

seen the same amount of technical consolidation, over

time leading to a disconnect between the ROS world

and the Cognitive Robotics community. Of the many

existing high-level action and planning languages,

there exists only the ROSPlan package (Cashmore

et al., 2015) in ROS which uses PDDL (McDermott

et al., 1998; McDermott, 2000) as the declarative in-

put language. While having PDDL readily available

is certainly very valuable, we do believe that a purely

planning-based approach is not necessarily the best

https://orcid.org/0000-0003-4606-4758

https://orcid.org/0000-0002-0643-5422

https://orcid.org/0000-0003-1343-7140

choice for every real-world robotics problem. How-

ever, within the ROS ecosystem, the only other op-

tions for high-level control are based on ﬁnite au-

tomata (Bohren and Cousins, 2010; Brunner et al.,

2016), which makes them more of a complement to

PDDL than an alternative.

One approach that sits precisely in-between purely

declarative problem description (planning) and im-

perative behavior prescription (like ﬁnite automata)

is GOLOG (Levesque et al., 1997; Reiter, 2001). It

allows for combining classical imperative program-

ming constructs with more exotic constructs like

the non-deterministic choice of action and argument.

One feasible architecture is, for example, having a

GOLOG agent play the role of an executive below a

PDDL-based planner. Another option with some di-

alects of GOLOG is to have decision-theoretic plan-

ning integrated in the GOLOG interpreter itself. Dif-

ferent practical applications in robotics have shown

that really any permutation of the three approaches

can be suitable, depending on the domain require-

ments. High-level controllers based on Golog have

been used for various domains such as robotic soc-

cer (Ferrein and Lakemeyer, 2008) or domestic ser-

vice robotics (Schiffer et al., 2012).

692

Kirsch, M., Mataré, V., Ferrein, A. and Schiffer, S.

Integrating golog++ and ROS for Practical and Portable High-level Control.

DOI: 10.5220/0008984406920699

In Proceedings of the 12th International Conference on Agents and Artiﬁcial Intelligence (ICAART 2020) - Volume 2, pages 692-699

ISBN: 978-989-758-395-7; ISSN: 2184-433X

In this paper, we want to focus on the GOLOG

language family and propose an interface that makes

it a ﬁrst-class citizen of the ROS world. Since our

golog++-ROS interface aims to do for GOLOG what

ROSPlan does for PDDL, there are some functional

similarities, but also signiﬁcant differences in non-

functional requirements and the technical realization.

We start with some background, history and mo-

tivation for the development of golog++ in Sec-

tion 2 before we review related approaches in other

high-level languages in Section 3. Next, we give

an overview of the central ideas behind golog++

in Section 4. In Section 5 we describe the interface

between ROS and golog++ both from an abstract

and an implementation-oriented perspective. We con-

clude with a discussion of the results and future work

in Section 6.

2 BACKGROUND

Interfacing to some kind of execution platform is ob-

viously an issue that all high-level agent languages

have to deal with. In the following, we will give an

overview over the most important concepts and the

history of the GOLOG language family. Since we

want to focus on ROS in this paper, we continue with

a short introduction to its most relevant ideas and con-

cepts, in particular those that cater to agent languages.

2.1 The GOLOG Language Family

All GOLOG dialects, including the original one

(Levesque et al., 1997) have in common that they have

a formal semantics based on the Situation Calculus

(McCarthy, 1963; McCarthy and Hayes, 1969). The

Situation Calculus is a second order logical language

with equality which allows for reasoning about ac-

tions and their effects. The world evolves from situa-

tion to situation due to actions, starting in an initial sit-

uation S

. Possible world histories are represented by

sequences of actions. Properties of the world which

can change from situation to situation are stored in so-

called ﬂuents, predicates or functions with a situation

term as their last argument. Each action has precon-

ditions and effects that formalize when it is possible

to execute the action and how this action will change

the world with regard to ﬂuents. A basic action theory

(BAT) contains axioms about the initial situation, ac-

tion precondition axioms and successor state axioms

as well as unique names and some additional founda-

tional axioms.

GOLOG combines the declarative approach of the

Situation Calculus with imperative programming, of-

fering constructs such as loop and conditionals known

from imperative programming languages. Many

dialects also support less standard constructs such

as concurrent program execution, nondeterministic

choice or decision-theoretic planning. The purpose

of the nondeterministic constructs is to generate the

search space for a planning operator which can thus

be used not only to search the entire action space,

but to search for an executable parameterization of

a nondeterministic program. Additionally, an agent

must be able to perform both active and passive sens-

ing, i.e. to actively execute an action to acquire new

knowledge about its environment (Lakemeyer, 1999)

(e.g. using sensors), and to passively receive new

knowledge (i.e. react to uncontrollable events like the

press of a button on the robot) (De Giacomo et al.,

1997). Noteworthy about active sensing (i.e. sensing

actions) is that their sensed effect is unknown during

planning—only when the action is actually being ex-

ecuted will the agent’s knowledge be updated. Pas-

sive sensing—a background update of ﬂuents when-

ever a sensor value has changed in the world—is of

course also unplannable by deﬁnition, and is usually

modelled by so-called exogenous actions. These are

actions that are beyond the control of the agent, but

update its internal knowledge about the world.

In practical robotics, actions are not normally

completed instantaneously. This is reﬂected in the

concept of durative actions (Reiter, 1996), which in-

troduces instantaneous actions that mark the begin

and end of an ongoing activity. This also allows the

agent to do other things (e.g. plan) while a physical

action is in progress.

Many different GOLOG dialects have been pro-

posed. CONGOLOG (De Giacomo et al., 1997) im-

plements exogenous actions, interrupts and the abil-

ity execute actions concurrently, and INDIGOLOG

(De Giacomo and Levesque, 1999; De Giacomo

et al., 2009) expands on that allowing for incremen-

tal planning. DTGOLOG (Boutilier et al., 2000) in-

troduces decision-theoretic planning, i.e. the abil-

ity to generate plans that are optimized with re-

gard to some reward function. READYLOG (Ferrein,

2010b; Ferrein and Lakemeyer, 2008) builds upon

that base and integrates features from CCGOLOG and

PGOLOG (Grosskreutz, 2002; Grosskreutz and Lake-

meyer, 2000) to handle actions with uncertain out-

comes and ﬂuents that change continuously.

While most of the GOLOG-related research deals

with language semantics, practical use has shown that

the issue of interfacing with and executing actions

on a real robot is also not entirely trivial. GOLEX

ahnel et al., 1998) is one of the ﬁrst developments

that identiﬁed some important interfacing issues: The

Integrating golog++ and ROS for Practical and Portable High-level Control

693

Level of Abstraction in GOLOG is generally too high

to directly map primitive GOLOG actions to direc-

tives for robot actuators. Execution Monitoring is

needed, since in reality actions can fail for many rea-

sons beyond the control and/or scope of the agent pro-

gram. To enable Sensing and interaction, the lan-

guage semantics actually had to be extended (Lake-

meyer, 1999). It was also determined that some re-

source management system is required “since certain

resources such as motors cannot be shared simultane-

ously”. At that time, GOLEX did not support parallel

actions; so it was not able to react to user inputs, say,

while the robot was travelling.

2.2 The Robot Operating System (ROS)

ROS (Quigley et al., 2009) is an open-source middle-

ware designed for robotic application development.

It offers fundamental concepts and tools to manage

distributed robot applications, as well as ready-to-use

packages for common problems such as localization,

navigation, vision, motion etc.

Its fundamental architecture is a loosely coordi-

nated, network-transparent multi-process system. In-

dividual components are called nodes, and they com-

municate asynchronously by publishing messages un-

der a so-called topic. Topics have a speciﬁc message

type and are organized within a namespace. To re-

ceive messages, a node subscribes to a certain topic,

after which it will receive all messages published un-

der that topic. To support synchronous communica-

tion, there are so-called services which employ a re-

quest/response pattern.

This fundamental architecture has caused a leap

forward in robotics research by fostering a commu-

nity that can easily exchange software components

with clearly deﬁned interfaces.

2.3 ROS ActionLib

The ROS ActionLib

is an execution monitoring in-

terface in the sense of (H

ahnel et al., 1998). Client

and server communicate over action-speciﬁc mes-

sages that deﬁne a goal,

a feedback and a result.

To execute an action with certain arguments, an Ac-

tionClient sends a GoalMessage to a speciﬁc Action-

Server. The action server is then responsible for ex-

ecuting the action with the given goal, tracking its

progress (possibly giving feedback), and ﬁnally no-

tifying the client if and when the goal has succeeded

http://wiki.ros.org/actionlib

Note that the term goal here has nothing to do with

the goal concept in the context of a planning system. No

reasoning is involved at this level.

or was aborted, possibly along with some data as a

result. For example, an action server can provide the

action to move the robot from position A to B. The

goal parameters could be the (x, y) coordinates the

robot has to reach. As feedback, the action server

could then, for instance, periodically notify the client

about the current position, or it could simply give an

estimated percentage driven of the planned trajectory.

While the robot is on its way, the state of the goal is

running. A running goal can be canceled, whereupon

the action server stops the execution and the status

of the goal is set to preempted. When the movement

stops, the action server notiﬁes the client with the ﬁ-

nal state (succeeded, preempted or aborted), possibly

along with the ﬁnal position.

All actions can be started in blocking or non-

blocking mode. In the former case, the action client

simply performs a function call which returns when

the action server is done with execution, or in the lat-

ter case, the function dispatching a goal returns im-

mediately, and the end of action execution is signalled

with a callback.

3 OTHER RELATED WORK

ROSoClingo (Andres et al., 2013; Gebser et al., 2011)

is one example of an action language that leverages

the ROS ActionLib. It interfaces to the ROS Action-

Lib through two topics, one for output (i.e. executing

actions) and one for input (i.e. action feedback/results

and sensing). These two topics have to be subscribed

to by special adapter nodes that translate the ROSo-

Clingo-speciﬁc messages into ROS ActionLib goals.

Another noteworthy work is the framework ROS-

Plan (Cashmore et al., 2015) which embeds the ac-

tion language PDDL (Fox and Long, 2011) into the

ROS system. ROSPlan provides an interface to exe-

cute the planned actions of PDDL on a robot running

ROS. Therefore, a dispatcher component holds the in-

formation of the next planned PDDL action to be ex-

ecuted, but it is up to the developer how the planned

action should be executed in ROS. One of the reasons

for this is that ROSPlan integrates several solvers that

can solve a planning problem. A ROSPlan GitHub

software repository demonstrates the execution of the

planned action on a robot platform with the ROS Ac-

tionlib.

The so-called Cognitive Robot Abstract Machine

(CRAM) (Beetz et al., 2010) is another agent de-

velopment framework that uses the Actionlib to in-

terface with ROS. It targets robots in everyday (e.g.

https://ias.in.tum.de/research/cram

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

694

domestic) environments, with a focus on integrat-

ing common-sense knowledge from multiple sources,

sharing (updated) knowledge between robots and

learning from past experience.

EXPCOG (Eppe et al., 2014) integrates several in-

dependent logic-based action calculi in one frame-

work. Among others, a STRIPS-like planning sys-

tem implemented in SWI-Prolog, an ASP-based on

OCLINGO and a situation calculus-based on GOLOG

and INDIGOLOG. However to our current knowledge

there is no straightforward ROS integration.

The work of (Adam et al., 2017) transforms

declarative expert domain models into PDDL prob-

lems. For this purpose, a Java interface must be im-

plemented for each robot that calls the functions of

the connected middleware. At the time of writing this

paper, there was however no publicly available ROS

integration.

4 THE golog++ FRAMEWORK

Most research about high-level control focuses on

language semantics, while architectural aspects such

as code reusability, portability and maintainability as

well as usability and ergonomics receive less atten-

tion. The golog++ framework offers an alternative

approach over other existing implementations that

takes such aspects into account. It extends previous

work on Golog such as YAGI or golog.lua (Ferrein,

2010a; Ferrein and Steinbauer, 2010; Ferrein et al.,

2012; Ferrein et al., 2016).

The main purpose of golog++ (Matar

e et al.,

2018) is to factor the concerns of execution/platform-

interfacing and static semantics out of the runtime se-

mantics. This clear separation of concerns helps to

signiﬁcantly improve language usability, safety and

maintainability.

The runtime semantics can be implemented in dif-

ferent ways, e.g. by embedding an existing GOLOG

interpreter. With the ReadylogSemantics, golog++

supports both active and passive sensing, decision-

theoretic planning and concurrency. Furthermore

golog++ offers some unique features that are not

found in other GOLOG dialects:

• Code model: The C++ object model that forms

the core of golog++ supports all features re-

quired for an integrated development environ-

ment, i.e. full code introspection with reference

resolution.

• Type safety: Everything has a type, and inconsis-

tent use of types generates a speciﬁc error mes-

sage. Compound key-value types and list types

can be freely deﬁned and nested.

symbol domain objects = {

stop_sign, bottle, traffic_light

}

symbol domain position = {

left, middle, right

}

string fluent sought_object() {

initially: () = null;

}

number fluent found_position() {

initially: () = null;

}

action dialog(string question) {

senses: sought_object()

}

action detect_position(symbol obj) {

senses: found_position()

}

action say(string say_str) {}

Figure 1: Exemplary BAT (deﬁnes a world and available

actions).

procedure main() {

dialog("What shall I search?");

if (sought_object() != null) {

start(say("Give me a second."));

detect_position(sought_object());

if (found_position() != null) {

say("The " + sought_object() + " is at the "

+ found_position() + " position.");

say("Thanks for your attention");

}

else

say("Sorry, I couldn’t find the "

+ sought_object());

}

else

say("Sorry, I didn’t understand.");

}

Figure 2: Exemplary imperative procedure that implements

a simple behaviour on top of the BAT in ﬁg. 1. Some details

(like animations) are left out for conciseness.

• Syntax checking: golog++ comes with its own

syntax and a special parser, so the syntax is strict,

speciﬁc, and errors are pinpointed precisely.

In golog++, when a programmer deﬁnes an action

A(x), it is implicitly a durative action. That means

that in terms of classical GOLOG, A(x) actually de-

ﬁnes a primitive action start

(x) that begins some

activity, and another primitive action end

(x) that

waits for it to end.

The golog++ example program shown in Fig-

ures 1 & 2 demonstrates the use of durative actions

and active/passive sensing actions. The scenario can

be seen in Figure 3: The robot Pepper (Pandey and

Gelin, 2018) is standing in front of a table with a traf-

ﬁc light, a bottle and a stop sign on it. Spectators can

swap the objects’ positions around, and then ask Pep-

per for the position of either one. This example does

not leverage golog++’s planning capabilities, but it

does serve to show that a simple AI demo application

can be written up with minimal effort.

In the next section, we will outline the underly-

ing infrastructure that enables this kind of high-level

behaviour development.

Integrating golog++ and ROS for Practical and Portable High-level Control

695

Figure 3: Interactive demo with Pepper at an event. Top:

Pepper listens to a spectator who names an object that Pep-

per should look for. Bottom: Pepper looks for the object on

the table and points out its position.

5 INTEGRATING golog++ AND

ROS

Since golog++ is designed to work with different

platforms, the PlatformBackend is an abstract inter-

face that requires a platform-speciﬁc implementation.

Its job is to map the durative actions, exogenous and

sensing actions in a golog++ program onto a cer-

tain robot platform. Figure 4 gives an overview which

functions the RosPlatformBackend has to implement.

As the names suggests, the function execute activity

is called when the agent decides to begin some ac-

tivity, and preempt activity is called when the agent

wants to cancel a currently ongoing activity. The

function update activity is already implemented in the

PlatformBackend and must be called by the RosPlat-

formBackend to set the state ﬁnish, fail or preempted,

and to (possibly) pass a sensing result when a running

activity terminates.

In the following, we describe how the require-

ments of executing actions concurrently and active/-

passive sensing can be satisﬁed with the ActionLib

stack and ROS core functionality.

Action Execution. Obviously, the action concept

of the ROS ActionLib is quite similar to that of

golog++. As described in Section 2.3, the action

server can ﬁnish in the states succeeded, aborted and

preempted.

The RosPlatformBackend implements the exe-

cute activity method simply by dispatching a goal to

the appropriate action server in non-blocking mode.

When the action is done, the callback then calls up-

date activity, informing golog++ of the action’s

success/failure. This ultimately allows the agent to

execute the primitive action end

(x) and to decide

whether/which effect has to be applied.

Another ROS concept that maps easily to

golog++ actions is executing ROS service calls. A

service call could be to e.g. enable face tracking on

the Pepper platform (cf. Fig. 3). Since service calls

are synchronous by nature, they have to be started in

an own thread, so that they don’t block the execu-

tion of the golog++ agent program. The thread then

waits until the service reply has been received, and

calls update activity with ﬁnish or fail depending on

whether the service call was successful or not.

Active Sensing. As described in Section 2.3, both

an action server and a service call can return a spe-

ciﬁc result. The RosPlatformBackend translates the

result into a golog++ Value and passes it to the

update activity function as a sensing result, together

with the outcoming action state. So active sensing

is realized like a normal golog++ action with the

only difference that the action server (or service) has

to provide a result in addition to the success/failure

outcome.

Exogenous Actions. Exogenous actions are event-

based by nature, which precisely matches the core

message-passing architecture of ROS. Thus imple-

menting an exogenous action comes down to simply

subscribing to a topic where a message is published

when the desired event occurs. The message is then

converted into an ExogEvent object to be handled by

the golog++ event loop.

5.1 Design of the

ROSPLATFORMBACKEND

One problem we did not mention so far is the fact that

all ROS message types are realized as generated C++

headers with a strict typing discipline. Since every

ActionLib action uses speciﬁc messages for the com-

munication between ActionServer and ActionClient,

both have to be either hand-written or generated in

C++. Currently, the ROS ActionLib can generate Ac-

tionClients, but it does so without making use of in-

heritance, so there is no abstraction that would allow

handling an ActionClient in a generic manner.

That is why, as shown in Figure 4, the Action-

Manager, ExogManager and ServiceManager classes

exist, and why they must all be template classes.

Their template argument is the action/service type for

the ActionManager and ServiceManager respectively,

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

696

gologpp

«Interface»

ExecutionContext

+ exog_queue_push( in e: ExogEvent)

+ run( in program: Block)

«Interface»

PlatformBackend

+ execute_activity( in a: Activity)

+ preempt_activity( in a: Activity)

+ update_activity( in a: Activity)

gologpp_ros

ActionT

ResultT

StateT

GoalT

ServiceManager

+ make_request( in a: Activity): RequestT

+ convert( in r: ResponseT): Value

SrvT: Class

ExogManager

+ convert( in r: MsgT): Value

MsgT: Class

ActionManager

- make_goal( in a: Activity): GoalT

+ convert( in r: ResultT): Value

ActionT: Class

SrvT

RequestT

ResponseT

RosPlatformBackend

+ execute_activity( in a: Activity)

+ preempt_activity( in a: Activity)

+ service

0..1

+ goal

0..1

Figure 4: A UML class diagram that shows the most im-

portant properties of the golog++ PlatformBackend and

some implementation details of the RosPlatformBackend.

template<>

darknet::obj_detectionGoal

ActionManager <

darknet::obj_detectionAction

>::make_goal(const gpp::Activity &a)

{

darknet::obj_detectionGoal goal;

goal.obj_to_detect = std::string(

a.mapped_arg_value("obj"));

return goal;

}

Figure 5: Specialization of the make goal method, which

assigns the argument of an activity to a goal member for the

action server. The string argument to the mapped arg value

method speciﬁes the name of the golog++ action’s pa-

rameter, which can optionally be remapped from within the

golog++ code (hence the method’s name).

and the plain message type of the subscribed topic for

the ExogManager. With this design, we are able to

keep almost all of the glue code generic and lever-

age the code generation of the C++ template system

to signiﬁcantly reduce the amount of work that needs

to be done to make a speciﬁc ROS action, service or

topic accessible to golog++.

The only thing that remains to be written speciﬁ-

cally for an action/service/topic is the actual mapping

of data ﬁelds. As an example, consider the specializa-

tion of if the make goal method in Figure 5. It sim-

ply maps the arguments of a golog++ action onto a

goal for the DarkNet

ActionServer that does the ob-

ject recognition used in Figures 1 and 2. The rest is

taken care of by generic template code that is instan-

tiated by the C++ compiler when it sees this special-

ization. If/when an outcome from the action server

should be delivered as a sensing result, that is han-

dled by another template specialization which trans-

lates that speciﬁc result type to a golog++ value.

6 DISCUSSION & OUTLOOK

The most obvious benchmark to compare the

golog++ RosPlatformBackend to is the ROSPlan

PDDL interface. ROSPlan interfaces to the outer

world by publishing generic ActionDispatch mes-

sages that have to be received by another ROS node

which then somehow implements the desired be-

haviour. Most commonly, that is done by executing

some ActionLib action, just as in golog++. Unlike

in golog++, in ROSPlan the programmer also has

the freedom to not use ActionLib and write a free-

form ROS node that can do anything. This freedom

however can also be viewed as a lack of interface

rigidity, and it comes with the cost of large amounts

of boilerplate code. Having such a fundamentally un-

restricted behaviour node also signiﬁcantly increases

the risk of programmer errors, especially when con-

sidering that it requires high-level developers to read

into low-level ROS concepts.

In contrast, the golog++ RosPlatformBackend

deﬁnes an extremely rigid interface for the platform

integrator to implement. The behaviour required

of the convert, make goal and make request method

templates is completely speciﬁed by their respective

input and output types (cf. Fig. 5). Most importantly,

a golog++ platform integrator needs only to be pro-

ﬁcient in C++, no further knowledge about ROS con-

cepts (or even golog++ concepts for that matter)

is required except what can be gleaned immediately

from the types in the method’s signature. Should

action-speciﬁc quirks be required at other points in

the control ﬂow, the RosPlatformBackend also sup-

ports that by deriving from the ActionManager, Ex-

ogManager or ServiceManager class templates.

The difference between the two approaches also

becomes apparent in the number of lines of code that

are required to e.g. make a MoveBase action avail-

able. In golog++ that amounts to ∼12 LoC to trans-

late action arguments into a MoveBaseAction goal. In

ROSPlan, an entire ROSNode needs to be written for

the same job, which weighs in around 50 LoC, most

https://github.com/pjreddie/darknet

Integrating golog++ and ROS for Practical and Portable High-level Control

697

of which deals with managing the node itself as well

as ActionClient objects, callbacks and other accesso-

rial data structures which are hidden from the user in

golog++.

Practical tests on the Pepper platform (Fig. 3)

have shown that golog++ in combination with ROS

yields an easy-to-use and robust high-level agent ar-

chitecture. Since Pepper is a platform directly tar-

geted at human-robot interaction, implemented tasks

revolved around social robotics. That is, Pepper acts

as a simple tour guide in the rooms of the MAS-

COR Institute, or demonstrates simple speech-based

human-robot interaction and neural network-based

object recognition at science fairs and other events.

golog++’s concise syntax and interpreted nature

turned out to be very helpful in such scenarios by

making it easy to adapt a demo application on the

spot, e.g. to address questions from the audience.

Preliminary user studies have also shown that,

given some rudimentary documentation and exam-

ple code, users with varying backgrounds in robotics

and computer science were able to interface their ﬁrst

new action to the golog++ RosPlatformBackend in

about one hour. Subsequent action interfaces were

then done within mere minutes.

In the future, we plan on releasing golog++ with

the RosPlatformBackend as a ROS package to make

it as accessible as possible. The next development

step will be to hook into the ROS message generation

infrastructure to completely automate the process of

interfacing a ROS action to golog++ so that no ad-

ditional C++ coding will be necessary.

We are also following the development of ROS2

and will consider a port as soon as important function-

alities like the ActionLib are sufﬁciently developed.

ACKNOWLEDGEMENTS

This work was supported by the German Na-

tional Science Foundation (DFG) under grant number

FE 1077/4-1

REFERENCES

Adam, K., Butting, A., Kautz, O., Rumpe, B., and Wort-

mann, A. (2017). Executing robot task models in dy-

namic environments. In Proceedings of the 3rd In-

ternational Workshop on Executable Modeling (EXE)

held at ACM/IEEE 20th International Conference on

Model Driven Engineering Languages and Systems

(MODELS), pages 95–101.

Andres, B., Obermeier, P., Sabuncu, O., Schaub, T., and

Rajaratnam, D. (2013). ROSoClingo: A ROS package

for ASP-based robot control. CoRR, abs/1307.7398.

Beetz, M., M

osenlechner, L., and Tenorth, M. (2010).

CRAM A Cognitive Robot Abstract Machine for

everyday manipulation in human environments. In

2010 IEEE/RSJ International Conference on Intelli-

gent Robots and Systems, pages 1012–1017.

Bohren, J. and Cousins, S. (2010). The smach high-level

executive [ros news]. IEEE Robotics & Automation

Magazine, 17(4):18–20.

Boutilier, C., Reiter, R., Soutchanski, M., Thrun, S., et al.

(2000). Decision-theoretic, high-level agent program-

ming in the situation calculus. AAAI/IAAI, 2000:355–

362.

Brunner, S. G., Steinmetz, F., Belder, R., and D

omel, A.

(2016). Rafcon: A graphical tool for engineering com-

plex, robotic tasks. In 2016 IEEE/RSJ International

Conference on Intelligent Robots and Systems (IROS),

pages 3283–3290. IEEE.

Cashmore, M., Fox, M., Long, D., Magazzeni, D., Ridder,

B., Carreraa, A., Palomeras, N., Hurt

os, N., and Car-

rerasa, M. (2015). ROSPlan: Planning in the Robot

Operating System. In Proceedings of the Twenty-Fifth

International Conference on International Conference

on Automated Planning and Scheduling, ICAPS’15,

pages 333–341. AAAI Press.

De Giacomo, G., Lesp

erance, Y., and Levesque, H. J.

(1997). Reasoning about concurrent execution, priori-

tized interrupts, and exogenous actions in the situation

calculus. In IJCAI, volume 97, pages 1221–1226.

De Giacomo, G., Lesp

erance, Y., Levesque, H. J., and Sar-

dina, S. (2009). Indigolog: A high-level programming

language for embedded reasoning agents. In Multi-

Agent Programming, pages 31–72. Springer.

De Giacomo, G. and Levesque, H. J. (1999). An incremen-

tal interpreter for high-level programs with sensing. In

Logical foundations for cognitive agents, pages 86–

102. Springer.

Eppe, M., Bhatt, M., Suchan, J., and Tietzen, B. (2014).

ExpCog: Experiments in commonsense cognitive

robotics. In Proceeding of the 9th International Work-

shop on Cognitive Robotics (CogRob) held at the Eu-

ropean Conference on Artiﬁcial Intelligence (ECAI

2014).

Ferrein, A. (2010a). golog.lua: Towards a non-prolog

implementation of GOLOG for embedded systems.

In Hoffmann, G., editor, Proceedings of the AAAI

Spring Symposium on Embedded Reasoning, (SS-10-

04), pages 20–28. AAAI Press.

Ferrein, A. (2010b). Robot controllers for highly dy-

namic environments with real-time constraints. KI -

unstliche Intelligenz, 24(2):175–178.

Ferrein, A. and Lakemeyer, G. (2008). Logic-based robot

control in highly dynamic domains. Robotics and Au-

tonomous Systems, 56(11):980–991.

Ferrein, A., Maier, C., M

uhlbacher, C., Niemueller, T.,

Steinbauer, G., and Vassos, S. (2016). Controlling lo-

gistics robots with the action-based language YAGI.

In International Conference on Intelligent Robotics

and Applications, pages 525–537. Springer.

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

698

Ferrein, A. and Steinbauer, G. (2010). On the way to

high-level programming for resource-limited embed-

ded systems with GOLOG. In International Confer-

ence on Simulation, Modeling, and Programming for

Autonomous Robots, pages 229–240. Springer.

Ferrein, A., Steinbauer, G., and Vassos, S. (2012). Action-

based imperative programming with YAGI. In Work-

shops at the Twenty-Sixth AAAI Conference on Artiﬁ-

cial Intelligence.

Fox, M. and Long, D. (2011). PDDL2.1: an extension

to PDDL for expressing temporal planning domains.

CoRR, abs/1106.4561.

Gebser, M., Grote, T., Kaminski, R., and Schaub, T. (2011).

Reactive answer set programming. In LPNMR, vol-

ume 6645 of Lecture Notes in Computer Science,

pages 54–66. Springer.

Grosskreutz, H. (2002). Towards more realistic logic-based

robot controllers in the GOLOG framework. PhD the-

sis, Bibliothek der RWTH Aachen.

Grosskreutz, H. and Lakemeyer, G. (2000). Turning high-

level plans into robot programs in uncertain domains.

In ECAI, pages 548–552.

ahnel, D., Burgard, W., and Lakemeyer, G. (1998).

GOLEX: Bridging the gap between logic (GOLOG)

and a real robot. In Herzog, O. and G

unter, A., editors,

KI-98: Advances in Artiﬁcial Intelligence, volume

1504 of Lecture Notes in Computer Science, pages

165–176. Springer Berlin Heidelberg.

Lakemeyer, G. (1999). On sensing and off-line interpret-

ing in golog. In Logical Foundations for Cognitive

Agents, pages 173–189. Springer.

Levesque, H. J., Reiter, R., Lesp

erance, Y., Lin, F., and

Scherl, R. B. (1997). GOLOG: A logic programming

language for dynamic domains. Journal of Logic Pro-

gramming, 31(1–3):59–84.

Matar

e, V., Schiffer, S., and Ferrein, A. (2018). golog++:

An integrative system design. In Proceedings

of the 11th Cognitive Robotics Workshop 2018

(CogRob@KR 2018), co-located with 16th Interna-

tional Conference on Principles of Knowledge Rep-

resentation and Reasoning, pages 29–36.

McCarthy, J. (1963). Situations, actions, and causal laws.

Technical Report Memo 2, AI Lab, Stanford Univer-

sity, California, USA. Published in Semantic Informa-

tion Processing, ed. Marvin Minsky. Cambridge, MA:

The MIT Press, 1968.

McCarthy, J. and Hayes, P. J. (1969). Some philosophi-

cal problems from the standpoint of artiﬁcial intelli-

gence. In Meltzer, B. and Michie, D., editors, Machine

Intelligence 4, pages 463–502. Edinburgh University

Press. reprinted in McC90.

McDermott, D., Ghallab, M., Howe, A., Knoblock, C.,

Ram, A., Veloso, M., Weld, D., and Wilkins, D.

(1998). PDDL – the planning domain deﬁnition lan-

guage.

McDermott, D. M. (2000). The 1998 ai planning systems

competition. AI magazine, 21(2):35–35.

Pandey, A. K. and Gelin, R. (2018). A mass-produced

sociable humanoid robot: Pepper: The ﬁrst machine

of its kind. IEEE Robotics Automation Magazine,

25(3):40–48.

Quigley, M., Conley, K., Gerkey, B., Faust, J., Foote, T.,

Leibs, J., Wheeler, R., and Ng, A. Y. (2009). ROS: an

open-source robot operating system. In ICRA work-

shop on open source software, volume 3, page 5.

Kobe, Japan.

Reiter, R. (1996). Natural actions, concurrency and contin-

uous time in the situation calculus. In Proceedings

of the Fifth International Conference on Principles

of Knowledge Representation and Reasoning, KR’96,

pages 2–13, San Francisco, CA, USA. Morgan Kauf-

mann Publishers Inc.

Reiter, R. (2001). Knowledge in Action. Logical Founda-

tions for Specifying and Implementing Dynamical Sys-

tems. MIT Press, Cambridge, Massachusetts.

Schiffer, S., Ferrein, A., and Lakemeyer, G. (2012). CAE-

SAR: An intelligent domestic service robot. Intelligent

Service Robotics, 5:259–273.

Integrating golog++ and ROS for Practical and Portable High-level Control

699