What Is Robot Planning? From Goals to Feasible Motion

From a Goal to a Plan

Suppose a robot is asked to pick up a part and place it in a tray, but another object blocks the approach. The desired end state is clear; the actions that could achieve it are not. The robot might first need to move the blocking object, choose another grasp, or approach from a different side. “Put the part in the tray” names a goal, not a complete sequence of physically possible actions.

Moving the obstacle creates an ordering question: what must be true before each action can begin? The robot needs a place to set the obstacle, a grasp it can use, and a way to reach both objects. A plausible action sequence is only one part of the answer. Each proposed action also has to be checked against the geometry and constraints of the scene.

Robot planning turns a desired outcome into candidate actions or motions under stated constraints. It can help decide what to do next and how the robot might move, but its answer is conditional on the state and models used to produce it. Within a broader Physical AI system, sensing, control, and physical interaction still matter after a plan has been found. A feasible plan is not proof that the real task will succeed.

What Is Robot Planning?

A planning problem needs a representation of where the system starts, what counts as a goal, which actions or motions are available, and which states or transitions are disallowed. For a tabletop robot, those constraints may include occupied space, joint limits, and the required pose of an object. A different robot or task may require a different representation. The common question is whether some candidate sequence can connect the starting situation to an acceptable goal.

Finding a feasible solution is different from finding a preferred one. A path may avoid every modeled obstacle yet be unnecessarily long; an alternative may be shorter but require a less desirable grasp or more demanding motion. Optimization compares candidates according to a specified cost, such as path length or smoothness. It does not make a solution universally “best,” and neither feasibility nor a low modeled cost guarantees success during execution.

“Robot planning” therefore covers related problems rather than one algorithm or software box. A system may reason over named actions, search for collision-free configurations, optimize a motion, or combine these operations. Some approaches incorporate feedback or dynamics within planning; others connect a planner to separate components. The useful distinction is the question being solved and the constraints represented, not whether every robot follows a fixed stack.

Task Planning, Motion Planning, and TAMP

Task planning works at the level of actions and their prerequisites. In the blocked-object example, it may consider “move the obstacle” before “grasp the target,” while checking that the robot has somewhere to put the obstacle. Such a sequence explains the order of intended changes to the scene. It says little, by itself, about the continuous motions needed to perform them.

Motion planning asks whether the robot can move between relevant configurations while satisfying the constraints included in the problem. A command such as “grasp the target” leaves open the arm pose, the route around nearby objects, and whether the proposed grasp can be reached at all. The planner must address those physical possibilities, not merely confirm that the action name appears in a sensible order.

Task planning can order actions and their prerequisites, but each chosen action still needs a feasible motion through the scene.

1. 01Clear access
2. 02Grasp part
3. 03Place in tray

Task and motion planning, often abbreviated TAMP, treats these choices as connected. A proposed action can fail because there is no feasible motion for it; a different grasp or object placement can make another action sequence possible. Methods differ in how they search across discrete choices and continuous geometry. TAMP is not a rule that every robot must complete task planning first and motion planning second.

This coupling is especially clear in robot manipulation tasks. “Place the part behind the fixture” may be a reasonable action at the task level, yet a particular arm, grasp, or object arrangement may leave no admissible approach. The planner may have to reconsider the grasp, placement, or order of actions. Logical plausibility does not remove the need for geometric checks.

Configuration Space and Collision Constraints

Positions and poses of the robot and objects can be described in physical Cartesian space. A robot’s reachable workspace, when that term is used for its end effector, is the set of positions or poses the end effector can attain. Configuration space is different: each point represents a complete robot configuration—for example, a set of joint positions. Two configurations can place the end effector at the same location while putting the elbow in different places. A gap that looks open in a scene may be unusable for one configuration and usable for another.

Collision checking must consider more than the tool tip. As the arm moves, its links can strike the fixture, the carried object can hit the environment, and parts of the robot can collide with one another. What counts as a collision-free configuration depends on the robot and scene model supplied to the checker. A sketch showing a clear line for the gripper cannot establish that the whole robot has a clear route.

Imagine that the gripper can reach a desired pose on the far side of a fixture, but a direct motion from its current pose would sweep the forearm through the fixture. The planner must look for a connection through allowable configurations, possibly going around it, while respecting the modeled joint and collision constraints. Both the start and the goal must be appropriate for the problem; their individual acceptability alone does not establish an acceptable path between them.

A target may be reachable by more than one arm configuration. Link collisions and joint limits determine which configurations—and which connecting paths—are acceptable.

1. 01Cartesian sceneLeft: two-link planar arm and physical obstacle.
2. 02Whole-arm configurationTwo elbow poses reach one target; the dashed pose intersects the obstacle.
3. 03Configuration space q=(θ₁, θ₂)Right: each point represents both joint angles.
4. 04Excluded configurationsGray region: sampled link–obstacle collisions.
5. 05Colliding candidateDark dashed connection crosses the gray region.
6. 06Checked alternativeSolid orange connection was sampled for collisions.

Collision checking is numerical and subject to the model assumptions and sampling resolution.

Inverse kinematics answers a narrower question: which joint configuration could put the end effector at a requested pose? One IK solution may put an elbow into an obstacle, violate a joint limit, or be disconnected from the robot’s current configuration by the permitted motions. Even a valid goal configuration does not supply the intervening path. IK can help specify a candidate destination; it is not, on its own, a motion plan.

How Motion Planners Search and Optimize

One way to understand motion planning is as a search for connections among candidate states. A planner tests whether nearby configurations can be linked without violating the constraints it represents, then uses the resulting connections to look for a route from start to goal. This graph-like picture is an intuition, not a requirement that every method first build and store the same kind of graph.

Two influential sampling-based ideas construct different search structures. A probabilistic roadmap, or PRM, samples collision-free configurations, connects suitable neighbors into a roadmap during construction, and then connects a query’s start and goal to that roadmap to search for a route. The original rapidly-exploring random tree, or RRT, instead begins at a start and incrementally extends a tree toward sampled regions. These are the original intuitions, not descriptions of every later variant. Neither name alone promises a fast answer, a globally shortest route, or success on every query.

Optimization-based methods instead work on a candidate motion and an objective or constraints. The original CHOMP paper describes gradient-based improvement of a path or trajectory while accounting for qualities such as smoothness and obstacle avoidance. The 2014 TrajOpt paper formulates motion planning through sequential convex optimization and convex collision checking. They are distinct methods, and results reported for their test problems should not be turned into a general ranking against sampling-based planning.

Method choice depends on the problem formulation: the robot’s configuration space, constraints, available model, and the type of answer required. Even within a family, algorithms and implementations have different assumptions and guarantees. “Sampling-based” does not mean randomly guessing until success, while “optimization-based” does not mean guaranteed global optimality. A responsible comparison specifies the particular planner and conditions rather than declaring one family universally faster or better.

From Paths to Timed Trajectories

A geometric path describes a route through configurations without necessarily saying when the robot reaches each point. The arm’s candidate route around the fixture from the earlier example illustrates the gap: the route alone does not say how quickly the arm should accelerate, slow down, or stop. A time-parameterized trajectory adds that timing. This distinction is useful even though some planning methods generate timed trajectories directly rather than producing a separate path first.

Timing can be assigned with reference to specified joint velocity and acceleration limits. The resulting trajectory gives the controller a more concrete motion target than an un-timed route. Those limits are part of the configured planning problem, however; they are not a complete description of every motor, load, contact, and environmental condition the physical robot will encounter.

A geometric path says which configurations to pass through; a time law says when. A trajectory checked against modeled speed and acceleration limits still does not guarantee physical execution.

1. 01Geometric path q(s)Left: configurations without assigned times.
2. 02Time law s(t)Upper right: monotone progress over time.
3. 03Joint trajectory q(t)Lower right: solid ink and dashed orange curves represent the two joints.
4. 04Modeled limitsJoint speed and acceleration are checked for this example.

Time parameterization does not, by itself, prove full dynamical or execution feasibility. Further checks may be needed for forces, contact, changing obstacles, and the actual robot. Some post-processing implementations can also alter waypoints or the geometric route within a tolerance, so collision validity may need to be checked again. That is an implementation-dependent caution, not a claim that every timing method changes the path.

Even a checked, timed trajectory is still a desired motion, not the observed one. The robot must respond to tracking error, disturbances, and physical contact as the task unfolds. That is the natural handoff to robot control: planning supplies a candidate to execute, while feedback helps the machine deal with what actually happens. The two functions can be integrated in different ways.

Planning, Models, Policies, and Feedback

If the sensed state changes, the robot may need to revise a plan instead of continuing an obsolete sequence. Feedback can also guide motion while a plan is being executed. Model predictive control, or MPC, is one conceptual example of repeatedly optimizing over a limited horizon and using updated state information to choose the next control action. It is not a required component of every planner, nor is it a promise that replanning will overcome every disturbance.

A model that estimates what might happen after an action can help assess candidate plans. That predictive role is related to, but different from, the planner’s role in selecting an action or motion. World models offer a broader discussion of prediction in robotics; their existence does not mean every planner contains a separate learned world model. Predictions remain conditional on the model and the situations it represents.

A policy chooses an action from observations or state, while a planner may search over possible choices; the boundary is not absolute. A feedback plan can itself specify what to do in different states, and a system may combine learned action generation with explicit planning. VLA policies provide one adjacent concept, but the label VLA does not tell us which planning or control functions a particular implementation includes.

A plan evaluated in a model or simulation must still confront imperfect descriptions of the real world. Object pose estimates can be wrong, contact can differ from the model, and the environment can change before execution finishes. These limitations connect to Sim2Real transfer, but no single transfer technique guarantees that a planned motion will work on a physical robot. State updates and checks remain important.

Conclusion

Robot planning connects goals to candidate action orders, motions, and, when needed, timed trajectories under stated constraints. It can reveal that a logical action has no feasible movement, that a reachable goal has no acceptable route, or that a geometric route needs more execution detail. Its result is only as relevant as the state, model, and constraints behind it. A feasible plan is not a successful physical execution; the robot must still sense, control, and respond to the world.