PaperlayerView exact revision on arXiv

Source-linked AI summary

MATE-BT: A Behavior-Tree-Based Framework for Hierarchically Decentralized Mission Autonomy in Heterogeneous Multi-Robot Teams

Sunbeen Lee, Hoseon Gi, Jik Hur, Inmo Jang

arXiv:2610.35429v1cs.RO

TL;DR

Multi-robot teams need to sustain predefined missions through runtime changes and robot failures. MATE-BT combines transferable onboard mission management with decentralized target assignment and robot-local behavior-tree execution. Simulations and physical experiments report mission continuity, onboard execution, and responsive updates without regenerating the full plan.

Abstract

from arXiv · show

Multi-robot teams executing predefined missions must adapt to runtime changes and sustain mission management despite robot failures. This paper proposes MATE-BT (Mission, Allocation, and Task Execution with Behavior Trees), a hierarchically decentralized framework that separates mission execution, allocation, and task execution. An active onboard leader manages mission progression and team-level task assignment, with authority transferable to another leader-capable robot after failure. Interchangeable decentralized methods resolve target assignments, while each robot adapts its local behavior through planning and acting with behavior trees. Webots simulations and real-robot experiments demonstrate mission continuity despite new targets and robot failures, including active-leader failure. In the physical experiments, all MATE-BT computation runs onboard. Hardware-in-the-loop resource measurements further support onboard execution on Jetson Orin Nano and Raspberry Pi 5. By updating only the affected layers without full-plan regeneration, MATE-BT maintained a response time of approximately 130 ms with 30 robots and 120 targets. Comparisons of four target-assignment plugins reveal scenario-dependent trade-offs between mission completion time and total travel distance.

I. INTRODUCTION

Heterogeneous teams must sustain predefined missions through environmental changes, platform failures, and communication disruption, motivating decentralized onboard autonomy. MATE-BT connects behavior-tree execution and decentralized allocation while separating responses by functional layer.

I. INTRODUCTION

  • Heterogeneous teams must sustain predefined missions despite environmental changes, platform failures, and disrupted communication with external mission management, motivating onboard decentralized autonomy.In crewed–uncrewed operations, onboard automation may support mission management while uncrewed robots execute delegated tasks.Source: §I · p. 1
  • Runtime disturbances may require local behavior changes, reassignment of unfinished work, or continued mission management after a robot failure.These examples motivate addressing a disturbance at the functional layer it affects.Source: §I · p. 1

A. Related Work

  • Prior work addresses robot-local adaptation with PA-BT, decentralized multi-robot task allocation –, and hierarchical BT organization.The paper frames its contribution as connecting these mechanisms.Source: §I · p. 1

I. INTRODUCTION

  • MATE-BT assigns mission progression and team-level task assignment to an active onboard leader, while target assignment and task execution are decentralized; another leader-capable robot takes over after failure.This hierarchical decentralization connects mission management with robot-local adaptation.Source: §I · p. 1

A. Related Work

  • The related-work discussion groups BT architectures by whether robots execute dispatched actions, manage local tasks under central coordination, or participate in decentralized coordination.It highlights BTs’ reactive behavior, modular composition, and subtree reuse,.Source: A. Related Work · p. 1

1) Action execution from symbolic plans:

Existing BT-based architectures distribute different parts of execution and coordination, but the reviewed work leaves gaps in decentralized mission management and physical demonstrations of continuity after robot or manager failure.

1) Action execution from symbolic plans:

  • Monolithic symbolic-plan architectures dispatch actions to robots and require plan-level updating and regeneration when a change invalidates the plan.PlanSys2 compiles PDDL plans into BTs, while selects local replanning, robot reallocation, or full replanning according to failure impact.Source: 1) Action execution from symbolic plans · p. 1

2) Robot-local task execution:

  • Robot-local task-execution architectures delegate complete tasks, but mission progression and allocation authority remain central while robots adapt only within assigned tasks.Related single-robot FSM/BT systems manage phases or modes without decentralized coordination among independent robots,.Source: 2) Robot-local task execution · p. 2

3) Distributed coordination among robots:

  • Distributed coordination architectures let robots participate in allocation or delegation, but prior examples retain central mission management or do not specify how it continues after its executing component fails.An earlier replicated BT architecture also leaves conflict reconciliation under differing local information unspecified and evaluates fault tolerance analytically.Source: 3) Distributed coordination among robots · p. 2
  • The reviewed coordination studies report analysis or simulation, but no physical multi-robot demonstration integrating onboard mission management, decentralized allocation, and robot-local execution while testing continuity after task-robot or active-manager failure.The authors state this is the case to their knowledge.Source: 3) Distributed coordination among robots · p. 2

1) Layered execution with hierarchical decentralization:

MATE-BT separates mission progression, allocation, and robot-local execution, with hierarchical authority and decentralized target assignment. Its stated scope assumes a predefined mission policy and normal-operation communication, while its evaluation covers responsiveness and mission continuity.

1) Layered execution with hierarchical decentralization:

  • Mission management and team-level task assignment are replicated across leader-capable robots, while decentralized MRTA resolves target assignments and PA-BT adapts each robot’s local behavior.This separates the decision layers so disturbances can be handled at the layer they affect.Source: 1) Layered execution with hierarchical… · p. 2

2) Interchangeable decentralized target assignment:

  • The common plugin interface allows established decentralized MRTA methods – to be interchanged without changing mission-management or task-execution structure.Controlled comparisons show scenario-dependent performance, with no method consistently preferred across tested scenarios.Source: 2) Interchangeable decentralized… · p. 2

3) System-level evaluation of responsiveness and mission continuity:

  • MATE-BT handles newly added targets and limits response-time growth as mission scale increases by updating affected assignments rather than regenerating the full mission plan.Webots simulations and four-robot physical experiments demonstrate continuity after a task-executing robot or active leader fails; physical computation runs onboard, with central infrastructure supplying communication and detected-target information.Source: 3) System-level evaluation of… · p. 2

A. Problem Setting

  • The mission policy is a predefined, abstract sequence of phases specifying tasks and completion conditions, and is assumed to remain valid throughout execution.The example mission proceeds through Rescue, Suppress, and Return phases.Source: A. Problem Setting · p. 2
  • A task is a type of work and a target is the object or location it applies to; target-directed execution begins after both are assigned.A robot executes at most one task at a time, while a task request may be assigned to multiple robots and may cap their number.Source: A. Problem Setting · p. 2
  • Normal operation assumes a connected, not necessarily fully connected, inter-robot network, with multi-hop delivery possible and delays that may temporarily diverge local information.Source: A. Problem Setting · p. 2

B. Overall Architecture

The architecture splits mission management and robot-local execution across two onboard behavior trees, with allocation spanning both; ROS interfaces connect robots and blackboards share information within each robot.

B. Overall Architecture

  • The Swarm BT manages mission progression, the Agent BT manages robot-local task execution, and allocation spans both: task assignment occurs in the Swarm BT and target assignment in the Agent BT.Robot-specific action primitives execute tasks.Source: B. Overall Architecture · p. 3
  • Every robot runs an Agent BT onboard, while leader-capable robots also run identical Swarm BT instances and only the active leader ticks the mission-management subtree.This replication allows another leader-capable robot to take over mission management.Source: B. Overall Architecture · p. 3
  • Separate ROS 2 nodes run the Swarm BT and Agent BT asynchronously, with local blackboards and ROS-aware leaves connecting conditions and action primitives to ROS interfaces.Robots exchange task requests, execution feedback, and MRTA messages over ROS topics.Source: B. Overall Architecture · p. 3
  • Alive signals carry robot ID, type, and leader priority; each BT maintains its own local team-membership view and excludes a robot after a configured timeout without its signal.The Swarm BT uses this view for mission management and the Agent BT for target assignment.Source: B. Overall Architecture · p. 3

C. Mission Execution

The Mission BT advances mission phases using completion conditions based on current world information. An onboard leader manages progression and task assignment, with authority transferable after failure.

1) Mission Policy Encoding and Progression:

  • Each mission phase checks its completion condition or task-request statuses, then the sequence advances to the next phase.Completion conditions are reevaluated from world information when the phase is ticked.Source: 1) Mission Policy Encoding and… · pp. 3–4

2) Mission-Management Authority and Handover:

  • Leader-capable robots are ranked by priority and robot ID; after a timeout, the next-ranked candidate takes over and reevaluates the mission from current information.A new leader or an expanded membership view resets the Mission BT to its first phase; partitioned groups converge after reconnecting and exchanging alive signals.Source: 2) Mission-Management Authority and… · p. 4

1) Task Assignment:

  • ScopeOf reserves scoped tasks for their designated robot type while available; otherwise, AssignTask allocates unscoped tasks subject to per-robot and per-task limits.BroadcastTask publishes requests each tick, and each robot stores its assigned task and parameters locally.Source: 1) Task Assignment · p. 4

2) Target Assignment:

MATE-BT separates target selection from local task execution: interchangeable decentralized plugins select targets, while behavior-tree backchaining builds actions for each robot's current assignment.

2) Target Assignment:

  • A standardized two-phase plugin interface supports decentralized target assignment through local decisions and inter-robot conflict resolution.At each tick, AssignTarget provides available targets, robot state, and received messages to the configured plugin, then stores the selected target locally.Source: 2) Target Assignment · p. 4

E. Task Execution

  • The Agent BT maps each task request and target to a desired postcondition, then uses PA-BT backchaining over a PPA library to add actions and unmet preconditions.Task completion is determined by observing the postcondition, and the resulting status is reported as feedback.Source: E. Task Execution · p. 4
  • Application-specific components include the mission policy, assignment models or plugins, a PPA library, and robot-specific actions with ROS interfaces.Source: E. Task Execution · p. 4

III. EXPERIMENTS AND RESULTS

The evaluation combines Webots simulations and physical LIMO experiments, testing mission execution with new targets and robot failures under a specified team and runtime configuration.

III. EXPERIMENTS AND RESULTS

  • The physical team used four LIMO platforms: one Rescue UGV and three Fire UGVs; all UGVs could lead, and UAVs appeared only in simulation.The Rescue UGV carried up to two victims, while each Fire UGV carried one; Table I identifies the heterogeneous team configuration.Source: §III · p. 4, Table I · p. 5
  • The breakdown scenario introduced two failures during Rescue: Fire UGV 1 failed first, followed by the active leader, Rescue UGV 1, after it delivered its victims to base.Source: §III · pp. 4–5
  • The BTs ticked at 10 Hz, alive signals ran at 5 Hz with a 2.5 s timeout, and the mission tests used CBAA for target assignment.Fig. 2 depicts the normal and breakdown sequences and timelines; its markers distinguish task bars, phase transitions, robot failures, and unavailability.Source: §III · p. 5, Figure 2 · p. 5

A. Simulation and Hardware-in-the-Loop Tests

Across the reported tests, MATE-BT sustained mission execution through robot and leader failures without operator intervention. Repeated runs measured handover and reassignment responses, while hardware-in-the-loop measurements assessed onboard resource use.

A. Simulation and Hardware-in-the-Loop Tests

  • The team completed both scenarios without operator intervention, including after a task-executing robot and the active leader failed.After leader failure, the next-ranked robot took over, regenerated current-phase requests, and surviving robots continued unaffected assignments.Source: A. Simulation and Hardware-in-the-Loop… · p. 5
  • Mean handover latency from leader failure until successor identification was 2.44 s in Breakdown 1 and 2.46 s in Breakdown 2, slightly below τ = 2.5 s because the timeout began at the last alive signal.Breakdown 1 recorded four within-phase task reassignments; Breakdown 2 recorded only the escort reassignment.Source: A. Simulation and Hardware-in-the-Loop… · p. 5
  • Both breakdown scenarios had longer mission durations and more target reassignments than normal; normalized mean reassignment rates were approximately 14–15 per minute across scenarios.The similar rates suggest higher totals partly reflected longer execution.Source: A. Simulation and Hardware-in-the-Loop… · p. 6
  • CPU utilization rose by 19.9 to 22.5 percentage points on Raspberry Pi 5 and 14.3 to 15.3 points on Jetson Orin Nano; RAM rose by 1.5 to 2.1 and 0.9 to 2.0 points, respectively.Hardware-in-the-loop runs support onboard execution of both trees on the tested platforms.Source: A. Simulation and Hardware-in-the-Loop… · p. 6

B. Real-Robot Tests

The real-robot team completed both scenarios, including leader handover and task reassignment after a breakdown. The section also describes the resource and timing measurements used to assess onboard execution and scalability.

B. Real-Robot Tests

  • Both indoor real-robot scenarios were completed autonomously, and the breakdown test reproduced leader handover and task reassignment from simulation.Source: B. Real-Robot Tests · p. 6
  • Enabling MATE-BT increased system CPU utilization by approximately 13 percentage points and RAM utilization by approximately 2, with resource use stable during mission execution.The increase differed little between the active leader and a non-leading leader-capable robot.Source: B. Real-Robot Tests · p. 6

C. Reactivity and Scalability Test

  • The reactivity and scalability comparison used a monolithic planning baseline, a common 100 ms tick period, and stationary robots.MATE-BT target assignment was run centrally with the Hungarian algorithm for this comparison only.Source: C. Reactivity and Scalability Test · pp. 6–7
  • Response time was measured from target detection or a scheduled trigger until dispatch of an updated action goal; supplementary measures were assignment and replanning time.Task BT expansion counted toward full response time but not target-assignment computation time.Source: C. Reactivity and Scalability Test · p. 7

1) Reactivity Test:

MATE-BT maintained near-tick-period response as fires or team scale increased, while the monolithic baseline slowed at larger scales. A separate allocation evaluation compared plugins across mission cases.

1) Reactivity Test:

  • As active fires increased from 10 to 100, MATE-BT full response time stayed near 100 ms, while baseline response reached approximately 370 ms at 100 fires.Baseline replanning time increased with fire count and exceeded the tick period around 60 fires; MATE-BT retained the Mission BT while updating targets and assignments.Source: 1) Reactivity Test · p. 7
  • With 30 robots and 120 fire targets, MATE-BT response time reached approximately 130 ms, compared with approximately 2,800 ms for the baseline.The baseline was comparable up to 10 robots; MATE-BT remained near the tick period as team size increased.Source: 1) Reactivity Test · p. 7

D. Allocation Strategy Evaluation

  • The allocation evaluation compared CBAA, distributed Hungarian, CBBA, and GRAPE without changing the Mission BT or Agent BT.Cases included spread and clustered fires, sequential batches, and large fires requiring cooperation.Source: D. Allocation Strategy Evaluation · p. 7

2) Scalability Test:

Across allocation cases, no target-assignment plugin performed best on both mission completion time and total travel distance. The conclusion reports near-tick-period response at up to 30 robots and 120 targets, while noting that new missions require manual specification.

2) Scalability Test:

  • The four allocation cases covered spread fires, clustered fires, sequential batches, and large fires requiring cooperation.Each plugin was evaluated over 15 episodes per case using completion time and total travel distance.Source: Figure 6 · p. 7, 2) Scalability Test · p. 7
  • CBBA, distributed Hungarian, and GRAPE achieved the lowest mean completion times in Cases 2, 3, and 4, respectively; CBBA had the shortest mean travel distances in Cases 1–3.GRAPE had the largest mean travel distance in every case, and no plugin performed best across all cases and both metrics.Source: 2) Scalability Test · p. 7, Table IV · p. 7

IV. CONCLUSION

  • MATE-BT maintained response times near the tick period with up to 30 robots and 120 targets, compared with a monolithic baseline that regenerates its full plan.Source: §IV · p. 8
  • Applying MATE-BT to a new mission currently requires manually specifying the Mission BT and the PPA library.Source: §IV · p. 8

Related papers

Loading 2610.35429v1…