🧭 Path Planning & Motion Algorithms for Robots

Every industrial robot deployment eventually runs into a question that kinematics alone cannot answer. Inverse kinematics, covered in our industrial robot kinematics guide, tells the controller how to reach one specific point: given a target position and orientation, what joint angles get the end effector there. But a robot rarely moves to just one point in isolation. It has to get from where it is now to where it needs to be next, across a work cell full of fixtures, conveyors, other machinery, and sometimes people — without colliding with any of it. Deciding the actual sequence of intermediate points the robot should pass through to make that trip safely and efficiently is a separate problem called path planning (often used interchangeably with the broader term motion planning, which also accounts for velocity, acceleration, and dynamic constraints along the path). Kinematics answers "how do I reach this point"; path planning answers "which points should I reach, in what order, to get across this environment."

Why Path Planning Is a Distinct Problem

Consider a 6-axis arm reaching into a machine tending cell to pick a part, then placing it on a conveyor a meter away. Naively commanding the controller to move directly from the pick pose to the place pose — a straight-line interpolation in joint space or Cartesian space — might send the arm straight through the machine's door frame, a safety fence, or a fixture sitting between the two points. The robot's inverse kinematics would happily compute a valid joint solution for the destination pose; nothing in that calculation knows or cares that the straight-line path to get there is blocked. Path planning exists specifically to solve that gap: it searches for a route through the space of possible robot configurations that avoids known obstacles, and hands the resulting sequence of waypoints to the motion controller, which then relies on kinematics to execute each individual point along that route. In mobile robotics the same logic applies at a larger scale — an automated guided vehicle (AGV) or autonomous mobile robot (AMR) navigating a warehouse floor needs a route around shelving, parked equipment, and other traffic, not just a bearing and a distance to its destination.

Configuration Space: The Space Path Planners Actually Search

Path planning algorithms rarely search directly in the physical 3D workspace a person would picture. Instead, they search in configuration space, commonly abbreviated C-space. A configuration is a complete description of the robot's state: for a 6-axis arm, that's six numbers, one angle per joint; for a wheeled mobile robot moving on a flat floor, that's typically three numbers — x position, y position, and heading angle. Configuration space is the set of all possible configurations, and a single point in that space represents one complete pose of the entire robot, not just the position of its end effector or its footprint.

The reason planners work in C-space rather than physical space is that it elegantly folds the robot's own geometry into the obstacle definition. In physical workspace, whether a given arm pose collides with a fixture depends on the shape and position of every link, not just the tip — a seemingly clear target point can still be unreachable if the elbow would swing through an obstacle on the way there. By pre-computing which configurations put any part of the robot in collision with a known obstacle, and marking those regions of C-space as "blocked," the planner reduces the problem to a much cleaner one: find a continuous path between a start point and a goal point in C-space that never crosses a blocked region. Any such path is guaranteed collision-free in the real world, because the collision-checking work was already absorbed into how the space was defined. The tradeoff is that C-space grows in dimensionality with every joint the robot has — a 2D mobile robot's C-space is easy to visualize and search directly, while a 6-axis arm's six-dimensional C-space cannot be visualized at all and is expensive to search exhaustively, which is exactly why different classes of algorithms have evolved for different C-space sizes.

Grid and Graph-Search Methods: Dijkstra and A*

The most intuitive family of path planning algorithms treats the environment (or C-space) as a grid or graph of discrete points, connected to their neighbors, and searches that graph for the shortest connected route from start to goal.

Dijkstra's algorithm is the foundational method: it explores outward from the start node, always expanding the closest unvisited node next, and keeps track of the cheapest known route to every node it has reached. It is guaranteed to find the truly shortest path, but it explores somewhat blindly — it has no sense of which direction the goal actually lies in, so it tends to expand a large, roughly circular region around the start before it happens to reach the goal.

A* (pronounced "A-star") improves directly on that blindness by adding a heuristic: an estimate of the remaining distance from any given node to the goal (commonly straight-line distance). Instead of expanding purely by cost-so-far like Dijkstra, A* expands nodes based on the sum of the cost already spent getting there plus the heuristic estimate of what's left, which biases the search to expand nodes that are actually making progress toward the goal rather than nodes that are merely close to the start. As long as the heuristic never overestimates the true remaining distance, A* is still guaranteed to find the shortest path, and in practice it typically explores dramatically fewer nodes than plain Dijkstra to get there. This efficiency is why A* (and its many variants, such as D* for environments that change while the robot is moving) is the default choice for grid-based mobile robot navigation, including the global planners used inside frameworks like ROS 2's Nav2 stack.

Grid-search methods work well when the space being searched is low-dimensional — a 2D or 2.5D floor map is the classic case — because the grid stays a manageable size. They become impractical for a 6-axis arm's six-dimensional C-space: discretizing six dimensions finely enough to plan around obstacles reliably produces a grid so large that exhaustive search is computationally out of reach.

Sampling-Based Planning: RRT and Its Variants

For high-dimensional configuration spaces — robotic arm motion planning being the archetypal case — the dominant approach is sampling-based planning, and the best-known member of that family is the Rapidly-exploring Random Tree (RRT). Rather than trying to discretize and search the entire space, RRT builds up a tree of valid, collision-free configurations incrementally: starting from the robot's current configuration, it repeatedly picks a random point in C-space, finds the closest existing node in the tree, and grows the tree a small step toward that random point, checking along the way that the new branch doesn't pass through a blocked (obstacle) region. Over many iterations, the tree spreads out and "explores" the reachable space, and the algorithm terminates once a branch gets close enough to the goal configuration to connect to it.

The appeal of RRT is that it never needs to represent or search the whole C-space explicitly — it only ever evaluates the specific configurations it samples, which makes it tractable in spaces with many degrees of freedom where grid search simply cannot run. The tradeoff is that a plain RRT path is typically jagged and far from optimal, since it follows whatever random sequence of tree growth happened to reach the goal first, not the shortest or smoothest possible route. In practice, RRT-generated paths are almost always passed through a post-processing smoothing step before being executed, and a widely used improved variant, RRT*, continues refining the tree after an initial path is found, progressively rewiring connections to reduce path cost and asymptotically approach an optimal path given enough planning time. RRT and RRT* are the planning backbone behind arm motion-planning tools such as MoveIt, precisely because they scale to the joint-space dimensionality real manipulators present.

Potential Field Methods

A third conceptual approach, the artificial potential field method, treats path planning more like physics than search. The goal is modeled as generating an attractive force that pulls the robot toward it, while obstacles generate repulsive forces that push the robot away, and the robot's next move at any instant is simply computed from the combined vector sum of all those forces acting on its current position. This makes potential fields extremely cheap to compute at each control step and naturally reactive to new sensor information, which is exactly why they show up far more often as a local, reactive layer — dodging a person or forklift that has just entered the robot's path — than as the sole planner for an entire route.

The well-known weakness of pure potential field methods is the local minimum problem: in certain obstacle configurations (a classic example is a U-shaped or box-shaped obstacle positioned between the robot and the goal), the repulsive and attractive forces can cancel out or trap the robot in a spot where it feels no net pull toward the goal, even though a valid path clearly exists a short distance away. Because potential fields have no global memory of the environment's layout, they can't reason their way out of that trap the way a graph search naturally would. This is why most deployed systems don't rely on potential fields alone: a global planner (A* or RRT-family) works out a sound overall route first, and a fast, reactive potential-field-style local planner handles moment-to-moment obstacle avoidance and small deviations around that global path.

Comparing the Three Approaches

Obstacle Avoidance: Static vs. Dynamic

Path planning problems split further based on whether the environment stays fixed or changes while the robot moves. Static obstacle avoidance plans a full route once, against a known, unchanging map of obstacles — a fixed conveyor, a permanent fixture, a wall — and that plan remains valid until something in the layout genuinely changes. Dynamic obstacle avoidance has to account for obstacles that move during execution: a person walking through a shared work cell, another AMR crossing the same aisle, or a part swinging on a hook. Handling dynamic obstacles generally requires either replanning at a fast enough rate to keep up with the changing environment (algorithms like D* were specifically designed to efficiently update an existing plan rather than restart from scratch), or layering a fast reactive method — often potential-field-style — underneath a global planner so the robot can make small, immediate deviations without waiting for a full replan. This is also where path planning connects directly to the safety systems covered in our cobot safety guide: speed and separation monitoring, for instance, is functionally a dynamic obstacle response, continuously adjusting the robot's motion based on how close a moving person currently is.

Where Path Planning Fits in the Robot Software Stack

In a modern ROS 2-based system, path planning is a distinct, swappable layer, not something baked directly into a motor driver. Nav2 handles global and local path planning for mobile robots navigating a mapped environment, typically using an A*-family global planner combined with a reactive local planner or controller for moment-to-moment obstacle avoidance. MoveIt plays the equivalent role for robotic arms, providing collision-aware motion planning built primarily on sampling-based planners like RRT and its variants, along with the post-processing smoothing that turns a raw sampled path into a trajectory a real arm controller can execute cleanly. In both cases, the planner's output — a sequence of waypoints or a smoothed trajectory — is handed downstream to inverse kinematics and the motion controller, which is the layer that actually knows how to move the physical joints to hit each point in the sequence. Treating planning and kinematics as separate, composable layers is exactly what lets an engineer swap in a different planning algorithm, or add a new class of obstacle, without touching how the robot's joints are controlled at all.

Practical Guidance for Choosing an Approach

• Use grid-based search (A*) when the problem is genuinely low-dimensional — routing a mobile robot or AGV across a mapped floor plan — and an optimal or near-optimal path on that map matters.
• Use sampling-based planning (RRT/RRT*) when planning a multi-joint arm's motion through a cluttered cell, where the configuration space has too many dimensions for exhaustive search to be practical.
• Use potential fields, or a reactive local planner inspired by them, as a fast safety layer for handling obstacles that appear or move unpredictably during execution, always paired with a global planner that has already established a sound overall route.
• Always plan in configuration space, not physical space, when the robot's own geometry (not just its end effector or footprint) can plausibly collide with something along the way — which, for any multi-link arm, is essentially always.

None of these algorithms replace kinematics — they sit one layer above it, deciding the route the robot should take before kinematics figures out how to move the joints to trace it. Understanding that division is usually the fastest way to diagnose why a robot program that "looks correct" pose by pose still ends up colliding with something on the way between poses.