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. Hü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. Rö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 Computación, 2008. [1] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, [17] A. Van Breemen, K. Crucq, B. Krö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 7