Why a robot's straight-line motion in one space can look curved in the other.
When a motion planner sends a robot arm from one pose to another, it has to decide how to get there — not just where to end up. That choice is the interpolation mode, and there are two fundamentally different ones: interpolate directly in joint space (each joint's own angle), or interpolate in Cartesian space (the end-effector's real-world X/Y/Z position). This is a close cousin of the forward vs. inverse kinematics distinction — in fact, Cartesian-space motion is only possible because inverse kinematics can be solved, repeatedly, along the way.
Joint space describes a robot arm's configuration purely as a list of joint angles — θ1, θ2, θ3, and so on, one number per joint. Cartesian space (also called task space) describes the same pose in terms the world actually cares about: the end-effector's X/Y/Z position and orientation. Any reachable pose has a value in both spaces at once — the question this Concept Explainer answers is what happens to the path in between two poses, depending on which space the motion is interpolated in.
Joint-space interpolation is computationally simple and gentle on the motors: each joint just ramps its own angle at a controlled, predictable rate from start value to end value, with nothing else to compute. But because several joints are moving simultaneously, each at its own independent linear rate, the combined motion of the links generally does notadd up to a straight line at the tip — it curves, the way our example arm's end-effector traces a circular arc even though θ1 and θ2 are each changing perfectly linearly the whole time. Joint-space interpolation makes no promise at all about the shape of that in-between path; it only promises the correct final destination.
Cartesian-space interpolation flips the guarantee: the controller commands the end-effector's real-world position directly, along a specific geometric path (a straight line, an arc, whatever the task needs), and continuously re-solves inverse kinematics — over and over, many times per second — to find the joint angles that keep the tip exactly on that path at each instant. That is far more computationally demanding than joint-space interpolation's one-time ramp, and because the same end-effector point can sometimes be reached by more than one joint configuration (the classic elbow-up/elbow-down ambiguity), the required joint motion can occasionally involve a large, fast, or awkward swing — exactly the kind of jump shown between the middle two poses above — even though the tip never leaves the commanded line.
False, and it's a genuinely common programming mistake. Joint-space interpolation only guarantees the correct final destination pose — it has no control whatsoever over the shape of the path the end-effector traces on the way there, and that shape is generally curved, not straight. Cartesian-space interpolation is specifically what's required to guarantee the end-effector follows a particular real-world path shape, like a straight line, between start and end. For tasks where the actual path matters — welding a straight seam, following a precise cutting line, threading a tool through a constrained space — choosing joint-space interpolation by mistake can produce a genuinely wrong, wandering, curved path that misses the actual work, even though the robot arrives at the technically correct destination pose at the end. The reverse mistake is also real: using Cartesian-space interpolation for a simple point-to-point move, where only the destination matters and no one cares about the path shape, adds unnecessary continuous inverse-kinematics overhead and can occasionally trigger an unexpectedly large joint swing for no practical benefit.
Explains why interpolating a robot arm's motion directly in joint space (each joint's own angle changing linearly) generally produces a curved end-effector path, while interpolating in Cartesian space (the end-effector's real-world position) guarantees a specific path shape — like a straight line — but requires the controller to solve inverse kinematics continuously along the way, and can occasionally demand large or awkward joint swings to do it.
In joint-space interpolation, the controller ramps each joint's angle smoothly and linearly from its start value to its end value over the duration of the move — nothing more complicated than that. It is computationally cheap and easy on the motors and drives, since every joint follows its own independent, predictable, constant-rate trajectory with no coordination required between joints. The cost is that the resulting path traced by the end-effector through real 3D space is generally not a straight line. Because several joints are rotating simultaneously, each at its own linear rate, their combined geometric effect on the tip's position is curved rather than linear — joint-space interpolation guarantees the correct destination pose and nothing about the shape of the path used to get there.
In Cartesian-space (task-space) interpolation, the end-effector's position and orientation are commanded directly along a specific geometric path in real-world coordinates — most commonly a straight line, but any parametrized path works the same way. To actually execute this, the controller must repeatedly solve inverse kinematics at many points along that path, converting each intermediate Cartesian target back into the specific joint angles needed to reach it at that instant. This is computationally heavier than joint-space interpolation, since inverse kinematics runs continuously throughout the motion rather than once at the destination, and because a given end-effector point can sometimes be reached by more than one valid joint configuration, the required joint motion can occasionally involve a large, fast, or awkward angular change to keep the tip exactly on the commanded path.
The two modes are not interchangeable, and the choice depends entirely on whether the actual path matters or only the destination does. Tasks like welding a seam, following a precise cutting line, or moving through a constrained space depend on the tool tip tracing a specific route — those require Cartesian-space interpolation, since joint-space interpolation offers no guarantee about path shape and can produce an unwanted curved or wandering path even when it reaches the technically correct destination. Simple point-to-point moves, where only the final pose matters and nothing about the route in between, are usually better served by joint-space interpolation, since Cartesian interpolation there adds unnecessary continuous inverse-kinematics overhead and can occasionally trigger a large, unexpected joint swing for no practical benefit.
Joint space describes a robot arm's configuration purely as a list of individual joint angles — θ1, θ2, θ3, and so on for each joint. A specific pose in joint space is just that set of numbers, with no direct reference to where the end-effector sits in the real world.
Cartesian space, also called task space, describes the end-effector's pose directly in real-world X/Y/Z coordinates plus orientation — the terms a human actually cares about, independent of which specific combination of joint angles happens to produce that pose.
Because multiple joints move simultaneously, each changing its own angle at its own independent, constant linear rate. The combined geometric effect of several rotating links moving at once generally does not add up to a straight line at the tip, even though each individual joint's motion is perfectly linear over time.
Commanding the end-effector to follow a specific real-world path means the controller must repeatedly compute which joint angles place the end-effector at each intermediate point along that path — running the inverse-kinematics calculation continuously throughout the motion, not just once at the final destination.
Cartesian-space interpolation, because the task depends on the actual path the torch or tool tip follows through space, not just on reaching the correct final pose. Joint-space interpolation offers no guarantee about the shape of that in-between path, and can easily miss the seam.
Yes. Because it must recompute inverse kinematics continuously, it can occasionally demand a large, fast, or awkward joint angle change to keep the end-effector exactly on the commanded path — particularly if the path passes near a kinematic singularity or requires switching between different valid inverse-kinematics solutions (such as an elbow flipping from one configuration to another) partway through the motion.
Try our Robotics & Automation Studio
More calculators, simulators, and guides for this discipline.