What Is ROS 2?

A robot is a team of small programs

Imagine a small delivery robot rolling down a sidewalk. To do that, it has to do many things at the same time:

• Read its camera and depth sensors, many times per second
• Figure out where it is on a map
• Plan a safe path around people and obstacles
• Send speed commands to its wheel motors
• Watch its battery and report status

You could try to write all of that as one giant program. But that program would be enormous, fragile, and impossible for a team to work on together. If the path-planning part crashed, the whole robot would die.

Instead, robotics engineers split the work into many small, independent programs that each do one job well, and then let those programs talk to each other. ROS 2 is the system that lets them talk.

The core idea: the graph

In ROS 2, each small program is called a node. A node does one focused job — for example, a camera_node, a path_planner, or a motor_driver.

Nodes don't call each other directly. Instead they exchange messages over named channels called topics. A node can publish (send) messages to a topic, and any number of other nodes can subscribe (listen) to that topic.

  [ camera_node ] --publishes--> (/image) --subscribed by--> [ path_planner ]
                                                                    |
                                                          publishes (/cmd_vel)
                                                                    |
                                                                    v
                                                             [ motor_driver ]

This web of nodes and topics is called the ROS graph. It's exactly the kind of diagram you saw on the Voyager Lab home page: circles (nodes) connected by lines (topics like /vision, /nav, and /cmd_vel).

Because nodes are independent, this design gives you three big wins:

• Modularity — swap the camera node for a better one without touching the planner.
• Reusability — the same motor_driver works on many different robots.
• Resilience — if one node crashes, the others keep running.

Ways nodes talk: topics, services, and actions

Topics are the most common, but ROS 2 gives you three communication styles, each for a different situation. You'll use all three in this course:

• Topics — a continuous stream, one-to-many. Great for sensor data that's always flowing (camera images, wheel speeds). Lesson 4.
• Services — a one-time request and response, like calling a function on another node ("take a snapshot → here's the image"). Lesson 5.
• Actions — a long-running task you can track and cancel ("drive to the kitchen"), with progress updates along the way. Previewed in Lesson 6.

Why "2"? A quick bit of history

The original ROS launched in 2007 and became the standard in robotics research. But it was built for one robot in a lab, on a trusted network. ROS 2 is a ground-up rewrite for the real world: multiple robots, unreliable Wi-Fi, real-time control, and commercial products. It handles messaging using an industrial standard called DDS (Data Distribution Service), which is why ROS 2 nodes can discover and talk to each other automatically, even across different computers.

ROS 2 ships as named distributions (like Ubuntu does). This course targets Humble Hawksbill (long-term support, very stable) and Jazzy Jalisco (newer). Either works — we'll point out any differences.

(Answers: 1 — a node is a small single-purpose program; a topic is a named channel it sends/receives messages on. 2 — path_planner publishes /cmd_vel; motor_driver subscribes. 3 — a service.)

Key takeaways

• A robot is many small programs working together; ROS 2 is what connects them.
• Nodes are the programs; topics are the named channels they publish and subscribe to; together they form the graph.
• Three communication styles: topics (streams), services (request/response), actions (long tasks).
• We'll use ROS 2 Humble or Jazzy with Python.