Package request: lbr_fri_ros2_stack

[garylvov]

Package name

lbr_fri_ros2_stack

Operating System(s)

• [x] linux-64
• [ ] linux-aarch64
• [ ] osx-64
• [ ] osx-arm64
• [ ] win-64

Additional context (optional)

Hi, I'd love to add support for KUKA arms in RoboStack! Thank you for the great work on this project!

I plan to try the vinca.yaml soon

Links and references (optional)

Package Repo: https://github.com/lbr-stack/lbr_fri_ros2_stack

[traversaro]

At a first glance, the repo is not released in rosdistro?

In that case, you can nevertheless package it in robostack, but I am afraid the correct steps are not documented in https://robostack.github.io/Contributing.html at the moment. In particular, on top of adding the package in vinca, you also need to add all the packages you are interested in in the rosdistro_additional_packages.yaml file. If you tried and you found any problem, feel free to ask!

[garylvov]

Hi, one of my lab mates, @kenichi-maeda has been kind enough to take care of this.

https://github.com/kenichi-maeda/ros-humble/tree/add-lbr-fri-ros2-stack

I will test it within the next few days on hardware, we'll PR it after we make sure it works!

@mhubii for viz

[mhubii]

Hi All, that's really great news. Just to provide some context: the lbr_fri_ros2_stack is not released in rosdistro because it compiles against multiple robot vendor SDK versions. Please also refer ROS Discourse: https://discourse.openrobotics.org/t/help-needed-distribute-a-ros-package-against-multiple-sdk-versions/40827/2

Would RoboStack support such scenarios?

On another note, is it also possible to distribute for Jazzy? The Humble LTS does currently lack a little behind with some features.

[traversaro]

Hi, one of my lab mates, @kenichi-maeda has been kind enough to take care of this.

https://github.com/kenichi-maeda/ros-humble/tree/add-lbr-fri-ros2-stack

I will test it within the next few days on hardware, we'll PR it after we make sure it works!

@mhubii for viz

Great, thanks!

[garylvov]

On another note, is it also possible to distribute for Jazzy? The Humble LTS does currently lack a little behind with some features.

We can add Jazzy next!

Hi All, that's really great news. Just to provide some context: the lbr_fri_ros2_stack is not released in rosdistro because it compiles against multiple robot vendor SDK versions. Please also refer ROS Discourse: https://discourse.openrobotics.org/t/help-needed-distribute-a-ros-package-against-multiple-sdk-versions/40827/2

Would RoboStack support such scenarios?

I'm not sure about compiling against a specific robot vendor SDK. We intend to use FRI 1.15 on our setup.I guess that the realsense packages in robostack must solve a similar problem with librrealsense. From what I remember, each realsense driver package in RoboStack is pinned against a single librealsense version.

I'll defer to @traversaro any insight would be appreciated on this front!

[garylvov]

Maybe we can build FRI versions into conda and just have the user be able to specify in their manifest?

[traversaro]

I'm not sure about compiling against a specific robot vendor SDK. We intend to use FRI 1.15 on our setup.I guess that the realsense packages in robostack must solve a similar problem with librrealsense. From what I remember, each realsense driver package in RoboStack is pinned against a single librealsense version.

I'll defer to @traversaro any insight would be appreciated on this front!

Ok, I now looked a bit into this. So, in RoboStack we do not have any feature to build multiple version of the same ROS/robostack package in the same rebuild. If that is something of interest for you, I think the easiest way to proceed would be to add https://github.com/lbr-stack/fri.git to conda-forge, and there support all the version you are interested in via abi_migration_branches, see https://conda-forge.org/docs/how-to/advanced/several-versions/ . Once that is done, we can add all the version of fri you want to target in https://github.com/RoboStack/ros-humble/blob/main/conda_build_config.yaml, and then rattler-build will automatically build multiple variants of packages that use fri for each version of fri. As long as the packages that use fri are not so much, I think that would be ok to do.

[mhubii]

Thanks for looking into this @traversaro! Let's give this a go, and revert if compile time becomes unaccetable.

[garylvov]

Thank you for looking into this @traversaro those steps really help!!

We will try it! If we can't figure it out, for now, we will package only FRI 1.15 for Humble.

[mhubii]

that'd be a great step! Thanks @garylvov :)

[traversaro]

On a related note, why you are interested in packaging different versions? It is useful to have old versions as robots may need older version to work?

[garylvov]

I think @mhubii can probably speak to this better than I can.

From our end, our robot already has FRI 1.15. On Kuka's website, it costs ~7K USD to purchase FRI 2.5.

At this cost, it would make sense for my lab to purchase two new arms without predatory software prices (such as the Agilex Piper) instead of upgrading.

[mhubii]

On top, KUKA has no remote software updates in place, complicating upgrades even further and requiring engineers on site.

For some reason, KUKA keeps:

1. Breaking SDK API. This is currently handleled via pre-processor directives. There surely are alternatives to this approach.
2. Breaking compatability, even for patches, like 1.15 -> 1.16.

[kenichi-maeda]

I'm not sure about compiling against a specific robot vendor SDK. We intend to use FRI 1.15 on our setup.I guess that the realsense packages in robostack must solve a similar problem with librrealsense. From what I remember, each realsense driver package in RoboStack is pinned against a single librealsense version. I'll defer to @traversaro any insight would be appreciated on this front!

Ok, I now looked a bit into this. So, in RoboStack we do not have any feature to build multiple version of the same ROS/robostack package in the same rebuild. If that is something of interest for you, I think the easiest way to proceed would be to add https://github.com/lbr-stack/fri.git to conda-forge, and there support all the version you are interested in via abi_migration_branches, see https://conda-forge.org/docs/how-to/advanced/several-versions/ . Once that is done, we can add all the version of fri you want to target in https://github.com/RoboStack/ros-humble/blob/main/conda_build_config.yaml, and then rattler-build will automatically build multiple variants of packages that use fri for each version of fri. As long as the packages that use fri are not so much, I think that would be ok to do.

I'm working on it now (https://github.com/kenichi-maeda/staged-recipes/tree/add-lbr-fri-client-sdk), and will link to the PR once it's done

PR: https://github.com/conda-forge/staged-recipes/pull/31958

[mhubii]

Maybe to add to the complexity 😅.

There is an interface definition language (IDL) per major FRI version, somewhat going against the notion of an IDL:

FRI	1.11, ..., 1.17	2.5	2.7 (KUKA falsly ships this as 2.7, but it really is 3.0)
IDL	1.x	2.x	3.x

The lbr_fri_ros2_stack compiles against matching FRI-IDL using pre-processor directives.

Changes to the IDL might be necessary to make the above happen.

[kenichi-maeda]

Maybe to add to the complexity 😅.

There is an interface definition language (IDL) per major FRI version, somewhat going against the notion of an IDL:

FRI 1.11, ..., 1.17 2.5 2.7 (KUKA falsly ships this as 2.7, but it really is 3.0) IDL 1.x 2.x 3.x The lbr_fri_ros2_stack compiles against matching FRI-IDL using pre-processor directives.

Changes to the IDL might be necessary to make the above happen.

@traversaro For this, do you think it makes sense to add https://github.com/lbr-stack/lbr_fri_idl to conda-forge like FRI?