Robotiq Open-Sources Its Grip on the Physical AI Stack
Robotiq released a C++ SDK, a company-maintained ROS 2 driver, and updated NVIDIA Isaac Sim assets with closed-loop kinematics, the first pieces of a Contact Core physical AI software layer with paid embedded-intelligence features due in Q4 2026.

A robot gripper built for a fixed, repetitive pick-and-place cycle has different engineering requirements than one that is supposed to teach an AI model how to grasp an object it has never seen before. That distinction is what Robotiq, the Quebec City-based maker of adaptive grippers and end-of-arm tooling for industrial automation, is acting on with three open-source software packages it released on Tuesday, September 22, covering a standalone C++ SDK, a ROS 2 package built as a drop-in replacement for existing community drivers, and updated NVIDIA Isaac Sim assets with closed-loop kinematics for higher-fidelity simulation. The releases are free, hosted on github.com/robotiq, and maintained directly by the company rather than handed off to a volunteer community, a deliberate reversal of how gripper software has typically been supported.
Robotiq's own explanation for the move is that community-maintained driver packages, the kind of volunteer-supported ROS integrations that have served conventional automation projects reasonably well for years, cannot sustain what physical AI applications actually demand: higher simulation fidelity to close the gap between a model trained in simulation and one deployed on real hardware, tighter control loops to give a manipulation model finer-grained feedback on contact forces, and continuous data collection across millions of cycles to generate the training volume a modern robotics foundation model requires. Vincent Duchaine, Robotiq's chief technology officer for AI, put the underlying problem plainly: "physical AI applications ask far more of a gripper than conventional ones ever did." A gripper used to close, hold and release on a fixed timer does not need to report granular contact-force data in real time or behave identically in simulation and reality down to the millisecond. A gripper being used to train or run a manipulation model does, because the model is learning from every cycle, and noisy or inconsistent data from the hardware layer corrupts what it learns.
What Each Package Actually Solves
The C++ SDK is a standalone library aimed at teams building custom robotic stacks rather than working inside the ROS ecosystem at all, giving developers direct, low-level control over a Robotiq gripper without needing to route commands through ROS middleware, useful for teams building proprietary control systems or integrating a gripper into a non-ROS industrial controller. The ROS 2 package, by contrast, is explicitly built as a drop-in replacement for the community drivers many existing Robotiq deployments already run, matching their interfaces so an existing project can swap in the company-maintained version without rewriting its integration code, while gaining the tighter control loops and more consistent behavior the new package is built around. That compatibility choice matters commercially: Robotiq is not asking existing customers to rebuild their software stack to get the benefit of company-backed maintenance, it is asking them to change one dependency.
The third package, updated NVIDIA Isaac Sim assets with closed-loop kinematics, addresses a narrower but increasingly important problem in physical AI development: the sim-to-real gap, where a manipulation model trained entirely in simulation performs well in that simulation and then fails or behaves unpredictably on the physical gripper it was modeled after, because the simulated kinematics did not accurately capture how the real mechanism moves and responds to contact. Closed-loop kinematics in this context means the simulated gripper model incorporates feedback the same way the physical gripper does, rather than assuming idealized, open-loop motion, which should make a model trained against the updated Isaac Sim assets more likely to transfer its learned behavior to the real gripper without extensive retraining or fine-tuning on physical hardware.
The First Layer of a Bigger Software Bet
Robotiq is positioning these three releases as the first components of what it calls Contact Core, a physical AI software layer the company plans to build out with embedded intelligence capabilities expected in the fourth quarter of 2026. That framing changes how a buyer should read Tuesday's release: this is not a one-time open-source contribution meant to generate developer goodwill, it is the infrastructure layer for a product Robotiq intends to keep building on top of, which gives the company a direct incentive to keep maintaining the open-source packages rather than letting them stagnate the way many company-sponsored open-source projects eventually do once the initial publicity value fades. A developer or integrator adopting the ROS 2 package or the Isaac Sim assets today is, in effect, adopting the foundation Robotiq's own forthcoming Contact Core features will be built around, which is a meaningfully different commitment than adopting a generic community driver with no clear maintenance roadmap.
The strategic logic behind giving away foundational software while building a paid layer on top of it is a familiar one in developer tooling, and Robotiq's version of it is aimed squarely at winning the default integration slot in a specific, fast-growing niche: teams building manipulation models that need to train on and deploy to real gripper hardware. A robotics lab or startup building a general-purpose manipulation model has to pick some gripper to standardize its data collection around, and the gripper whose software stack offers the tightest simulation-to-reality fidelity and the most reliable open-source tooling has a real advantage in that decision, independent of any difference in the underlying mechanical hardware. By shipping company-maintained ROS 2 and Isaac Sim support ahead of most competitors, Robotiq is trying to make itself the default answer to that standardization question before a rival gripper maker does the same.
A Gripper Market That Has Mostly Competed on Mechanics
Robotiq was founded in Quebec City in 2008 and built its early reputation on adaptive grippers, particularly its 2F-85 and 2F-140 two-finger models, that became a common default choice for integrators pairing a cobot arm with a general-purpose gripping tool, competing against rivals such as Schunk, OnRobot and Zimmer Group largely on mechanical adaptability, force-sensing precision and ease of integration with major cobot brands. That competition has historically played out almost entirely at the hardware layer: which gripper can handle the widest range of object shapes and weights, which offers the finest force control, which integrates fastest with a given robot arm's native software. Software maintenance was a secondary consideration, handled through basic ROS drivers that a gripper vendor might publish once and then leave largely static, with the robotics community filling gaps as needed.
Physical AI development breaks that pattern because the software layer stops being a convenience feature and becomes part of the product's core value. A manipulation model training on millions of grasp attempts needs consistent, high-fidelity data from the gripper on every single cycle, and a simulation environment that does not accurately model the gripper's real kinematics will teach the model behavior that fails the moment it moves from simulation to physical hardware. That shift changes what counts as gripper differentiation: two mechanically similar grippers can produce meaningfully different training outcomes if one has tightly maintained, high-fidelity simulation assets and the other relies on a community-contributed model that has not been updated to reflect the hardware's actual closed-loop behavior. Robotiq's three releases are a direct bet that this software-layer differentiation, not incremental mechanical improvement, is where the next round of competitive advantage in end-of-arm tooling gets decided.
What This Means for a Team Choosing Gripper Hardware Today
For a procurement or engineering team evaluating end-of-arm tooling for a physical AI project rather than a fixed-cycle industrial line, the practical takeaway is that gripper selection now carries a software-maintenance dimension it did not carry a few years ago. A gripper with an actively maintained, company-backed ROS 2 driver and simulation assets reduces integration risk and engineering time relative to one whose community driver has an uncertain update cadence, particularly for a team that expects to iterate on a manipulation model over months or years rather than deploying once and leaving the configuration static. That said, the backward-compatible design of Robotiq's ROS 2 package, matching interfaces with the existing community drivers, means a team already running Robotiq hardware faces close to zero switching cost in trying the new package, which lowers the bar for adoption regardless of how the broader Contact Core roadmap plays out over the next several quarters.
Robotiq's bet is that the gripper layer of a physical AI stack becomes as consequential a vendor choice as the robot arm or the foundation model sitting above it, and that shipping company-maintained, simulation-ready open-source tooling now is what earns that position before the market settles on a default. The open question for a rival gripper maker is how long the current window stays open. Nothing about closed-loop kinematics or a company-maintained ROS 2 driver is proprietary in principle, and a competitor with comparable engineering resources could publish equivalent packages within a similar timeframe. What is harder to replicate quickly is the roadmap commitment behind Contact Core: Robotiq has signaled it intends to keep building paid, embedded intelligence features on top of this open-source foundation through the rest of 2026, which means a team standardizing on Robotiq hardware today is betting on sustained investment rather than a one-time release, a bet that only pays off if the company actually ships the Q4 features it has promised.
This account synthesizes Robotiq's public disclosures on the software packages released September 22, 2026. It is for general information purposes only and does not constitute investment, financial, or legal advice.
Hero image credit: Robotiq.











