Where Robotics Innovation Begins
If robotics has a common language today, it's ROS 2.
Whether you're building an autonomous mobile robot, a humanoid platform, a surgical robot, an industrial manipulator, or the next generation of AI-enabled machines, chances are ROS 2 has played a role somewhere in the journey. Over the last decade, ROS and ROS 2 have become robotics’ most influential ecosystems, giving developers a rich collection of middleware, frameworks, tools, and libraries that let them turn ideas into functioning robotic systems quickly.
Its appeal is easy to understand. Developers can integrate sensors, build perception pipelines, evaluate navigation algorithms, connect AI frameworks, and experiment with new concepts without reinventing the foundations of robotics software. It allows engineers to focus on solving robotic problems rather than building communications infrastructure from scratch.
For many robotics teams, innovation begins with ROS 2.
Production Requirements Extend Beyond Middleware
Despite the name, ROS 2 is not an operating system. It provides application frameworks and communication abstractions through middleware implementations based on technologies such as DDS and Zenoh, but it remains one layer of the complete robotics platform.
That distinction becomes increasingly important as robotics systems mature.
During early development, engineers typically ask whether the robot navigates correctly, whether the perception pipeline identifies objects, and whether the AI model performs as expected. Flexibility and rapid iteration take priority.
As systems move towards production, the questions change: Can it behave predictably under load? Can critical workloads be protected from non-critical applications? Can teams measure and understand latency across the complete robotics pipeline? Can AI inference, real-time control, and safety-related workloads coexist on a consolidated hardware platform?
These are system architectural questions and are becoming more relevant as robotics enters the era of Physical AI.
Modern robotics increasingly combines computer vision, machine learning, sensor fusion, localization, planning, and autonomous decision-making. Much of this intelligence is moving onto the robot so that it can perceive, reason, and act locally.
The result is a significant increase in system complexity.
A modern robotics platform may run vision processing, AI inference, navigation software, motion planning, industrial communications, operator interfaces, real-time control loops, and safety-related functions at the same time.
This creates an architectural challenge.
ROS 2 connects software components, but deterministic end-to-end behavior depends on the middleware, applications, operating system, drivers, networking, and compute resources working together.
Consider a typical robotics pipeline:
Camera → Vision Processing → AI Inference → Localization → Planning → Controlling → Actuating
Each stage introduces latency and jitter. Middleware moves messages, executors schedule callbacks, threads compete for processor time, drivers service interrupts, networks carry traffic, and AI models consume compute resources.
When latency appears, developers need to determine whether it came from an AI workload, network activity, resource contention, middleware, an application, or the operating system.
As robots become more intelligent, system-wide observability becomes as important as individual component performance.
Build with Familiar ROS2 Technologies on QNX
QNX lets robotics teams start with familiar ROS 2 technologies while simultaneously building on a platform fundamentally designed to support the needs of production robotics programs.
Instead of treating development and deployment as unrelated phases with entirely different stacks, teams can use ROS 2 during development while engineering the underlying system for real-time, high-availability, and safety-oriented use cases.
Developers can leverage ROS 2 Jazzy and supported technologies available through the QNX open-source ecosystem, including robotics frameworks, libraries, and communications components. The exact package versions and support status should be confirmed against the current QNX catalogue.
Explore ROS 2 packages available through QNX Open Source Software:
Preserve Engineering Investment as Requirements Mature
This continuity helps teams preserve applicable software investments and engineering expertise. Work created with ROS 2 Control, NAV2, or MoveIt 2 can continue to evolve as teams introduce more demanding control, networking, availability, and safety requirements. The goal is not to claim that every prototype moves unchanged into production, but to reduce unnecessary architectural discontinuity.
As projects mature, teams can also introduce commercial robotics technologies where their system requirements call for them. These may include commercial DDS and Zenoh implementations, EtherCAT master solutions, industrial communications, real-time control technologies, visualization frameworks, AI accelerators, and functional safety components.
QNX can therefore serve as the bridge between robotics experimentation and production-oriented system design.
Putting the Architecture into Practice with NVIDIA IGX Thor
Robotic systems have historically distributed motion control, vision processing, and safety monitoring across separate computers and controllers. This let each subsystem be optimized independently, but added hardware, software stacks, communication paths, integration work, and potential latency.
Emerging platforms are bringing AI inference, computer vision, planning, and real-time control, and safety-related functions closer together on a common compute foundation. Consolidation can simplify data movement and system integration, but only when it preserves determinism, fault isolation, and safety.
NVIDIA Halos is a full-stack safety system for physical AI, with NVIDIA Halos OS providing the software safety environment on NVIDIA IGX Thor, and Halos Core is the foundational layer within Halos OS.
A key advantage of IGX Thor is its dedicated Functional Safety Island (FSI), an independent processor subsystem with its own I/O, power, and clocks. It monitors faults and supports safety responses separately from the main AI compute domain, helping high-performance AI and safety-related workloads coexist on one platform. IGX Thor also supports NVIDIA Isaac ROS, enabling developers using ROS 2 to build on familiar workflows and GPU-accelerated packages to simplify development and deployment.
It combines high-performance edge AI and sensor-processing capabilities with an architecture intended for industrial, medical, and robotics systems.
On NVIDIA Halos Core, QNX OS for Safety can operate in a partitioned, mixed-criticality architecture alongside a Linux-based environment. The hypervisor separates operating-system domains so deterministic and safety-related functions can be isolated from high-performance AI workloads while remaining on a consolidated computing platform.
In this architecture, the Linux domain supports non-safety-related applications, while the QNX domain supports real-time control and safety-related applications.
This division of responsibilities is important. AI frameworks prioritise throughput and computational performance, motion-control systems prioritise deterministic execution, and safety-related applications require isolation, fault containment, and predictable behaviour.
A consolidated platform is valuable only if it can support these different workload requirements without obscuring their boundaries.
Continuous Path to Production-Oriented Physical AI
ROS 2 has become the foundation upon which much of today's robotics innovation is built. It enables developers to explore new ideas, integrate emerging technologies, and accelerate the development of increasingly capable autonomous systems. As robotics evolves toward Physical AI, however, success will depend on more than algorithms and middleware alone.
Production robotics requires an architecture that can bring together AI, perception, networking, control, and safety-related functions while maintaining predictability, observability, and system integrity. The challenge is no longer simply getting a robot to work, but ensuring it continues to behave as expected as complexity grows.
QNX helps bridge that transition. By supporting familiar ROS 2 technologies while providing a foundation for real-time performance, mixed-criticality system design, high availability, and functional safety, teams can keep building on the tools they know while preparing for the realities of deployment.
Whether development begins on a small prototype, a laboratory platform, or a next-generation AI compute architecture such as NVIDIA IGX Thor, the goal remains the same: provide a continuous path from innovation to deployment, allowing robotics teams to focus on creating intelligent machines without having to rebuild their software and system architecture as requirements mature.
In other words, ROS 2 may be where the journey begins, but bringing robotics and Physical AI into the real world requires an architecture designed for the road ahead. One that’s with QNX.
