By Sarah Xiao 
Most people learn robotics algorithms the way a syllabus presents them: math first, then kinematics, then control, then perception, then something called “embodied AI” at the end. The order is defensible and almost entirely wrong in practice, because the field is not a sequence of courses. It is a set of layers that keep referring back to each other.
The map below, circulating in Chinese and English robotics circles, makes the structure visible. Mathematics sits at the centre, not because it is the first thing to study, but because every other branch reaches back into it. Around it sit kinematics and dynamics, control and planning, perception and SLAM, and then the newer branches — reinforcement learning, vision-language-action models, world models.
What follows is a reading of that map as an engineering stack — what each layer actually answers, where the layers break, and why learning them in order tends to produce people who can derive a Jacobian but cannot make a joint stop oscillating.
Mathematics is the substrate, not the entrance exam
Calculus, linear algebra, probability. Every robotics problem turns out to be one of these three wearing a different costume.
Coordinate transforms are matrix multiplication. A pose is a homogeneous transform, a chain of joints is a product of transforms, and getting the order wrong is the single most common bug in a robot codebase. Kinematic modelling is differentiation: the Jacobian is the derivative of position with respect to joint angle, J = ∂f/∂q. State estimation is probability: a Kalman filter is a Gaussian conditioned on new evidence, and a particle filter is the same idea without the Gaussian assumption. Optimal control is a cost function with constraints, minimised over a horizon.
The reason this layer sits at the centre rather than the bottom is that a working engineer revisits it constantly. When a planner produces a trajectory the controller cannot track, the fix is usually not in the planner — it is a units error in a transform, or a sign convention, or a covariance that was never updated.
Kinematics and dynamics: what moves, and why it resists
Kinematics answers “where is the tool, and how fast is it moving”. Forward kinematics composes transforms; inverse kinematics solves for joint angles given a pose, which is where redundancy and singularities appear. The Jacobian maps joint velocity to end-effector velocity, v = J(q) q̇, and its transpose maps end-effector force back to joint torque, τ = Jᵀ F. At a singularity the Jacobian loses rank: the arm cannot move in some direction no matter how fast the joints turn, and joint velocities blow up as you approach it. Every six-axis arm has these configurations, and every production cell either avoids them in the layout or handles them in software.
Dynamics answers “why does it move that way”. The standard form is
M(q) q̈ + C(q, q̇) q̇ + g(q) = τ
with inertia, Coriolis and centrifugal terms, and gravity. This is where the gap between simulation and hardware opens. A trajectory that looks smooth in a rigid-body simulator will show lag, overshoot and chatter on the real machine, because the real machine has friction that depends on direction and temperature, compliance in the reducer, backlash, and actuators with finite current and thermal limits.
The practical consequence: a controller tuned in simulation is a starting point, not a result. System identification — measuring friction, inertia and delay on the actual hardware — is what closes the gap, and it is usually the least glamorous and most valuable work in the project.
Control and planning: the two questions people conflate
Control asks “how do I hold this trajectory”. Planning asks “which trajectory”.
The control layer is a cascade. Current loop innermost, typically in the tens of kilohertz; velocity loop next, around one to two kilohertz; position loop outermost, around one kilohertz. Each loop assumes the one inside it is fast enough to be treated as ideal, which is why a sluggish inner loop cannot be fixed by tuning the outer one. PID remains the workhorse — u = Kp e + Ki ∫e dt + Kd de/dt — and most of the field’s practical knowledge is about what happens when the three terms fight each other: integral windup during a stall, derivative action amplifying encoder noise, gain scheduling as the arm changes configuration.
Frequency-domain analysis is what turns tuning from folklore into procedure. A Bode plot of the closed-loop response shows the bandwidth and the phase margin; a resonance from a flexible joint shows up as a peak that no amount of gain will fix; system identification gives you the plant model you need to design anything beyond a PID.
Planning splits into two questions that are often merged in conversation and never merged in code. Path planning is geometric: RRT and PRM sample a configuration space and return a collision-free path, and neither knows or cares about time. Trajectory planning assigns time: velocity and acceleration limits, jerk limits, blending between segments. Model predictive control sits above both and re-solves a constrained optimisation over a receding horizon,
min Σ cost(xₖ, uₖ) subject to xₖ₊₁ = f(xₖ, uₖ), constraints
which is powerful exactly to the extent that the model inside it is right. MPC on a bad model produces confident, wrong motion.
Perception and SLAM: the layer that decides whether any of it is usable
A robot that knows how to move but not where it is will move into a wall.
Perception turns sensor data into state: detection, segmentation, 3D reconstruction, sensor fusion. The hard part is rarely the model — it is time synchronisation, calibration, and the fact that a camera and a lidar disagree about where the world is by a few centimetres. SLAM adds mapping, localisation and loop closure on top; loop closure is what keeps drift from accumulating without bound when a robot revisits a place.
There is a reason the map draws perception as a peer of control rather than a preprocessing step: without reliable localisation, the best controller in the world is executing a trajectory in the wrong frame.
RL, VLA and world models: the branches that changed the job description
Reinforcement learning reframes control as policy search. Instead of designing a controller, you define a reward and let the policy improve by interaction — PPO, value functions, exploration, and then the Sim2Real problem, which is that a policy trained in a simulator will exploit whatever the simulator got wrong.
Vision-language-action models put a different interface on top: images plus a natural-language instruction in, action chunks out. Their appeal is that the task specification stops being a hand-coded state machine. Their weakness is the same as any learned model — the failure cases are not enumerable in advance.
World models go one step further and learn the dynamics themselves, then use that learned model for prediction or for training a policy inside it. This is the branch that has produced the most striking efficiency results of the past year, and also the branch where the caveats matter most: a learned model is only valid where it has data.
None of these replace the earlier layers. A VLA model still outputs actions that a joint controller has to track; an RL policy still runs on hardware with backlash; a world model still needs a state estimator to tell it where the robot is.
Why the ladder order fails
Taught as a ladder, the layers produce a predictable failure pattern: someone can implement an MPC solver and cannot explain why the robot vibrates at a particular frequency; someone can train a policy in simulation and cannot debug why it falls over on the real machine.
Taught as a map, the questions get asked in the right order. For any new robot behaviour, the useful sequence is:
- What state do I need to know, and can I measure it? (perception, estimation)
- What motion produces the behaviour, and is it reachable? (kinematics, planning)
- What forces are required, and can the hardware deliver them? (dynamics, actuator limits)
- How do I hold it against disturbance? (control)
- Only then: can learning do this better than the model-based version?
Most projects that fail at step 5 actually failed at step 1 or 3 and blamed the algorithm.
What the map leaves out
Three things, and they matter more in production than any branch on it.
Real-time behaviour. Algorithms are usually taught as if compute were free. On a robot, a control loop that misses its deadline is not slower — it is unstable. Deterministic scheduling, jitter budgets and worst-case execution time belong in the same conversation as controller design.
Safety. Torque limits, speed limits, workspace limits, emergency stop, and the difference between a fault that stops the robot and a fault that makes it move unexpectedly. None of this appears on the map; all of it decides whether the robot ships.
Integration. Calibration, time sync, message latency, coordinate frame conventions, log replay. The reason robotics projects take longer than the algorithm work suggests is almost always here.
The short version
The map is right, and the most useful thing about it is that nothing on it is optional. Mathematics is not a gate you pass once; it is the layer you return to when something downstream misbehaves. Kinematics and dynamics tell you what is possible, control and planning make it repeatable, perception and SLAM make it valid in a real place, and the learning branches extend the range of behaviours you can specify.
Learn the map, then go deep where your project actually lives. The people who are effective at this are not the ones who finished the ladder; they are the ones who know which layer is lying to them.