Package request: roboplan

[sea-bass]

Package name

roboplan

Operating System(s)

• linux-64
• linux-aarch64
• osx-64
• osx-arm64
• win-64

Additional context (optional)

https://github.com/open-planning/roboplan

Doesn't work on Windows, but it does on Linux and macOS on conda-forge and PyPi.

Package list:

• roboplan
• roboplan_cartesian_planning
• roboplan_example_models
• roboplan_examples
• roboplan_oink (will require osqp-eigen from conda to work)
• roboplan_rrt
• roboplan_simple_ik
• roboplan_toppra

These packages are already on conda-forge as roboplan-SUBPACKAGE-python (with python bindings) or libroboplan-SUBPACKAGE (without) in https://github.com/conda-forge/roboplan-feedstock, so wondering if for RoboStack we can just grab the python ones?

Links and references (optional)

No response

[traversaro]

Are these packages released in the ROS buildfarm? If yes, we can just add them and then reused the conda-forge builds with generate_dummy_package_with_run_deps. If they are not available on the ROS buildfarm, I guess we can add them as additional recipes, and then use anyhow generate_dummy_package_with_run_deps, even if I never tested this combination.

Just to understand, this issue is not about packaging https://github.com/open-planning/roboplan-ros ?

[sea-bass]

OK so a lot of details from my attempts.

The core roboplan packages are on the buildfarm but full releases are being held up by:

• proxsuite needing a new release for their 0.7.3 version. This makes roboplan_oink and the downstream roboplan_cartesian_planner / roboplan_examples also not work. However, this is already on conda-forge.
• On Humble, nanobind is not available via apt (it's a pip dependency), so it cannot be on the buildfarm for this distro. Again, on conda forge though!

roboplan-ros hasn't yet made it onto the buildfarm because of the above. Basically no point in trying until the core is releasable first.

Also, and very importantly... roboplan core packages are directly on conda-forge. So we could also simply grab them from there and forget the buildfarm efforts, using dummy packages as you suggested?

Is it sufficient that the keys are available on rosdistro to do this, even if not fully released? Just so rosdep resolves then?

[sea-bass]

@traversaro We've made updates to roboplan since, and Windows is now supported.

Due to proxsuite still not updated to work with the ROS buildfarm, the number of roboplan packages on the buildfarm is still incomplete. Should we wait until this is all squared away, or should we instead go with the (already working) conda-forge packages?

[traversaro]

@traversaro We've made updates to roboplan since, and Windows is now supported.

Due to proxsuite still not updated to work with the ROS buildfarm, the number of roboplan packages on the buildfarm is still incomplete. Should we wait until this is all squared away, or should we instead go with the (already working) conda-forge packages?

We can add them as additional recipes, see https://github.com/RoboStack/ros-rolling/blob/main/rosdistro_additional_recipes.yaml .

[sea-bass]

oh cool -- I think I was able to get this working in #38.

Could you tell me if I'm on the right track? It built locally at least...

[traversaro]

oh cool -- I think I was able to get this working in #38.

Could you tell me if I'm on the right track? It built locally at least...

The direction seems nice. I only wonder if perhaps you want to reuse the packages that are already in conda-forge, such as all the non-ROS roboplan packages and toppra? Otherwise if a user install both ros2-roboplan from robostack and roboplan from conda-forge, it would result in incompatibilities.

This can be done by adding generate_dummy_package_with_run_deps sections in pkg_additional_info.yaml, see for example

ros-rolling/pkg_additional_info.yaml

Lines 125 to 128 in 296fd19

	octomap:
	generate_dummy_package_with_run_deps:
	dep_name: octomap
	max_pin: 'x.x'

.

[sea-bass]

done! Toppra needs a patch so I left it for now, but the others seem to have worked

[traversaro]

done! Toppra needs a patch so I left it for now, but the others seem to have worked

I guess the conda-forge roboplan will bring in conda-forge toppra, so having a robostack toppra seems to install two different toppra libraries, that seems quite dangerous. What is necessary to fix the toppra issue in conda-forge ?

[sea-bass]

Yeah, I just realized this too, actually it seems like the conda-forge toppra works fine, since the issue was specifically with ament related macros.

This is the fix I'm going to get upstream btw: hungpham2511/toppra#299

[traversaro]

If you need to toppra to be listed by ros2 pkg list, you will need the toppra conda-forge package to install package.xml and an empty file in ament_index/resource_index/packages. See for example https://github.com/gbionics/resolve-robotics-uri-cpp/tree/main/examples/example_cmake_package .

[sea-bass]

Don't think I need that (unless it's required for other reasons), but one thing I did just notice is I never supported multiple Python versions for the toppra feedstock: conda-forge/toppra-feedstock#15

[sea-bass]

Actually seems like I may have had some build outputs cached. Locally, after deleting the output/ folder and switch to the conda-forge version of the roboplan, I get incompatibilities with coal.

I can update the overridden coal version in pkg_additional_info.yaml to 3.0.4, and that works in my local build, but that may not be okay to do?

  ╰─▶ Cannot solve the request because of: The following packages are incompatible
      ├─ ros2-roboplan * can be installed with any of the following options:
      │  └─ ros2-roboplan 0.6.0 would require
      │     ├─ roboplan-python >=0.6.0,<0.7.0a0, which can be installed with any of the following options:
      │     │  └─ roboplan-python 0.6.1 would require
      │     │     └─ libcoal >=3.0.4,<3.0.5.0a0, which can be installed with any of the following options:
      │     │        └─ libcoal 3.0.4
      │     └─ ros2-pinocchio *, which can be installed with any of the following options:
      │        └─ ros2-pinocchio 4.0.0 would require
      │           ├─ ros2-coal *, which can be installed with any of the following options:
      │           │  └─ ros2-coal 3.0.3 would require
      │           │     └─ coal >=3.0.3,<3.0.4a0, which can be installed with any of the following options:
      │           │        ├─ coal 3.0.3 would require
      │           │        │  └─ coal-python ==3.0.3 py314hc25f7af_1, which can be installed with any of the following options:
      │           │        │     └─ coal-python 3.0.3 would require
      │           │        │        └─ eigenpy >=3.12.0,<3.12.1.0a0, which can be installed with any of the following options:
      │           │        │           └─ eigenpy 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 |
      3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 | 3.12.0 would require
      │           │        │              └─ libboost-python >=1.88.0,<1.89.0a0, which can be installed with any of the following options:
      │           │        │                 ├─ libboost-python 1.88.0 would require
      │           │        │                 │  └─ libboost ==1.88.0 hd24cca6_7, which can be installed with any of the following options:
      │           │        │                 │     └─ libboost 1.88.0
      │           │        │                 ├─ libboost-python 1.88.0 would require
      │           │        │                 │  └─ libboost ==1.88.0 hed09d94_6, which can be installed with any of the following options:
      │           │        │                 │     └─ libboost 1.88.0
      │           │        │                 ├─ libboost-python 1.88.0 would require
      │           │        │                 │  └─ libboost ==1.88.0 hed09d94_5, which can be installed with any of the following options:
      │           │        │                 │     └─ libboost 1.88.0
      │           │        │                 ├─ libboost-python 1.88.0 would require
      │           │        │                 │  └─ libboost ==1.88.0 hed09d94_4, which can be installed with any of the following options:
      │           │        │                 │     └─ libboost 1.88.0
      │           │        │                 ├─ libboost-python 1.88.0 would require
      │           │        │                 │  └─ libboost ==1.88.0 hed09d94_3, which can be installed with any of the following options:
      │           │        │                 │     └─ libboost 1.88.0
      │           │        │                 └─ libboost-python 1.88.0 would require
      │           │        │                    └─ libboost ==1.88.0 hed09d94_2, which can be installed with any of the following options:
      │           │        │                       └─ libboost 1.88.0
      │           │        └─ coal 3.0.3 would require
      │           │           └─ libcoal ==3.0.3 h5d272c1_0, which can be installed with any of the following options:
      │           │              └─ libcoal 3.0.3 would require
      │           │                 └─ libboost >=1.88.0,<1.89.0a0, which can be installed with any of the following options:
      │           │                    ├─ libboost 1.88.0
      │           │                    ├─ libboost 1.88.0
      │           │                    ├─ libboost 1.88.0
      │           │                    ├─ libboost 1.88.0
      │           │                    ├─ libboost 1.88.0
      │           │                    ├─ libboost 1.88.0
      │           │                    └─ libboost 1.88.0 | 1.88.0
      │           └─ ros2-eigenpy *, which can be installed with any of the following options:
      │              └─ ros2-eigenpy 3.13.0 would require
      │                 └─ eigenpy >=3.13.0,<3.13.1a0, which can be installed with any of the following options:
      │                    └─ eigenpy 3.13.0
      ├─ ros2-distro-mutex 0.19.* rolling_* cannot be installed because there are no viable options:
      │  └─ ros2-distro-mutex 0.19.0 would constrain
      │     └─ libboost 1.90.*, which conflicts with any installable versions previously reported
      └─ ros2-ros-workspace * cannot be installed because there are no viable options:
         └─ ros2-ros-workspace 1.0.3 would require
            └─ python_abi 3.14.* *_cp314, which cannot be installed because there are no viable options:
               └─ python_abi 3.14, which conflicts with the versions reported above.

[traversaro]

I can update the overridden coal version in pkg_additional_info.yaml to 3.0.4, and that works in my local build, but that may not be okay to do?

In general it would be a problem due to ABI, but in 3.0.3 --> 3.0.4 nothing in the library changed (see coal-library/coal@v3.0.3...v3.0.4). However, it seems that the soversion for that library is set to x.x.x, see:

(test242) straversaro@gblaptop0086:~/test242$ ldd ./.pixi/envs/default/lib/libpinocchio_collision.so
        linux-vdso.so.1 (0x00007ffd64597000)
        libpinocchio_default.so.4.0.0 => /home/straversaro/test242/./.pixi/envs/default/lib/./libpinocchio_default.so.4.0.0 (0x00007aeb6a600000)
        libcoal.so.3.0.3 => /home/straversaro/test242/./.pixi/envs/default/lib/./libcoal.so.3.0.3 (0x00007aeb69e00000)
        libstdc++.so.6 => /home/straversaro/test242/./.pixi/envs/default/lib/./libstdc++.so.6 (0x00007aeb69a00000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007aeb6acfb000)
        libgcc_s.so.1 => /home/straversaro/test242/./.pixi/envs/default/lib/./libgcc_s.so.1 (0x00007aeb6a5d2000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007aeb69600000)
        libassimp.so.6 => /home/straversaro/test242/./.pixi/envs/default/lib/././libassimp.so.6 (0x00007aeb68a00000)
        libboost_serialization.so.1.90.0 => /home/straversaro/test242/./.pixi/envs/default/lib/././libboost_serialization.so.1.90.0 (0x00007aeb6a58b000)
        libboost_filesystem.so.1.90.0 => /home/straversaro/test242/./.pixi/envs/default/lib/././libboost_filesystem.so.1.90.0 (0x00007aeb6a55d000)
        libqhull_r.so.8.0 => /home/straversaro/test242/./.pixi/envs/default/lib/././libqhull_r.so.8.0 (0x00007aeb6a4e1000)
        liboctomap.so.1.10 => /home/straversaro/test242/./.pixi/envs/default/lib/././liboctomap.so.1.10 (0x00007aeb6a47a000)
        liboctomath.so.1.10 => /home/straversaro/test242/./.pixi/envs/default/lib/././liboctomath.so.1.10 (0x00007aeb6acee000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007aeb6ace9000)
        /lib64/ld-linux-x86-64.so.2 (0x00007aeb6adfe000)
        libz.so.1 => /home/straversaro/test242/./.pixi/envs/default/lib/./././libz.so.1 (0x00007aeb69de5000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007aeb6a475000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007aeb69de0000)

so changing the patch version would indeed break ABI. So unfortunately we need a full rebuild. We should definitely add libcoal and pinocchio to the global conda-forge pinnings to reduce the time this is happening.

[sea-bass]

So unfortunately we need a full rebuild.

I can try switching to that by following https://robostack.github.io/Contributing.html#doing-a-full-rebuild, one sec