If you run a Robotiq gripper in the Robot Operating System (ROS) 2 workspace today, you are almost certainly running PickNik Robotics’ ros2_robotiq_gripper. As of today, there is an official Robotiq-maintained package, and it is a drop-in replacement: same package names, same launch files, same controller interfaces.
Version 1.1.0 is live in github.com/robotiq/ros, open source under the BSD-3-Clause license, and it builds on Humble, Jazzy, and Lyrical from a single branch.
Four packages ship under grippers/:
robotiq_driver, the ros2_control hardware interfacerobotiq_controllers, the gripper command and activation controllersrobotiq_description, the URDF and xacro descriptions, meshes, RViz configuration, and bringup launch filesrobotiq_hardware_tests, integration tests that run against real hardware
Descriptions ship for the 2F-85 and the 2F-140. This release is hardware-validated on a 2F-85.
Underneath, the hardware interface runs on Robotiq’s open-source C++ SDK at version 1.0.0, pulled in as a submodule. ROS and non-ROS applications now share one tested core, so a fix to how the gripper is driven reaches both at once.
Why Robotiq Releases ROS 2 Packages for Adaptive Grippers
Robotiq grippers run in ROS 2 today because the community put them there. The PickNik package, and every developer who filed an issue or a patch against it, is the reason a Robotiq gripper is an ordinary thing to find in a ROS workspace. Plenty of working cells depend on it.
What changed is the demand. Physical AI applications are asking more of these grippers than a conventional pick-and-place cell ever did: tighter control loops, more of what the gripper reports, and deployments they expect to run for millions of cycles. We wanted to hand them the most optimized and maintained package we could.
So we took it on. These packages are the maintained successor to the community driver, with the upstream history and every copyright and author tag carried across.
What changed
The surface API is a drop-in. The implementation is not the same package it was, and most of what changed came from customer and partner feedback.
- A shared, versioned core. The hardware interface is a thin layer over the C++ SDK, which follows semantic versioning from 1.0.0 and ships its own hardware-free test suite. It also retires the
vcs importstep: the driver linkslibserialportthrough the SDK instead of a forked serial library. - Three distributions, one branch. Humble, Jazzy, and Lyrical build from the same source, with continuous integration (CI) gating every pull request on all 3 and Rolling running non-blocking. Nobody should have to plan a ROS upgrade around a gripper.
- Predictable bring-up. Activation and fault recovery are bounded by an
activation_timeoutinstead of running open-ended, and a connection that cannot be opened fails cleanly during configuration. - One transaction per cycle. The exchange with the gripper is a single Modbus function code 0x17 read-write transaction, replacing separate reads and writes on the wire. This makes it possible to achieve a communication frequency of 200 Hz with the gripper at 115200 baud.
- Configurable hardware parameters. Serial and timing parameters live in the
<hardware>block of your description rather than in the driver. - A fake gripper with real semantics. Set
use_dummyin your description’s<hardware>block and the driver runs the SDK’s fake device instead of a port: no port opened, instant activation, and the real plugin still loaded, so both controllers bind as they do on hardware. Distinct fromuse_fake_hardware:=true, which swaps inros2_control'smock_components/GenericSystem.
Moving from the community package
The migration is short, and it is documented in the release notes. In an existing workspace:
Three things to know. --recurse-submodules matters, because that is how the SDK arrives. libserialport installs manually, since no rosdep key exists for it yet, which is also why these packages are a source install rather than a bloom release for now. And on Jazzy and Lyrical the action type is ParallelGripperCommand, following an upstream change in ros2_controllers and control_msgs, while Humble keeps the older GripperCommand.
Bringing up a gripper in Jazzy/Lyrical
Commands as of August 2026. Please refer directly to the repository for the latest version.
Add launch_rviz:=true to bring up the visual model alongside it. The bringup activates joint_state_broadcaster, robotiq_gripper_controller, and robotiq_activation_controller, and holds its terminal, so command the gripper from a second shell:
Position is the knuckle joint angle in radians, running from roughly 0.0 open to 0.8 closed on a 2F-85. Effort and velocity are optional per-goal maximum limits.
To inspect the model with nothing plugged in, skip ros2_control entirely and drag the slider:
What’s next
The next substantial piece of work is getting more of what the gripper reports up through the ROS interface, starting with object detection and measured effort. The repository is also where Robotiq’s other ROS packages live. The TSF-85 tactile sensor driver was updated in this same release, with a new SDK-backed node, USB autodetection, a first-data watchdog, and RViz visualization with 3D markers and 2D heatmaps.
Beyond that, the roadmap follows what you build. Issues and pull requests filed on GitHub directly inform what comes next, exactly as they did for the package this one carries forward.
Getting started
Gripper-only users should replace the final colcon build with the README’s
Issues, pull requests, and feedback are welcome on GitHub.
Learn more about Robotiq’s physical AI at robotiq.com/physical-ai.
![]()
The post “Robotiq Releases ROS 2 Packages for Adaptive Grippers” by Robotiq Team was published on 08/26/2026 by blog.robotiq.com



















