NVIDIA Open-Sources OSMO for Robot AI Orchestration

NVIDIA has open-sourced OSMO, a Kubernetes-native workflow orchestrator designed to address the fragmentation in physical AI development for robots. The tool aims to unify the three distinct computing tiers involved in robot AI: policy training, simulation, and hardware-in-the-loop (HIL) testing. Traditionally, developers face separate clusters, schedulers, and glue scripts for each stage, leading to accumulated custom code and inefficiencies. OSMO allows teams to define the entire pipeline in a single YAML file, enabling it to run across these different tiers without requiring direct infrastructure code modifications. The project is licensed under Apache-2.0 and provides Helm charts and containers on NGC, with a local quickstart option for workstation deployment using KIND. NVIDIA frames physical AI development as a "three computer problem." The first computer is for training, typically utilizing data-center GPUs like NVIDIA's GB200 or H100 clusters. The second computer is for simulation, physics, and sensor rendering, often leveraging workstation-class RTX hardware, such as the RTX Pro 6000. The third computer is for deployment and HIL testing on edge devices, exemplified by the Jetson AGX Thor, usually situated on-premises. Each of these tiers traditionally employs its own set of tools, and the handoffs between them are a common source of custom scripting. OSMO integrates all three tiers as backends of a single control plane. Each backend is represented as a Kubernetes cluster registered via the command-line interface. Workflows in OSMO do not specify a particular cluster but rather a platform, such as 'gb200', 'rtx-pro-6000', or 'jetson-agx-thor'. OSMO then intelligently routes the task to an available pool that supports the named platform. A canonical example workflow demonstrates chaining three tasks: a simulation task running an Isaac Sim container on an 'rtx-pro-6000' platform; a 'train-policy' task executing a PyTorch container on a 'gb200' cluster with 8 GPUs, taking the simulation output as input; and an 'evaluate-thor' task running a ROS application on a 'jetson-agx-thor' device, consuming the trained policy and recording results to a named dataset. Dependencies between tasks are managed through inputs and outputs, and task placement is determined by the specified platform. The user guide further details support for serial and parallel task groupings, Jinja templating for parameterized workflows, retry policies, and the ability to assign HIGH, NORMAL, or LOW priorities to tasks.