migrate to OSQP v1.0 C API for rolling-resolute buildfarm release

[nbbrooks]

Why

A proper rolling-resolute buildfarm release of moveit_core is currently blocked. The chain:

• CMake 4 (Ubuntu Resolute default) removed the pre-3.5 policy compatibility layer.
• osqp_vendor 0.2.0 (in rosdistro rolling) still vendors OSQP v0.6.x, whose cmake_minimum_required(3.2) trips that removal.
• moveit2#3760 works around it in CI by setting CMAKE_POLICY_VERSION_MINIMUM=3.5 as a container env var (propagates into the ExternalProject_Add sub-build; the -D form doesn't).
• The ROS buildfarm doesn't inherit our DOCKER_RUN_OPTS, so that workaround is CI-only. A bloom release of moveit_core on resolute would fail at the same CMake-policy check the CI env-var papers over.

The unblocking upstream change ([tier4/osqp_vendor#25](https://github.com/tier4/osqp_vendor/pull/25), sea-bass fork) bumps the vendored OSQP to v1.0 — that version's CMake is naturally CMake-4-clean, no env-var hack needed. But OSQP v1.0 also redesigned the C API, and moveit_core::online_signal_smoothing::AccelerationFilter uses that API directly. So bumping the vendor version alone breaks moveit_core's compilation (verified — pushed the swap onto #3760 and CI immediately failed on OSQPWorkspace* and c_int symbols).

That leaves one route to a buildfarm-releasable rolling-resolute moveit_core: migrate the OSQP call sites to the v1.0 API in lockstep with the osqp_vendor version bump.

How

Proposed plan:

1. Track the upstream tier4/osqp_vendor#25 PR. Do not start the moveit_core migration until it's merged and released in rosdistro, or work against a local pin.
2. Port AccelerationFilter to the OSQP v1.0 C API. If keeping compatibility with humble/jazzy/kilted (which still ship osqp_vendor 0.2.0) matters, gate the two implementations behind a version macro on either osqp_vendor or an OSQP-provided version header — same shape as the AMENT_INDEX_CPP_VERSION_GTE guard used in resolute: complete ament_index_cpp::get_package_share_path migration #3705.
3. Validate against MoveIt's existing online-signal-smoothing regression tests (behavioural equivalence, not just build-clean).
4. Once merged: drop the osqp_vendor entry from moveit2_rolling.repos and the CMAKE_POLICY_VERSION_MINIMUM=3.5 line from the rolling-resolute CI matrix — the CI-only workaround becomes redundant.

The follow-up PR's commit message will carry the concrete API-diff (function renames, type renames, setup/solve signature changes) — leaving this issue focused on the release path.

[christian-rauch]

Since https://github.com/tier4/osqp_vendor appears unmaintained, and it is unclear when and if tier4/osqp_vendor#25 is going to be merged, and because osqp_vendor is such a critical dependency of the MoveIt stack, can I suggest that you move this dependency into the @moveit organisation and maintain it there?

@sea-bass If I fork tier4/osqp_vendor into @moveit, could you rebase your PR onto this fork? Also, would you be willing to maintain osqp_vendor, for example fix build issues and manage the bloom releases?

[sea-bass]

I generally am willing to help with the releases/issues for osqp_vendor, but the maintainer just responded to the issue this weekend, so things may finally be moving along? Though, there seems to be unwillingness to upgrade to 1.0.0 on Kilted and earlier distros because it breaks ABI.

But as you said, if stuff remains just as slow then we can switch the upstream location to a different source as a last resort. There is reasonable justification.

If we end up going down this route, probably the moveit org makes the most sense so I may need to be re-added to this release team. I'd offer up my org too, but I think we're actually going to move away from OSQP in favor of proxsuite so moveit makes more sense as the fallback.

[christian-rauch]

I generally am willing to help with the releases/issues for osqp_vendor, but the maintainer just responded to the issue this weekend, so things may finally be moving along?

The current maintainer is not with @tier4 any more. See tier4/osqp_vendor#28 and tier4/osqp_vendor#25 (comment). While he can approve these PRs, he cannot merge them and resolve the issue. @tier4 is not very responsive regarding merging critical PRs.

I wouldn't rely on such limbo maintainer relations, if a package is so important for MoveIt. We shouldn't need to wait for months until blocking issues are resolved. In terms of "supply chain management", MoveIt should be in control, or at least have good relations, with the dependencies it requires.

Though, there seems to be unwillingness to upgrade to 1.0.0 on Kilted and earlier distros because it breaks ABI.

I would only release this to lyrical and rolling any way.

But as you said, if stuff remains just as slow then we can switch the upstream location to a different source as a last resort. There is reasonable justification.

If we end up going down this route, probably the moveit org makes the most sense so I may need to be re-added to this release team. I'd offer up my org too, but I think we're actually going to move away from OSQP in favor of proxsuite so moveit makes more sense as the fallback.

I just requested to be added to the release team that can make new osqp_vendor releases (ros2-gbp/ros2-gbp-github-org#1078).

[sea-bass]

Yes, I meant the actual current maintainer responded, after several contact attempts from us and the former maintainer. See tier4/osqp_vendor#26 (comment)

You may also want to look at the Zulip thread in #Infrastructure General > Next actions for osqp_vendor release for Resolute distros where several of us have been discussing these plans too.

[christian-rauch]

Looking at https://github.com/osqp/osqp, this is a plain CMake package that already builds with colcon and installs libraries, headers, and the osqp-config.cmake etc.

This could be bloom-released with a patched package.xml, without requiring a separate osqp_vendor package.

[sea-bass]

oh nice! I actually went down that path very recently with the osqp_eigen package that we also additionally use over this in RoboPlan: gbionics/osqp-eigen#227

If we can follow this with core osqp too, it might be preferable. It's possible that the vendor repo was created because of maintainers' unwillingness to "bloat" their setup with build system specific additions like package.xml and specific install rules, but worth a try IMO.

EDIT: Oh, you mean patched as in the release repo could apply a patch on top. Yeah, that works too.

[christian-rauch]

If we can convince https://github.com/osqp/osqp to add a package.xml in their repo, like it has been done for https://github.com/stack-of-tasks/pinocchio, you can release directly from the tagged upstream repo.

[130s]

Another example of a catkin-agnostic repo accepting catkin framework (old, hence not colcon) https://github.com/AndreaCensi/csm