The Math You Need for Robotics, in Order: And What You Can Safely Put Off

• Introduction — "What Math Do I Need First to Get Into Robotics?"
• Linear Algebra — The One Branch of the Six You Can't Defer
• Trigonometry and Rotation Representations — One Function Is Half the Battle
• Calculus and Multivariable Methods — The Jacobian Is a Table of Partial Derivatives
• Differential Equations and Control Theory — Before You Touch a Gain by Hand
• Probability and Estimation — When Sensors Lie
• Optimization — Inverse Kinematics and Trajectory Planning Both Come Down to This in the End
• Putting It in Order — What When, What Later
• Conclusion — The Same Tools Keep Coming Back

Introduction — "What Math Do I Need First to Get Into Robotics?"

There are two common answers to this question. One is "linear algebra and calculus," which is so broad you can't tell where to stop. The other is a list copied straight from a graduate curriculum, and almost nobody who finishes that whole list ever actually starts building a robot.

The problem isn't the list — it's order and depth. Building a robot arm, you hit moments where you need math, and the depth needed at each moment varies enormously. Multiplying rotation matrices takes about a month of first-year undergrad math; understanding why joint velocity diverges near a singularity takes you all the way to singular value decomposition, and the gap between the two is several semesters. Hand someone both of these on the same single list, and they stop at line one.

So this post lays out six branches in order, and for each one writes down three things:

• Exactly where it gets used in a robot arm
• How deep is deep enough
• What you can safely put off for later

The third one matters most. The spot where most people stall out is exactly the moment they lose confidence about whether it's okay to skip something. Marking explicitly what you're allowed to defer is what keeps you moving forward.

This post is the last in a series that runs from robot arm anatomy through forward kinematics and inverse kinematics to the control loop. The previous four posts already did all the actual computing, so this post goes back and looks at what was underneath those calculations the whole time.

Linear Algebra — The One Branch of the Six You Can't Defer

In robotics, linear algebra isn't a tool — it's the language. You can learn the other five branches whenever they become necessary, but not this one. Fail to understand rotation matrices and you can't even read the first line of forward kinematics.

Where it's used. Rotation matrices, homogeneous transformation matrices, the Jacobian, the inertia matrix — all of these are matrices. Attaching a coordinate frame to each link and moving between them is all change of basis. A singularity is exactly the Jacobian's rank dropping, manipulability is defined by singular values, and a redundant robot's null space is, quite literally, a null space.

Broken down by depth:

First, matrix multiplication and vectors. Needed right away. You need to be able to multiply 3x3 and 4x4 matrices by hand, and know in your bones that swapping the multiplication order changes the result. That T01 · T12 and T12 · T01 are different is one fact that, by itself, prevents half of all coordinate-frame sign mistakes.

Second, change of basis. Also needed right away. Get this one concept solid and forward kinematics is essentially done.

Think of a rotation matrix as "an operation that rotates something" and the list of things you have to memorize keeps growing. Instead, read the columns. A rotation matrix's first column is the direction the rotated frame's x-axis points in, expressed in the original frame; the second is the y-axis; the third is the z-axis.

R = [ x̂'  ŷ'  ẑ' ]     <- the new frame's three axes written side by side as columns

So R · p_local means
"take a weighted sum of p_local's components along the new axis directions."

Seen this way, a rotation matrix's properties stop being things to memorize and become obvious. The columns being mutually orthogonal and unit length just means the coordinate axes are orthogonal and unit length, which is why the inverse equals the transpose. It's a table of axes written down, so reading it backward gives you the inverse transform.

Third, rank and null space. Not needed through forward kinematics, needed once you get to inverse kinematics.

If the Jacobian is 6x6 but its rank drops to 5, the direction the end effector can move in shrinks from 6D down to 5D. That one lost direction is exactly the direction you can't move in at a singularity. Conversely, on a 7-joint arm the Jacobian is 6x7, and there's a 1-dimensional null space left over. Move the joints within that null space and the end effector stays put while only the elbow moves. That's exactly the structure redundancy has.

Fourth, singular value decomposition. Needed once you start solving inverse kinematics numerically. And this tool is the workhorse of Jacobian analysis.

SVD splits a matrix into three stages.

J = U · Σ · Vᵀ

V  : the principal axes in joint space of "which combination to move in"
Σ  : how much that combination gets amplified into end-effector velocity (singular values, diagonal)
U  : the principal axes in task space of "which direction the result points"

Why SVD in particular fits the Jacobian becomes clear once you see what the singular values mean. Each singular value is the velocity transfer ratio for that particular direction. A direction with a large singular value means turning the joints a little moves the end effector a lot; a direction with a small singular value means the joints have to turn a lot for the end effector to move a little.

From there, what a singularity is falls out automatically. It's the point where the smallest singular value goes to zero. Moving the end effector in that direction would require infinite joint velocity. The smallest singular value is therefore a natural measure of "how close am I to a singularity," and the ratio of largest to smallest, the condition number, tells you in a single number how balanced the arm's current pose is.

Checking this yourself is faster than reading about it. Let's decompose the Jacobian of a 2-link planar arm — 0.20-meter upper arm, 0.15-meter forearm — while sweeping the elbow angle.

import numpy as np

L1, L2 = 0.20, 0.15


def jacobian(t1, t2):
    """Analytic Jacobian of a 2-link planar arm. Each column is the contribution of one joint."""
    s1, c1 = np.sin(t1), np.cos(t1)
    s12, c12 = np.sin(t1 + t2), np.cos(t1 + t2)
    return np.array([
        [-L1 * s1 - L2 * s12, -L2 * s12],
        [ L1 * c1 + L2 * c12,  L2 * c12],
    ])


def fk(t1, t2):
    return np.array([L1 * np.cos(t1) + L2 * np.cos(t1 + t2),
                     L1 * np.sin(t1) + L2 * np.sin(t1 + t2)])


print(" elbow angle   σ_max     σ_min   condition #")
for deg in [90, 45, 20, 10, 5, 1, 0.1]:
    J = jacobian(np.radians(30), np.radians(deg))
    sv = np.linalg.svd(J, compute_uv=False)
    print(f"  {deg:6.1f}°  {sv[0]:.6f}  {sv[1]:.6f}  {sv[0] / sv[1]:12.1f}")

Here's the output.

 elbow angle   σ_max     σ_min   condition #
    90.0°  0.269451  0.111337           2.4
    45.0°  0.351840  0.060292           5.8
    20.0°  0.375011  0.027361          13.7
    10.0°  0.379341  0.013733          27.6
     5.0°  0.380427  0.006873          55.4
     1.0°  0.380774  0.001375         276.9
     0.1°  0.380789  0.000138        2769.3

As the elbow straightens out, the smallest singular value heads toward zero and the condition number explodes. Shrink the angle from 10 degrees to 1 degree to 0.1 degree, and the condition number climbs in almost exact factors of 10: 27.6, 276.9, 2769.3. That's because the smallest singular value shrinks in near-direct proportion to the angle. The inverse kinematics post's description of a fully extended arm being a singularity is sitting right there in this table, in numbers.

And this is also where damped least squares becomes explainable. The pseudoinverse inverts singular values directly as 1/σ, so it diverges as σ approaches zero. Add damping and it becomes σ / (σ² + λ²), which is nearly the same as 1/σ when σ is large, and smoothly goes to zero as σ approaches zero. At a singularity, instead of going to infinity, it becomes "give up on that direction." Explaining this without SVD would be much harder.

How deep is deep enough. You should be able to multiply and transpose 3x3 matrices by hand, know that a rotation matrix's columns are axes, be able to explain rank and null space in words, and know what each of SVD's three pieces is. The computation itself is handled by numpy.linalg.svd. If you only need the singular values, passing compute_uv as false skips computing U and Vᵀ and runs faster — which is why the code above does it that way.

What you can put off. The axioms of abstract vector spaces, Jordan normal form, cofactor expansion of a determinant, hand-computing Gram-Schmidt orthogonalization, tensor notation. These see essentially no use in a robot arm, or if they ever do become necessary, learning them on the spot is not too late.

Trigonometry and Rotation Representations — One Function Is Half the Battle

This branch is small in volume but produces a lot of mistakes.

Where it's used. The analytic solutions for 2-link and 3-link inverse kinematics are solved with the law of cosines. Rotation representations are about what you store the end effector's orientation as, and how you interpolate it.

Let's start with one function: atan2.

import numpy as np

# atan2(y, x) looks at each sign separately, so it distinguishes quadrants.
print(np.degrees(np.arctan2( 1.0,  1.0)))   #   45.0
print(np.degrees(np.arctan2( 1.0, -1.0)))   #  135.0
print(np.degrees(np.arctan2(-1.0, -1.0)))   # -135.0

# Whereas passing just a single ratio can't tell the 1st and 3rd quadrants apart.
print(np.degrees(np.arctan(1.0 /  1.0)))    #   45.0
print(np.degrees(np.arctan(-1.0 / -1.0)))   #   45.0  <- actually -135 degrees

The bug where a robot arm's shoulder angle suddenly flips 180 degrees mostly comes from exactly this. When computing an angle, don't pass a single divided ratio — pass y and x separately. This one habit alone eliminates a large share of sign-debugging time.

asin and acos have the same kind of trap. Their domain is clipped, so if rounding error pushes an input just barely past 1, you get NaN. This actually happens in code that computes the elbow angle with the law of cosines, right when the target sits at exactly the sum of the link lengths away. You need one line that clips the input.

cos_t2 = np.clip(cos_t2, -1.0, 1.0)   # Without this line, NaN shows up right at the boundary

There are four rotation representations, each used in a different spot.

What this table means in practice is simple. Euler angles at the human-facing boundary, rotation matrices or quaternions for internal computation. And keeping the conversion between them in one single place is what cuts down on sign mistakes.

Euler angle order conventions especially deserve caution. The same three numbers mean a different rotation depending on the convention. If a pose looks wrong after mixing two libraries, check the convention first.

How deep is deep enough. Reach for atan2 reflexively, be able to solve a triangle with the law of cosines, and for quaternions, know that "multiplying composes rotations, you need to keep them normalized, and interpolation uses slerp" — that's enough. You don't need to derive quaternion algebra.

What you can put off. The algebraic construction of quaternions, Lie groups and Lie algebras, the exponential and logarithm maps, screw theory. These become very useful later, especially for keeping optimization-based control clean, but you don't need them to move your first arm. They read far more easily once you've built one serial arm all the way through.

Calculus and Multivariable Methods — The Jacobian Is a Table of Partial Derivatives

Where it's used. It's essentially all Jacobian. And the Jacobian shows up three separate times in a robot arm: in the velocity relationship, in the force relationship, and in the linearization step of an extended Kalman filter.

The name "Jacobian" sounds intimidating, but the substance is simple. It's a table of partial derivatives of each output with respect to each input, laid out in a grid.

If the end-effector position is (x, y) and the joints are (θ1, θ2),

J = [ ∂x/∂θ1   ∂x/∂θ2 ]
    [ ∂y/∂θ1   ∂y/∂θ2 ]

column j = "the direction and magnitude the end effector moves when only θj spins at 1 rad/s"

Build the habit of reading columns this way and the Jacobian becomes something you can hold in your hands. In a fully extended pose, the two columns end up pointing almost the same direction, so the range of directions those two columns can reach narrows — and that's exactly the phenomenon from the earlier section where the smallest singular value goes to zero. You can see the same fact through partial derivatives or through SVD.

There's a practical habit worth building here. Once you've derived an analytic Jacobian, always cross-check it with numerical differentiation. A Jacobian with a single wrong sign sends IK converging in a completely wrong direction, and the symptom only shows up as "it converges slowly," which makes the cause hard to find.

def numeric_jacobian(f, q, eps=1e-6):
    """Approximates the Jacobian using central differences. For checking an analytic derivation."""
    q = np.asarray(q, dtype=float)
    base = f(*q)
    J = np.zeros((len(base), len(q)))
    for j in range(len(q)):
        dq = np.zeros_like(q)
        dq[j] = eps
        J[:, j] = (f(*(q + dq)) - f(*(q - dq))) / (2 * eps)
    return J


q = np.radians([30.0, 40.0])
Ja = jacobian(*q)
Jn = numeric_jacobian(fk, q)

print("Analytic Jacobian:\n", np.round(Ja, 8))
print("Numeric Jacobian :\n", np.round(Jn, 8))
print("Max error        :", np.max(np.abs(Ja - Jn)))

Here's the output.

Analytic Jacobian:
 [[-0.24095389 -0.14095389]
 [ 0.2245081   0.05130302]]
Numeric Jacobian :
 [[-0.24095389 -0.14095389]
 [ 0.2245081   0.05130302]]
Max error        : 2.6600312230673495e-11

An error around 1e-9 means the derivation is correct; an error around 1e-2 means something's wrong somewhere. A value in between usually means you mixed up units (degrees and radians) rather than getting a sign wrong.

The chain rule shows its true colors here too. On a 6-joint arm, the end-effector position is a composite function of six angles, and finding the Jacobian is differentiating that composition. The differentiation chains together in the same structure as multiplying the frames together.

How deep is deep enough. Be able to compute partial derivatives, use the chain rule, know that the gradient points in the steepest-ascent direction, and be able to check your work with numerical differentiation. Deriving an analytic Jacobian by hand is worth doing up through 2-link and 3-link arms to get the feel for it. Leave a 6-link arm to a library.

What you can put off. Differential geometry, calculus on manifolds, calculus of variations, tensor calculus. And integration turns out to see surprisingly little use. The places integration shows up in a robot arm are PID's I-term and a trajectory's accumulated quantities, and both of those get implemented as discrete sums, so you'll never need analytic integration techniques.

Differential Equations and Control Theory — Before You Touch a Gain by Hand

Where it's used. Why the arm jerks, why PID's three terms do what they do, why the control period eats away at stability — all of this is this branch.

A robot arm's equation of motion looks like this.

M(q)·q̈  +  C(q, q̇)·q̇  +  g(q)  =  τ

M(q)      inertia matrix — varies with pose
C(q, q̇)  Coriolis and centrifugal forces — proportional to velocity squared
g(q)      gravity term — depends only on pose
τ         joint torque — the thing we're producing

You don't need to solve this equation. But you do need to be able to read it. Three things stand out. First, inertia isn't a constant — it's a function of pose, which is why gains tuned well with the arm folded stop working once it's extended. Second, there's a term proportional to velocity squared, so nonlinearity grows the faster you move. Third, the gravity term is always there regardless of velocity, which is why feeding it forward ahead of time takes a large load off feedback.

What you actually need to get your hands on in control theory is a single second-order system.

Standard form:   ẍ  +  2ζωn·ẋ  +  ωn²·x  =  ωn²·u

ωn  natural frequency — how fast
ζ   damping ratio     — how it arrives

ζ < 1   underdamped, overshoots and comes back (overshoot)
ζ = 1   critically damped, fastest without overshooting
ζ > 1   overdamped, creeps in slowly

A single joint with a PD controller takes exactly this form. The P gain maps to ωn², and the D gain maps to 2ζωn. Once you see that, gain tuning takes on a different meaning. Instead of fumbling with two numbers by feel, it becomes: decide "how fast (ωn) and in what manner (ζ) should it arrive," then convert that into gains.

Knowing this mapping lets you diagnose common symptoms immediately. Large overshoot means ζ is small — raise D. Slow with no overshoot means ωn is small — raise both P and D together. Raise P alone and it gets faster but ζ drops, producing overshoot. This relationship is exactly the background behind the gain-tweaking done in the control loop post.

The delay problem shows up here too. A long control period or a sensor filter introduces lag, and feedback ends up reacting to a stale error — which means the phase has shifted backward. As phase margin shrinks, even a small gain increase causes oscillation. The experience of "doubling the sampling rate let me push the gains higher" is a direct consequence of this theory.

How deep is deep enough. Be able to look at the second-order standard form and read off ζ and ωn, know how that maps to PD gains, and know that delay eats into phase margin. For the Laplace transform, it's enough to know "differentiation becomes multiplication" and that pole locations determine the response.

What you can put off. State-space optimal control (LQR), robust control, Lyapunov stability proofs, rigorous application of the Nyquist criterion, adaptive control. These become necessary once you're turning a robot arm into a product, but PD plus gravity compensation gets you remarkably far in the early stages of just getting an arm moving.

Probability and Estimation — When Sensors Lie

Where it's used. An encoder is quantized, an IMU drifts, and vision wobbles with lighting. This branch is about deciding what to trust when several sensors' readings disagree.

This branch is needed later than the other four. An arm doing only position control with a single encoder and just trusting its value generally gets by fine. Probability tends to become necessary once you're past a single sensor — mounting a camera on the arm, adding an IMU, adding a force sensor.

Three concepts are the core of it.

First, how to write down uncertainty as a number. Instead of a single measured value, you deal with a pair: mean and variance. In multiple dimensions this becomes a covariance matrix, and that matrix is an ellipse describing how much uncertainty spreads in which direction. Linear algebra comes back here — a covariance matrix's eigenvectors are the ellipse's axes, and the eigenvalues are the axis lengths.

Second, propagating uncertainty. Compute forward kinematics from an inaccurate joint angle and the end-effector position is inaccurate too. How inaccurate is computed with the Jacobian.

When the joint angle covariance is Σq, the end-effector position covariance is

Σx  ≈  J · Σq · Jᵀ

The Jacobian shows up again. This is exactly why this post said the Jacobian shows up three times. And this equation states something practically important: near a singularity, the Jacobian amplifies heavily in a particular direction, so the same encoder error turns into a much bigger error at the end effector. A singularity isn't only a speed problem — it's also a precision problem.

Third, the Kalman filter. The name sounds intimidating, but in one dimension it's a single line. When a prediction and a measurement each carry their own uncertainty, you take a weighted average by precision (the reciprocal of variance).

Prediction:  x̂ = 5.0,  variance = 4.0   (precision 0.25)
Measurement: z  = 6.0,  variance = 1.0   (precision 1.00)

Weight = 1.00 / (0.25 + 1.00) = 0.8       <- this is the Kalman gain
Updated value = 5.0 + 0.8 × (6.0 - 5.0) = 5.8
Updated variance = 1 / (0.25 + 1.00) = 0.8       <- smaller than either one alone

The measurement was more accurate, so the result moved more toward it, and combining two pieces of information reduced the uncertainty. That's the whole story. A multidimensional Kalman filter is this same calculation done with matrices, and an extended Kalman filter linearizes the nonlinear model every step with the Jacobian and runs the same calculation.

How deep is deep enough. Understand a Gaussian's mean and variance, have a feel for a covariance matrix as an ellipse, and be able to do the 1D Kalman update above by hand. Use a library for the actual implementation, but you do need to know what the tuning parameters — process noise and measurement noise — actually mean.

What you can put off. Particle filters, factor graphs and graph SLAM, the theoretical foundations of Bayesian inference, information filters, unscented Kalman filters. And if you're only dealing with a robot arm, you can put off SLAM entirely. SLAM is a mobile-robot problem and doesn't show up on an arm with a fixed base.

Optimization — Inverse Kinematics and Trajectory Planning Both Come Down to This in the End

Where it's used. The point of this branch is that everything learned separately up to now comes together under one framework.

Numerical inverse kinematics is a least-squares problem. It finds the joint angles that minimize the difference between the target position and the current position. Damped least squares adds a penalty on joint-velocity magnitude on top of that — it's regularized least squares. The same structure machine learning calls ridge regression.

Ordinary least squares: minimize  ‖J·Δq - Δx‖²
Damped least squares:   minimize  ‖J·Δq - Δx‖²  +  λ²·‖Δq‖²
                                                     └── this term prevents divergence

Trajectory planning is optimization too. A minimum-jerk trajectory is the result of minimizing the integral of squared jerk, and a time-optimal trajectory is the result of minimizing time subject to torque and velocity limits. Deriving the 5th-order polynomial in the control loop post is the same kind of problem in the sense that it picks the smoothest function among those satisfying six boundary conditions.

The modern standard shape for arm control is solving velocity-level inverse kinematics as a quadratic program (QP). The objective is moving the end effector at a target velocity, and the constraints — joint angle limits, joint velocity limits, collision avoidance — go in as inequalities. It's a way of bundling together things that used to be handled one at a time into a single problem.

Three concepts are worth knowing here.

The difference between convex and non-convex. In a convex problem, a local solution is the global solution, so you land in the same place no matter where you start. Least squares and QP fall into this category. Position-level inverse kinematics, on the other hand, is non-convex, so it lands on different solutions depending on the initial guess — that's exactly the situation where an elbow-up solution and an elbow-down solution are both correct answers. In a non-convex problem, the initial guess is part of the algorithm. This is why using the previous pose as the initial guess matters.

What regularization means. Raise the penalty term's coefficient and the solution gets smaller and more stable, but tracking the target gets worse. Tuning damped least squares' damping coefficient is exactly this tradeoff, and only increasing damping near a singularity is adjusting where that tradeoff sits based on the situation.

Constrained versus unconstrained problems. Putting a joint limit in as a penalty is different from putting it in as an inequality constraint. A penalty allows a solution that slightly exceeds the limit; a constraint doesn't. On real hardware, exceeding a joint limit means physically crashing into something, so the constraint approach is the correct one.

How deep is deep enough. Be able to write a least-squares problem as normal equations, know what a regularization term does, know how convexity relates to initial-guess dependence, and know how gradient descent works. Use a library for the QP solver.

What you can put off. Implementing an interior-point method, deriving duality theory and the KKT conditions, the details of sequential quadratic programming (SQP), comparing direct and indirect methods for trajectory optimization. These matter if you're building your own solver or writing a paper. To move an arm, knowing how to call a solver is enough.

Putting It in Order — What When, What Later

Folding the six branches into a single table looks like this. The further left, the sooner it's needed, and the right-hand column is the most important part of this post.

If you pick just one textbook, I'd recommend Kevin Lynch and Frank Park's Modern Robotics: Mechanics, Planning, and Control. A preprint PDF, video lectures, and Python/MATLAB/Mathematica implementations are all freely available, so wherever you get stuck in the table above, you can jump straight to the matching chapter. That said, this book is structured around screw theory up front, so you'll run into this table's "put off for later" column before anything else. On a first pass, it's fine to skip that part and pick only the chapters you actually need.

The most common mistake is trying to finish this table top to bottom before starting on a robot. Doing it backward is much faster. Take just the first two rows, get a 2-link arm moving, watch the arm go haywire at a singularity with your own eyes, and then read the fifth row — you'll understand it that same day. Learning something after the need has appeared and learning it while imagining the need are absorbed at completely different rates.

And I'd ask you to look again at the "what to put off" column. Every item in that right-hand column, without exception, takes up a large share of an undergraduate curriculum. Lie groups, LQR, KKT conditions, particle filters. That doesn't mean they're unnecessary — it means you can build a working arm without them. And someone who's already built a working arm once reads through that list far faster, because by then it's obvious which problem each item solves.

Conclusion — The Same Tools Keep Coming Back

Writing this post confirmed one more thing for me. Even though it's organized into six branches, in practice it's really just a handful of tools showing up again and again.

The Jacobian first appears in the velocity relationship, appears again in the force relationship, appears again in error propagation, and appears yet again in an extended Kalman filter's linearization. SVD explains singularities, defines manipulability, explains why damped least squares works, and tells you a covariance ellipse's axes. Least squares is inverse kinematics, and trajectory planning, and filtering, all at once.

That decides the learning strategy too. You're better off going deep on the tools that show up often than skimming broadly. Understanding the Jacobian in four different contexts takes less time and stays with you longer than learning those four places separately.

And the highest-value part of this post's list isn't the front — it's the back, the things you're allowed to defer. Deciding what NOT to learn moves you forward more than deciding what to learn. Far more people never start robotics because they tried to learn everything first than people who couldn't start because they didn't know enough math.

To put it in one line — matrix multiplication and atan2 alone are enough to get an arm moving. Learn the rest when the arm starts doing something strange.