What Is ROS 2? Architecture, ROS 1 vs. ROS 2, and Migration Guide

ROS 2, short for Robot Operating System 2, is an open-source framework for developing robotics applications. Despite its name, it is not a conventional operating system such as Linux or Windows. Instead, ROS 2 provides libraries, communication mechanisms, development tools, and interfaces for connecting robotic software components.

Modern robots depend on multiple software components working together: sensors collect environmental data, perception algorithms interpret it, planners determine the next movement, and controllers translate decisions into physical actions. ROS 2 provides the software framework and communication layer that allows these components to operate as a distributed robotic system.

ROS 2 was developed to support requirements that became increasingly important as robotics moved from research prototypes into commercial and industrial deployment, including distributed computing, configurable Quality of Service (QoS), security, and time-sensitive communication.

With ROS 1 Noetic reaching End of Life (EOL) on May 31, 2025, understanding these differences has also become important for teams planning the long-term maintenance or migration of existing ROS 1 systems.

What Is ROS 2 (Robot Operating System 2)?

ROS 2 organizes a robotics application as a set of modular software components called nodes. Each node can handle a specific function, such as reading a camera, estimating the robot's position, planning a route, or issuing motion commands.

Nodes exchange information through communication patterns that match the task: topics for continuous data streams, services for short request-and-response interactions, and actions for longer-running operations that provide feedback or support cancellation.

This modular structure lets developers separate perception, localization, planning, control, and other functions while deploying them across one or more processes or computers.

Why Was ROS 2 Developed?

ROS 1 became widely used for robotics research and prototyping, but its architecture predates many requirements that became increasingly important, as robots grew more distributed and commercially deployed.

ROS 2 was designed around these requirements. Its middleware architecture separates the ROS application layer from the underlying communication technology, giving developers more flexibility when deploying robotics software across different processes, computers, and networks.

These changes are particularly relevant to autonomous mobile robots (AMRs), industrial robots, humanoid robots, and other autonomous machines in which many sensors, computers, and software components need to exchange data continuously.

Core Concepts and Architecture of ROS 2

At the architecture level, ROS 2 combines application-level nodes and communication interfaces with a middleware layer that handles functions such as discovery and data transport.

DDS Middleware Architecture

ROS 2 does not hard-code a single transport layer. It uses the ROS Middleware Interface (RMW) to connect ROS APIs to interchangeable middleware implementations, many of which are based on Data Distribution Service (DDS) and use the Real-Time Publish-Subscribe wire protocol.

DDS is a standardized publish/subscribe middleware framework. Publishers send data while subscribers receive the data they need, and the Object Management Group Data Distribution Service specification defines data exchange and Quality of Service controls for distributed applications.

The RMW abstraction means developers normally work through ROS 2 interfaces rather than programming against a middleware implementation directly. The selected middleware then handles functions such as discovery, serialization, and data transport.

This separation supports distributed deployments in which cameras, controllers, AI computers, operator interfaces, and other components run across multiple processes or physical computers.

Nodes, Topics, and Discovery Mechanism

A node is a ROS 2 software component responsible for a particular function. A robot might have one node reading a camera, another estimating position, another planning a route, and another issuing motion commands.

A topic is a named channel for one-way publish/subscribe communication. A camera node might publish image data, while one or more perception nodes subscribe to that topic.

ROS 2 also supports automatic discovery. With DDS-based middleware, nodes can find one another and establish communication without relying on the central ROS Master used in ROS 1, while discovery behavior can be configured for different network environments.

As deployments grow, discovery traffic may need additional management. Some middleware implementations support discovery-server configurations, such as Fast DDS Discovery Server, to reduce or control peer-discovery traffic in larger robot networks.

Services and Actions Communication Model

ROS 2 services handle short request-and-response interactions, such as when one node requests the robot's current joint positions from another.

Actions are designed for longer-running operations. A navigation action can receive a destination, provide progress feedback while the robot moves, accept cancellation, and return a final result.

The distinction is practical: topics suit continuous data, services suit discrete requests, and actions suit tasks that unfold over time.

Choosing the interface based on the interaction pattern keeps communication semantics explicit as a robotics application grows.

ROS 1 vs. ROS 2: What Are the Biggest Differences?

ROS 2 preserves many familiar ROS concepts, but the key differences are most visible in discovery, middleware, QoS, real-time support, security, build tools, and platform support.

Centralized vs. Decentralized Communication

ROS 1 uses a ROS Master for node registration and name lookup, although message data can flow directly between nodes after a connection is established. ROS 2 removes this mandatory discovery point and normally relies on middleware-driven distributed discovery.

For robot architecture, this makes it easier to distribute perception, planning, control, and monitoring nodes across multiple computers or robots without depending on one ROS Master for discovery. The advantage becomes especially relevant as a system grows beyond a single computer.

Decentralized discovery does not eliminate network design work. Larger ROS 2 deployments may need to tune discovery behavior, network topology, or middleware configuration, and some implementations provide options such as Fast DDS Discovery Server to control discovery traffic.

Real-Time Performance and QoS Policies

ROS 1 and ROS 2 also differ in how much control developers have over message delivery. A robotics application may tolerate an occasional dropped camera frame while requiring robot-state updates to arrive reliably and within a defined time window.

ROS 2 exposes Quality of Service (QoS) policies for properties such as reliability, message history, deadlines, data lifespan, and liveliness. These controls let developers match communication behavior to the requirements of each data stream rather than applying one delivery model across the system.

Real-time behavior depends on the entire system. Operating-system scheduling, middleware configuration, memory management, hardware, and application code all affect timing. ROS 2 can support more predictable time-sensitive applications, but it does not by itself guarantee hard real-time performance or functional safety.

Security and Multi-Platform Support

Compared with ROS 1's limited built-in security mechanisms, ROS 2 can integrate DDS-Security features for authentication, access control, and encrypted communication. The ROS 2 DDS-Security integration design describes how these mechanisms fit into the ROS 2 architecture.

ROS 2 also supports multiple platforms, with support levels defined for each release. REP 2000 specifies the operating systems, architectures, and middleware implementations targeted by each ROS 2 distribution.

Development Tools and Build System Improvements

ROS applications are organized into packages, which group together the code, configuration, and dependencies needed for a particular function. Before those packages can run, they need to be built into a usable form.

ROS 1 commonly uses catkin for this process. ROS 2 uses ament to define how individual packages are built and installed, while colcon handles a workspace containing multiple packages by finding them, resolving their dependency order, and building them in the correct sequence.

ROS 2 also provides a command-line interface and launch files in XML, YAML, or Python for starting, inspecting, and managing applications composed of multiple packages.

Why Migrate to ROS 2?

ROS Noetic Ninjemys was the final ROS 1 distribution. When it reached End of Life on May 31, 2025, official maintenance for ROS 1 ended with it. Existing ROS 1 systems can continue to operate, but teams that remain on ROS 1 must now take greater responsibility for security fixes, dependency maintenance, compatibility issues, and long-term software support. For organizations developing or maintaining commercial robots, that changes ROS 2 migration from a feature-driven upgrade into a lifecycle planning decision.

ROS 1 Noetic Has Reached End of Life

End of Life does not mean existing ROS 1 systems stop working.

The official ROS 1 Noetic EOL notice states that the ROS project no longer provides new features, security updates, bug fixes, patches, or updated binaries for ROS 1. Teams that continue using ROS 1 therefore assume more of the maintenance burden themselves, including keeping dependencies compatible and addressing future security or operating-system changes.

That distinction matters for commercial robotics products with multi-year service lives. A system may still function today, but maintaining it over the next several years becomes more difficult when the underlying framework is no longer officially supported.

A Practical ROS 1-to-ROS 2 Migration Path

Migrating from ROS 1 to ROS 2 does not necessarily require moving every package at once. A practical migration usually starts with an inventory of the existing ROS 1 system: packages, custom messages and services, external dependencies, operating-system requirements, and hardware or other software interfaces.

Next, teams can determine which dependencies already have ROS 2 equivalents and which packages need to be ported, replaced, or redesigned. Packages with fewer dependencies are often easier to migrate first, while heavily interconnected components may need to remain on ROS 1 temporarily.

During a staged transition, the ros1_bridge package lets ROS 1 and ROS 2 components exchange messages and services. Standard interfaces can often be bridged directly, while custom interfaces may require building the bridge from source.

Migration should also include validation of the target ROS 2 distribution, operating system, middleware implementation, QoS configuration, hardware interfaces, and application timing requirements. A package that compiles successfully may still require communication or architectural changes to behave correctly under ROS 2.

Because ros1_bridge compatibility depends on the ROS 1, ROS 2, and operating-system versions in use, it is generally best treated as a transition mechanism rather than the final long-term architecture.

Long-Term Benefits of ROS 2 Adoption

Moving to ROS 2 shifts a robotics codebase to an actively maintained ecosystem and a platform designed for current distributed robotics development. For products with long service lives, that reduces dependence on the unsupported ROS 1 stack and makes it easier to align with supported operating systems, middleware, and tooling.

Migration effort also depends on package dependencies. A package can only migrate once its dependencies are available in ROS 2; some packages can retain much of their existing source code, while others require more extensive redesign.

The Advantages of ROS 2 for Industrial Robotics and Humanoid Robots

Industrial and humanoid robots combine perception, AI inference, motion planning, control, sensor fusion, and connectivity, often across several onboard or nearby computers. ROS 2 provides the communication structure for coordinating these software workloads without forcing them into a single process or machine.

Scalability for Multi-Robot Systems

For multi-robot systems, distributed discovery and publish/subscribe communication let ROS 2 applications span multiple processes and computers. The same architecture can therefore support fleets of AMRs, coordinated robots, and complex machines with several embedded computers.

Scaling the ROS 2 graph is only part of fleet scalability. Network topology, middleware selection, discovery settings, message rates, and application design still determine how efficiently communication behaves as the number of robots and connected systems grows.

QoS for Time-Sensitive Robot Communication

In industrial robots, QoS becomes useful when different data streams carry different operational importance. High-rate sensor data, robot-state updates, control messages, and status information can be assigned different reliability or timing behavior instead of being treated identically.

That flexibility can make communication more predictable for time-sensitive workloads. ROS 2, however, does not provide functional safety on its own or guarantee hard real-time performance.

For industrial robot applications, ISO 10218-2:2025 addresses safety at the system and integration level, including commissioning, operation, maintenance, and decommissioning of industrial robot applications and robot cells. ROS 2 communication performance is therefore only one part of the overall safety architecture.

Integration with Edge Computing and IIoT

Robotics applications increasingly place perception and AI inference on onboard or nearby edge computers so time-sensitive processing does not depend on a remote cloud connection.

ROS 2's distributed architecture lets robot software communicate across onboard computers and edge controllers. At the factory level, gateways or integration software can then expose selected robot data to Industrial Internet of Things (IIoT) platforms, manufacturing systems, databases, or other enterprise applications.

For AI robotics, the NVIDIA Isaac ROS platform provides GPU-accelerated ROS 2 packages and AI models for workloads such as perception, localization, mapping, and autonomous systems. Isaac ROS supports NVIDIA Jetson platforms, including Jetson Thor, but the supported ROS 2 distribution, JetPack version, and hardware combination depend on the Isaac ROS release. Teams should therefore verify the current NVIDIA support matrix when defining the software stack.

NEXCOM Robotic Solutions for ROS 2 and AI Workloads

NEXCOM Robotic Solutions (NexCOBOT Co., Ltd.) offers the MARS400 T10-05 robotic controller, powered by NVIDIA Jetson T5000. Its Blackwell GPU and 128 GB LPDDR5X support perception and AI inference, while eight GMSL, four Gigabit Ethernet, and four USB 3.2 Gen2 interfaces connect cameras, sensors, peripherals, and networked robot components.

Because the MARS400 T10-05 uses Jetson T5000, it belongs to the Jetson Thor platform family supported by current Isaac ROS releases. This makes it relevant for teams evaluating NVIDIA-accelerated ROS 2 workloads, but teams should always validate the target Isaac ROS release, JetPack version, ROS 2 distribution, and hardware configuration together before deployment.

The NEXCOM RCB400 T20-05 industrial AI control board uses the NVIDIA IGX T5000 industrial module and is positioned for intelligent robotics, motion control, AI-driven automation, humanoid robots, AMRs, smart manufacturing, and medical edge systems. The board provides CAN FD, serial communication, GPIO, and optional GMSL connectivity, and it includes functional-safety-oriented hardware such as NVIDIA's Functional Safety Island and support for a safety MCU through the EBK-210 expansion board.

These features bring AI computing, industrial I/O, and functional-safety-oriented hardware onto the same control platform. Final software compatibility, safety targets, and certification requirements remain system-level engineering decisions.

NEXCOM Bridges AI Computing and Industrial Robot Control

For teams adopting ROS 2, computing hardware is part of the robotics architecture rather than a separate afterthought. AI perception, multi-camera input, robot control, networking, and safety-related workloads place different demands on processors, interfaces, thermal design, lifecycle support, and system integration.

NEXCOM Robotic Solutions provides platforms including the MARS400 T10-05 and RCB400 T20-05 for advanced robotics and edge AI architectures. For ROS 2, NVIDIA-accelerated robotics, motion control, edge AI, or customized robotics requirements, contact NEXCOM to discuss the computing architecture for your application.