Suppose you're working on a version of ARCHO that, besides wheels, also has a pick-up arm — for grabbing boxes off a shelf. So far, with Nav2, we've seen how ARCHO moves through space. But when it comes to moving the arm, the problem is entirely different: if Nav2 is the brain behind the mobile robot's motion, MoveIt 2 is the brain of the robotic arm.
If you only say "the tip of the arm must be here" with no further checking, the arm might collide with the table, the shelf, or even itself on its way to that point. MoveIt eliminates exactly this risk — before any actual movement, it simulates and checks the entire path in its mind (in memory).
Suppose you have this arm:
Base → Joint1 → Joint2 → Joint3 → GripperNow a simple question: if I know the angle of all three joints, exactly where in space is the tip of the arm (the Gripper)?
If I know the angle of your shoulder, elbow, and wrist, I can calculate the exact location of your fingertip — that's exactly FK. This calculation is simple because we just "move forward": motor angle → link angle → link position → tip of the arm. There is always exactly one answer.
FK is exactly what TF2 (Chapter 5) actually uses: when TF says "the joints have these angles," it's
FK that calculates the real position of gripper_link or camera_link in
space. RViz, Gazebo, and Collision Detection all constantly rely on FK.
Now flip the question around: if I know where the tip of the arm needs to be (say, X=0.50, Y=0.20, Z=0.80), how many degrees must each joint turn?
When you say "pick up the cup on the table," your brain itself calculates the shoulder, elbow, and wrist angles — that's IK. But unlike FK, IK may have several solutions (say, elbow-up or elbow-down, both reaching the target), no solution at all (the target is out of reach), or even infinitely many solutions.
Why does IK matter more than FK? Because a human (or a production-line operator) always specifies a goal — "tighten this screw," not "rotate Joint1 by 13 degrees." MoveIt performs this translation from goal to joint angles for you.
| Forward Kinematics | Inverse Kinematics | |
|---|---|---|
| Input | Joint angles | Target position (Pose) |
| Output | Position of the arm tip | Joint angles |
| Number of solutions | Always exactly one | Zero, one, several, or infinite |
| Computational difficulty | Simple and direct | Usually requires a numerical solver |
| Common use | RViz, TF, Robot State, Gazebo | MoveIt, Pick & Place, Manipulation |
In real 6- or 7-axis arms, there is usually no simple closed-form formula for IK, and numerical solvers such as KDL, TRAC-IK, or IKFast are used, any of which MoveIt can employ as a plugin.
Don't think FK means "moving the arm" or IK means "moving the motor." Neither does that — they only calculate. Actually executing the motion is the job of ros2_control and the Controllers (Chapter 8).
Workspace means all the points the arm can actually reach. If the target is outside this range, IK responds: Unreachable — meaning reaching it is simply not possible, no matter how clear the path is.
When the arm becomes fully extended and straight, movement in certain directions suddenly becomes difficult or even impossible — this is called a Singularity. MoveIt tries to steer paths around configurations that approach this state.
| IK case | Cause |
|---|---|
| Multiple solutions (e.g. elbow-up/down) | The arm's geometry allows several different configurations to reach one target |
| No solution (No IK Solution) | The target is too far, a Joint Limit prevents it, or there's an obstacle in the way |
If MoveIt only had IK, it might choose the best mathematical answer — even if its path passes right through a box on the table. So the question is: how does MoveIt even know that box exists?
The Planning Scene is a complete digital model of the world ARCHO moves through: the robot itself, the table, the floor, the wall, boxes, tools, humans, fixed equipment, shelves, and the conveyor belt. MoveIt always checks this world in memory before every move.
Suppose a worker places a new box on the table next to ARCHO. The Planning Scene updates immediately, and from that moment on, MoveIt's new paths automatically route around that box — without anyone writing a single new line of code.
When ARCHO picks up a box, from that moment the box is effectively treated as part of the robot itself — this is called an Attached Object. If MoveIt forgets this, it might think the arm is still narrow, while with the box in hand its actual width has grown from, say, 40 centimeters to 80 centimeters — and this is exactly what causes the box to hit a wall, even if the arm itself passed by it completely unscathed.
Before executing any path, MoveIt asks: "Does the arm collide with anything at any moment along this path?" And this check isn't just at the start and end of the path — it's performed at hundreds or thousands of intermediate points along the way. If the start and end are clear but a collision occurs mid-path, that path is rejected.
| Collision type | Meaning | Example |
|---|---|---|
| Self Collision | The robot collides with itself | The Gripper hits the Upper Arm due to excessive elbow bending |
| World Collision | Collision with the environment | Table, wall, human, box, shelf |
Two adjacent joints like Joint1 and Joint2 are naturally always close to each other, and constantly checking their collision is pointless and slow. MoveIt builds a Self-Collision Matrix that specifies which pairs don't need checking at all — which makes the computation dramatically faster.
Remember in Chapter 4 we said URDF has two sections, visual and collision?
MoveIt only uses the collision section — a simple box instead of the precise screws,
edges, and logo of the visual model, because that's enough for collision checking and much faster.
Sometimes a collision is completely natural and necessary — for example, the Gripper must touch an
object in order to grasp it. MoveIt marks these exceptions with a matrix:
Gripper ↔ Object → Allowed, but Gripper ↔ Table → Not Allowed.
| Constraint type | Example |
|---|---|
| Orientation Constraint | A cup of water must always stay upright |
| Position Constraint | The arm may only move within a specified region |
| Joint Constraint | Joint3 must never exceed 90 degrees |
| Workspace Constraint | The arm is only allowed to move within a specified volume |
Suppose ARCHO's arm has 6 joints, and each joint has only 100 possible states. If MoveIt tried to test every combination, it would have to check 100⁶ — one trillion states — completely impossible.
Many people think MoveIt finds a path inside the three-dimensional space of the room. That's wrong. MoveIt actually searches inside the Configuration Space (C-Space) — the space of joint angles. If you have 6 joints, every configuration of the arm is a single point in a 6-dimensional space, not a point in the room.
Inside C-Space, some points are Free Space (allowed and collision-free) and some are Collision Space (not allowed because they collide with the table, wall, or the arm itself). The goal of the Motion Planner is to find a path from the Start point to the Goal point that stays entirely within Free Space.
Open Motion Planning Library — MoveIt doesn't write its own path-planning algorithms; instead it uses this open-source library. OMPL's input: Planning Scene + Robot Model + Goal. Output: a Trajectory.
Instead of examining the whole space, RRT grows a tree from the start point, like the roots of a plant. Each new branch is a new random configuration of the arm. If a branch hits an obstacle, it's discarded and the tree grows in another direction. When a branch reaches the Goal, that branch becomes the final path.
An improved version: instead of one tree, two trees grow simultaneously — one from Start and one from Goal. When these two trees meet, a path has been found. This is usually the fastest planner available in MoveIt.
First, thousands of random points are generated in C-Space and connected to each other — like building a road map. Then a suitable path is simply chosen along that road network.
| RRT / RRTConnect | PRM | |
|---|---|---|
| Method | Starts fresh from scratch each time | First builds a fixed "road network," then uses it repeatedly |
| Best suited for | Constantly changing environments | Static, repetitive environments |
The Planner only finds a Path — a sequence of joint angles with no information about time at all. This raw path usually has sharp corners that aren't suitable for physical execution, so MoveIt smooths it out with Path Smoothing.
A Path is just the route. A Trajectory means route + time — for example, "second zero: Joint1=0°, second one: Joint1=20°, second two: Joint1=35°." This final Trajectory is what the Controller (Chapter 8) actually executes.
When building the final Trajectory, MoveIt also respects several constraints:
| Constraint | Meaning |
|---|---|
| Velocity Limit | No joint's speed exceeds its allowed limit |
| Acceleration Limit | No sudden acceleration |
| Jerk | Even a sudden change in acceleration is limited in professional industrial robots |
The central coordinator of all this is a Node known as move_group:
RRT and RRTConnect find a good, safe path, not necessarily the mathematically
optimal path in the world — because finding the absolutely optimal path could take hours. MoveIt
has a limited Planning Time (say, 5 seconds); if no path is found by then, it returns
Planning Failed.
Now you know what happens behind the scenes when ARCHO raises its arm to pick up a box: FK calculates where the arm currently is, IK calculates what joint angles are needed to reach the target, the Planning Scene keeps the surrounding world in memory, Collision Detection verifies the safety of the path, and OMPL finds a safe route through the multi-dimensional Configuration Space, which is finally turned into an executable Trajectory.
ARCHO Project now has a complete MoveIt configuration that, using the Planning Scene, Collision Detection, and the RRTConnect algorithm, can guide its pick-up arm to grab a box from the shelf without colliding with the environment.
In Chapter 14 we move away from a single ARCHO and enter the world of multi-robot systems: Namespaces, TF Prefixes, and coordinating multiple ARCHOs working simultaneously in a warehouse.