What It Really Takes to Make a Robot Move Precisely

Deep dive · Dynamics & control · ~15 min read

A datasheet can promise micron resolution and a robot can still move badly. The gap between those two facts is filled by dynamics and control — the part of robotics that decides whether a system actually performs. Here is what's really going on underneath, equations and all.

It is one of the most common and most expensive misconceptions in machine design: that precision is something you buy. Specify a good enough encoder and a stiff enough motor, the thinking goes, and precise motion follows. It does not. A robot built from excellent components will still overshoot, vibrate, sag under gravity, and lose accuracy the moment it moves quickly or carries a load — unless the control system wrapped around those components is designed to prevent it. This article walks through why, from the physics up, and what the engineering that closes that gap actually looks like.

1 · A robot is a nonlinear, coupled machine

Start with the physics, because everything downstream follows from it. Whatever its structure or number of axes, a rigid robot's motion obeys a single equation — the manipulator equation of motion — derived from the Euler–Lagrange method:

$$\underbrace{M(q)\,\ddot{q}}_{\text{inertia}} + \underbrace{C(q,\dot{q})\,\dot{q}}_{\text{Coriolis / centrifugal}} + \underbrace{g(q)}_{\text{gravity}} + \underbrace{\tau_f(\dot{q})}_{\text{friction}} = \tau$$

Here q is the vector of joint positions, q̇ and q̈ their velocities and accelerations, and τ the torques the motors apply. Read it term by term, because each one is a physical headache:

• Inertia, M(q) q̈. M(q) is the mass matrix, the high-dimensional generalisation of "mass." The crucial word is q: the effective inertia changes with the robot's pose. An arm stretched out is far harder to accelerate than one folded in. The plant you are controlling is literally a different machine in every configuration.
• Coriolis and centrifugal forces, C(q,q̇) q̇. These arise because the robot has many axes moving at once. Spin one joint and it throws sideways forces onto the others. They grow with the square of speed, so they are negligible in a slow demo and dominant in a fast one.
• Gravity, g(q). The pose-dependent torque needed just to hold still against gravity. It is why an un-compensated arm droops the instant you release it.
• Friction, τ_f(q̇). Nonlinear, partly discontinuous, and the quiet enemy of fine positioning (more on it later).

Two structural properties of this equation are what make principled control possible at all. The mass matrix is always symmetric and positive-definite, so it is always invertible. And with a proper choice of C, the matrix Ṁ − 2C is skew-symmetric:

$$x^{\top}\left(\dot{M}(q) - 2\,C(q,\dot{q})\right)x = 0 \quad \forall\, x$$

That looks abstract, but it is really a statement that the robot's internal forces do no net work — an energy-conservation law. It is the hook on which the stability proofs below hang. Far from academic trivia, these properties are exactly what let model-based controllers be designed systematically rather than tuned by trial and error.

2 · Why a PID loop per joint hits a wall

The instinctive approach is to treat each axis as an independent motor and wrap a PID loop around it — measure the joint, compare to target, correct. For a slow, lightly loaded, well-geared axis this works, and it is where most systems start:

$$\tau_i = K_p\,e_i + K_i\!\int_0^{t} e_i\,d\tau + K_d\,\dot{e}_i, \quad e_i = q_{d,i} - q_i$$

The wall it hits is Equation 1. A per-joint PID assumes each axis is a simple, constant, decoupled system. But the real axis sees an inertia that changes with pose, cross-coupling forces from every other axis, and a standing gravity load. A gain set that is crisp with the arm folded becomes sluggish or unstable with it extended. The controller spends its budget fighting physics it doesn't know about, and you discover the limit precisely when you ask for speed, payload, or accuracy at the same time — which is to say, in exactly the demanding application that justified a robot in the first place.

A PID loop reacts to error after the physics has already produced it. Model-based control cancels the physics before it becomes error.

3 · Model-based control: cancelling the physics

The breakthrough idea — known as Inverse Dynamics Control (IDC), or equivalently the Computed-Torque method, or in control theory feedback linearization — is to stop fighting the dynamics and instead use a model of them to cancel them out. If we know (approximately) the terms in Equation 1, we can compute the exact torque needed to produce any acceleration we want, and add a feedback term on top to handle what the model gets wrong.

The control law has two nested parts. An outer loop decides the acceleration the robot should have, based on the desired trajectory and the tracking error:

$$a_q = \ddot{q}_d + K_d\,\dot{e} + K_p\,e, \quad e = q_d - q$$

Note the q̈_d term: that is feedforward — the controller anticipates the acceleration the planned move requires instead of waiting for error to reveal it. An inner loop then converts that desired acceleration into motor torque by running it through a model of the robot's dynamics:

$$\tau = \hat{M}(q)\,a_q + \hat{C}(q,\dot{q})\,\dot{q} + \hat{g}(q) + \hat{\tau}_f(\dot{q})$$

The hats are the engineer's best estimates of the true terms. Now watch what happens if the model were perfect. Substitute Equation 5 into the true dynamics of Equation 1, cancel the matching terms, and use the fact that M(q) is invertible. The entire nonlinear, coupled mess collapses into something astonishing:

$$\ddot{e} + K_d\,\dot{e} + K_p\,e = 0$$

This is the payoff. In the ideal case the tracking error of every joint obeys a simple, linear, second-order equation that is completely decoupled from the others and independent of the robot's configuration. The pose-dependent inertia, the Coriolis coupling, the gravity sag — all gone, absorbed by the inner loop. What remains is a textbook system you can tune with confidence anywhere in the workspace.

Because Equation 6 is decoupled, you can now choose the gains directly from the response you want. Treating each joint as a second-order system with natural frequency ωₙ and damping ratio ζ:

$$K_p = \omega_n^{2}, \quad K_d = 2\,\zeta\,\omega_n$$

Want a critically damped axis (no overshoot) that settles in a chosen time? Pick ζ = 1 and the ωₙ that gives that settling time, and read the gains straight off. This is the difference between tuning a robot by educated guesswork and engineering it to a specification.

4 · Why it's provably stable

Engineers don't take "it seems to work" on faith for a system that could whip a multi-kilogram arm across a room. Stability is proven, and the proof is where the passivity property of Equation 2 earns its keep. Using the Lyapunov method, you define an energy-like function of the error — for a positioning task, something like:

$$V = \tfrac{1}{2}\,\dot{e}^{\top} M(q)\,\dot{e} + \tfrac{1}{2}\,e^{\top} K_p\,e \ \ge\ 0$$

This V is the total "error energy" — kinetic-like in the first term, spring-like in the second. Differentiate it along the closed-loop motion, and the skew-symmetry of Ṁ − 2C makes the messy coupling terms cancel exactly, leaving:

$$\dot{V} = -\,\dot{e}^{\top} K_d\,\dot{e} \ \le\ 0$$

Because the error energy can only fall, never rise, the error is driven to zero: the robot is guaranteed to converge to its target. This is the mathematical backbone behind a machine you can trust to behave. It is also why those structural properties of the dynamics weren't a digression — without them, there is no proof, and without a proof, no responsible deployment.

5 · Where the real world bites back

Everything above assumed a perfect model. No real robot has one. The honest version of Equation 6 keeps a right-hand side — everything the model got wrong, lumped into a disturbance:

$$\ddot{e} + K_d\,\dot{e} + K_p\,e = \underbrace{M^{-1}\left[(M-\hat{M})\ddot{q} + (C-\hat{C})\dot{q} + (g-\hat{g}) + (\tau_f-\hat{\tau}_f) - \tau_d\right]}_{\delta(t)\ =\ \text{model error} \,+\, \text{disturbance}}$$

The left side is the clean design; the right side, δ(t), is reality. Everything that separates a simulation from a shipped product lives in that term, and managing it is most of the real engineering work.

Model error and identification

The terms (M − M̂), (g − ĝ) and so on are only zero if the model is exact. Deriving and calibrating a robot's dynamic parameters — link masses, inertias, centres of gravity, friction coefficients — is a serious, time-intensive task in its own right. The closer the identified model, the smaller δ(t), and the better the cancellation. Good system identification isn't a formality; it directly buys accuracy.

Friction: the nonlinear spoiler

Friction deserves its own paragraph because it dominates at the low speeds where fine positioning happens. A workable model superposes Coulomb (constant, direction-dependent), viscous (proportional to speed), and the Stribeck effect (a dip as the joint breaks away from rest):

$$\tau_f(\dot{q}) = f_c\,\operatorname{sgn}(\dot{q}) + f_v\,\dot{q} + (f_s - f_c)\,e^{-(\dot{q}/v_s)^2}\operatorname{sgn}(\dot{q})$$

Sensor noise and quantization

The controller needs velocity, ė, but encoders measure position. Differentiating a quantized, noisy position signal amplifies that noise — and the derivative gain K_d multiplies it straight into the motor command, turning into audible buzz and wasted heat. Real systems filter the velocity estimate or, better, run a state observer that fuses the model with the measurement to produce a clean estimate. You cannot simply turn the gains up to chase precision; past a point you are amplifying noise, not rejecting error.

Actuator saturation

Equation 5 may demand a torque the motor cannot deliver. When the actuator saturates, the loop is momentarily open, and an integrator keeps winding up — producing exactly the overshoot you were trying to avoid. Practical controllers respect the limit explicitly and use anti-windup so the system degrades gracefully rather than lurching when pushed to its envelope.

Sampling, delay and the multi-axis clock

All of this runs on a digital controller at a finite rate. The control bandwidth you can achieve is fundamentally capped by the loop rate and its latency — you cannot reject a disturbance faster than you can sense and respond to it. On a multi-axis machine the problem multiplies: dozens of axes must sample, compute and actuate in lockstep, sharing a common, jitter-free sense of "now," or the coordinated motion smears. This is exactly the job of a deterministic fieldbus such as EtherCAT with distributed clocks — not a networking nicety, but a hard requirement for synchronised precision across many axes.

The pattern worth internalising

Model-based control doesn't make the disturbance δ(t) vanish — it makes it small and well-behaved, so a robust outer loop can mop up the rest. That is why serious systems don't stop at PD outside the inner loop; they reach for PID, and sometimes H∞ or adaptive and passivity-based designs, specifically to reject the uncertainty that no model fully captures. Precision is the product of a good model and a controller engineered to survive the model being imperfect.

6 · When the robot touches something

Everything so far assumed the robot moves freely. The instant it makes contact — assembly, polishing, inserting a connector, a surgical tool on tissue — position control alone becomes dangerous: a fraction of a millimetre too far means either no contact or a crushed part. The robot now has to regulate the wrench (force and torque) it exchanges with the world, not just its position. The most general tool, impedance control, shapes the dynamic relationship between motion and force, making the end-effector behave like a tunable spring–mass–damper:

$$M_d\,\ddot{\tilde{x}} + B_d\,\dot{\tilde{x}} + K_d\,\tilde{x} = F_{\text{ext}}, \quad \tilde{x} = x - x_{\text{ref}}$$

By choosing the desired inertia, damping and stiffness, the engineer decides exactly how compliant or firm the robot feels when it touches the world — soft enough not to break the part, firm enough to do the work. It is the same control philosophy as the rest of this article, extended from "where" to "how hard."

7 · What this means for a real product

Step back from the equations and the practical lesson is simple. The performance you actually live with — settling time, tracking accuracy, stability under changing load, smoothness at speed, behaviour on contact — is not a property of any single component. It is decided by the dynamic model, the control architecture, the quality of the parameter identification, and how carefully the whole thing was engineered against the real-world terms in δ(t). The encoder on the datasheet is necessary and nowhere near sufficient.

This is also why precise motion is genuinely hard to get right, and why it doesn't come from a catalogue. It sits at the intersection of mechanical design, dynamic modelling, real-time control, sensing and power electronics — disciplines that have to be solved together, by people who can move fluently between the physics and the firmware.

This is the engineering Segev Technologies does

Multi-axis motion control is the centre of our work — from dynamic modelling and control-law design to the drives, the embedded firmware, and the synchronised multi-axis hardware underneath. We've built systems coordinating dozens of EtherCAT axes for precision rigging and automation, and motion controllers for demanding medical and industrial applications, where "close enough" was never on the table.

If your product depends on motion that has to be exactly right — especially fast, loaded, multi-axis or contact-rich motion — this is precisely the layer where that confidence is engineered in. Let's talk about your system.

---

Technical grounding drawn from H. D. Taghirad, Fundamentals of Robotics: Applied Case Studies with MATLAB & Python (chapters on dynamics and linear/nonlinear motion control), with force and impedance concepts from the same work. Notation simplified for a general technical audience.