Loading system evidence
Loading system evidence
Build a working ROS 2 mental model by fixing tiny broken examples of every core concept.
Sign in to start - freeOutcome
Build
A single-package ROS 2 workspace whose nodes, launch files, and transforms you repair concept by concept.
Sample incident
Make `/sensor_node` stay alive so it appears in the graph, without changing how it is launched.
Full syllabus
A ROS 2 program is a graph of nodes. A node must be created, named, and kept alive to appear on the graph.
Nodes exchange messages over named topics. Publisher and subscriber must agree on both the topic name and the message type.
Services are synchronous request/response calls. Client and server must share the service name and type.
Parameters make nodes configurable. A parameter must be declared before it is read, and its type must match its use.
Actions handle long-running goals with feedback. The server must accept goals and publish feedback while it works.
Launch files start and wire many nodes at once. A node left out of the description never starts; a wrong remap misroutes traffic.
tf2 tracks the transforms between coordinate frames. Frame names must match the robot, and lookups must use the right direction.
ROS 2 code lives in packages built in a workspace. Manifests must declare dependencies and entry points must point at real code.