ROS2-BDI
A planning based Multi-Agent BDI architecture for ROS2
What is it?
ROS2-BDI is a
MAS (Multi Agent System)
framework aiming to run on top of
ROS2 Foxy,
emulating the
BDI architecture
for implementing the agents' behaviour. The framework makes usage
of an automated
PDDL planner for
computing plans in the means-end reasoning phase. Specifically it
uses
PlanSys2, a planning system designed and deployed on top of ROS2, taking
inspiration from what ROSPlan represented for the first
version of ROS.
The BDI-PDDL is certainly a synergic duo, allowing to boost the
adaptability of any agent, so that the course of actions it has to
take to reach a certain goal are computed at run time based on its
skillset and the current known environment. Moreover, the
interactions among different actors have been accounted for and
properly facilitated, so that the designed agents can reach out to
their peers whenever the fulfillment of a desire involves an
ability out of their scope.
The platform is still under development by a research team based in the
University of Trento. First results
are promising, since arisen flaws don’t question in any way the
strength of the idea, they indeed ignite sparks enlighting the
steps on the road to realize a viable product for the market,
ready for the general purpose use in industrial as well as private
applications. The framework is openly available on github, free, can be tested and used by other
teams.
Mentions and contributions are hugely appreciated 😉.
Here the repo
with the source code for the respective ROS2 packages and the
instruction for building and testing it.
Architecture
The image below represents the typical architecture characterizing every running agent in the proposed solution. The structure of agent_n is zoomed, while the ones of agent_s and agent_t are not. However, conceptually speaking, they are all the same for what concerns their core behaviours and possibilities. All the circles are ROS2 nodes, the rectangles depict ROS2 topics and the ellipses within the red boundaries are PlanSys2’s nodes. Every running ROS2 BDI agent is going to have its own independent instance of PlanSys2. The core nodes are represented by the five green circles, while all the agent-specific nodes (sensors, actions) have a teal-blue colored background. While the firsts will always be the same five regardless of the agent’s specific tasks, the actions and sensors nodes strongly depend on them, hence their number and functionalities will differ from agent to agent. Nonetheless, it’s true that core nodes expose parameters that will allow to properly tune their behaviour, hence the agent’s one with respect to the scenario and environment in which it’s put in will require. Each topic or service name presents as its prefix the agent_id (in the zoomed case below it'd be "agent_n"), which is also the value of the namespace in which all the respective nodes for the agent are loaded. There are topics for beliefs and desires: one ”channel” for triggering the addition callback and one for the deletion, while another one serves the purpose to regularly notify about the current status of the respective desire/belief set. The topic /{agent_id}/plan_execution info shows updates regarding the currently running plan execution; it consists of a special null message (e.g. no action executing, empty body plan) if there isn’t any and the agent is in idle-state. The topic /{agent_id}/plansys2_state state could be considered as a utility extension to PlanSys2 in order to make it easier to know if one of its nodes is ”active” or not.
Core nodes
| Core Node | Description |
|---|---|
| PlanSys2 Monitor | Regularly calls PlanSys2 nodes’ services to check their respective status and publishes them to /{agent_id}/plansys2 state (ALL core nodes are subscribed to it). |
| Belief Manager | It manages the agent’s beliefs: from initialization to handling the callbacks behind /{agent_id}/add_belief and /{agent_id}/add_belief topics, periodically publishing the belief set to /{agent_id}/belief_set. The core of its job regards keeping the PDDL problem and the belief set aligned by exchanging information with PlanSys2’s Problem Expert node. |
| Scheduler | It manages the agent’s desires: from initialization to handling the callbacks behind /{agent_id}/add_desire and /{agent_id}/del_desire topics, periodically publishing the desire set to /{agent_id}/desire_set. The core of its job involves selecting the new plan to be executed (computed by PlanSys2’s Planner) in order to fulfill a desire and checking for desires’ satisfaction. It triggers, monitors and/or aborts the plan execution via the Plan Executor node. |
| Plan Director | Handles plan execution and abortion requests to be forwarded to PlanSys2’s Executor. Regularly notifies its progress status to other nodes, checks for context conditions to be satisfied and restores internal state if the plan is aborted. |
| Event Listener | Based on a set of statically defined rules, implements the belief revision function and option generation function of the agent reasoning loop |
| MA (Multi-Agent) Request Handler | Handles belief or desire addition/deletion requests forwarded by other agents, enforcing the specified policies to decide what can be accepted and what has to be rejected or (partially) redefined |
Agent-specific nodes (skills)
| Skill Node | Description |
|---|---|
| Sensor | Regularly performs a sensing operation which leads to request an addition, a deletion or an update within the belief set via the /{agent_id}/add_belief and /{agent_id}/del_belief topics. |
| Action Executor | Handles the execution advancement of an action. Triggered by PlanSys2’s Executor, communicate with it to notify about its progress, failure or success status. Requests toward other agents, calling the respective services of their Communication node, are performed within an agent’s action. API calls are provided. |