From One Controller to ROS 2

ROS 2 is not the definition of robotics. It is one framework for organizing distributed robot software.

This course does not turn into a ROS 2 course here. The goal is to understand why middleware exists before learning the framework itself.

The problem middleware solves

Without a shared communication layer, every pair of processes could need its own custom networking code.

camera ↔ custom link ↔ navigation
camera ↔ custom link ↔ logging
navigation ↔ custom link ↔ UI
...

Middleware creates common patterns for exchanging data and invoking behavior.

ROS 2 commonly organizes software into nodes that communicate through mechanisms such as topics, services, and actions.

Topic mental model

A topic fits data that is published and consumed as a stream.

Conceptually:

camera node
    │ publishes image
    ▼
 /camera/image
   ├────────→ vision node
   └────────→ logger

The sender does not need a hard-coded direct call to every consumer.

That decoupling is powerful.

It also means the system now depends on:

• message definitions;
• discovery;
• timing;
• quality-of-service choices;
• naming;
• network behavior.

Boundary with this course

By the end of this unit, you should be able to explain why a distributed robotics framework is useful.

The dedicated ROS 2: For Students course can then teach actual nodes, topics, services, actions, packages, launch systems, DDS behavior, and ROS tooling without pretending those ideas are basic motor control.

Bridge artifact

Take your Unit 15 robot architecture.

Circle one communication link that would make sense as a streamed topic.

Write:

• publisher;
• subscribers;
• message meaning;
• expected update rate;
• stale-data behavior.

That single interface is your bridge from general robotics into ROS 2.

ROS 2 solves a class of coordination problems

As robot software grows, directly wiring every program to every other program becomes difficult to maintain.

A robotics middleware architecture introduces named communication patterns so components can exchange data without being one giant executable.

Conceptually:

camera process → image messages → perception
perception → target messages → planner
planner → motion requests → controller

ROS 2 provides concrete tools for this kind of distributed robotics, including nodes and several communication patterns. You will study those mechanisms directly in the ROS 2 course.

The important idea here is why middleware appears at all.

Do not use middleware to hide bad boundaries

Breaking one messy program into twelve networked messy programs does not improve the architecture.

A subsystem boundary should have:

• a clear responsibility;
• a defined interface;
• useful data ownership;
• known timing/failure behavior;
• a reason to be independently deployed or changed.

Before proposing a separate process for a robot function, write one sentence explaining why the boundary exists.

If the answer is only "microservices are modern" or "ROS has nodes," the boundary is not yet justified.