Add support for FRI ver2.5

[cmower]

This PR adds support for ver2.5. @mhubii I'm not sure how you want to handle this? Currently this overwrites the v1.15. So the PR is not ready to merge. Probably good to add a switch in the build somewhere so the user can specify which version they use.

I would suggest creating a macro that specifies the FRI version, then use something like

#if FRI_VERSION == 115
// v1.15 implementation
#elif FRI_VERSION == 25
// v2.5 implementation
#endif

Also, I am getting the error when building:

--- stderr: lbr_fri_ros2                                                              
CMake Error at CMakeLists.txt:19 (add_subdirectory):
  add_subdirectory not given a binary directory but the given source
  directory "/home/cm22/balgrist_ws/src/fri/fri" is not a subdirectory of
  "/home/cm22/balgrist_ws/src/lbr_fri_ros2_stack/lbr_fri_ros2".  When
  specifying an out-of-tree source a binary directory must be explicitly
  specified.


CMake Error at CMakeLists.txt:41 (target_link_libraries):
  The plain signature for target_link_libraries has already been used with
  the target "lbr_fri_ros2".  All uses of target_link_libraries with a target
  must be either all-keyword or all-plain.

  The uses of the plain signature are here:

   * /opt/ros/foxy/share/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake:145 (target_link_libraries)



---

I think the issue is that I made the FRI package non-ament_cmake, so linking the library is not the same. Perhaps this is something you know better than me how to fix?

If you could let me know if you have any ideas re this issue above then I'll fix, and can do the macro support switch thing i mention above. However, for this I will also need to know how you want to handle the switch? Ie. where you think it should be placed?

[mhubii]

this PR needs some re-design. Below is the (approximate) new layout

• fri needs to be turned into a vendor package, see Turn this repo into a vendor fri#10

• fri target needs to be created from .zip files, somewhere here https://github.com/cmower/FRI-Client-SDK_Cpp/

• this change should be conform with novel Python bindings https://github.com/cmower/FRI-Client-SDK_Python/

• this change requires lbr_fri_msgs to live outside this stack, as the IDL changes with changing fri versions

• given the python bindings, enums like these https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/blob/59f714ecde55dcfa5d5a71707f6ce1c5825cf301/lbr_demos/lbr_fri_ros2_python_demos/lbr_fri_ros2_python_demos/joint_sine_overlay_node.py#LL33C56-L33C73 might be changed

[mhubii]

this logic is now mostly implemented in

https://github.com/KCL-BMEIS/fri
https://github.com/KCL-BMEIS/fri_vendor/

dev-humble-fri-vendor branch
https://github.com/kCL-BMEIS/lbr_fri_ros2_stack/tree/dev-humble-fri-vendor

[mhubii]

hi @cmower , is this something we can revive? Or are you too occupied? Asking because we will be going to Zurich in April

I am only a little afraid of re-basing this PR to humble branch, not sure your contribution is tracked in that scenario. Maybe I can commit under your name?

Also refers to lbr-stack/fri#8

[mhubii]

Closing in favor of #158