APTree: Extended Behavior Trees for Adaptive and Scalable Automated Robotic Task Planning in Construction
Authors: Shermin Sherkat, Thomas Wortmann, Andreas Wortmann
Organizations: Institute for Computational Design and Construction, Department for Computing in Architecture (ICD/CA), University of Stuttgart, Keplerstraße 11, Stuttgart, 70174, Germany · Institute for Control Engineering of Machine Tools and Manufacturing Units (ISW), University of Stuttgart, Seidenstraße 36, Stuttgart, 70174, Germany
Task planning for robots in off-site construction prefabrication is primarily manual, leading to planning inefficiencies and reluctance to adopt robotic solutions. Existing approaches provide limited support for scalable, modular automated task planning and localized runtime replanning. This paper proposes APTree, a model-driven framework that integrates automated task planning with modular task execution using behavior trees as the execution model. APTree repeatedly applies and coordinates heterogeneous symbolic planners to automatically generate and compose modular task plans at runtime. To support this approach, we develop a domain-specific language for the formal specification and validation of task plans, together with a compatible execution engine. We evaluate APTree on the real-world livMatS Biomimetic Shell pavilion, where it models the construction robotic fabrication domain, detects injected specification and planning errors at design time and runtime, and automatically generates large-scale task plans by coordinating three symbolic planners across numerous planning modules. A machine-checked formal analysis further shows that composed execution and local replanning are safe under explicitly stated assumptions, including planner soundness and non-interference of generated plans, providing practitioners with explicit conditions for dependable plan composition. APTree thus enables construction practitioners to leverage automated task planning without requiring detailed knowledge of symbolic planning techniques or APTree's internal implementation.
Figures & tables
Figure 1: Overview of the APTree method discussed in the paper. The APTree method extends the existing BT metamodel with four packages, each marked by its corresponding section (S) number in the paper and the challenge it addresses (C).
Figure 2: Running example of a BT for picking and placing a plate and two beams. Sequence nodes are shown with an arrow icon and parallel nodes with two parallel lines. Decorators and services, when present, are attached to their associated node. Decorators can model node-specific preconditions evaluated before execution (e.g., Gripper Empty? ).
Figure 3: A MontiCore grammar production rule with annotated components.
Q
Evaluation Question
Metric
Metric Description
Q1–Q4
Detection or prevention of structural, syntactic, type, and logical errors
M1 ( TPR )
Ratio of injected errors correctly detected
M2 ( PR )
Ratio of errors prevented by design
Q5
Preservation of structure during local replanning
M3 ( Gtree )
Average structural change after replanning
Q6
Scalability of repeated local replanning
M4 (RF)
Number of replanning events per minute
M5 ( NRR )
Ratio of nodes retained in the BT to generated nodes
Q7
Composition of plans from multiple symbolic planners
M6
Number of distinct symbolic planners applied
Table 1: Summary of research questions and corresponding metrics.
Figure 4: BT metamodel used and extended in this paper for the proposed DSL, highlighting nodes, decorators, services, and their relations.
Figure 5: Behavior model defining the runtime semantics of the BT metamodel. Gray boxes correspond to metamodel classes. lbb abbreviates linkedBlackboard to reduce diagram clutter.
Figure 7
Figure 6: DomainTypesDef metamodel highlighting concepts for defining new property, predicate, and action types. The DomainTypesCon metamodel extends DomainTypesDef and is automatically generated from user-defined DomainTypesDef models. BasicType includes types such as String, Boolean, Integer, etc.
Figure 9
Figure 7: Behavior model extending the metamodels defined in this section to describe runtime behavior. It highlights concepts such as blackboard registration. Green boxes correspond to the DomainTypesDef or DomainTypesCon metamodel elements and gray boxes to the BehaviorTree metamodel elements. Custom types other than Element and Agent have similar blackboard relations but are omitted for clarity.
Figure 8: Planning service metamodel defining automated planning as a BT service, highlighting concepts such as planning services, planners, and PDDL-based planners.
Figure 9: Behavior model extending the planning service metamodel, highlighting components such as the RESTPlanningCommunicator , which sends planning requests and receives planning results. Classes highlighted in orange correspond to the same classes in the PlanningService metamodel.
Figure 10: Dynamic flow node metamodel defining flexible and configurable flow nodes, highlighting core concepts such as node graphs, success criteria, and temporal types.
Figure 11: Behavior model extending the DynamicFlowNode metamodel, highlighting operations such as getExecutableNodes and canExecute that determine executable graph nodes. Blue classes correspond to the metamodel (Figure 10 ).
Figure 12: Robotic prefabrication setup for the livMatS Biomimetic Shell project [ 41 ] . Shown are the main types and instances: raw element storage (FirstPos, fpn) , rail positions (PositionOnRail, prn) , assembled cassette storage (StackPosition, sp1) , industrial robot (Robot, r1) , and equipment positions (EquipPosition, epn) . Each cassette comprises a low plate (lpn) , a top plate (tpn) , and six beams (bn) , where n denotes the instance number.
Table 2: Action node types representing tasks defined in each planner domain.
Figure 13: Activity diagram illustrating the process from input provision to node generation and planning modes.
ID
Error Type
Error Description
APTree
PlanSys2
BT.CPP
Symbolic Planner
1
Structural
Mismatch of planning model artifacts (e.g., planner and its configuration)
DT
NA
PT
2
Missing planning model artifact (e.g., lacking problem or domain)
DT
NA
PT
3
Mismatch of planner and planning models (e.g., unsupported language)
DT
NA
PT
4
Execution model involves invalid component hierarchy
DT
PD
NA
5
Execution model inconsistent with the symbolic plan
PD
PD
NA
Table 3: Comparison of error detection and prevention between APTree and PlanSys2. DT = detected at design-time, PT = detected at planning time, RT = detected at runtime, RTC = detection at runtime leads to crash, SF = silent failure, NA = not applicable, PD = prevented by design
Figure 14: BT Node Change ( gn ,left) and BT Width Change ( gw ,right) across 1,098 replanning events. Each dot represents a single replan; the dashed red line indicates the average (0.80% and 0.38%, respectively).
With Replanning _ 13 min 29 sec
Without Replanning _ 5 min 6 sec
Category
Final
Before Ticking
After Ticking
Final
Before Ticking
After Ticking
Action Instances (ML & HL)
1,149
0
6,507
1,149
0
1,149
Action Instances (HL)
372
0
372
372
0
372
Replanning triggered
1,098
0
1,098
0
0
0
PDDL Problem files
384
12
1,470
384
12
372
FlowNode Instances
388
16
372
388
16
372
Table 4: Comparison of BT structure metrics between execution with dynamic replanning (1,098 replans over 13 min 29 s) and without replanning (5 min 6 s), showing node counts at final state, before ticking, and after ticking.
PlannerType
Call Count
Success Rate
Average Planner Time (ms)
Average Service Time (ms)
Average Plan Size
Cumulative Planner Time (s)
Cumulative Service Time (s)
ENHSP
12
100.00%
1364.30
1556.77
31
16.37
18.68
Metric-FF
735
100.00%
270.10
349.96
3.9
198.52
257.22
LAMA-First
735
100.00%
3082.30
3145.78
4.5
2265.49
2312.15
TOTAL
1482
100.00%
1673.67
1746.32
4.4
2480.38
2588.05
Table 5: Average planning time, planning service time (including parsing and action instance generation), and average plan size by planner type. The TOTAL row reports call-weighted averages. These values were obtained using the active replanning configuration.
Figure 15: Per-call planning service latency for Metric-FF only (left) and LAMA-First + Metric-FF (right) as ML planners, ENHSP as HL planner, with replanning. Per-call latency remains stable across all invocations, with no degradation from repeated calls.
Figure 16: Comparison of APTree and PlanSys2 on progressively larger subsets of the livMatS case study. The values above the planning-to-execution transitions indicate the BT generation overhead. The values inside ribbons are the number of actions per planning instance.
Manual Plan (JSON, Excerpt)
Generated Plan (APTree, Excerpt)
"names": "Move", "actors": "Robot"
TravelML_r1_pr2_ep1
"names": "Take Tool", "tools": "VG1"
EquipeML_r1_vg1_ep1
"names": "Initiate Tool"
InitializeML_r1_vg1
Table 6: Comparison and mapping between the manual expert plan (JSON) and the automatically generated task plan from APTree logs.
Figure 17: Execution sensitivity under the two branch-selection policies. (a) Time between consecutive ML actions, with (blue) and without (orange) replanning. (b) Cumulative net action nodes over execution time; upward steps are generated nodes, downward steps are nodes removed during plan replacement (replanning only).
Department of Construction Science, Texas A&M University, College Station, TX 77843, USA · Amazon Robotics, North Reading, MA 01864, USA · Department of Civil and Environmental Engineering, University of Michigan, MI 48109, USA +1