Intrinsic, the Google-owned robotics company, open-sourced its industrial robot software foundation, Intrinsic Core, on September 22, 2026. The announcement came at ROSCon 2026 in Toronto. The release gives developers a runtime, control, perception, and simulation stack they can use locally. Intrinsic also published a reference implementation for loading and unloading parts in machine tools. The question is how far shared software can take you when every factory has different robots and equipment. The answer becomes clear once you separate what the published code covers from the integration work that remains on site.
What was released, and what still depends on other components
What Intrinsic's announcement open-sourced is the "core" of its platform. The Intrinsic Core public repository contains modules for a local runtime, real-time control, motion planning, and image recognition. It is licensed under Apache 2.0, so developers can use and modify the code. Intrinsic also released the Open Machine Tending Solution (OMTS) as a concrete application example. It feeds parts into a CNC machine tool and removes them after machining.
What was released is a development and runtime foundation, not the full product line, which includes Flowstate and enterprise AI models. The announcement says that what you build with Core can work with the Flowstate development environment, advanced AI models, and industrial cloud services. These are described as enterprise services and should not be equated with what has now been published. Comparing the two public repositories with the scope described in the announcement gives the following boundary:
| Category | What is confirmed as provided | What to check separately when deploying |
|---|---|---|
| Intrinsic Core | Local runtime and control, planning, and perception modules, released under Apache 2.0 | Supported OS, ROS 2, drivers and control environment for real hardware |
| OMTS | Reference implementation for loading and unloading parts in CNC machine tools | Adapting to your own machines, grippers, cameras, and I/O signals |
| Intrinsic enterprise services | Intrinsic describes compatibility with Flowstate, advanced AI models, and industrial cloud | Terms of use and actual integration behavior |
| NVIDIA FoundationPose model weights | Not bundled with the OMTS code; fetched from NVIDIA at build time | NVIDIA Open Model License, separate from Apache 2.0 |
This table classifies the September 22, 2026 announcement and the Core and OMTS READMEs as checked on the 23rd. It is not a comparison of price or processing speed. FoundationPose, which estimates part poses from images, is a case where the integration code and the model itself have to be considered separately. According to the OMTS README, the model weights are not included in the repository, and users obtain them from NVIDIA. Adopting OMTS code published under Apache 2.0 does not mean the AI model's terms of use are the same.
Connection points for getting a robot moving
In the configuration described in the Core README, the local runtime, "intrinsic_runtime," manages application processes and state. The real-time control component, "intrinsic_control (ICON)," handles robot arms and grippers through a mechanism that absorbs differences between devices. Motion planning is connected to this, and information from cameras is used to estimate part positions. The aim is to run, in one shared runtime, functions that developers had previously combined individually.
"Hardware-agnostic design" here does not mean that any robot will work without configuration. The official announcement points to ROS-compatible drivers for supported robots, grippers, and 3D cameras. It may be possible to swap machines without rewriting the entire application, but each device's drivers, coordinate frames, communication, and stop conditions still have to be verified. Because the work involves physical motion, abstraction alone does not erase differences between sites.
On the perception side, there is a function that works with NVIDIA's FoundationPose to estimate the position and orientation of parts. Motion planning builds the robot's movement paths, and simulation using Gazebo lets you check behavior on a digital twin of the equipment. Camera calibration is also among the provided features. The pieces needed to link image recognition to motion are in place, but the announcement's terms "fast" and "highly accurate" cannot be read as measured values obtained on arbitrary equipment. The published materials show no success rates or processing times compared under common conditions.
The development environment prerequisites are also specific. The Core README lists Ubuntu 24.04 LTS or 26.04 LTS and notes that 22.04 LTS is also supported. It specifies the ROS 2 distribution Lyrical Luth. Whether existing factory systems and development PCs fit this combination is the first thing to check before deployment.
The process the machine-tending reference implementation shows
OMTS covers a broader task than a robot arm simply grasping a part. The published design describes the flow as a single composed sequence of actions: picking a part, loading it into the CNC machine, waiting for machining to start and finish, removing the part afterward, and returning it. In addition to robot motion, it handles opening and closing machine doors and fixtures, and the machining start signal. This shows that running it in a factory requires interaction with surrounding equipment, not just the arm.
There are two methods for locating parts to feed in. One estimates the pose of placed parts from camera images. The other determines pick positions from a fixed grid arrangement. The former allows flexibility in how parts are placed, but depends on the camera, lighting, and model weights. The latter fixes positions in advance, which lets you try the flow without complex image recognition. The value of this reference implementation lies in letting developers choose what to make flexible and what to fix on the equipment side.
The OMTS code also includes processing that adjusts contact behavior using force and torque, gripper opening and closing, and I/O signals for the CNC machine. However, the operation examples shown in the README cannot be treated as safe operating procedures for another factory as they are. If door or fixture signals differ, the connection layer has to be rebuilt. The public repository also shows no general uptime figures for real machines or success rates on different equipment.
What to verify before factory deployment
Testing is needed between getting started locally and running reliably in mass production. First, connect the target robot and gripper drivers, camera calibration, and machine-side signals, and confirm that the digital-twin layout matches the actual equipment. Next, evaluate the safety design, including stopping and recovery on contact, against that site's machines and workers. Intrinsic itself states that Core requires foundational knowledge of robotics.
For businesses making comparisons, missed grasps, machine wait times, and changeover setup times need to be measured under the same conditions. For methods that use image recognition, accuracy should also be checked when the target part and lighting change. The current announcement and READMEs show no independent verification of such metrics and no deployment costs. Intrinsic's stated path "from prototype to production" can only be assessed once each factory measures these things.
The end of the public repository states that Intrinsic Core is "not an officially supported Google product." Being released by a Google-owned company is separate from being supported as a Google product. For developers, a realistic starting point is to run OMTS on an equipment configuration close to their own and confirm the necessary device support and model licensing terms. If they can then measure whether success rates rise and downtime shrinks compared with existing processes, they can judge how much the published code widens a factory's options.