Key takeaways
- TAMP searches for a discrete task sequence and continuous robot motions as one coupled problem.
- A command such as ‘pick up the cup’ needs a feasible grasp, placement, joint configuration and path.
- When motion planning finds a collision or unreachable pose, the task planner must revise an earlier choice.
- Frameworks such as MoveIt Task Constructor organize a job into stages connected to IK, collision checks and planners.
- Real deployments still need perception and replanning for pose error, slipping, deformable objects and execution failure.
TAMP joins two kinds of planning
Task and motion planning, usually shortened to TAMP, asks a robot to decide both what actions to perform and how to realize them in physical space. Task planning handles discrete changes such as move, grasp, carry and place. Motion planning handles continuous values such as joint angles, grasp poses, placement coordinates and collision-free trajectories. TAMP treats these as a coupled search rather than two unrelated programs.
The coupling matters because a logically correct sequence can be physically impossible. A plan may say ‘grasp the cup, then place it on the tray,’ yet the arm might not reach the selected grasp. The wrist could hit a shelf, or no path may exist while the robot carries the cup. Conversely, a motion planner cannot search efficiently until the system chooses which object, hand, grasp and destination are relevant.
A correct action sequence can still be impossible
Consider a hypothetical kitchen scene. A robot must put a blue cup on a tray at the right side of a counter. A task planner can propose the skeleton ‘move to cup, grasp, carry, place.’ If a kettle blocks the approach to the tray, the final placement fails collision checking. A fixed action sequencer stops. A TAMP system can instead search for a different skeleton that first moves the kettle to a temporary location.
A skeleton specifies action types and their order but leaves geometric details open. The planner then samples candidate wrist poses for the cup, approach directions, temporary kettle placements and robot configurations. Inverse kinematics checks whether a hand pose has a valid joint solution. Collision checking rejects overlapping robot, object and furniture geometry. A motion planner attempts to connect valid start and goal configurations with a trajectory.
Grasp, placement and path choices must agree
Those candidates cannot be selected independently. A top grasp may be easy at the first step but impossible to carry under a shelf. A temporary kettle placement may clear the tray while blocking the arm’s exit path. TAMP therefore propagates constraints between stages: a grasp chosen now must support the later carry and placement, and an earlier placement must preserve room for all later motions.
Backtracking is central. Suppose the first grasp candidate passes inverse kinematics but every transport path collides. The planner can keep the same task skeleton and try another grasp. If all grasps fail, it may change the approach or placement. If that still fails, it can return to the task level and insert the action that moves the kettle. A geometric failure becomes evidence that an earlier symbolic decision must change.
Geometry can force the planner to backtrack
The weakness is combinatorial growth. More objects, grasp candidates and temporary locations create many combinations, and running a full motion planner for each one can be expensive. Practical systems use fast reachability filters before detailed planning, change the sampling order, cache useful results or expand low-cost partial plans first. TAMP is less a single formula than an architecture for coordinating search, sampling and validation.
MoveIt Task Constructor illustrates that architecture with stages. A serial container can hold steps such as current state, open hand, connect to an object, carry and place. Generator stages create grasp or placement candidates; propagating stages extend a state forward or backward; connector stages bridge separate subplans. Each stage can use a MoveIt pipeline planner, joint interpolation or a Cartesian path solver according to the motion it needs.
How a practical system organizes the stages
The framework does not define the task automatically. Developers still provide collision geometry, allowed contacts, grasp frames, support surfaces, goal conditions, costs and failure rules. A cup model with the wrong diameter or a pose estimate shifted by two centimeters can produce a computationally valid plan that misses the real handle. Planning quality cannot exceed the quality of the model and perception feeding it.
Classical TAMP discussions commonly assume deterministic actions, a fully known world, known rigid-body shapes and an explicit final goal. Real cloth folds, liquids slosh, friction varies and pose estimates carry uncertainty. A grasp can slip after the planner marks it complete, or a person can place a new obstacle in the path. Deployment therefore needs a closed loop that senses the state again, verifies outcomes and interrupts or replans when the world changes.
Real uncertainty begins outside the plan
Learned models can help rank grasps, predict affordances or suggest promising action sequences, reducing the amount of search. A language model could propose the high-level idea of moving the kettle first. But a separate geometric system still has to verify joint limits, collisions, stability and execution. A learned proposal mechanism can guide TAMP; it does not replace physical feasibility checks or safety monitoring.
A product evaluation should focus on failure conditions rather than one successful demonstration. Ask how much pose error the system tolerates, how long it takes to recover after all grasp samples fail, and what happens if a person or object moves during planning. Measure not only average planning time but tail latency, missed collisions, post-action state verification, safe stopping and the manual recovery path.
A product test needs failure conditions, not one successful clip
TAMP is therefore more than a way to make robots understand long instructions. Its core role is to turn a logically plausible sequence into physically executable behavior and to feed physical failure back into logical planning. In warehouse picking, assembly and service robotics, where object choices and spatial constraints are inseparable, that bridge often determines whether a polished demonstration becomes repeatable automation.
A practical pilot should begin with one repeated task whose objects, obstacles and allowed contacts are explicitly modeled. Planning failures and execution failures should be logged separately, while grasp-sample count, replanning latency and completion rate are measured together. Clearly stating where the plan is valid—and when an operator must intervene—is more useful than making a broad promise of general autonomy.
Sources reviewed
- Annual Review of Control, Robotics, and Autonomous Systems: Task and Motion Planning (2021)
- arXiv HTML: Task and Motion Planning survey
- MoveIt Task Constructor concepts
- MoveIt Task Constructor pick-and-place tutorial
- Open Motion Planning Library documentation
Sources reviewed on September 22, 2026.
Related reading
Sean Woo — I have spent more than 15 years shaping robotics technology and business direction. Drawing on public technical documents, research papers and company announcements, I explain changes in robotics and AI in accessible terms. The interpretations in this publication do not represent the official position of any company or organization.