ROS2 (Robot Operating System 2) is open-source robotics middleware, not a traditional operating system. It provides message-passing between processes, hardware abstraction, and package management so robotics developers don't have to rebuild basic plumbing for every robot.

What is the difference between ROS2 and ROS1?

ROS2 is a ground-up redesign: it uses DDS (Data Distribution Service) as its communication backbone instead of ROS1's custom TCP-based system, runs natively on Linux, Windows, and macOS instead of Linux-only, adds built-in security via DDS Security, and supports multi-robot fleets and lifecycle management that ROS1 lacked.

What are nodes, topics, services, and actions in ROS2?

A node is a single running process. Topics are a publish-subscribe channel for continuous data streams, like camera frames. Services are synchronous request-response calls for a single result, like computing a path. Actions are for long-running goals that report progress and can be canceled, like navigating to a waypoint.

Can ROS2 run spiking neural networks?

Yes, though no major ROS2-native package existed for it until recently. NeuroCUDA ships a ROS2 package, neurocuda_ros2, that wraps a compiled spiking neural network in standard ROS2 nodes and topics, so a model trained in PyTorch can run as part of a normal ROS2 graph.

June 22, 2026

What Is ROS2? The Robot Operating System Explained

Q: Is ROS2 an operating system?

No. ROS2 runs on top of an existing OS, usually Ubuntu Linux, and is not a real-time operating system (RTOS) by default, though it can be integrated with real-time code. It is more accurately described as a robotics SDK or middleware layer.

Despite the name, ROS2 isn't an operating system. It's the plumbing that lets a robot's sensors, motors, and algorithms talk to each other without everyone reinventing it from scratch.

ROS2 (Robot Operating System 2) is open-source robotics middleware: a layer of tools, libraries, and protocols that sits between a robot's hardware and the software that controls it. The name is a historical artifact - ROS2 doesn't manage CPU scheduling or memory the way Linux or Windows does. It runs on top of a real OS, almost always Ubuntu Linux, and handles a narrower, robotics-specific problem: how does a camera driver tell a navigation algorithm what it's seeing, and how does that algorithm tell the motors what to do, without every team writing custom message-passing code for every robot.

The core idea: a computation graph

A running ROS2 system is a graph of independent processes called nodes. A camera driver is a node. An obstacle-detection algorithm is a node. A motor controller is a node. Nodes don't call each other directly - they communicate through four mechanisms, and almost everything in ROS2 is one of these:

Topics - publish-subscribe, like a radio channel. A depth camera publishes to /camera/depth; any number of nodes can subscribe without the publisher knowing who's listening. Used for continuous data streams.
Services - synchronous request-response, for a single result. "Compute a path from A to B" is a service call: one request, one response, then done.
Actions - for long-running goals that report progress and can be canceled mid-way, like "navigate to this waypoint." Built on top of topics and services.
Parameters - per-node configuration values that can be set at launch or changed at runtime, like a camera's frame rate.

This graph model is why ROS2 scales from a single robot arm to a warehouse fleet: adding a new capability usually means adding a new node that subscribes to existing topics, not rewriting the nodes that already work.

Why ROS2 exists - what was wrong with ROS1

ROS1 launched in 2007 and became the de facto standard for robotics research, but its design had hard limits that became obvious as robots left the lab:

ROS1	ROS2
Custom TCP-based transport (TCPROS)	DDS (Data Distribution Service), an industrial pub-sub standard
Linux only	Linux, Windows, macOS
No built-in security	DDS Security: encryption and authentication
Single robot, single master node	Multi-robot fleets, no single point of failure
No formal node lifecycle	Lifecycle nodes: configure, activate, deactivate, shut down cleanly

The single-master design in particular was a real production problem: if ROS1's master process died, the whole system lost discovery. ROS2's DDS-based discovery has no equivalent single point of failure, which matters once you're running a fleet rather than a lab demo.

What ROS2 is used for in practice

ROS2 backs a wide range of deployed robotics, not just research: autonomous mobile robots in warehouses, robotic arms on factory floors, delivery robots, drones, and self-driving research platforms. Companies including NVIDIA, Amazon, and Microsoft contribute to or build on top of it. It is distributed under the Apache 2.0 license and released as named "distros" - the current ones in active use include Humble, Iron, and Jazzy Jalisco.

Getting started: what you actually install

ROS2 isn't one download - it's a meta-package of interdependent tools. A minimal setup looks like:

sudo apt install ros-jazzy-desktop
source /opt/ros/jazzy/setup.bash
ros2 run demo_nodes_cpp talker

From there, the standard workflow is: write nodes in Python (rclpy) or C++ (rclcpp), define or reuse message types, wire them together with a .launch.py file, and build the workspace with colcon build.

Where neural networks - and spiking neural networks - fit in

Standard deep learning already has a place in ROS2: packages like ros_deep_learning wrap CNN-based object detection for camera nodes. Spiking neural networks (SNNs), the more biologically inspired, event-driven alternative, have had far less ROS2-native tooling. Most published SNN-on-robot work - Gridbot's SNN navigation, the Loihi-based oculomotor head control - runs on ROS1, not the current standard, and isn't packaged for reuse outside its original paper.

NeuroCUDA's ROS2 package closes that gap: a normal ROS2 node, snn_inference_node, that takes camera input and publishes typed spike and detection messages, backed by a compiler that converts an existing PyTorch model into a spiking network rather than requiring training from scratch. See the full deployment walkthrough for the node graph, message types, and a Docker image.

Frequently asked questions

Is ROS2 an operating system? No - it's middleware that runs on top of an OS, almost always Ubuntu Linux.

Is ROS2 real-time? Not by default, though it can be integrated with real-time code and DDS implementations that support real-time scheduling.

Do I need ROS2 to do robotics? No, but most published robotics research, off-the-shelf robot SDKs, and industrial robot fleets standardize on it, so most reusable code you'll find assumes it.