Available online at www.sciencedirect.

com

ScienceDirect
IFAC PapersOnLine 53-2 (2020) 10000–10005
Embedded
Embedded Architecture
Architecture Composed
Composed of
of
Embedded
Embedded Architecture
Architecture Composed
Composed of
of
Cognitive
Cognitive Agents
Agents and
and ROS
ROS for
for
Embedded
Cognitive Architecture
Agents and Composed
ROS for of
Cognitive
Programming
Programming Agents and
Intelligent
Intelligent ROS for
Robots
Robots
Cognitive Agents
Programming and ROS
Intelligent for
Robots
Programming Intelligent Robots
Programming
Gustavo R. Silva ∗ LeandroIntelligent Robots
B. Becker ∗ Jomi F. Hübner ∗
Gustavo R. Silva ∗∗ Leandro B. Becker ∗∗ Jomi F. Hübner ∗∗
Gustavo R. Silva ∗∗ Leandro B. Becker ∗∗ Jomi F. Hübner ∗∗
∗Gustavo R. Silva ∗ Leandro B. Becker ∗ Jomi F. Hübner ∗
Department
∗Gustavo R.ofSilva
Automation andB.
Leandro Systems,
BeckerUniversidade Federal de
Jomi F. Hübner
∗ Department of Automation and Systems, Universidade Federal de
∗ Department of
Santa
∗ Department
Automation
Catarina and Systems,
(UFSC), SC, Universidade
Brazil.(e-mail: Federal de
of Automation
Santa
Santa Catarina and Systems,
Catarina (UFSC),
(UFSC), SC,
SC, Universidade Federal de
Brazil.(e-mail:
Brazil.(e-mail:
∗ gustavorezendesilva@hotmail.com,
Department of Automation leandro.becker@ufsc.br,
and Systems, Universidade Federal de
Santa Catarina (UFSC),
gustavorezendesilva@hotmail.com,
gustavorezendesilva@hotmail.com, SC, Brazil.(e-mail:
leandro.becker@ufsc.br,
leandro.becker@ufsc.br,
Santa Catarina jomi.hubner@ufsc.br).
(UFSC), SC, Brazil.(e-mail:
gustavorezendesilva@hotmail.com,
jomi.hubner@ufsc.br).
jomi.hubner@ufsc.br). leandro.becker@ufsc.br,
gustavorezendesilva@hotmail.com,
jomi.hubner@ufsc.br). leandro.becker@ufsc.br,
jomi.hubner@ufsc.br).
Abstract: This paper proposes and evaluates an embedded architecture aimed to promote
Abstract: This
Abstract: This paper proposesproposes and evaluates evaluates an embedded
embedded architecture
architecture aimed aimed to to promote
the utilization of paper cognitive agentsand in cooperationanwith the Robotic Operating Systempromote (ROS),
Abstract:
the
the utilization
utilization This of
of paper
cognitive
cognitiveproposes
agents
agents and
in
in evaluates
cooperation
cooperation an embedded
with
with the
the architecture
Robotic
Robotic Operating
Operating aimedSystem
System to promote
(ROS),
(ROS),
serving
Abstract: as an
This alternative
paper for
proposes programming
and evaluatesintelligent
anwith robots.
embedded It promotes
architecture the
aimed programming
to promote
the utilization
serving
serving as
as an
an of cognitive
alternative
alternative agents
for
for in
programming
programming cooperationintelligent
intelligent the
robots.
robots.Robotic It
It Operating
promotes
promotes the
the System
programming
programming (ROS),
abstraction
the utilization level in
of in two
cognitive directions.
agents The
inThe first
cooperation direction regards
with regards
the Roboticusing cognitive
Operating agents
System facilities
(ROS),
serving
abstraction
abstraction as an
level
levelalternative
in two for programming
directions. first intelligent
direction robots. It
usingpromotes
cognitive the programming
agents facilities
for programming
serving as an thetwo
alternative directions.
robots forintelligence,The first
programming direction
consisting regards
of its
intelligent using
perceptions
robots. cognitive
and related
It promotes theagentsactions.
programmingfacilities
The
abstraction
for
for programming
programming level in
thetwo
thetwo directions.
robots
robots The
intelligence,
intelligence, first direction
consisting
consisting of regards
its
of its using
perceptions
perceptions cognitive
and
and the related
related agents
actions.
actions. facilities
The
The
second direction
abstraction level exploits
in the facilities
directions. Theof using
first ROS layers
direction for
regards programming
using cognitive robot
agents interaction
facilities
for programming
second
second direction the
exploitsrobots
the intelligence,
facilities of consisting
using ROS of
layersits perceptions
for programming and related
the robot actions.
interaction The
for itsdirection
sensors exploits
withprogramming and
the robotsthe facilities
actuators. The of
intelligence, using
paper ROS layers
reports
consisting itsfor
experiments
of programming
perceptions of usingand the agents
relatedrobot to interaction
command
actions. The
second
with itsdirection
with its sensors exploits
sensors and
and the facilities
actuators.
actuators. The of
The using
paper
paper ROS layers
reports
reports for
experiments
experiments programming
of using
of using the
agents
agents robot to
to interaction
command
command
simulated
second UAVs
direction while
exploits measuring
the facilities performance
of metrics
usingreports
ROS layers that allowed
for allowed
programming us to evaluate
the robot the benefits
interaction
with its
simulated
simulated sensors
UAVs and
while
UAVs architecture.
while actuators.
measuring
measuringThe The paper
performance
performance metrics
metrics experiments
that
that allowed of using
us to agents
evaluate tothe command
benefits
of theits
with proposed
simulated
of the sensors
the proposed
proposed and actuators.
UAVs architecture.
while measuring performance
architecture. paper reportsmetrics experiments
that allowed of ususing
us
to evaluate
agents tothe
to evaluate the
benefits
command
benefits
of article under the CC BY-NC-ND licensethe benefits
Copyright
simulated
of the proposed© The Authors.
2020architecture.
UAVs while measuring This is an open access
performance metrics that allowed us to evaluate
(http://creativecommons.org/
Keywords:
of the proposed BDI Agents, licenses/by-nc-nd/4.0)
Robotics,
architecture. UAVs, ROS, Jason
Keywords:
Keywords: BDI Agents,
BDI Agents, Robotics, UAVs,
Robotics, UAVs, ROS, ROS, Jason
Jason
Keywords: BDI Agents, Robotics, UAVs, ROS, Jason
1. INTRODUCTION
Keywords: BDI Agents, Robotics, UAVs, ROS, Jason 2. BACKGROUND
1. INTRODUCTION
1. INTRODUCTION 2.
2. BACKGROUND
BACKGROUND
1. INTRODUCTION 2. BACKGROUND
When designing robots, 1. INTRODUCTION
one of the difficulties is to develop Multi-agents systems 2. BACKGROUND
When designing
designing robots,
robots, one one of of the
the difficulties
difficulties is is to develop Multi-agents systems can
to develop can
be defined as systems that are
be
When
autonomous software that is capable to perceive the envi- composed
When designing
autonomous robots,
software one
that isof the
capable difficulties
to perceive is to develop
the envi- Multi-agents of onesystems
or more be defined
canintelligentdefined as
as systems
agents. systems that
that are
As Wooldridge are
autonomous
ronment, software
reasoning that
about is
what capable
it to
knows, perceive
and then the envi-
choos- Multi-agents
composed
composed of
of systems
one
one or
or more
more can be defined
intelligent
intelligent as
agents.
agents. systems
As
As that are
Wooldridge
Wooldridge
When designing
autonomous robots,
software
ronment, reasoning
reasoning one
that what
about of the
is capable
what difficulties
to perceive
it knows,
knows, is
and then to
then develop
thechoos- (1999)
envi- Multi-agents
choos- stated, the
systems task of
can defining
be defined intelligent
as systems agents that is not
are
ronment,
ing appropriate about
actions. it and composed
(1999) stated, of one theor
the more
task ofintelligent
of defining agents.
intelligent Asagents
Wooldridgeis
is not
autonomous
ronment,
ing appropriate software
reasoning
appropriate actions.thatTo
about To
solve
is capable
what
this
it knows,
solve this
challenge,
to perceive
and then
challenge,
multi-
envi- (1999)
thechoos-
multi- an easystated,
composed
(1999)
one,
of
stated,
even
onethe ortask
because
more
task of
defining
there isintelligent
intelligent
defining
no consensus
agents.
intelligent Asagents for
Wooldridge
agents is
not
the
not
ing
agents systems actions.
(MAS) To
techniquessolve this
seem to challenge,
bethen multi-
an advan- an
an easy one,
easystated,
one, even
even because
because there
therethis,is no consensus
isintelligent
no for the
ronment,
ing
agents reasoning
appropriate
systems about
actions.
(MAS) what
To
techniques it knows,
solve and
this challenge,
seem to be an multi- concept
choos-
an advan-
advan- (1999) of intelligence.
the task Despite
of defining theconsensus
author
agents for
came the
up
is not
agents
tageous systems
approach (MAS)
since techniques
it Tooffers seem
theoretical to be
and practical an easy of
concept
concept one,
of even
intelligence.
intelligence.because Despite
Despite therethis,is no
this, the
the consensus
author
author for
came
came the
up
up
ing
agentsappropriate
tageoussystems
approach actions.
(MAS)
since techniques
it offers solve this challenge,
seem to be
offers theoretical
theoretical multi-
andanpractical
advan- an
practical with easythe definition:
one, even because “An intelligent
therethis,is no agent is
consensusone that
for is
the
tageous
tools to approach
develop since
autonomous it systems (Bordini andet al., 2005, concept
with
with the
the of intelligence.
definition:
definition: “An
“An Despite
intelligent
intelligent the
agent
agent author
is
is one
one came
that
that up
is
is
agents
tageous
tools to systems
approach
to develop
develop (MAS) techniques
since it offers
autonomous systems seem
theoretical to
(Bordini be
and an advan-
practical
et al.,
al., capable
2005, concept of flexible
ofdefinition: autonomous
intelligence. Despite action
this, agent in
the order
author to meet
came its
tools
2007). Among autonomous
the benefits, systems
agents (Bordini
can properly et 2005,
balance with
capable
capable theofof flexible
flexible “An
autonomous
autonomous intelligent
action
action in
in is one
order
order to
to that up
meet
meet is
its
its
tageous
tools
2007). to approach
develop
Among the since
autonomous it offers
benefits, systems
agents theoretical
(Bordini
can and
properly et practical
al., 2005,
balance design
with theobjectives”,
definition: flexible
“An means
intelligent that it
agent posses
is reactivity,
one that is
2007). Among
reactivity the benefits,
and pro-activeness, agents
speciallycan properly
those agents balance capable
design
built pro-activeness, of flexible
objectives”, autonomous
flexible means action
that in
it order
posses to meet
reactivity, its
tools
2007). toAmong
reactivity
reactivity
develop
and
autonomous
the benefits, systems
and pro-activeness,
pro-activeness, agents
specially
specially
(Bordini
can properly
those
those
et al.,
agents
agents built design
2005,
balance
built capable
design
objectives”,
of flexible
objectives”,
pro-activeness, and
flexible
andautonomous
flexible
social
means
social ability.
means
ability.
that
Reactivity
action
that
it posses
in
Reactivityit order
possesis
reactivity,
is to
the ability
meet
reactivity,
the its
ability
on top of the BDI (Belief, Desire, Intention) model. pro-activeness, andflexible
social ability. Reactivity is the ability
2007).
on top Among
reactivity
on top of andBDI
of the
the the (Belief,
benefits,
pro-activeness,
BDI (Belief, Desire,
agents
specially
Desire, canthose
properly
Intention)
Intention) agents
model.
model. built to
balance perceive
design
to perceive
the environment
objectives”,
pro-activeness, the and social ability.
environment
and promptly
means
and that
Reactivity
promptly
react
it posses
react
according
reactivity,
is the ability
according
reactivity
on
Thistopwork and
of the pro-activeness,
BDI (Belief,
proposes specially
Desire, Intention)
an architecture those
for programmingagents
model. in- tobuilt to perceive
what
pro-activeness, is the environment
perceived;
and social and
pro-activeness
ability. promptly is
Reactivity thereact
is according
capability
the abilityof
This work proposes an architecture for programming in- to perceive
what
what is
is the environment
perceived;
perceived; and promptly
pro-activeness
pro-activeness is
is the
thereact according
capability
capability of
of
on
Thistopwork
telligentofrobots
the BDI
proposes (Belief,
based anon Desire,
architecture
the Intention)
cognitivefor concepts model.
programming of BDI.in- taking
to perceive
what
taking
to
the
the is
initiative
the to
environment
perceived;
initiative to
perform
perform and
pro-activeness
actions
promptly
actions is
in
in
order
thereact to achieve
according
capability
order to achieve of
This work
telligent
telligent proposes
robots
robots based
based an on
onarchitecture
the cognitive
the tocognitive for programming
concepts
concepts of BDI.
of BDI.in- taking
goals, the initiative
producing a to perform
goal-driven actions
behaviour; in order
social to achieve
ability is
Experiments
This work were
proposes performed
an architecture evaluate
for the feasibility
programming of to
in- what
taking
goals, the is initiative
producing perceived;
a to pro-activeness
perform
goal-driven actions
behaviour; isinthe capability
order
social to achieve
ability of
is
telligent
Experiments
Experimentsrobotswere
werebased on
performed
performed the tocognitive
evaluate
tocognitive
evaluate concepts
the
the in of
feasibility
feasibilityBDI. of
of the goals,
the producing
capacity of a goal-driven
interacting with behaviour;
other agents.social ability is
the developed
telligent robots architecture:
based on the whether it runs
concepts embedded
of BDI. taking
goals, the initiative
producing
capacity of a to perform
goal-driven
interacting with actions
behaviour;
other in order
agents.social toability
achieve is
Experiments
the
the developed
developed were performed
architecture:
architecture: to
whether
whetherevaluate
it
it the
runs
runs feasibility
in
in embedded
embedded of the capacity of interacting with other agents.
devices and
Experiments can
were be practically
performed used
to evaluate to operate
the robots.
feasibility of goals,
the
An producing
capacity
important of a goal-driven
interacting
characteristic with ofbehaviour;
other
intelligentagents.social
agents ability
is is
the
the developed
devices
devices and can
and architecture:
can be
be practically
practicallywhether usedit to
used runs
to in
operate
operate embedded
robots.
robots. An important characteristic of intelligent agents is the
The developed
the paper alsoarchitecture:
discusses thewhether
advantagesit runsand in limitations
embedded the
An capacity
important
balance between of interacting
characteristic
reactivity with
and of other
intelligentagents.
pro-activeness agents is
Wooldridge the
devices
The paper andalso
paper candiscusses
also be practically
discusses used to operate
the advantages
advantages and limitationsrobots. An
limitations important
betweencharacteristic
The
of using and
devices
The
of
BDI can
paper
using BDI
agents
also
agentsbe to
to
the
program
practically
discusses the
program
robots
used to
advantages
robots
when
when
and compared
operate
and compared robots.
limitations
to balance
to balance
(1999).
An Ifbetween
important an agent
reactivity
reactivity
characteristic andof
and
is only reactive, of
intelligent agents
pro-activeness
pro-activeness
it is difficult
intelligent agents
is the
Wooldridge
Wooldridge
to envision
is the
of using BDI
traditional agents
imperative to programming.
program robots when compared balance
(1999).
to how to Ifperform between
If an agent reactivity
is only and
reactive, pro-activeness
it is difficult Wooldridge
to envision
The
of paper
using BDI
traditional
traditional
also discusses
agents
imperative
imperative
the advantages
to programming.
program
programming. robots when andcompared
limitations to (1999).
balance
(1999).
how to
an agentreactivity
between
If an
perform agent
is only to
actions
is only
actions
reactive,
to andachieve
reactive,
it is
long
pro-activeness
achieve it is
long
difficult
difficult
term
to
to
envision
termWooldridge
goals, the
envision
goals, the
of using BDI
traditional
The reminder agents
imperative
parts of to this
programpaperrobots
programming. when compared
are organized as follows. how
to agent
(1999). towillperform
If anbeagent actions
simplyis only to
reacting achieve
reactive, to the it long
is term to
environment
difficult goals, the
which
envision
The reminder parts of this paper are organized as follows. how
agent
agent to perform
will
will be
be actions
simply
simply to
reacting
reacting achieve
to
to the
the long term
environment
environment goals, the
which
which
traditional
The reminder
Section imperative programming.
partsaofbackground
2 provides this paper are for organized
what is discussedas follows. in how likely will
to not
perform lead to
actions the accomplishment
to achieve long of goals.
term On
goals, the
the
The reminder
Section 2 parts
provides aof this
backgroundpaper are
for organized
what is as follows.
discussed in agent
likely
likely will
will
will be
not
not simply
lead to reacting
the to
accomplishment the environment
of goals. Onwhich
the
Section 2 provides
this paper; Section 3aofpresents
background for organized
the are what
related is discussed
work that servedin other
agent hand,
will be if lead
simply to the
an agent isaccomplishment
reacting purely to pro-active,
the of goals.
environment On
goal-driven, the
which
The reminder
Section
this paper;
paper; parts
2 provides this
Section 33a presents
background
presents paper for what
the related
related as
is discussed
work follows.
that served
served likely
other
in it will hand,will
hand, not if lead
an to
agent the isaccomplishment
purely pro-active, of goals. On
goal-driven, the
this
as reference Section
to tailor the proposed the work
architecture; thatSectionin4 other likely
other
takenot
will
hand,
if lead
an agent
actions
if an agenttoto the isaccomplishment
purely pro-active,
accomplish goals but
is purely pro-active,
itgoal-driven,
willOn
of goals. rarely
the
Section
this
as
as
2 provides
paper;
reference
reference
contains the
Section
to
to tailor
tailor3a presents
description
background
the
the proposed
proposed
of the
the for what
related
architecture;
proposed
is discussed
work
architecture; that
architecture
served
Section
Section
used
4
4
it
it will
will
check
other if
take
take
the
hand,
actions
actions
conditions
if an
to
to
agent
accomplish
accomplish
that
is led
purely it to
goals
goals
commit
pro-active,
but
but itgoal-driven,
it
to
will
will rarely
those rarely
goals
goal-driven,
this
as paper;
theSection
reference
contains to tailor3 presents
description theof thethe
ofproposed related work that
architecture;
proposed architecture served
Section
used 4 it willif
check
check iftake
the actions to that
the conditions
conditions accomplish
led
ledinit togoals
to commit but toit those
will rarely
goals
contains
as
contains
the
to reference
integrate
the
description
BDI
to agents
tailor
description theofand the
proposed
the
proposed
hardware; architecture
Section Section
architecture;
proposed architecture
used
5 details
used 4 it
still
check
still
stands,
will iftake
stands,the
which may
actions
conditions
which mayto that
result
accomplish
that
result led in
it an
it to
an
commit
agentbut
goals
commit
agent
to
it those
pursuing
to will a
those
pursuing
goals
goal
rarely
a goals
goal
to
to integrate
integrate BDI
BDI agents
agents and
and hardware;
hardware; Section
Section 5
5 details
details still
that stands,
is no which
longer may
possible result
or in an
relevant. agent pursuing a goal
the performed
contains the experiments;
description of the and Section
proposed 6 outlinesused
architecture the stillcheck
that isifno
stands,the conditions
longer
which possible
may that or
result led it to
relevant.
in an commit
agent to those
pursuing a goals
goal
to
theintegrate
the performed
performed BDI agents and and
experiments;
experiments; hardware;
and SectionSection
Section 6 outlines
6 5 details
outlines the that is no longer possible or relevant.
the
conclusions
to integrate and
BDI future
agents works.
and hardware; Section 5 details still
that stands,
is
According no to which
longer
Bratman may
possible result
et or
al. in an
relevant.
(1988) agent
an ideal pursuing
but a goal
unrealistic
the performed
conclusions
conclusions and experiments;
and works. and Section 6 outlines the According to Bratman et al. (1988) an ideal but unrealistic
future works.
future
the performed
conclusions future works. and Section 6 outlines the solution
and experiments; that is no
Accordingtotothis longer
Bratmanpossible
problem or
et al.wouldrelevant.
(1988)beantoideal but unrealistic
compute at each
solution
According totothis
Bratmanproblem al.would be to compute at
at each
conclusions and future works. solution
instant
According oftotime
to this
Bratmanproblem
which isetthe
et al.
(1988)
would
best
(1988) bean
possible
an toideal but unrealistic
compute
course
ideal but each
of actions.
unrealistic
solution
instant
instant of
of to
time
time this problem
which
which is
is the
the would
best
best be
possible
possible to compute
course
course of
of at each
actions.
actions.
However,
solution it is not possible since agents have a limited
 The authors acknowledge the support from CAPES and Pró- instant
However,
However, oftotime
it this
is problem
is which
not is thewould
not possible
itresources possible best
since
since
beagents
possible to compute
agentscourse have ofa at each
a actions.
limited
have Therefore,
limited
amount
instant ofoftime which to
is perform
the best computation.
possible course of actions.
 The authors acknowledge the support from CAPES and Pró-
 However,
amount
amount of it is not
resources
ofitresources possible
to
to perform since agents
computation. have a limited
Therefore,
Alertas.
The authors acknowledge the support from CAPES and Pró- the author
However, proposed an perform
is not possible sincecomputation.
architecture have Therefore,
for practical
agents a reason-
limited
 The authors acknowledge the support from CAPES and Pró-
Alertas.
Alertas.
amount
the
the author
author of resources
proposed
proposed to
an
an perform
architecture
architecture computation.
for
for practical
practicalTherefore,
reason-
reason-
 The authors acknowledge the support from CAPES and Pró-
Alertas. amount of resources to perform
the author proposed an architecture for practical reason- computation. Therefore,
Alertas.
2405-8963 Copyright © 2020 The Authors. This is an open access article under the the
author proposedlicense
CC BY-NC-ND an architecture
. for practical reason-
Peer review under responsibility of International Federation of Automatic Control.
10.1016/j.ifacol.2020.12.2718
 Gustavo R. Silva et al. / IFAC PapersOnLine 53-2 (2020) 10000–10005
ing based in the cognitive notions of belief, desire, and
intention (BDI), which in short is the combination, in the
right amount, of reactivity and pro-activeness. Beliefs are
the representation of the information the agent has about
the world and itself, desires are world states the agent
wants to achieve, and intentions are the desires that the
agent decided and committed to accomplish.
Due to the characteristics of intelligent agents, especially
BDI agents, they seem to be a good approach to develop
complex systems composed of several entities (Bordini
et al., 2005, 2007). With that in mind, the authors de-
veloped an agent-oriented programming (AOP) language
called Jason, which is an extension of AgentSpeak(L)
(Rao, 1996), to allow the development of MAS with real-
world applications in an elegant manner and with a rig-
orous formal basis. Thus, Jason will be used as AOP the
language in this work.
3. RELATED WORKS
The use of BDI agents to control robots is already being
explored in related words (Verbeek, 2003; Morais, 2015;
Pantoja et al., 2016; Menegol et al., 2018). For instance,
Menegol et al. (2018) proposed an architecture for embed-
ding Jason agents and effectively embedded the solution
into a real unmanned aerial vehicle (UAV), proving that
it is feasible to use BDI agents to command real-world
robots. While this proposal keeps the hardware details
transparent for the agent programmer, the integration
works in an ad hoc manner. The high-level (BDI agent)
and the low-level layers (robot hardware) are connected by
specific protocols and ports – no standardization has been
used or defined for using agents to control hardware. As
consequence, if the hardware is exchanged a considerable
part of the architecture must be reprogrammed. Therefore,
it is not trivial to reuse the referred architecture. Also,
it does not provide any interface for (re)utilizing robotic
software developed by the roboticist community, for navi-
gation, localization, and control purposes.
Wesz (2015) proposed JaCaROS, an architecture com-
posed of Jason, CArtAgO (Ricci et al., 2009), and The
Robot Operating System (ROS)(Quigley et al.) to inte-
grate BDI agents with hardware. In summary, CArtAgO
artifacts are used as the main abstraction for sensors and
actuators, which communicate with the hardware software
via ROS topics and services. The authors already pro-
vide some artifacts for handling a few existent sensors
and actuators. However, for each different hardware it
is necessary to implement a specific artifact using Java,
where it is needed to handle how actions are converted
into ROS messages, how the messages coming from ROS
are converted into beliefs, and how the agent is updated
in relation to the artifact. Using a different hardware re-
quires that a significant peace of software is programmed,
demanding that the programmer possess knowledge in
Java and CArtAgO, resulting in a non trivial process.
On the other hand, this solution supports customization
quite well. One interesting point of this method is that
to interact with the hardware the agent must only know
about how to operate the artifact. Another advantage of
this method is that with the use of ROS it is possible to
leverage all the robotic software that already exists within
the framework.
10001
In order to promote the integration of hardware and BDI
agents, Morais (2015) also developed a solution that com-
bines Jason and ROS. The author modified the architec-
ture of the Jason agents to receive perceptions and to
send actions using standardized ROS topics. The agents
communicate with intermediary nodes called decomposers
and synthesizers, the former is responsible for translating
high-level actions into commands for the hardware, and
the latter receives data from the hardware and translate
it to perceptions understandable by the agents. Thus, the
exchange of hardware requires that new decomposers and
synthesizers nodes are programmed. Both can be pro-
grammed in any language supported by ROS since they are
decoupled from the Jason agents. Once again, this process
is not trivial. An advantage of this approach is that the
integration with the hardware is totally transparent for the
agent. Also, since it uses ROS, the existing robotic stack
can be utilized.
Although inspired by all these work, in this paper we
focus particularly on the improvement of the architecture
proposed by Morais (2015). This will be accomplished by
establishing standards for using ROS alongside Jason, and
by designing an intermediary node that is more generic,
mitigating the need of reprogramming when the hardware
is changed.
4. JASON-ROS ARCHITECTURE
As discussed in Section 3, there are already some related
works that use Jason for programming the cognitive part of
robotics applications. However, those works provide ad hoc
solutions regarding the control of the robot’s hardware de-
vices, therefore a significant part of the software related to
this integration must be always created. In case the device
is replaced, again the software must be re-programmed.
Thereby, to circumvent this problem, we propose a set
of standards for using Jason with ROS, including the
creation of a dedicated and configurable ROS node named
HwBridge that allows the integration of Jason and the
robot.
An architecture composed of four ROS nodes is proposed
to integrate Jason and ROS, as shown in Figure 1. The
Agent node, as the name suggests, is the agent itself
and is implemented with the Jason language. The Hw-
Bridge node serves as a bridge between the agent and the
hardware, it translates the messages and publishes them
in the correct topics. The Hardware Controller node is
the one that manages the hardware. The Comm node is
responsible for the communication between agents, this
can be via Ethernet, wifi etc. An implementation of the
proposed integration is available at: https://github.
com/jason-lang/jason_ros.
4.1 Agent Node
To allow the use of ROS by a Jason agent it was necessary
(1) to specify and establish standards for ROS topics
and messages; (2) to customize the agent architecture to
include the functionalities defined in the first step.
Specifications and standards For the definition of stan-
dards, the work of Morais (2015) was used as an starting
10002 Gustavo R. Silva et al. / IFAC PapersOnLine 53-2 (2020) 10000–10005

fields: header and the data. In order to receive messages the

Embedded System
agent subscribes to the topic /jason/receive msg, which
Real Hardware also makes use of the Message type.
Manifest
topics & services
Hardware Controller
HwBridge Node
Node
Listing 4. Message message
1 Header h e a d e r
Simulation 2 s t r i n g data
Agent topics

Roscore

Agent architecture customization With the specification

Agent topics
Network
completed and the standards defined, the agent architec-
Agent Node Communication Node
Interface ture was modified to include the functionalities discussed,
ROS Node
which was done by overloading the methods represented in
Table 2. To accomplish that, since ROS does not provide
support for using Java in its official distribution, a 3rd
Fig. 1. System architecture party Java ROS implementation, rosjava was used. It must
be emphasized that for the Jason programmer this is all
point. The resulting specification of ROS topics and their transparent, in other words, a user of this Jason-ROS
definition can be seen in Table 1. integration does not need to modify any code in Java.
Table 1. Topics used by the agents Table 2. Overloaded methods
Topic Name Definition Method Customization
/jason/percepts Subscribes to get new perceptions init Initialize a ROS node
/jason/actions Publishes to send actions it wants to perform act Send actions via ROS
/jason/actions status Subscribes to receive the status of an action sent reasoningCycleStarting Receive feedback of actions via ROS
/jason/send msg Publishes to send message
perceive Receive perceptions via ROS
/jason/receive msg Subscribes to receive message
checkMail Receive msgs via ROS
sendMsg Sends msgs via ROS
To handle perceptions, the agent subscribes to the topic broadcast Broadcast msgs via ROS
/jason/percepts which uses a custom type of message
called Perception (see listing 1), that is composed of 4 4.2 HwBridge Node
fields: header, name of the perception, perception param-
eters, and a boolean called update which indicates if the The HwBridge node is the main advantage in relation to
perception should be added or updated in the belief base. the architecture proposed by Morais (2015), this node has
a similar purpose that the ones he calls decomposers and
Listing 1. Perception message synthesizers. As discussed in Section 3, they are used as
1 Header h e a d e r
intermediary nodes to translate the information between
2 s t r i n g perception name the agent and the hardware. The biggest difference here
3 s t r i n g [ ] parameters is that instead of requiring that both of these nodes are
4 b o o l update programmed for each specific use case, depending on the
hardware, a general purpose node (HwBridge node) is
In order to perform an action, the agent publishes into available and the only thing that has to be adjusted for
the /jason/action topic a message of the type Action (see each case is a couple of configuration files.
listing 2), which contains 3 fields: header, the action name, The communication with the Agent node is done via
and action parameters. Then, the agent subscribes to the the first three topics defined in Table 1, /jason/percepts,
topic /jason/actions status to receive information about /jason/actions, and /jason/actions status. However, the
an action that was previously sent, the message type used information flow is in the opposite direction. The Hw-
is ActionsStatus (see listing 3), which also contains 3 fields: Bridge node publishes the perceptions it receives from
header, the result of the action, and its unique id. the Hardware Controller into the topic /jason/percepts, it
subscribes to the topic /jason/actions to get the actions it
Listing 2. Action message needs to send to the Hardware Controller, and it publishes
1 Header h e a d e r into the topic /jason/actions status to inform the agent
2 s t r i n g action name about the status of previously submitted actions.
3 s t r i n g [ ] parameters
To communicate with the Hardware Controller specific
topics and services are used for each different perception
Listing 3. Action status message and action, which are configured via two configuration
1 Header h e a d e r
files, the perceptions and actions manifest. These files
2 bool r e s u l t contain all the information required to translate actions
3 uint32 id sent by the agent into understandable commands by the
Hardware Controller, and to create perceptions under-
standable by the agent based on data published by the
Regarding communication, when an agent wants to send Hardware Controller.
messages to external agents it publishes it into the topic
/jason/send msg using a custom type of message called The perception manifest contains the information about
Message (see listing 4). This message is composed of 2 which topics the HwBridge node must subscribe to get
 Gustavo R. Silva et al. / IFAC PapersOnLine 53-2 (2020) 10000–10005
each perception, and how to translate the data into a
perception understandable by the agent. An example of
perception manifest is shown in listing 5. In this case
the perception comes from the topic /turtle1/pose and it
results in a perception such as pose(3.0, 2.0, 0.3) being
sent to the Agent node, then the agent replaces in its belief
base all the perceptions called pose by this new one, or add
it in case none exists.
Listing 5. Perception manifest
1 [ pose ]
2 name = / t u r t l e 1 / p o s e
3 msg type = Pose
4 d e p e n d e n c i e s = t u r t l e s i m . msg
5 args = x , y , theta
6 b u f = update
The action manifest describes in which topics/services the
HwBridge node should publish/request to perform each
action, and how the data being sent must be set up.
An example of action manifest can be seen in listing 6.
With this configuration when the agent tries to perform
an action, as for example cmd vel(1.5, 0.0, 0.0), the Hw-
Bridge node would publish to the topic /turtle1/cmd vel
a message of the type Twist with its fields “linear.x=1.5”,
“linear.y=0.0”, and “linear.z=0.0”.
Listing 6. Action manifest
1 [ cmd vel ]
2 method = t o p i c
3 name = / t u r t l e 1 / c m d v e l
4 msg type = Twist
5 d e p e n d e n c i e s = geometry msgs . msg
6 params name = l i n e a r . x , l i n e a r . y , l i n e a r . z
7 params type = f l o a t , f l o a t , f l o a t ,
Figure 2 illustrates typical sequence of messages exchanged
by the system nodes. Firstly, when an Agent sends an
action, the HwBridge node translates the message and
forwards it to the Hardware Controller node in the right
topic/service, which then executes what is necessary to
perform the action, and upon its completion or failure it
informs the agent about its status. In another situation,
when the Hardware Controller node publishes data into a
topic associated with a perception, the HwBridge node
interprets the information and, if the data is different
from the last one received, it translates it into a digestible
message and forwards it to the Agent node.
It is important to highlight that the the arrival of new
actions and perceptions are handled with callbacks and
in separate threads, which allows that they are processed
concurrently, despite what is being shown in the diagram.
All message exchanging are asynchronous, except when the
HwBridge node sends an action to Hardware Controller,
in this case it is synchronous.
It was decided to implement the HwBridge node using
Python language because: (i) ROS offers native support
for Python; (ii) since Python is an interpreted language,
it facilitates to deploy the proposed solution into different
embedded systems, as no (cross)compilation is needed.
10003
Hardware
Agent node HwBridge node
Controller node
sendAction()
translateAction()
sendAction()
performAction
actionStatus
sendActionStatus()
sendPerception()
translatePerception()
sendPerception()
Fig. 2. Typical sequence of messages exchanged by the
system nodes
4.3 Hardware Controller node
The Hardware Controller node is the one that, de facto,
controls the hardware. Since a lot of robots nowadays
already have a ROS package implemented for interacting
with hardware, most of the time, there is no need to
implement this node.
The proposed architecture is advantageous since the pro-
grammer has to only implement the Agent node, set up
the perceptions and actions manifest and reuse an existent
Hardware Controller node. This allows a person that only
posses knowledge about Jason to program real robots,
even for those with extended knowledge about different
programming languages, it reduces the time needed for
setting up a robotic system.
4.4 Comm Node
Given that our proposal works in a distributed way, that is,
there exists several ROS-Master nodes, it was created the
Comm node. It serves as communication interface between
agents, given that standard ROS protocols cannot be used
within this scenario.
It is left to developers to decide which technology should
be used to implement the Comm node, attempting that
the message Data Field (listing 4) must comply with the
Jason message specification. It consists in a string with
the following format: “<id,sender,itlforce,receiver,data>”.
Where id is an unique identifier for the message, sender
is the name of the agent sending the message, itlforce
is the illocutionary force (Searle, 1965), receiver is the
name of the agent receiving the message, and data is the
information being sent.
10004 Gustavo R. Silva et al. / IFAC PapersOnLine 53-2 (2020) 10000–10005
5. EXPERIMENTS
In order to validate and evaluate what is being proposed,
a MAS composed of unmanned aerial vehicles (UAVs) will
serve as a testbed. Firstly, the overall system architecture
will be embedded in a board (e.g., beaglebone, raspberypi)
and used to control a simulation with a single UAV, the
main objective of this experiment is to serve as a test of
concept. Then, a more complex simulation involving mul-
tiple UAVs is performed in order to assess the advantages
of using BDI agents as a programming paradigm instead
of the more traditional approaches. The implementation
of the experiments performed can be seen at: https://
github.com/Rezenders/mas_uav.
5.1 Single UAV Mission
The first step is to enable the proposed architecture to
control a single UAV. For that a proper Hardware Con-
troller node must be used. Fortunately, there is already
implemented a ROS package called mavros that allows
to communicate with flight controllers (FC), avoiding the
need to develop a new Hardware node. This UAV archi-
tecture differs from the one shown in Figure 1 with regard
to the Hardware Controller node, which in this case is
mavros, and the UAV is the actual hardware.
This proposal was tested in a simulated environment
(ArduPilot SITL) with a single UAV. The simulation did
run in a desktop and all the other applications executed in
the embedded device. For this experiment a simple mission
was performed: the UAV had to (1) takeoff; (2) fly to a
predefined waypoint; (3) return to home; and finally (4)
land.
A Beaglebone black was initially used as embedded device.
However, the application did run out of memory every time
it was executed, not being able to complete the mission.
Considering that the proposed architecture uses ROS,
such behavior was not a surprise if compared to results
reported in Menegol et al. (2018). In such experiments
the Jason solution (without ROS) reached a maximum
memory usage of 85% using the same embedded device.
The same tests were performed once again using a Rasp-
berry Pi 3 embedded device, and thereby the UAV success-
fully completed the mission every time the application was
executed. This shows the feasibility of integrating Jason
and ROS within an embedded device.
Afterwards, the Jason agent was replaced by a Python
program in charge of performing the same mission. It
was opted to maintain the same HwBridge node to keep
everything else similar in the experiment, but the Agent
node (Jason or Python). CPU and memory usage info
collected collected during the execution of both agents are
shown in Table 3. It is possible to note that Jason requires
more computational resources than Python, 256% more
CPU and 231% more memory. However, both agents can
properly execute in the Raspberry Pi 3 device.
Another point of comparison between both agents is qual-
itative, and regards the easiness of programming the cor-
responding mission in Jason versus Python. To support
this subjective analyses the size of the programs, their
number of lines, and number of words were measured.
Table 3. Results for Single-UAV mission
Approach
CPU [%] Memory Usage [%]
Mean Std Max Mean Std Max
Python 1.65 0.20 2.61 17.45 0.00 17.45
Jason 4.22 2.25 14.59 40.37 0.06 40.51
For the measurement of the source files size they were
compressed using gzip to reduce the influence of line breaks
and blank spaces. As can be seen in Table 4, the size of
the source file, number of lines, and number of words of
the Jason program is smaller than the one in Python. This
may be considered as an indicator that the Jason approach
is easier to program.
However, it should be noted that the Jason approach
requires the perception and action manifests to be properly
set up. Besides, rosjava needs to be installed and config-
ured. This results in development and execution overhead
in the side of the proposed architecture, which must be
properly balanced in too simple applications.
In order to better assess the complexity gap (difficulty) in
between programming using Jason versus Python, a more
elaborate experiment was developed, as follows.
Table 4. Programs metrics in S-UAV mission
Approach Size (bytes) # of lines # of words
Python 518 49 112
Jason 344 26 64
5.2 Multiple UAV Mission
To better understand and evaluate the usage of Jason in
more complex tasks, it was chosen to design an application
that is already being explored in the real world, a search-
and-rescue (S&R) mission where UAVs are being used to
find victims in floods and then deliver them buoys.
In the context of S&R missions, it is really useful to have
more than one UAV collaborating since when vehicles are
equipped with buoys their flight autonomy time is reduced
due to the increased payload. Hence, a good strategy to
adopt is to have two types of UAVs working together: (i)
the Scouts which are equipped with cameras and (ii) the
Rescuers that are in possession of buoys, using the former
to find victims and inform the latter about their location,
which then deliver the buoys.
Thus, an application was designed to mimic a S&R mission
that uses one Scout and two Rescuers agents working in
cooperation. Firstly, the Scout takes off and flies over an
area looking for victims. When a victim is located the
agent informs the rescuers about the victim’s position.
When the rescuers receive information about a victim’s
location they negotiate to decide which one will deliver the
buoy. The one that ends up in charge of the rescue takes
off, flies to the designated position, drops a buoy, and then
returns to the landing area to recharge and replace the
buoy. For the sake of simplicity, scouts are only in charge
to locate victims and the rescuers to drop buoys.
As well as in the first experiment the agents will be em-
bedded in three distinct Raspberry Pi 3 and the simulation
will be running in a separate desktop computer. Another
 Gustavo R. Silva et al. / IFAC PapersOnLine 53-2 (2020) 10000–10005 10005

simplification done in this experiment is that the connec- Python. A disadvantage of the proposed approach is that
tion between the Raspberrys’ is considered to be constant it uses more computational resources. However, this is not
and without losses. The Raspberrys and the desktop were prohibitive in embedded platforms like Raspberry Pi 3.
connected with each other via Ethernet. The Comm Node
was implemented to send/receive messages to/from other As future work, it should also be possible to use ROS
devices via UDP. actions in addition to topics and services. Also, it should
be explored if the perception and actions manifests can
Like in the single UAV experiment, the agents performed be replaced by rosparams in order to make it even more
the same mission using both Jason and Python. During the compliant with ROS.
execution of both methods the CPU and memory usage
were monitored and the data collected can be seen in We also intend to further explore the Comm Node (Sec-
Table 5. As expected, Jason uses more CPU and memory tion 4.4). It should be analyzed the possibility to imple-
than Python, 2.31 and 2.30 times respectively. Again, ment it together with the HwBridge Node. Furthermore,
this is not a problem for embedded platforms such as it can be analyzed the possibility of deploying the Comm
Raspberry Pi 3. Node as a ROS package that already implements commu-
nication using Ethernet or Wifi networks.
Table 5. Results for Multi-UAVs mission
REFERENCES
CPU [%] Memory Usage [%]
Approach Agent Bordini, R.H., Hübner, J.F., and Vieira, R. (2005). Ja-
Mean Std Max Mean Std Max
Scout 1.73 0.17 2.30 19.78 0.00 19.78
son and the Golden Fleece of Agent-Oriented Pro-
Rescuer 1 1.78 0.42 4.02 19.61 0.00 19.64 gramming. 3–37. Springer, Boston, MA. doi:10.1007/
Python
Rescuer 2 1.76 0.27 3.67 17.99 0.00 18.01 0-387-26350-0 1.
ALL 1.76 0.31 4.02 18.93 0.85 19.78 Bordini, R.H., Hübner, J.F., and Wooldridge, M. (2007).
Scout 4.68 1.56 8.61 43.81 0.06 43.87 Programming Multi-Agent Systems in AgentSpeak using
Rescuer 1 3.95 1.57 16.00 44.00 0.06 44.15
Jason Jason. Wiley Series in Agent Technology. John Wiley &
Rescuer 2 3.94 1.08 8.86 43.14 0.03 43.18
ALL 4.07 1.42 16.00 43.64 0.40 44.15
Sons, Ltd, Chichester, UK. doi:10.1002/9780470061848.
Bratman, M.E., Israel, D.J., and Pollack, M.E. (1988).
Plans and resource-bounded practical reasoning. Com-
Regarding the ease of programming, considering the sub- putational Intelligence, 4(3), 349–355. doi:10.1111/j.
jective analysis of the authors, in this experiment it was 1467-8640.1988.tb00284.x.
undoubtedly easier to program the behaviour logic using Menegol, M.S., Hübner, J.F., and Becker, L.B. (2018).
Jason. But still, in order to support this statement, for Evaluation of Multi-agent Coordination on Embed-
each approach the size of the source files, number of lines, ded Systems. 212–223. Springer, Cham. doi:10.1007/
and number of words of all agents were measured and 978-3-319-94580-4 17.
its sum can be seen in Table 6. It can be noted that Morais, M.G. (2015). Integration of a multi-agent system
the Jason program is smaller, and contains less lines and into a robotic framework : a case study of a cooperative
words than the one in Python, which is an indicative of the fault diagnosis application. URL http://tede2.pucrs.
Jason approach being easier to program. Another metric br/tede2/handle/tede/6396.
that can be used is that in the Python approach it was Pantoja, C.E., Stabile, M.F., Lazarin, N.M., and Sichman,
necessary to use multi-threading and locks, which made J.S. (2016). ARGO: An Extended Jason Architecture
the programming more complex. that Facilitates Embedded Robotic Agents Program-
Table 6. Programs metrics in M-UAVs mission ming. 136–155. doi:10.1007/978-3-319-50983-9 8.
Quigley, M., Gerkey, B., Conley, K., Faust, J., Foote,
Approach Sum Size (bytes) Sum # of lines Sum # of words T., Leibs, J., Berger, E., Wheeler, R., and Ng, A.
Python 3668 384 928
Jason 2473 260 569 (????). ROS: an open-source Robot Operating System.
Technical report. URL http://stair.stanford.edu.
Rao, A.S. (1996). AgentSpeak(L): BDI agents speak out in
6. CONCLUSIONS AND FUTURE WORKS a logical computable language. 42–55. Springer, Berlin,
Heidelberg. doi:10.1007/BFb0031845.
The present work shows that it is possible to use Jason Ricci, A., Piunti, M., Viroli, M., and Omicini, A. (2009).
agents with ROS interface within an embedded platform. Environment Programming in CArtAgO. In Multi-
It also addresses the advantages of using such architecture Agent Programming, 259–288. Springer US. doi:10.
to program intelligent robots. 1007/978-0-387-89299-3 8.
Experiments using Hardware-in-the-Loop simulations shows Searle, J.R. (1965). What is a Speech Act? Perspectives
that the use of BDI agents approach simplifies the devel- in the philosophy of language: a concise anthology, 2000,
opment when compared to the conventional imperative 253–268. URL https://pdfs.semanticscholar.org/
programming. Such conclusion is supported by metrics a6c7/56a24ea621d3882d9b2baa8eb5352105a2cd.pdf.
such as number of lines from the respective programs, Verbeek, M. (2003). 3APL as Programming Language for
their binary size, number of words, and code complexity Cognitive Robots. Technical report.
in terms of the need to use multi-threading and locks. Wesz, R.B. (2015). Integrating robot control into the
Another interesting point to highlight is that given the Agentspeak(L) programming language. URL http://
nature of the Comm node, it is possible to create a multi- tede2.pucrs.br/tede2/handle/tede/6941.
robot system with heterogeneous agents, i.e., where some Wooldridge, M. (1999). Intelligent agents. Multiagent
agents may be programmed using Jason and others using systems, 35(4), 51.