ROS / ROS2
The middleware that glues real robots together.
Prerequisites
Why it matters in robotics
ROS/ROS2 is the de facto middleware for real robots: a publish/subscribe graph of processes exchanging messages over named channels, request/response calls, and long-running goals, with tooling to track coordinate frames over time, start and configure a whole robot at once, and watch data flow live for debugging. Choosing the right communication pattern for a given exchange, and understanding how message delivery guarantees and frame lookups behave, is what lets a team integrate perception, planning, and control into one running system. Solid ROS fundamentals are what turn isolated algorithms into shippable robot software.
What to study
- ✓The computation graph: nodes, topics + messages, services, and actions — and when to choose each
- ✓Workspaces and packages: colcon build, package layout, launch files, and parameters
- ✓The tf2 transform system: coordinate frames, the transform tree, and looking up transforms over time
- ✓DDS underpinnings and QoS settings, plus core CLI/visualization tools (ros2 CLI, rqt, RViz, rosbag)
Where to study
Cheatsheet
Topics, services, actions
Topic: many-to-many, asynchronous, fire-and-forget pub/sub — for continuous streams (sensor data, odometry).
Service: one-to-one, synchronous request/response — for a quick call that either completes or fails ("is this pose valid?").
Action: like a service but for long-running, preemptible goals with periodic feedback and cancellation ("navigate to this waypoint") — built on topics under the hood (goal, feedback, result, cancel).
tf2: frames over time
tf2 maintains a tree of coordinate frames (map, odom, base_link, sensor frames, ...) with exactly one parent per frame, and buffers transforms with timestamps so you can ask "where was the lidar frame relative to the map 200 ms ago," not just "where is it now."
Looking up a transform between two frames walks up to their common ancestor and back down. A missing or late link anywhere in the tree makes the whole lookup fail or extrapolate — the most common source of "transform not found" errors at startup.
Packages, build, launch
A ROS2 workspace holds one or more packages (each with its own `package.xml` and build config), built with `colcon build`, then sourced via the workspace's `install/setup.bash`.
A launch file starts and wires together a whole robot at once — nodes, parameters, remappings, and composition — instead of running each node by hand in its own terminal.
QoS is a contract, not a suggestion
Publisher and subscriber each declare a QoS profile (reliability, durability, history, deadline). They only connect if the subscriber's request is compatible with what the publisher offers — e.g. a `reliable`-requesting subscriber will not connect to a `best_effort` publisher.
`reliable` retries until acknowledged (ordered delivery, more latency/bandwidth under loss); `best_effort` just sends and moves on (lower latency, fine for high-rate sensor data where a dropped frame doesn't matter). `transient_local` durability lets a late-joining subscriber still get the last published message(s) — critical for things like a map published once at startup.
Tooling for a live graph
`ros2 node/topic/service list` and `ros2 topic echo` inspect the running graph and message traffic from the CLI. `rqt_graph` visualizes who's talking to whom. `RViz` renders sensor data, tf frames, and markers in 3D. `rosbag2` records and replays topic traffic for offline debugging and dataset creation.
| Topic | Service | Action | |
|---|---|---|---|
| Pattern | Pub/sub | Request/response | Goal + feedback + result |
| Cardinality | Many-to-many | One-to-one | One-to-one (per goal) |
| Blocking? | No | Caller blocks (or async) | No — preemptible, async |
| Use for | Continuous streams | Quick, bounded calls | Long-running, cancellable tasks |