What Is Motion Planning, in Plain English?

Motion planning is how a robot works out a way to move without hitting anything, and borrowing a planner beats writing one. Most first robots need no planner at all: a fixed sequence, or a straight line with a stop rule, carries them further than expected. That flips the moment obstacles move between runs, and middleware such as ROS 2 or HORUS then decides whether the plan reaches the wheels in time. The rest of this post is for someone whose arm keeps clipping the table, or whose base finds a route and then drives into a chair.

You told the arm to go to the cup, and it went to the cup — through the fruit bowl. Or it refused, printed a line about no solution being found, and sat there while you looked at a gap wide enough for your own hand. Or worst of all it worked eleven times and then, on the twelfth, swung its elbow out in a wide arc nobody asked for and knocked a monitor off the desk.

The wheeled version is the same complaint at a different scale. The robot draws a route on the screen, sets off, and grazes a doorway the route showed it clearing comfortably. Or it stops dead and thinks for long enough that somebody asks whether it has crashed.

So you start hardcoding. Waypoints, angles, a position for each object, and it works right up until somebody moves the table by a hand's width. The frustrating part is that you can see the answer. The robot obviously should go around the left side. Explaining why, in a way a machine can act on, turns out to be the actual job.

Does your robot actually need motion planning?

You need a planner the moment the robot has to choose its own route, and not one minute before. A machine repeating the same movement in a space that nobody rearranges is not planning; it is replaying, and replaying is simpler, faster to build and far easier to trust. The dividing line is whether the obstacles are known when you write the code or only when the robot runs. A pick-and-place cell with a fixture holding every part in the same spot needs no planner. A robot reaching into a dishwasher that a human loaded needs one badly. The second test is how many ways there are to get there. A wheeled base on an open floor has a handful of sensible routes, and a rule of thumb plus a stop-if-blocked reflex covers most of them. An arm with several joints reaching behind a shelf has an enormous number of ways to move, nearly all of which end with an elbow inside something solid, and no rule of thumb will pick a good one for you. Count the choices before you buy the machinery.

What is motion planning in plain language?

Motion planning is working out a sequence of movements that takes the robot from where it is to where it needs to be without hitting anything, including itself. It has two halves that beginners often merge by accident. The first half decides the route — which way around the chair, over the shelf or under the bar. The second half decides how the robot travels that route: where it speeds up, where it slows, how sharply it turns, and whether the motion is smooth enough that nothing being carried tips over. The first half is geometry, the second half is physics, and a route the machine cannot physically follow is not a plan at all. For an arm, one further idea is worth swallowing early. The planner does not really think in the room; it thinks in the space of possible joint positions, where each point stands for a whole pose of the whole arm. That sounds abstract, but it explains the strange behaviour you will see: two poses that look adjacent in the room can be far apart for the arm, which is why it sometimes takes a long way round.

What are your actual options for planning a motion?

Your options run from no planner at all to a full planning stack, and the first question is which end you belong at. The lightest is teach-and-repeat: move the robot through the motion once, record it, replay it, and accept that the world must stay put. Next is a straight move towards the goal with a rule for stopping when something is in the way, which handles more real tasks than its reputation suggests. Above that sits route search over a map for a wheeled base, and for an arm a sampling planner that tries many candidate movements and keeps one that collides with nothing — under ROS 2 that arrives packaged with collision checking, a model of the robot's own body and an executor to run the result, while HORUS, an open-source real-time middleware for Rust, Python and C++, does a different job, putting all three languages on the same shared-memory ring buffers so a planner written in Python can hand its result to a C++ or Rust follower on the same machine without serialising it. Read the table as a set of situations, not a ranking.

What should you do if you are one person building a first arm or base?

Make the robot stop reliably before you make it move cleverly. A solo builder's first planning project almost always begins at the wrong end: weeks reading about search algorithms, followed by a robot that finds an elegant route and then drives through a chair leg because nothing was ever watching. Build the reflex first. Give the machine a way to notice something is in the way and a way to give up safely, then test that by putting your hand where the robot wants to go. Once stopping works, add the crudest possible planner — go straight, and if blocked, try going around one side, then the other. That covers a surprising share of first tasks, and more importantly it teaches you what your robot's actual problem is. Some people discover their problem was never the route at all but knowing where things are, which is a different job entirely and covered in sensor fusion without the maths. Only when the crude version fails for reasons you can describe in a sentence is it worth reaching for a real planner.

What changes when the planner runs on a small onboard computer?

A small computer makes planning's bursty appetite for attention into a visible stutter, because a planner is not a steady worker. It sits idle, then wants everything at once while it searches, then goes quiet again. On a desktop nobody notices. On a small board shared with camera processing and the code driving the motors, that burst arrives as a pause you can see: the arm stops mid-reach and hangs there while the machine thinks, or the base drifts a little because nothing was steering it for a moment. The fix is not a faster board, it is separation. Put the planner in its own program, let it produce plans ahead of when they are needed, and make sure whatever feeds the motors always has something to follow — even if that something is only the instruction to hold still. Then the planner can take as long as it likes without the robot noticing. This is the same division that keeps a control loop running on time, and it is the single structural decision that separates robots that move smoothly from robots that hesitate.

What if you have only a few weeks before a demo?

Shrink the world rather than growing the planner. With a deadline in sight, every hour spent making a planner cleverer is an hour not spent removing the reason it has to be clever. Clear the table. Put the objects in known places. Mark the floor. Choose an approach direction the arm can always use, and design the task so the robot never has to reach across something. Then record a small number of motions that work and replay them, with a stop reflex as insurance. This feels like cheating and it is exactly what shipped products do — an enormous amount of working automation is a fixed motion in a controlled space with a good safety reflex. The specific danger of demo week is a sampling planner, because such planners give a different motion each run: it will look fine in rehearsal and produce an unfamiliar wide swing in front of an audience. If you must use one, plan the motions in advance, check each one by eye, save them, and replay the saved versions on the day.

What if you have never written planning code before?

Learn three ideas and you will understand most of what a planner does. The first is the pose: everything about where the robot is right now, which for an arm means every joint angle at once rather than just where the hand is. The second is the collision model, which is the simplified set of boxes and cylinders the planner uses to stand for the robot, the table and the obstacles — deliberately fatter than reality, so that near misses count as hits. The third is cost, meaning whatever makes one motion better than another: shorter, smoother, further from people, easier on the motors. Every planner is some way of searching through poses, rejecting the ones that collide, and preferring the ones with lower cost. That is genuinely the whole shape of the field. Most of your debugging, though, will be in the second idea rather than the first. When a planner behaves absurdly, the model is usually wrong: a box in the wrong place, a gripper nobody described, or a table that exists in the room and not in the robot's picture of it.

What do you give up by adding a planner?

You give up doing the same thing twice. Most arm planners search by trying random candidate movements and keeping the first set that works, so every run produces a slightly different motion — safe, valid, and never quite the one you watched yesterday. That single property upsets more teams than any other. It breaks tests that compare against a recorded motion, it unnerves anybody standing nearby, and it makes a fault reported by a colleague hard to reproduce. You also give up explainability. When a fixed sequence goes wrong, you read the sequence. When a planner goes wrong, you reason about a search, a model and a cost setting, and the answer is often that the robot did exactly what you asked in a way you did not anticipate. There is an ongoing cost as well: the collision model needs updating whenever the robot changes, and a model that stops matching the hardware turns a careful planner into a confident source of collisions. Take that trade when the world genuinely varies. Refuse it while the world is still standing still.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost any robot that plans, and that is not a close call. Both hard versions of this problem — navigating a mapped building on wheels, and moving a jointed arm around obstacles — have maintained stacks in that ecosystem, complete with collision checking, robot description formats, visualisation to see what the planner was thinking, and executors that run the result on real hardware. Rebuilding any one of those pieces alone is a serious project, and rebuilding all of them means you are no longer building a robot. Take the stack. The same holds if your sensor ships only a ROS 2 driver, if the robot spans more than one computer, or if your team already speaks the vocabulary. HORUS is not the answer for those projects, and picking it there means writing plumbing instead of moving an arm. The honest boundary is narrow: a shared-memory middleware helps with getting a plan from one language to another on one machine quickly, and it does not help at all with deciding what the plan should be.

Can a language model plan the motion for you?

No, and here is why: a language model is good at deciding what should happen and poor at deciding where the elbow goes. Ask one to fetch the mug and it will produce a sensible sequence of steps — approach, grasp, lift, carry — because that is a description task, and descriptions are what such models do. Ask it for the joint angles that clear the shelf edge by a finger's width, and it has no access to the shape of your robot, the position of your shelf, or whether the gripper fingers are open, so it produces something plausible and wrong. The plausible-and-wrong combination is the dangerous one, because it reads like an answer. The division that works is to let the model choose the goal and let a planner produce the motion that reaches it, with the planner keeping veto power over anything that collides. That split is explored further in why a model that writes apps cannot pick up a cup, and it is the arrangement most serious teams have converged on.

Is motion planning the same as finding a path on a map?

Partly, but not the way you think. Route-finding on a grid is the friendly cousin of the problem: a robot with a position, a map of blocked squares, and a search for a chain of free squares to the goal. That version is genuinely enough for many wheeled machines, and if your robot is one of those, take it and move on. The difference for an arm is that the robot is not a point. It is a body with a shape that changes as it moves, so whether a position is blocked depends on how the arm got there, and the map you would need has one dimension per joint — far too many to draw or to search square by square. That is why arm planners sample candidate poses rather than examining every option. The other difference is that the map version stops at the route, while a real plan has to be executable: the joints have limits, the motors have limits, and a route that requires an impossible change of direction is a picture rather than an instruction.

What does motion planning look like when it goes wrong?

The signature failure is a planner that refuses a motion a human can see is possible. You watch the gap, you know your hand fits, and the robot insists there is no solution. Nine times out of ten the collision model is wrong: an obstacle described bigger than it is, a gripper nobody added, a table surface placed slightly too high, or a goal a hair outside the arm's actual reach. The second failure is the wild motion — a valid, collision-free plan that swings the elbow through a huge arc because nothing told the planner that a shorter, calmer route was preferable. The third is the plan that is fine and the execution that is not: the drawn route is correct, but the robot cuts the corner because whatever follows the plan cannot keep up with it, which is a tracking fault rather than a planning one. The fourth is the freeze, where the search takes long enough that the machine appears to have died. Four faults, four different cures, and only one lives inside the planner.

What do people try first, and why does it stop working?

Nearly everybody starts by hardcoding waypoints, and it works well enough to feel like the right answer. You move the arm by hand to a few good positions, write the numbers down, and replay them. For a fixed task in a fixed cell, that is not a hack — it is what a lot of production automation actually is. It stops working at a very specific moment: the first time the position of something matters and is not known in advance. Then comes a list of waypoints per object, then a lookup table, then rules choosing between saved motions, and each addition works while the cases stay few. The collapse comes when two variable things combine, because the number of cases you must record multiplies rather than adds, and nobody can enumerate them. The realisation waiting at the end is that a planner is not a cleverer version of your list. It is a way of generating the entry you would have needed, at the moment you need it, from a description of what must not be touched.

How do you tell which planning problem you actually have?

Watch where the failure happens, because before-moving and during-moving are different diagnoses. If the robot fails before it moves, the fault is in the planner or its model, and the first suspect is always the model rather than the algorithm — describe the obstacles again and check what the robot believes about its own body. If it fails during the movement, the plan was accepted and something downstream could not follow it, which points at the executor, the timing, or a motor being asked for more than it has. If the motion is correct but arrives at the wrong place, the planner was fed a bad idea of where things are, and the problem is perception rather than planning. If it works in simulation and not on the real machine, the model and the hardware have drifted apart. And if it works slowly and fails quickly, you are meeting physics rather than geometry. Deciding which robot to face all this with is its own question, weighed in arms against humanoids for developers.

Decide by situation rather than by instinct:

• If the world is the same at the start of every run -> record and replay a motion, because a planner you did not need is a variable you did not have.
• If the space is mostly empty and the robot just has to stop -> a straight move with a stop reflex, because that reflex is what actually keeps things safe.
• If a wheeled robot must cross a mapped floor -> the ROS 2 navigation stack, because that route problem is thoroughly solved already.
• If a jointed arm must reach around obstacles -> a maintained manipulation stack, because collision checking is where the real work hides.
• If Python planning must feed a C++ or Rust follower on one machine -> a shared-memory middleware, because the language boundary is where a plan goes stale.

When the foundation question arrives, weigh it on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and take the option that loses on the fewest, with no scores involved. If your robot keeps landing on one machine, more than one language, and a plan that has to reach the motors before the moment passes, star HORUS on GitHub so it is in your list when you start building.