=Paper= {{Paper |id=Vol-2404/paper01 |storemode=property |title=Towards a Real-Time BDI Model for ROS 2 |pdfUrl=https://ceur-ws.org/Vol-2404/paper01.pdf |volume=Vol-2404 |authors=Francesco Alzetta,Paolo Giorgini |dblpUrl=https://dblp.org/rec/conf/woa/AlzettaG19 }} ==Towards a Real-Time BDI Model for ROS 2== https://ceur-ws.org/Vol-2404/paper01.pdf

Workshop "From Objects to Agents" (WOA 2019)

Towards a Real-Time BDI Model for ROS 2
Francesco Alzetta Paolo Giorgini
University of Trento University of Trento
Trento, Italy Trento, Italy
francesco.alzetta@unitn.it paolo.giorgini@unitn.it

Abstract—In the race for automation, electronic devices are the environment, but also by time restrictions. Our proposal
required to become more and more intelligent in order to represents a first step towards implementing in ROS 2 the
make the correct choices in unforeseen situations without any concept of agents whose practical reasoning is bounded for
need of human intervention. AI proposes basically two different
approaches: machine learning algorithms and multi-agent sys- real-time performances.
tems. While the former perform very well when dealing with In Section II we briefly cover the background knowledge
single, independent, computing units, multi-agent systems are needed to understand the technical part of the work. In
more suitable in case of different components interacting with Section III we show the architecture of our system, discussing
one another. In this paper, we propose a real-time multi-agent
the most interesting details about how we implemented it in
approach to improve practical reasoning, integrating the Belief-
Desire-Intention model into one of the most popular robotics Section IV. We conclude with an overview of the related work,
framework, ROS 2. followed by a discussion about the future improvements and
Index Terms—BDI model, ROS 2, Multi-Agent Systems, Soft the contributions of this work.
Real-time, Robotics framework, Smart devices
II. BACKGROUND
I. I NTRODUCTION
Robots and devices involved in complex environments gen- Despite its name, ROS 2 is not an operative systems, but
erally require both high level, deliberative, capabilities (such it can rather be seen as a distributed framework of processes
as reasoning, knowledge representation, planning, communi- (or nodes) that enables executables to be individually designed
cation) and low level, reactive, primitives (such as sensor man- and loosely coupled at run-time.
agement, obstacle avoidance, navigation). While nowadays As mentioned in the introduction, there are many improve-
the reactive capabilities are quite satisfyingly achieved, with ments made in ROS 2, concerning in particular real-time
devices able to reliably sense the environment and promptly compliance and system scalability, which led us to choose
react to stimuli, the deliberative part still presents a number it instead of its widely adopted first version. Moreover, ROS
of open problems. 2 has several desirable properties that are missing in other
Reasoning and planning, for instance, are activities that robotics frameworks taken into consideration such as ORO-
usually consume time and resources, making them unsuitable COS [4], YARP [5] or CARMEN [6], namely:
for real-world scenarios involving devices with real-time con- • Modularity: This characteristic allows a developer to
straints. decide which parts of the general implementation take
Furthermore, for many years robotics developers struggled from the packages shared by other developers and which
with a large variety of open source and proprietary standards, implement by himself instead. In our case, for instance,
which forced them to find ad hoc solutions to make possible we focused mainly on the development of the BDI
the interaction and communication between devices sold by system, leaving the management of other tasks such as
different vendors. Robot Operative System (ROS) [1] solves locomotion or sensing to modules designed and imple-
this problem, giving the developers an across-the-board tool mented by other developers.
able to deploy the same code on devices of different vendors. • Compatibility: Being ROS designed to be as thin as pos-
ROS 2 overcomes some of the ROS limitations [2], such as sible, the code written for it can be easily integrated inside
the possibility to write real-time nodes when using a proper other robot software frameworks. Some ROS code has
Real-Time Operating System (RTOS) and the implementation been already integrated with OpenRAVE[7], Player[8]
of a distributed structure for discovery and interaction between and OROCOS.
nodes. • Language independence: Having the possibility of writ-
In this paper, we propose a new approach that allows ing different parts of the code with different languages
integrating the notion of agent into devices running ROS 2. (C++, Python, Lisp, Java are some of the supported
We develop a model of a real-time agent, implementing a BDI languages) allows the developer to exploit the advantages
architecture [3] natively by using the core functionality of the of each language and their libraries.
middleware. The choices of the agent, then, are influenced • Wide adoption: ROS is a very popular framework among
not only by its internal status and by the stimuli coming from the robotics developers and manufacturers so, by choos-

1
Workshop "From Objects to Agents" (WOA 2019)

ing it, we are widening the possible application fields of
User Code
our work.
The main concepts of ROS 2 are: packages, nodes, mes- ...
Module1 Module2 ModuleN RT-BDI
sages, topics, and services.
• Packages are collections of nodes, datasets, configuration
files and anything else that logically constitutes a useful
module, where module is intended as an easy-to-consume ROS client library API
piece of software that can be nimbly reused by other
users. Rclcpp Rclpy Rclcs Rcljava
• Nodes are processes responsible for performing compu-
tations. They can be seen as entities that can execute code
and communicate with each other.
ROS middleware API
• Messages are simple data structures that comprise typed
fields. Standard primitive types (integer, floating point,
Application

boolean, string) are supported, as long as arbitrarily DDS implementation
nested structures and arrays. Messages are passed be-
tween nodes when they have to share information.
• Topics can be seen as containers in which the publishing
nodes send out messages that will be gathered by the
subscribing nodes. For each topic, there may be multiple Linux / Windows / MacOS / RTOS
concurrent publishers and subscribers, and each node may
publish and/or subscribe to multiple topics. This publish-
Fig. 1: The software architecture.
Middleware

subscribe pattern allows the system to be more scalable,
since new nodes can be added and start publishing
and/or subscribing to already existing topics in a totally
transparent way to all the other nodes, which do not need layer extremely simplifies the job to the developer, since it
to be aware of the newly joined nodes. avoids him the task of setting up a connection between two
• Services are used when the designer of the system wants
nodes to exchange information. The ROS middleware API,
request/reply interactions between two nodes, instead of instead, is responsible for providing support to multiple DDS
the many-to-many mechanism of the publish-subscribe implementations despite the fact that each of them differs
pattern. They are defined by a pair of message structures, slightly in their exact API. This interface, then, allows using a
one defining the request a client can send towards the general publish-subscribe system in the upper layers without
worrying about the specific DDS implementation used. The
OS

provider of the service, and one representing the struc-
ture of the reply the provider should send back to the ROS client library API layer makes ROS concepts easy to use
client. Services, then, should be used when a one-to-one and to access via code. It allows the programmer to implement
communication is needed. its own nodes in the desired language (obviously provided that
a client library for ROS exists for that language), being sure
The tangible part of our work, then, is represented by a
that it will be fully compatible with all the other nodes in
package containing design skeletons and examples of im-
the system, even those written in a totally different language.
plementation of some nodes which are interacting through
The upper layer is where the code written by the designer of a
the exchange of messages published on topics or sent via a
package is located. All the nodes run by the device reside here,
service.
hence this is the level at which our work has focused most.
III. A RCHITECTURE In the following, we present the architecture of our agent,
In this section, we show the multi-layered architecture we showing how the ROS 2 nodes make use of the BDI model.
propose to integrate BDI agents in ROS 2.
The real-time BDI architecture
The general architecture We designed our BDI model to explicitly consider timing
In Fig. 1 we show how our implementation (in orange) constraints in the actions of the agents and in the interactions
wedges in the general ROS 2 architecture. between them. This is particularly helpful when assuming that
Starting from the bottom, the proposed architecture can be agents have different ways to reach their goals, so that timing
deployed without restrictions in any operative system running restrictions play an important role in deciding which actions
ROS 2, even though an RTOS is necessary when running to perform in order to achieve the desired result.
systems that need hard real-time behavior. The Data Dis- In the real-time domain, there is a clear distinction between
tribution Service (DDS) implementation provides a publish- soft and hard real-time. These two terms do not differ in how
subscribe transport that allows any two DDS programs to the real-time is guaranteed, but rather in the extent of the
communicate without the need for a central coordinator. This damage caused to the system in case the real-time constraints

2
Workshop "From Objects to Agents" (WOA 2019)

are not met. In a soft real-time agent, missing a deadline Beliefs
may prevent the data to be processed or the behavior of the The elements of the belief-set are defined as couples com-
agent from being accurate, but it will not be considered as posed by a string, which identifies the belief, and a value
a catastrophic failure by the system. Conversely, a hard real- assigned to that belief, which could be of any type supported
time system will treat as a failure the non-fulfillment of its by ROS 2 messages. In the following, the BNF grammar of a
temporal restricted responsibilities. belief.
Since our work operates at a high-level layer, being al-
most completely transparent to those low-level components
: : =
responsible for achieving hard real-time constraints, it can only : : = s t r i ng
guarantee soft real-time constraints. Missing a deadline, then, : : = bool ean | st r i ng | i nt | f l oat
should be tolerated by the system.
In our model, the designer of the MAS will define a deadline
for desires, namely the time the agent has to accomplish that Desires
goal, while for plans it represents the maximum time required
The elements of the desire-set are expressed by a tuple: the
to complete a plan.
goal that has to be achieved, represented by the desired belief,
a set of preconditions that will trigger the desire when all of
them are satisfied, a variable stating which is the priority of
Beliefs Desires Plans that goal and a variable indicating the deadline, that is the time
- Name - Goal - Goal the agent has to complete the intention selected to achieve the
- Value - Preconditions - Preconditions
- Priority - Context goal.
- Deadline - Priority
- Deadline
- Actions
: : =
: : = ? |
: : = i nt
: : = f l oat

In future work, the last two parameters should be inferred
Monitoring_Nodes Scheduler_Node Executor_Node directly by the agent, that should be able to autonomously
decide which goal should have priority over the others, and
how much time each desire should take in order to be satisfied.
In this phase, predetermine such values is a task left to the
designer.
Belief topic Goal topic
Plans
The plan-set contains all the possible plans an agent can
Gets information from
execute. The scheduler will choose a plan on the basis of the
goal it wants to achieve, on its current beliefs, on its priority
Sends information to and on the executing time being available.

Fig. 2: The agent architecture. : : =

: : = s t r i ng
A real-time agent is represented as a tuple defined by the
: : = ? |
name of the agent, its belief-set, its desire-set and the set of : : = ? |
all possible applicable plans. These are pre-defined, and they : : = i nt
represent what an agent could know about the world, which : : = f l oat
are the goals it could achieve, and how it can interact with the
surrounding environment to accomplish that goal. Currently, a Indeed, when specifying a plan, the designer should explicit,
plan is a sequence of actions defined by the designer but, in besides the body of the plan (i.e. the actions to perform), also
future work, we will consider the development of an automated the priority of that plan (in order to make the scheduler choose
planner in order to make more flexible agents, which will be rapidly among a number of possible plans) and the maximum
able to autonomously build a plan. time required by the plan to complete.
In Fig. 2 we illustrate the relationships between the ele- We decided to split the concept of current beliefs into two
ments constituting an agent, highlighting how the ROS 2 part different data structures, preconditions and context, since the
interacts with the real-time BDI model. conditions necessary for the activation of a plan could be

3
Workshop "From Objects to Agents" (WOA 2019)

different from the ones that must hold during its execution. For IV. I MPLEMENTATION
instance, a drone could require to be fully charged as the only As briefly introduced previously, our package strongly relies
precondition to start a journey, but requiring the wind speed upon the advantages provided by the publish-subscribe system
to stay below 10 km/h to continue its traveling and not land implemented in ROS 2.
immediately. Preconditions are those beliefs that must hold at The reason why we decided to make the monitoring nodes
the very start of the plan selection, so the necessary conditions and executor use topics instead of services, preferring a many-
for the scheduler to consider the plan an applicable plan in to-many communication even though a one-to-one could seem
the current situation. The context, instead, is the set of beliefs more straightforward, is scalability. With this solution, in
that must hold for the entire execution of the plan, causing fact, the designer should not take care of the communication
the failure of the plan otherwise. This is particularly useful between a newly added node and other nodes which can
in highly dynamic environments where important beliefs are potentially be interested in the info the node is meant to share,
updated frequently. Obviously, not all the plans with the same but it is sufficient that the new node publishes the message to
goal must have the same preconditions and context. the proper topic.
The agent’s nodes, running in Ros 2, use these structures to The main listener on belief and goal topics is the scheduler
instantiate at run-time the actual beliefs, goals, and intentions that, by subscribing to them, is constantly updated on the state
of the agent. of the device. This node, every time either beliefs or desires are
updated, reschedules the intentions of the agent on the basis of
The monitoring nodes (i.e. those nodes responsible for the priorities and deadlines of its current desires, if necessary.
sensing the environment and monitoring the internal state of This choice is made by exploring the set of plans, searching
the agent) take from the real-time BDI model the representa- for all the applicable ones, and scheduling a sequence of plans
tion of those beliefs and desires that could belong to the agent, which can guarantee at least the achievement of the most
and instantiate at run-time a message corresponding to the critical goals (i.e. the ones with the highest priority).
actual belief/desire when perceived/generated. This message, Once the scheduler has decided the order in which the
then, will be published to the appropriate topic. plans should be executed, it communicates the sequence to
The scheduler node, which is the reasoner of the agent, the executor via a service, as it is the only node interested in
is continuously listening on belief and goal topics, updating this information. The main task of the executor is to control
the belief-set and the desire-set whenever a message on these the execution and to publish messages to the belief topic, in the
topics is published. Furthermore, since such an update could case where an action performed by the agent changes any of its
be meaningful for the failure or instantiation of a plan, or for states, or to the goal topic when an intention finishes, achieving
the activation of a pending one, the scheduler will check if a the goal. If the plan, instead, finishes due to a failure, there can
reschedule is necessary every time a node publishes to those be two reasons: the first one involves the executor encountering
topics. an error during the execution (e.g. an exception is raised). In
this case, the node sends a message to the scheduler node
In case a new schedule has been processed, this will be via a service, asking for a rescheduling. The second reason
sent to the executor node, which is the node that actually is that one condition of the context does not hold anymore.
executes step by step the actions of the currently selected In this case, the executor should do nothing, as the scheduler
plan. An executor node is necessary because executing a will be autonomously aware of the fact, starting immediately
plan is a blocking operation, and leaving this task to the a rescheduling.
scheduler would have meant preventing any rescheduling until We now illustrate the most relevant parts of the implemen-
the current plan either fails or succeeds, causing the system tation and the solutions we found to overcome some of the
to be very unresponsive. limits of ROS 2.
The executor node, during the execution of a plan, will Message structure
send messages to the belief and goal topic to make all the
ROS 2 does not allow to use generic types for message
nodes subscribed to them know about the changes in agent’s
fields, hence there is no way to use the same message to
belief or the completion of a goal. This is important because
represent, for instance, both a boolean-typed and a string-typed
some beliefs cannot be generated by the monitoring nodes,
belief. To cope with this limitation, we took into consideration
but have to be inferred from the actions of the agent. For
two different solutions: the first one consists in providing eight
instance, a robot vacuum could not rely on sensors to know
different types of messages, representing the four standard
if it has scoured the entire room, but this information can be
primitive types (boolean, string, int, and float) for both beliefs
provided from the executor node, that will publish the belief
and desires, while the second one involves only two types of
Room cleaned, true when a plan for cleaning the room has
messages, one for beliefs and one for desires, having a field
been completed, implying that the room has also been entirely
for each primitive type.
scoured.
Despite the last choice would allow a cleaner code, it forces
In the next section, we discuss more in depth how we the developer to find a way to make the nodes understand
implemented the architecture in ROS 2. which is the intended value type among all the fields.

4
Workshop "From Objects to Agents" (WOA 2019)

We implemented four different ROS 2 messages describing equal than the goal’s priority value (here we assume that lower
a belief (containing the name of the belief and its corre- is the priority value, more urgent is the desire). This way, we
sponding value) and four different ROS 2 messages describing give precedence to those plans that at the same time respect
a desire (containing the goal’s name, value, priority, and the priority required by the goal and are the less invasive,
deadline). hence leaving room for more urgent plans that may come
later. The third step involves deadlines: the algorithm checks
Belief and desire representation
every plan in the sorted order until it finds one whose deadline
Beliefs and desires can be represented by messages when fits in the current schedule (lines 9-12). In case there is no
they are simply treated as information that should be ex- way to insert that plan into the current schedule, the scheduler
changed between nodes, but when nodes need to use that checks if the desire it is taking into consideration has a higher
information; for instance, to check if they have a suitable plan priority then any of the desires for which a plan has been
to deal with an incoming desire, nodes have to be encapsulated previously added to the schedule. If that is the case, that plan
in a more standard structure to be easily handled. For this will be deleted from the scheduling queue and the third step
reason, when the scheduler node acquires the information that is repeated, otherwise the considered desire is added to the
a new belief or desire has been published on the proper topic, pending ones, waiting for a new reschedule. We preferred to
it instantiates a new Belief or Goal object, passing into the not include this case in our pseudocode for clarity. Finally, the
constructor the fields contained in the message. Then, this new new schedule is sent to the executor, which will manage the
object will be added to the belief-set if being a belief, or will execution of the new intention.
try to activate a new plan if being a goal.
Obviously, since we have eight different messages, we
also need eight different classes to encapsulate every type of Plan structure
possible belief and desire. To ensure that the scheduler will be able to process all
Nodes the plans made available by the designer, we decided to
force every plan to derive from a superclass called Plan.
As introduced in Section III, we have different nodes with
This decision brings at least two advantages: the first one
different purposes. The monitoring nodes give information
is that, since every plan has the same basic declarations, we
about the perception the agent has of the environment and its
guarantee that all the plans have the same structure and the
internal state, instantiating also the goals when their precon-
same fundamental functions. Secondly, this allowed us to have
ditions are met. In a real-case scenario, the majority of such
collections of plans, simplifying a lot the data structures in
nodes are implemented by the vendor of the device running
both the scheduler and executor nodes.
ROS 2, and the only job left to the designer of the agent is
to forward the information coming from these nodes to the Scheduler and executor, then, are guaranteed that the three
appropriate topic. The scheduler is the main consumer of this functions declared in the superclass will be defined in every
information. instantiated plan. We illustrate these functions by showing how
In the following, Algorithm 1 describes the main function we designed a robot vacuum’s plan for cleaning a room.
to reschedule an intention. Algorithm 2 defines how the scheduler should check if the
plan is suitable to achieve the requested desire. In our example,
Algorithm 1 the scheduler checks if the instantiated goal has the same name
1: procedure R ESCHEDULE I NTENTION (Goal g) of the plan’s goal (e.g. clean room) and the same value (e.g.
2: possiblePlans ← empty array of possible plans true).
3: chosenPlan ← the plan to be executed
4: for each plan p in plan-set do Algorithm 2
5: if p.verifyGoal(g) & p.verifyPrec(desire-set) then 1: procedure V ERIFY G OAL (Goal goal)
6: add p to possiblePlans 2: if plan.goal.name = goal.name then
7: sortBySuitability(possiblePlans) 3: if plan.goal.value = goal.value = true then
8: for each plan p in possiblePlans do 4: return true
9: if checkIfSchedulable(p) then 5: return false
10: chosenPlan ← p
11: break Algorithm 3 has to implement the procedures needed to
12: sendToExecutor(chosenPlan) check if the plan is applicable given the agent’s set of beliefs.
In our case we designed the plan so that the first precondition
It is composed of four steps: first, it collects all the possible is battery charge, 15, which means that a minimum of 15 %
plans by selecting those designed to reach the desired goal and of remaining charge is necessary for the robot to start this
whose preconditions are respected (lines 5-7). Then, it sorts plan (otherwise the function will return false). The second
them by suitability. In our implementation, the most suitable precondition is room clean, false, hence the agent should have
plan is the one having the greatest priority value being less or the perception (i.e. the belief) that the room is dirty.

5
Workshop "From Objects to Agents" (WOA 2019)

Algorithm 3 adding concepts such as agent, plan, and event as first-class
1: procedure V ERIFY P RECONDITIONS (Belief[] belief-set) components of the language. Although JADE and JACK are
2: for each belief b in belief-set do very powerful tools, extending an already existing language re-
3: if b.name = plan.precondition[0].name then quires constant maintenance of the framework. Indeed, JACK’s
4: if b.value < plan.precondition[0].value then syntax supports Java versions until J2SE 1.4, hence important
5: return false features such as annotations and generics are not available.
6: for each belief b in belief-set do Due to the structure of ROS 2, we do not face this problem,
7: if b.name = plan.precondition[1].name then since it is continuously maintained by the ROS community,
8: if b.value 6= plan.precondition[1].value then which deals with the changes in the language by updating
9: return false the ROS client library API layer. We took inspiration from
10: return true JACK for the design of our plans, which describe the exact
sequence of actions an agent should perform, in order to reach
the goal, when a given event occurs. However, in future, we
Algorithm 4 defines the actions the agent should perform will also consider implementing a planner that allows the agent
in case the scheduler chooses that plan as the next plan to be to autonomously build a plan, similarly to what currently do
executed. solvers based on STRIPS [12] and PDDL [13] languages. This
will greatly improve the adaptability of the agent, making
Algorithm 4 it able to find a suitable plan also in unforeseen situations.
1: procedure ACTIVATE P LAN Another relevant improvement, to make the design of our agent
2: goto(room) easier, concerns a design tool similar to the one developed
3: startV acuum for JACK. Indeed, the main problem with ROS 2 is about its
4: while room clean = f alse do learning curve, as while once reached an intermediate level
5: roam(room) of knowledge ROS 2 is pretty easy to manage, the first steps
6: stopV acuum can be problematic, especially for a developer which does not
have a strong C++ background. Such a tool would provide
the visual representation of the various components and of
The designer of a plan, besides implementing these three the links between them, creating and editing the appropriate
functions, has to instantiate in the class constructor the pa- design skeletons, i.e. well-formed and already linked files
rameters declared in the superclass, namely: the plan’s name, whose implementation can be developed further at any time.
the goal that it achieves, preconditions, context, priority, and During the design of our BDI architecture, we followed
deadline. the real-time approach proposed in the ARTS architecture
[14]. This work is particularly interesting because it introduces
V. R ELATED WORK AND FUTURE WORK
in a BDI architecture the concepts of deadline and priority
The source code and an implementation example are avail- for goals and plans, scheduling intentions so as to make the
able at https://github.com/ElDivinCodino/ROS2BDI. In such highest priority intentions achieved by their deadlines. This
an example, we simulated the behavior of a robot vacuum comes together with a deadline monotonic intention schedul-
having three different sensors that check the cleanliness of ing algorithm which, although it does not output the optimal
the rooms, the charge of the battery, and the filling level schedule, gives precedence to the most urgent intentions.
of the dirt tank, and being able to activate different plans We designed our scheduler to have the same behavior. An
depending on the situation. This implementation, despite a important improvement to the decision-making process of the
scheduling algorithm being still raw, shows that the robot agent concerns adding a dynamic inference of the priority
is able to autonomously take smart decisions, planning mid- and the deadline of a desire. Indeed, while now the task of
term strategies in order to adapt to the priorities given by the assigning such values to each possible desire is left to the
different desires that originate during the simulation. Further designer, there could be situations where these values may
experiments involving a simulated MAS are planned, so as to change on the basis of the situation, or simply the designer
have a more complex environment that allows us to formally could not know a priori how much time a plan will need in
compare our work with other state-of-the-art frameworks, as order to complete.
JADE [9], Jason [10] or JACK [11]. The idea of having a process dedicated to the management
JADE, a framework written in Java, simplifies the devel- of the execution of intentions is inspired by [14] and [15].
opment of intelligent multi-agent systems by offering to the These architectures, however, demand to one single process
developer desirable features, such as FIPA-compliant specifi- (called, respectively, executor and interpreter) both the activ-
cations, a distributed platform (agents can be split on different ities of selecting and executing a plan, while we decided to
hosts), parallel task execution and a GUI to manage several split these tasks into two different processes for the reasons
agents and agent platforms. The JACK framework exploits explained in Section III.
the Java Virtual Machine to build multi-agent architectures. It Concerning strictly the robotics field, the BDI model is
implements the BDI model by extending the Java language, often applied in very specific contexts such as robot com-

6
Workshop "From Objects to Agents" (WOA 2019)

petitions [16] and social interactions [17], [18]. However, few [3] A. S. Rao and M. P. Georgeff, “Modeling rational agents within a bdi-
general-purpose BDI implementations, such as the previously architecture.” KR, vol. 91, pp. 473–484, 1991.
[4] H. Bruyninckx, “Open robot control software: the orocos project,” in
mentioned CogniTAO [19], exist. However, while CogniTAO Proceedings 2001 ICRA. IEEE international conference on robotics and
implements the BDI model in the ROS architecture by creating automation (Cat. No. 01CH37164), vol. 3. IEEE, 2001, pp. 2523–2528.
an ad-hoc structure, delivering the execution of the agent [5] G. Metta, P. Fitzpatrick, and L. Natale, “Yarp: yet another robot
platform,” International Journal of Advanced Robotic Systems, vol. 3,
paradigm to a unit (called TAO machine) logically separated no. 1, p. 8, 2006.
from the other ROS-related components, in our work the BDI [6] M. Montemerlo, N. Roy, and S. Thrun, “Perspectives on standardization
model is completely integrated with the ROS main concepts, in mobile robot programming: The carnegie mellon navigation (carmen)
toolkit,” in Intelligent Robots and Systems, 2003.(IROS 2003). Proceed-
since it strongly relies upon them. Furthermore, real-time ings. 2003 IEEE/RSJ International Conference on, vol. 3. IEEE, 2003,
constraints are not considered in CogniTAO, and there is no pp. 2436–2441.
scheduler that decides the order of the execution of the tasks. [7] R. Diankov and J. Kuffner, “Openrave: A planning architecture for
autonomous robotics,” Robotics Institute, Pittsburgh, PA, Tech. Rep.
The problem of achieving agent cooperation has been CMU-RI-TR-08-34, vol. 79, 2008.
treated in an initial phase of our study, but the actual im- [8] B. Gerkey, R. T. Vaughan, and A. Howard, “The player/stage project:
plementation of a distributed computing algorithm that allows Tools for multi-robot and distributed sensor systems,” in Proceedings of
the 11th international conference on advanced robotics, vol. 1, 2003,
splitting tasks among agents has been left as a further im- pp. 317–323.
provement. [10] R. H. Bordini, J. F. Hübner, and M. Wooldridge, Programming multi-
agent systems in AgentSpeak using Jason. John Wiley & Sons, 2007,
VI. C ONCLUSIONS vol. 8.
[11] P. Busetta, R. Rönnquist, A. Hodgson, and A. Lucas, “Jack intelligent
We have proposed an approach to enhance the decision- agents-components for intelligent agents in java,” AgentLink News
making process of robotics devices by exploiting the core Letter, vol. 2, no. 1, pp. 2–5, 1999.
mechanisms of the ROS 2 middleware. Our work fully inte- [12] R. E. Fikes and N. J. Nilsson, “Strips: A new approach to the application
of theorem proving to problem solving,” Artificial intelligence, vol. 2,
grates the BDI model in the ROS 2 architecture, in the sense no. 3-4, pp. 189–208, 1971.
that it does not need the support of ad-hoc structures or the [13] D. McDermott, M. Ghallab, A. Howe, C. Knoblock, A. Ram, M. Veloso,
execution of external software. Moreover, it provides support D. Weld, and D. Wilkins, “Pddl-the planning domain definition lan-
guage,” 1998.
for real-time, allowing the agent to take into consideration [14] K. Vikhorev, N. Alechina, and B. Logan, “The arts real-time agent
time when generating its intentions. We acknowledge that the architecture,” in International Workshop on Languages, Methodologies
current implementation merely shows that this approach is and Development Tools for Multi-Agent Systems. Springer, 2009, pp.
1–15.
possible, but we planned to test it in more complex scenarios. [15] D. Morley and K. Myers, “The spark agent framework,” in Proceedings
Lastly, we have planned future work that facilitates the user of the Third International Joint Conference on Autonomous Agents and
experience and the design of a MAS, and improvements on Multiagent Systems-Volume 2. IEEE Computer Society, 2004, pp. 714–
721.
the scheduler and agent capabilities. [16] S. Gottifredi, M. Tucat, D. Corbatta, A. J. Garcı́a, and G. R. Simari,
“A bdi architecture for high level robot deliberation,” in XIV Congreso
R EFERENCES Argentino de Ciencias de la Computación, 2008.
[1] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, [17] A. Van Breemen, K. Crucq, B. Kröse, M. Nuttin, J. Porta, and E. De-
R. Wheeler, and A. Y. Ng, “Ros: an open-source robot operating system,” meester, “A user-interface robot for ambient intelligent environments,” in
in ICRA workshop on open source software, vol. 3, no. 3.2. Kobe, Japan, Proc. of the 1st Int. Workshop on Advances in Service Robotics,(ASER).
2009, p. 5. Citeseer, 2003, pp. 132–139.
[2] V. A. Hax, N. L. Duarte Filho, S. S. da Costa Botelho, and O. M. [18] B. R. Duffy, R. Collier, G. M. O’Hare, C. Rooney, and R. O’Donoghue,
Mendizabal, “Ros as a middleware to internet of things,” Journal of “Social robotics: Reality and virtuality in agent-based robotics,” in Bar-
Applied Computing Research, vol. 2, no. 2, pp. 91–97, 2013. Ilan Symposium on the Foundations of Artificial Intelligence: Bridging
[9] F. Bellifemine, A. Poggi, and G. Rimassa, “Jade–a fipa-compliant agent Theory and Practice (BISFAI), 1999.
framework,” in Proceedings of PAAM, vol. 99, no. 97-108. London, [19] Cogniteam, “Cognitao (bdi),” 2014. [Online]. Available:
1999, p. 33. http://wiki.ros.org/decision making/Tutorials/CogniTAO