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" — includes safety-rated functions intended to support collaborative applications, such as monitored stops and configurable speed, force, power, momentum, or workspace limits. The complete application is collaborative only after the integrator assesses the robot, tool, workpiece, process, and foreseeable contact; guarding may still be required. 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 control both position and orientation within much of its reachable workspace, subject to joint limits, singularities, payload, and geometry. 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; it is often efficient for travel through clear space, but the TCP follows a curved path that must be checked for collisions. A linear move (movel) interpolates in Cartesian space so the commanded TCP path is linear within the controller's tolerances, 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, where supported, its centre of gravity. Incorrect data degrades gravity compensation and dynamic calculations and can contribute to poor path tracking or protective stops. It may also invalidate assumptions used in the application safety assessment. Use the robot manufacturer's payload procedure and update the configured load whenever the tool or held part changes.
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
How real robot dynamics differ from commands, how collaborative applications are risk-assessed, 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 compensates for, the safety functions used in a risk-assessed collaborative application, and how to plan routes that reduce 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 has finite path and positioning accuracy. The size and predictability of the tracking error depend on the robot, load, speed, calibration, and operating conditions.
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.
Collaborative operation is a property of the complete application, not the robot arm alone. Depending on the assessed task, the design may use safety-rated monitored stop, hand guiding, speed-and-separation monitoring, or power-and-force limiting, together with other safeguards. Contact sensing or a protective stop cannot guarantee that no harm occurs: sharp tools, trapped body parts, payloads, and stopping distance still matter. ISO 10218 covers industrial robot safety, while ISO/TS 15066 provides guidance for collaborative applications. Configure and validate the actual safety functions, stopping behavior, and contact limits identified by the application risk assessment.
A protective stop is an important response to a detected condition, but frequent stops usually reveal a path, process, configuration, or integration problem that needs correction. 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.
Industrial robotics path
Practise coordinates and commands, connect the robot handshake to PLC state, then validate safety and vendor-specific behavior in the correct tools.