Before integrating Robotiq’s ROS 2 gripper packages, check three things: the action message required by your ROS distribution, whether the selected gripper has been tested on hardware, and the exact source revision behind the installation instructions. The same action endpoint can accept a different message type on Humble and Jazzy, and a shipped 2F-140 description does not establish hardware validation. A successful build alone answers neither question.
The latest published release checked on September 16, 2026 was v1.1.0, published on GitHub on August 14. Robotiq’s later August 26 announcement describes it as the official, Robotiq-maintained continuation of the community package. The current main branch already contains documentation beyond that tagged release, so release facts and development-branch instructions need to stay separate. This guide is a source review; we did not build the packages or connect hardware.
Start with the ROS distribution and action contract
The current support matrix lists Humble, Jazzy and Lyrical as supported targets. Their package, launch and controller names remain consistent, including the /robotiq_gripper_controller/gripper_cmd action endpoint. The message contract at that endpoint changes after Humble.
| ROS 2 distribution | Controller family | Action message | Repository status |
|---|---|---|---|
| Humble | position_controllers/GripperActionController |
control_msgs/action/GripperCommand |
Supported; merge-gating CI |
| Jazzy | parallel_gripper_action_controller/GripperActionController |
control_msgs/action/ParallelGripperCommand |
Supported; merge-gating CI |
| Lyrical | parallel_gripper_action_controller/GripperActionController |
control_msgs/action/ParallelGripperCommand |
Supported; merge-gating CI |
| Rolling | Moving development target | No supported contract promised | Observed by non-blocking CI; unsupported |
| Kilted and other non-LTS releases | — | — | Not built by this repository |
This is easy to miss during a migration: the action name can remain unchanged while a client built around Humble’s GripperCommand no longer matches Jazzy or Lyrical’s ParallelGripperCommand. Treat the action type as part of your interface contract. Check generated messages, client code and integration tests against the selected distribution rather than testing only whether the endpoint appears.
The distinction between supported and CI-observed matters too. The CI policy lets Rolling expose upcoming incompatibilities without making its job a release blocker. A successful job is not a support commitment. Kilted is not a fallback target in this matrix simply because it sits chronologically between named distributions.
Separate descriptions, drivers and hardware validation
The repository’s gripper stack includes descriptions for the 2F-85 and 2F-140. According to the pinned hardware section, hardware validation to date covers the 2F-85; the 2F-140 description ships without stated hardware validation. A model appearing in xacro, RViz or a launch argument therefore does not establish that the corresponding physical integration was tested.
Record three claims separately in an integration review:
- The description exists for the selected gripper.
- The driver exposes the interfaces the application needs.
- The exact hardware and distribution combination has been validated.
The repository also contains robotiq_tsf for the TSF-85 tactile sensor. That is a separate sensor stack, not evidence that tactile feedback is automatically present in a 2F gripper deployment. Include it only when the system actually uses that sensor and its dependencies.
For broader hardware selection questions, compare the mechanism, payload and sensing needs in the robot gripper types guide. Once the device is chosen, this package-specific checklist answers the narrower software compatibility question.
Pin the release, branch and source dependencies
The repository root VERSION file still reads 1.1.0 at the checked main commit, while the same README’s simulator notes describe an argument rename as occurring in 1.2.0. No v1.2.0 tag was present at the check time. That makes main a development snapshot, not evidence that version 1.2.0 has been published or that every current instruction belongs to the v1.1.0 release.
Choose either the published tag or a recorded commit, then keep its documentation with the build record. This is especially relevant to source dependencies. Both paths require the gripper SDK submodule, so the source checkout must include submodules. However, the tagged v1.1.0 instructions called for manual libserialport handling, while the checked main instructions say ordinary rosdep resolves the dependencies. Mixing those instructions can produce a workspace that is hard to reproduce.
The official material reviewed here documents source installation. We did not verify binary-package availability. Capture the commit or tag, ROS distribution, Ubuntu base, dependency resolution and SDK submodule revision in the integration record. The repository’s BSD-3-Clause license is a separate consideration from compatibility; check dependency licenses separately before distributing a combined build.
Interpret position and effort without inventing physical units
The current command documentation defines position as the knuckle joint angle in radians. It is not a jaw opening in millimetres. A planner that works in tool aperture needs an explicit, validated conversion for the selected geometry.
On Jazzy and Lyrical, the optional effort command is a grip threshold mapped through gripper_max_force to the gripper’s rFR setting. The documentation says this sets a maximum motor-current threshold; it does not directly command or measure the force applied at the fingers. Closing speed also affects the applied force, no force value is read back from the gripper, and motor_current is not convertible to force under this interface. Do not present the command value or motor-current reading as measured grasp force.
Before connecting hardware, confirm the following on a non-actuating review path:
- Pin the release tag or commit and the matching README.
- Match the ROS distribution to the correct action message type.
- Confirm the endpoint and joint names expected by the client.
- Include and record the SDK submodule revision.
- Distinguish model-description coverage from tested hardware coverage.
- Treat position as radians and effort as a configured threshold, then define separate hardware validation for aperture, speed and grasp force.
The ROS 2 control hardware-interface guide explains the wider controller-manager and hardware-plugin architecture. Use that architecture to place the Robotiq driver in the system, then use the matrix above to decide whether this exact package, distribution and gripper combination is ready for your integration test.