A structured robotics learning path in five stages. Each stage teaches a concept in plain language, then drops you straight into a browser simulator to do it on a real robot — from your first jog to multi-robot programming, vendor languages, dynamics and safety. No install. No robot. No vendor license. Stage 1 is free.
How the path works
You do not learn robotics by reading the manual — you learn it by moving a robot and seeing what happens. This path follows the order that works. Every stage opens with a short, plain-language explainer of what it covers and why it matters, then links you straight into the simulator lessons that practise it. You learn the idea, then immediately do it. The teaching below is open for everyone to read; the hands-on lessons from Stage 2 on are part of Pro, and clicking any Pro lesson takes you to the simulator where access is handled.
What a robot arm actually is — and how to move it by hand before you write a line of code.
Before you program a robot you need a clear mental model of what you are programming. This stage builds that model: what an industrial robot and a collaborative robot (cobot) are, how an arm is just a chain of rigid links joined by motors, and the two coordinate frames every command lives in. Then you jog — move the arm by hand with the control panel — so the abstract ideas connect to real motion before you automate anything.
An industrial robot is a programmable, multi-axis machine built to move a tool or part through space precisely and repeatably. Traditional industrial robots are fast and powerful but work fenced off from people, because a collision could injure someone. A collaborative robot — a "cobot" — is designed to share a workspace with humans: it moves more slowly, senses contact forces, and stops the instant it pushes against something unexpected. Same core idea, different safety envelope. The simulator you are about to use models a UR5e, one of the most common cobots in the world.
Mechanically, an arm is a chain of rigid segments called links, connected by motorised joints. Each joint adds one controllable axis of motion — one "degree of freedom" (DOF). A typical articulated arm has six joints, giving it six degrees of freedom: enough to place its tool at any reachable position AND in any orientation. Joints come in two flavours. A revolute joint rotates (like your elbow); a prismatic joint slides in a straight line (like a drawer). Most arm joints are revolute, but you will meet prismatic axes later in SCARA, Cartesian and other machines.
Every position you command is measured relative to a coordinate frame — a set of X, Y, Z axes with an origin. Two frames matter most. The base frame is bolted to the robot's foot; it never moves, so it is the fixed reference for the whole workspace. The tool frame rides on the end of the arm and moves with it. The single most important point in robotics is the Tool Center Point (TCP): the exact spot at the tip of the tool that you actually want to position — the centre of a gripper's fingers, the tip of a welding torch. When you tell the robot "go to this pose," you are commanding the TCP. Define the TCP wrong and every move is off by the same offset.
There are two ways to think about where the arm is. In joint space you specify the angle of every joint directly — six numbers for a six-axis arm. In Cartesian space you specify where the TCP sits in X, Y, Z (plus orientation) and let the robot solve which joint angles achieve it. Both describe the same arm; they are just different languages for it. Jogging is driving the arm manually with the control panel — nudging one joint at a time, or sliding the TCP along X, Y or Z — while you watch the live pose readout. You jog first because it builds intuition for free: you feel how each joint swings the tool, you see joint space and Cartesian space describe the same motion, and you learn the workspace before a single typo can crash anything.
Key takeaways
Practise it in the simulator
Motion types, waypoints, frames and I/O — the four things every robot program is built from.
A robot program is mostly four ingredients: moves, the path between them, the frame you work in, and the I/O that drives the tool. Get these four right and you can write almost any routine. This stage teaches the difference between joint and linear moves, how to chain them smoothly through waypoints, how to set the tool centre point so moves land where you mean, and how digital I/O lets the program act on the world — closing a gripper, reading a sensor.
There are two fundamental move commands, and choosing between them is a real engineering decision. A joint move (movej) interpolates in joint space: every joint starts and stops together, which is fast and easy on the motors, but the TCP traces a curved, hard-to-predict path through space. A linear move (movel) interpolates in Cartesian space: the TCP travels in a perfectly straight line, which the robot achieves by continuously solving for the joint angles along the way. Rule of thumb: use movej to get across open space quickly when the exact path does not matter, and movel when the tool must follow a straight line — approaching a part, inserting a peg, laying a bead — or must avoid sweeping through something.
A waypoint is simply a target pose along a path; a program is a sequence of moves from one waypoint to the next. By default the arm decelerates to a full stop at each waypoint, which is precise but slow and jerky for a long path. A blend (also called a zone or blend radius) lets the arm round the corner: instead of stopping dead at a via point, it flows through a sphere around it and carries on, trading a little positional accuracy at that point for much smoother, faster motion. You stop sharply where accuracy matters (picking, placing) and blend through the in-between via points.
In Stage 1 you met the Tool Center Point. Here you set it. A pose written p[x, y, z, rx, ry, rz] is measured from the base frame, but where the robot puts that pose depends on where you have told it the tool tip is. set_tcp declares the offset from the arm's flange to the working point of your tool. Mount a 120 mm gripper and you tell the robot the TCP is 120 mm out along the tool axis — now every move positions the fingertips, not the bare flange. Working in the right frame, with the right TCP, is what makes a pose mean what you intend.
Moving is only half a job; a robot also has to grab, release, clamp and sense. Digital I/O is how it does that. A digital output is a signal the robot drives high or low — set_digital_out(0, True) energises output 0 to, say, close a gripper or fire a vacuum; False releases it. A digital input is a signal the robot reads — a part-present sensor, a limit switch, a ready signal from a conveyor. The pattern that runs the world is: move to the part, set an output to grasp it, move away, set the output to release. Once you can move, blend, frame and toggle I/O, you have the whole vocabulary of a real routine.
Key takeaways
Practise it in the simulator
Assemble the four ingredients into the workhorse of industry: a complete pick-and-place cycle.
Pick-and-place is the single most common robot task on Earth — loading machines, packing boxes, tending lines. This stage assembles the moves and I/O from Stage 2 into a complete, reliable cycle, and adds the one configuration step beginners always forget: telling the robot how heavy its load is so it moves accurately and stops safely.
A robust pick-and-place is not "go to the part, grab it, go to the bin." It is a careful sequence: APPROACH a safe point directly above the part, descend straight down with a movel, CLOSE the gripper on the part, RETRACT straight back up before moving sideways (so you do not drag the part across a fixture), TRAVERSE across to the place location — often a fast movej through clear space — descend, OPEN the gripper to release, and retract again. The approach-and-retract moves are what make it reliable: they keep the part and gripper clear of edges during the grab and the release, which is exactly where naive routines crash.
A robot's motion controller is constantly predicting the forces it needs to apply to follow your path. That prediction depends on how much mass is hanging off the end of the arm — the gripper plus whatever it is holding. set_payload tells the robot that mass (and ideally where its centre of gravity sits). Get it wrong and two things go bad. Too low, and the arm under-drives the motors: it droops and lags under a heavy part, missing positions. Too high, and it over-drives. Worse, on a cobot the payload setting is what lets the safety system tell a real collision apart from the expected weight of the part — so a wrong payload causes nuisance protective stops or, dangerously, masks real ones. Update the payload whenever the load changes: empty gripper, then heavier with a part.
The capstone of this stage is a full routine you assemble yourself: set the payload, approach and pick the block, retract, traverse, place it on the target, and release — with no collisions. This is the moment the individual skills become a program that does real work. Everything after this stage is variation on this theme: other robot shapes, other languages, and the dynamics and safety that make it production-ready.
Key takeaways
Practise it in the simulator
Beyond the six-axis arm — SCARA, Cartesian and delta robots, and why your skills transfer across vendors.
The six-axis articulated arm is the most versatile robot, but it is not the only — or even the best — shape for every job. This stage tours the other major mechanisms: SCARA, Cartesian/gantry and delta robots, each with a geometry tuned for a kind of work. Then it makes a liberating point: the concepts you have learned transfer across every vendor's language. Once you can think in moves, frames and I/O, picking up RAPID, KRL or TP is mostly learning new syntax for ideas you already own.
A SCARA (Selective Compliance Assembly Robot Arm) has two parallel revolute joints that sweep the tool around in a horizontal plane, plus a vertical prismatic axis that drops straight down, and a wrist rotation — four axes in all. It is rigid vertically but compliant horizontally, which is exactly what you want for dropping parts into holes and fast surface-mount assembly. SCARAs dominate high-speed planar pick-and-place where everything happens at one working height.
A Cartesian (or gantry) robot is three orthogonal linear axes — X, Y and Z carriages that slide in straight lines — usually with a tool rotation on the end. Because the axes are linear, a target XYZ maps almost directly onto the carriages, motion is dead straight, and the working envelope is a simple rectangular box that can be made enormous. Gantries are the go-to for large, heavy or wide-area work: palletising, CNC loading, 3D printing, machine tending over a big table.
A delta robot is a parallel mechanism: three light arms hang from an overhead base and work TOGETHER to drive a single small platform, with parallelogram linkages keeping that platform perfectly level. Because the heavy motors stay fixed up at the base and only the feather-light arms move, a delta accelerates ferociously — it is the king of high-speed, lightweight picking, flicking hundreds of small parts a minute off a conveyor. The trade-off: a small workspace and low payload.
Every robot vendor has its own programming language, and beginners assume that means starting over each time. It does not. A linear move is a linear move; closing a gripper is setting a digital output; a pose is a pose. Only the syntax changes. Universal Robots use URScript (movel, set_digital_out). ABB uses RAPID (MoveL, SetDO). KUKA uses KRL (PTP, $OUT[1]=TRUE). FANUC programs on the teach pendant in TP (J P[1], DO[1]=ON). In this stage you write the SAME pick-and-place in several of these languages and watch the identical motion play out. That is the real lesson: master the concepts and you are vendor-independent — you read any robot's manual and map its keywords onto ideas you already understand.
Key takeaways
Practise it in the simulator
Why real robots don't perfectly obey, how cobots keep people safe, and earning your certificate.
Everything so far has treated the robot as if it follows commands perfectly. Real machines do not — they have mass and inertia, they droop under load, and they collide with things. This final stage teaches the physics the controller fights against, the safety systems that make a cobot fit to work beside a person, and how to plan routes that never trip a protective stop. Finish it and you earn the Robot Programming certificate.
A robot has real mass, and Newton applies. Gravity pulls the arm and its payload down, so a horizontally extended arm sags — "droop" — unless the motors actively hold it up. Inertia resists changes in motion, so the arm cannot start or stop instantly; the heavier the payload and the faster the move, the more it lags behind the commanded path. This is why a real robot never perfectly tracks your program: there is always a small, predictable gap between where you told it to be and where it is.
The controller closes that gap with a feedback loop running hundreds of times a second. It measures each joint's actual position, compares it to the commanded position, and drives the motors to cancel the error. On top of that it runs a dynamic model — using exactly the payload you configured in Stage 3 — to predict and pre-compensate for gravity and inertia BEFORE the error appears. Good payload data makes that model accurate; bad data makes the robot lag, overshoot, or nuisance-stop. This is the deep reason payload configuration mattered: it feeds the very model that keeps motion true.
A cobot earns the right to work next to people through layered safety. It monitors the force and torque at every joint; if it pushes against something harder than expected — a fixture, a hand — it triggers a protective stop, halting in milliseconds before it can do harm. It also runs under speed and force limits that cap how fast and how hard it may move in collaborative zones. The relevant standards name these ideas plainly: ISO 10218 covers industrial robot safety, and ISO/TS 15066 specifically defines collaborative operation — including the force and pressure limits that keep contact with a person below the threshold of injury. You do not memorise the numbers; you design so the robot stays within them.
The best protective stop is the one that never fires, because a protective stop in production means downtime. The safety lessons in this stage put a fixture in the cell and ask you to reach the goal without hitting it — and a naive straight movel slams right through. The fix is to plan the path: swing wide in joint space with a movej, or lift up and over with the gantry's vertical column, or step the delta's platform sideways and traverse clear. Each mechanism dodges in the way its geometry allows. Route planning is the skill that turns a program that merely works into one that runs all day.
Completing every lesson — foundations, your first programs, pick-and-place, the robot types and vendor languages, and these dynamics-and-safety challenges — earns you the Robot Programming certificate. It marks that you can model an arm, choose the right move, configure payload, work across mechanisms and languages, and plan safe, collision-free motion: the working foundation of an industrial robot programmer.
Key takeaways
Practise it in the simulator
Completing every lesson across all five stages earns the Robot Programming certificate — a verifiable record that you can model an arm, choose the right move, configure payload, work across mechanisms and languages, and plan safe, collision-free motion.
Keep exploring
Learn robotics step by step in your browser — concept first, then hands on a real simulated robot. Stage 1 is free; go Pro for the full path and a certificate.