No history yet

Introduction to ROS2

What is ROS2?

Think about the operating system on your computer, like Windows or macOS. It manages all the different parts, like your keyboard, screen, and internet connection, so that applications can run smoothly. A robot needs something similar. It has sensors, motors, cameras, and a lot of software trying to make sense of the world and move around in it. That's where ROS2 comes in.

ROS2, which stands for Robot Operating System 2, isn't a traditional operating system. Instead, it's a flexible framework of tools, libraries, and conventions that simplifies the task of creating complex and robust robot behavior. It's open-source, meaning anyone can use, modify, and share it. ROS2 provides a standard way for all the different parts of a robot's software to communicate with each other, whether they're running on a single computer or distributed across multiple devices.

From ROS1 to ROS2

The original Robot Operating System, ROS1, was a huge success and became the standard for robotics research and development. However, as robotics moved from university labs into the real world, its limitations became clear. ROS1 wasn't built for the demands of commercial products, like multi-robot fleets or systems that needed to be highly reliable and secure.

So, the community rebuilt it from the ground up to create ROS2. The goal was to keep the best parts of ROS1 while adding features needed for modern applications.

FeatureROS1ROS2
Real-time SupportLimited / difficult to implementBuilt-in for time-critical tasks
SecurityMinimal built-in securityComprehensive security features
PlatformsPrimarily LinuxLinux, macOS, and Windows
Multi-Robot SystemsChallenging to set upDesigned for multi-robot use
ReliabilityUnreliable network connections could failMore robust and reliable communication

These improvements make ROS2 suitable for everything from small, embedded devices to large, industrial automation systems.

The Building Blocks of ROS2

To understand how ROS2 works, it helps to think of a busy kitchen. In a kitchen, you have different chefs (nodes), a system for passing ingredients and information around (topics), and specific requests you can make (services). ROS2 organizes robot software using a similar set of core concepts.

Nodes A node is the smallest unit of executable code in ROS2. A complex robotic system is typically built from many nodes, each responsible for a single, specific task. For example, you might have one node that reads data from a camera, another that controls the wheel motors, and a third that plans a path from point A to point B. This modular approach makes the system easier to build, debug, and upgrade.

Topics Nodes need to communicate. They do this primarily through topics. A topic is like a radio channel where a node can broadcast (publish) messages, and any other node can tune in (subscribe) to receive them. For instance, the camera node would publish images to an /image_data topic, and the path-planning node could subscribe to that topic to see where it's going. This is a one-to-many communication system; one node can publish, and many can subscribe.

This publish-subscribe model decouples the nodes. The camera node doesn't need to know who is using its data; it just publishes it. This makes the system incredibly flexible.

Services Sometimes, you don't want to broadcast information continuously. You just want to ask for a specific piece of information or request a single task to be done. For this, ROS2 uses services. This is a two-way, request-response communication. A node (the client) sends a request to another node (the server) and waits for a response. For example, a navigation node might call a service on a mapping node with the request, "What is the robot's current location?" The mapping node would then send back the coordinates.

Actions What if a task takes a long time to complete, like "navigate to the kitchen"? A service isn't ideal because the client would be stuck waiting for the final response. Actions are designed for these long-running tasks. An action client sends a goal to an action server (e.g., the coordinates for the kitchen). The server accepts the goal and provides a stream of feedback along the way (e.g., "distance remaining: 10 meters"). When the task is finally done, it sends a final result.

Parameters Finally, every node needs configuration settings. Instead of hard-coding values like speed limits or sensor resolutions into the program, we use parameters. Parameters allow you to configure a node's settings externally, without changing the code. This is useful for tuning a robot's behavior in different environments.

Quiz Questions 1/5

What is the primary role of ROS2?

Quiz Questions 2/5

What was a key motivation for developing ROS2 to replace the original ROS (ROS1)?

These five concepts are the foundation of ROS2. By combining them, developers can create sophisticated and scalable robotic applications.