---
title: 'DAG-Plan: Dual-Arm Task Planning'
url: https://www.emergentmind.com/topics/dag-plan
type: topic
---

# DAG-Plan: Dual-Arm Task Planning

DAG-Plan is a structured task-planning framework for long-horizon dual-arm cooperative manipulation that replaces a linear large-language-model task sequence with a directed acyclic graph of typed sub-tasks, then executes that graph through online arm assignment conditioned on environment observations. It is designed for mobile dual-arm robots operating in kitchen-like settings, where temporal precedence, arm occupancy, and spatial interference make fixed sequential plans brittle and often inefficient. In DAG-Plan, the LLM generates a dependency graph, a validator checks graph completeness and connectedness, and a runtime planner selects feasible left-arm/right-arm action combinations using arm-state constraints and a geometric cost heuristic [2406.09953].

## 1. Problem setting and motivation

DAG-Plan addresses long-horizon dual-arm cooperative planning for kitchen-style manipulation tasks such as heating soup, cutting ingredients, moving objects across articulated containers, and coordinating tool use. The motivating claim is that dual-arm systems create richer dependency structure than single-arm systems: some sub-tasks must be serialized, others can be executed concurrently, and many feasible schedules depend on which arm is already occupied and where the targets are located. Existing methods that ask an LLM to emit a single linear task sequence, or that rely on predefined bimanual operations, do not represent that partial order explicitly and therefore tend to overcommit to one execution order and one arm assignment too early [2406.09953].

The framework is explicitly positioned against two deficiencies of linear dual-arm planning. First, a total order obscures which dependencies are mandatory and which are merely planner choices, so it often suppresses parallelism. Second, a fixed sequence with fixed arm-side decisions is not robust to the current state of the robot, including whether a hand is occupied, where objects lie relative to the two end-effectors, and whether a simultaneous pair of actions would cause crossing or excessive separation. DAG-Plan therefore treats task planning as construction of a dependency graph followed by online scheduling over that graph, rather than as direct sequence generation [2406.09953].

A common misconception is that DAG-Plan is only a graph-format variant of direct LLM planning. The paper’s method is more specific than that. The graph is not merely descriptive; it is used operationally to determine which nodes are executable, which arm should continue an occupy-release chain, and which left/right pair minimizes an execution cost under feasibility checks. This makes the graph a runtime control object rather than a static explanation artifact [2406.09953].

## 2. Graph representation and task semantics

The paper formalizes the task graph as
$$
G = (V, E, T, N),
$$
where \(V\) is the set of sub-task nodes, \(E\) is the set of directed dependency edges, \(T\) stores node types, and \(N\) stores the required number of arms for each node. Each edge
$$
e_{ij} = (v_i, v_j) \in E
$$
states that \(v_i\) must be completed before \(v_j\). The graph is terminated by a dedicated complete node, which becomes reachable only after all task requirements have been satisfied [2406.09953].

Each node is a concrete action-level sub-task such as grasping an object, placing it onto or into another object, opening a door, switching on an appliance, cutting with a knife, or pouring from a container. The `arm_num` field distinguishes one-arm and two-arm actions. If `arm_num = 1`, the task can be assigned dynamically to one arm at runtime. If `arm_num = 2`, the node is a genuinely bimanual action and is planned as one two-handed unit rather than as two independent one-arm nodes [2406.09953].

The node type system is central because it encodes arm-state transitions that a plain precedence DAG would miss.

| Node type | Semantics |
|---|---|
| `occupy` | Arm remains occupied after the action |
| `tool use` | Action uses a held tool and leaves the arm occupied |
| `release` | Action releases the held object after execution |
| `operate` | Manipulation leaves the gripper free afterward |
| `complete` | Terminal node indicating task completion |

These types support the paper’s notion of an occupy-release pair: an action chain that begins with an `occupy` node, may pass through one or more `tool use` nodes, and ends with a `release` node. This prevents invalid plans such as placing an object that has never been grasped, switching an arm to a second object while it is still committed to the first, or omitting the release step for a held tool. The validator checks the completeness of these pairs before execution [2406.09953].

A plausible implication is that DAG-Plan augments classical partial-order planning with a lightweight arm-resource semantics. The graph does not only say what depends on what; it also constrains when a hand may be considered available again.

## 3. LLM generation, validation, and graph maintenance

The planning input consists of a human instruction, object names, environment descriptions of objects and relations, and a fixed action API. The LLM is prompted to generate a structured DAG rather than free-form text. The prompt constrains the model to use available APIs, quote object names, keep the node set minimal, specify dependencies explicitly, assign each node a type and arm count, ensure every occupy node has a corresponding release node, and append a final complete node. The prompt also asks the model to encode not only immediate execution preconditions but also task-completion prerequisites; the paper’s example is that switching off a coffee machine should depend not only on switching it on, but also on putting the cup in, otherwise the goal state may not be achieved [2406.09953].

After generation, the graph is checked for two specific structural properties: whether it is a fully connected DAG and whether grasp-release or occupy-release pairs are complete. If the graph is invalid, DAG-Plan reflects to the LLM and requests regeneration. The paper reports such a case for task 8, where an initially incomplete DAG was repaired by reflection, improving the planning result for that task from 0.8 to 1.0 [2406.09953].

Execution uses two candidate sets. Common candidate nodes are available to a free arm. Priority candidate nodes are reserved for an already occupied arm that should continue along its current occupy-release chain. Initially, nodes with no incoming edges are common candidates. After a node is executed, the system removes that node and its incident edges, then updates the candidate sets according to node type. If the executed node is `operate` or `release`, the arm becomes free and newly unlocked successors enter the common set. If the executed node is `occupy` or `tool use`, the arm remains occupied and unlocked successors in that chain become priority candidates for that arm [2406.09953].

This execution policy is one of the framework’s distinctive features. The DAG is not preassigned to left and right arms at generation time. Instead, the graph is maintained online and queried repeatedly to determine which actions are both dependency-feasible and arm-state-feasible.

## 4. Online arm assignment and execution policy

Runtime assignment is dynamic. A free arm may choose from the common candidate set, whereas an occupied arm must prefer its priority candidates when such candidates exist. The planner enumerates feasible left-arm/right-arm combinations from these candidate sets and evaluates them under spatial and occupancy constraints. This makes arm assignment contingent on current robot state rather than fixed in the graph itself [2406.09953].

The paper describes three feasibility checks for candidate pairs. First, if a candidate contains an occupy node, the planner checks whether the resulting successor structure would keep the arm occupied in a way that harms efficiency. Second, it rejects simultaneous operations whose targets are beyond a distance threshold. Third, it rejects combinations in which the left-arm target lies to the right of the right-arm target, because that implies arm crossing and likely collision or awkward kinematics [2406.09953].

Among feasible pairs, DAG-Plan minimizes the cost
$$
J = dis(obj_{right}, obj_{left}) + 5 \left[ dis(obj_{right}, hand_{right}) + dis(obj_{left}, hand_{left}) \right].
$$
The selected pair is therefore biased toward geographically local assignments and toward simultaneous actions whose targets are near one another. The first term couples the two chosen targets; the second strongly biases each arm toward the object closest to its current hand position [2406.09953].

Low-level execution combines motion planning and learned manipulation skills. The paper states that the robot approaches target objects via RRT-connect and then executes the action with PPO-based reinforcement learning policies. For some high-precision two-arm actions, such as placing a pot into a sink, the method uses RL directly [2406.09953].

The paper’s examples show the intended runtime effect. In task 5, “heat the soup and put the tin on the table,” DAG-Plan opens the microwave door and refrigerator cooler door in parallel, grasps the bowl and tin in parallel, places the bowl into the microwave while putting the tin onto the table, then closes both doors in parallel before switching the microwave on and later off. In task 8, “cut the carrot and red bell pepper,” it first grasps both vegetables in parallel, places both onto the cutting board in parallel, then proceeds through the sequential knife-use chain. These examples illustrate that the graph preserves concurrency where it exists, while the node types preserve arm-state continuity where it is required [2406.09953].

## 5. Benchmark design and empirical results

The paper evaluates DAG-Plan on the Dual-Arm Kitchen Benchmark implemented in Sapien. The abstract describes evaluation on “5 sequential tasks with 44 sub-tasks,” whereas the detailed benchmark description reports “9 sequential tasks,” “78 sub-tasks,” “26 assets and objects,” and “3 scenarios.” The listed tasks include placing apple and bread onto a plate, toasting bread while placing an apple, juicing an apple while toasting bread, washing a cup and a bowl, heating soup while moving a tin, heating soup while pouring cola, placing apple and pear into a bowl, cutting a carrot and red bell pepper, and making a pot of soup. The robot platform is a mobile dual-arm Baxter-based system with two 7-DoF arms, two-finger grippers, and five RGB-D cameras [2406.09953].

The baselines are TP-S and TP-D. TP-S is direct LLM planning for a single-arm or one-stage-at-a-time formulation. TP-D is direct LLM generation of a dual-arm stage list in which a stage may use one arm or both arms. DAG-Plan differs by having the LLM produce a dependency graph and then running graph-based task inference online. Plan-test evaluation uses success rate, minimum stage count, and stage efficiency; physical simulation uses success rate, execution time, and execution efficiency [2406.09953].

In plan tests, TP-S reports success rate \(91.1\%\), stage count \(8.67 \pm 2.54\), and stage efficiency \(100.0\%\). TP-D reports success rate \(44.5\%\), stage count \(6.33 \pm 2.87\), and stage efficiency \(137.0\%\). DAG-Plan reports success rate \(97.8\%\), stage count \(5.67 \pm 2.35\), and stage efficiency \(152.9\%\). In physical simulation, TP-S reports success rate \(49.9\%\), time \(88.3 \pm 28.5\), and execution efficiency \(100.0\%\); TP-D reports success rate \(26.7\%\), time \(76.6 \pm 35.5\), and execution efficiency \(115.3\%\); DAG-Plan reports success rate \(55.6\%\), time \(60.1 \pm 24.5\), and execution efficiency \(147.0\%\) [2406.09953].

The task-level analysis in the detailed description is consistent with the framework’s stated purpose. TP-D can be concise when it succeeds, but it often fails because a direct stage list can be symbolically plausible while being geometrically infeasible. The paper’s example is task 6, where TP-D places “put cola bottle into refrigerator cooler” on the left arm and “close microwave door” on the right arm, even though the refrigerator lies to the right of the microwave and the resulting motion would cross the arms. DAG-Plan is designed precisely to reject such pairings at runtime [2406.09953].

## 6. Limitations, interpretation, and broader significance

The paper is explicit that DAG-Plan relies on reinforcement learning for the underlying manipulation skills and identifies this dependence as a limitation. Several further limitations are clear from the described system. The action vocabulary is fixed by a predefined API. The online scheduler is greedy and local, because it selects the lowest-cost feasible pair at each step rather than solving a global optimization over the whole DAG. The feasibility checks depend on thresholds that are described qualitatively but not formalized in the paper excerpt. The framework therefore offers structured adaptability rather than optimality guarantees [2406.09953].

Even with these constraints, DAG-Plan is best understood as a shift from “LLM as direct scheduler” to “LLM as dependency-graph generator.” That shift aligns it with a broader family of plan-first DAG systems. Plan*RAG externalizes multi-hop reasoning as a DAG of subqueries for retrieval-augmented generation [2410.20753]. A.DOT Planner compiles natural-language hybrid-data queries into a DAG of source-specific sub-queries with validation and topological execution [2603.14229]. OSDAG uses a dependency-annotated task graph plus online scheduling for heterogeneous multi-robot coordination [2606.15255]. OrchDAG studies plan DAGs for tool orchestration in multi-turn interactions [2510.24663]. This suggests that DAG-Plan is part of a wider methodological trend in which explicit DAGs replace monolithic sequences wherever concurrency, typed dependencies, or selective reuse matter.

Within that landscape, DAG-Plan’s distinctive contribution is its dual-arm specialization. The graph is typed by arm-state semantics, not only by precedence. Execution chooses arm assignments online rather than fixing them during graph generation. Spatial checks and a hand-target cost are integrated into node-pair selection. The result is a hybrid architecture in which high-level decomposition is language-driven, but concrete coordination emerges from graph-constrained runtime inference. For dual-arm manipulation, that is the paper’s central technical idea and its main encyclopedic significance [2406.09953].

Source: https://www.emergentmind.com/topics/dag-plan