ROS 2 & Robotics

It is not an operating system and it is not a robot control system. It is a communication middleware plus a set of conventions and tooling, and the algorithms that make a robot work are libraries on top of it. Getting that straight prevents the most common disappointment — expecting the framework to make the robot do something — and the comparison with ROS 1 is worth making explicitly, because the removal of the central master and the move to a distributed discovery layer is why the rest of the system behaves as it does.

🔴 Second, not tenth, because this is where almost everyone stalls. The workspace layout, the build tool, and the source-your-environment step that is invisible until it is missing — 'the package cannot be found' is the single most reported beginner problem and it is almost always an unsourced overlay or a stale build. A Skill element: the outcome is a workspace you can build, extend and debug, demonstrated rather than described.

A node is a process participating in the graph, and the part that gets glossed over is how its callbacks are actually scheduled. Single-threaded and multi-threaded executors, callback groups, and the reentrancy rules matter the moment a node does two things at once — and the resulting deadlock, where a service call inside a callback waits forever, is a rite of passage that this unit exists to skip.

🔴 The most important unit in the first half. Publish-subscribe is easy to demonstrate and quality-of-service settings are where real systems silently fail: a publisher and a subscriber with incompatible reliability or durability policies simply never connect, with no error and no warning. Anyone who will debug a real ROS 2 system needs the compatibility rules explicitly, not as an advanced topic.

The two request-shaped interaction patterns, and the judgement of which to reach for. A service is a blocking call that should return quickly; an action is a long-running goal with feedback and the ability to cancel — which is what almost every physical robot behaviour actually is, because moving takes time and might fail partway. Using a service where an action belongs is a design error that surfaces as an unresponsive robot.

Configuring a node at runtime rather than hardcoding it, with typed parameters, declared defaults and change callbacks. Lifecycle nodes belong here too: managed nodes with explicit configure, activate and deactivate transitions, which is how a serious system brings hardware up in a controlled order instead of hoping start-up races resolve favourably.

A real robot is dozens of nodes with hundreds of parameters, remappings and namespaces, and starting them by hand is not viable. Launch descriptions, composition, namespacing for multi-robot systems, and configuration files. This is the unit that separates a demo from a system, and it is a Skill because the outcome is a launch setup that reliably brings a whole stack up.

The tooling that makes an opaque distributed system observable: listing and echoing the graph from the command line, the graphical tools, and — the one worth the most — recording and replaying data, which turns an intermittent field failure into a reproducible desk problem. Placed before the harder subsystems deliberately, so the units that follow can be debugged rather than guessed at.

🔴 The conceptual pivot of the whole path. Robotics is mostly the bookkeeping of where things are relative to each other, and the transform system is how that bookkeeping is published and queried through time. Get it wrong and every downstream subsystem — description, simulation, perception, navigation, manipulation — is wrong in a way that looks like a hardware fault. Everything after this unit depends on it, which is why it sits here rather than later.

The machine-readable model of links, joints, geometry and inertia that publishes the transform tree from unit A9 and feeds simulation, collision checking and control. Covers the macro language that makes a description maintainable rather than a thousand lines of repeated markup, and the visual-versus-collision geometry distinction that quietly determines both rendering cost and planning behaviour.

Simulation is how you develop without breaking hardware, and it is also a confidence trap. Covers getting a described robot into a simulator with plausible sensors, and — the part that matters — where the simulation is systematically optimistic: contact and friction, sensor noise, latency, actuator dynamics, and compute timing. The transferable skill is knowing which results transfer.

The framework layer that stands between controllers and actual motors: hardware interfaces, controller managers, and the real-time constraint that makes this part of the system different from the rest. This is where the abstraction meets a physical device that will not wait, and where the difference between a demo running at whatever rate it manages and a control loop with a deadline becomes real.

Getting real sensor data into the graph correctly. Cameras, depth sensors and ranging sensors, their message types and coordinate conventions, timestamps and synchronisation, and calibration — both intrinsic and the extrinsic calibration that ties a sensor to the transform tree. Bad extrinsics are the classic failure that looks exactly like a broken algorithm.

The first large integrated subsystem, and the payoff for everything before it. Localisation against a map, mapping, costmap layers, global planning and local control, recovery behaviours, and the behaviour tree that coordinates them. It is taught as a system to be configured and debugged rather than a package to be launched, because that is what using it actually consists of.

The other large subsystem: kinematics, the planning scene and collision checking, motion planning, trajectory execution and grasping. Placed after navigation because it is more configuration-heavy and less forgiving, and because the same transform and description understanding is being applied to a harder problem.

The reality units. Configuring the underlying transport for a real network including multi-machine and wireless setups, containerising, resource limits on embedded compute, and security — a default ROS 2 network is unauthenticated and any participant on it can command the robot, which is a Risk element with a physical consequence. Emergency stop design and safe start-up belong here too.

The capstone Skill element: a real or simulated robot described, controlled, perceiving, navigating and recovering, with the failures documented honestly. It is an artifact and it is assessed as one — no quiz closes this unit.