Release the gripper stack to the ROS build farm with bloom

[ebarnett3]

Goal

Release the gripper stack to the ROS build farm with bloom, so users install it with apt install ros-<distro>-robotiq-driver instead of cloning this repo and building from source. Target the distros the driver supports: Humble, Jazzy, Lyrical, plus Rolling so future distros pick it up automatically.

Packages in the first release: robotiq_msgs, robotiq_description, robotiq_driver, robotiq_controllers. robotiq_hardware_tests needs a gripper on a serial port and has no place on the farm. robotiq_tsf and mcp/ are out of scope for now; bloom releases every package it finds in the repo, so anything not released needs an ignore marker bloom honours (a CATKIN_IGNORE file in the package directory) or its own release repository.

Blockers

• SDK delivery (Choose how the grippers SDK is delivered to ROS consumers (submodule vs vendor package) #36). The farm builds from a tarball of the release repository, which never contains git submodules, so extern/grippers disappears and robotiq_driver cannot build. The SDK has to reach the farm either as a vendor package (ament_cmake_vendor_package, with a pinned SDK tag and SHA) or as a released package of its own that robotiq_driver finds with find_package. Vendor packages are allowed to download at build time on the farm. This is the decision Choose how the grippers SDK is delivered to ROS consumers (submodule vs vendor package) #36 was deferred on; the release forces it.
• Every dependency must resolve through rosdep. libserialport-dev already resolves (it is in rosdep's base list). The SDK's other dependencies need the same check once its delivery is decided. Anything missing needs a rosdep PR before the release PR.
• A monitored maintainer address. The farm sends build-failure mail to the <maintainer> in package.xml. Every gripper package lists noreply@robotiq.com, which nobody reads. Change it to an address the team monitors.

Steps

1. Resolve the blockers above.
2. Per-distro build check in ros:<distro> containers with BUILD_TESTING=ON; the farm runs the tests, and a failing test turns the package red on the status page.
3. Create the release repository robotiq/ros-release (bloom convention: <repo>-release).
4. Generate CHANGELOG.rst for each released package with catkin_generate_changelog, then tag with catkin_prepare_release. The repo's VERSION file and dev/version.py already keep one version across every package.xml, which is what bloom expects; catkin_prepare_release must not fight it, so decide which tool owns the bump.
5. bloom-release --rosdistro <distro> --track <distro> ros for each distro. The first run asks for the upstream URL, the release repository and the packages to release, then opens the rosdistro PR itself.
6. Once the rosdistro PRs merge, the packages appear on the next sync of each distro. Update the READMEs to lead with apt install, keeping the source build as the alternative.
7. Add the release procedure to CONTRIBUTING.md: SDK first, then ROS, per distro, with the sync cadence in mind.

Considerations

• The SDK pin ties the two release trains together: a ROS release can only ship against a tagged SDK release, so every ROS release now waits on an SDK tag.
• Humble's ROS 2 control API differs from Jazzy's and Lyrical's; the compat shims already exist and are tagged in code, but the farm builds each distro independently, so a shim that only compiles locally on Jazzy will break the Humble build.
• Documentation index: with a release entry in rosdistro we can also add a doc entry, which lists the packages on index.ros.org with their README.