Using FRI for the KMR IIWA

[protoCore160]

Hello,

I have already used FRI alone on an LBR iiwa.
I now want to check if it is possible to use FRI on a KMR iiwa (KMP base + LBR).
The ROS 2 package found (kmr_iiwa - https://github.com/MortenMDahl/kmriiwa_ws_devel) should be fine for the base, but its arm control does not fit our needs. For context, see the diagram attached below (original communication layout) or the github link provided.

Note: We currently do not have physical access to the KMR and our time window is limited, so an early feasibility check and any blockers/gotchas would be very helpful.

Is it possible to run a single Sunrise application where:

• the base keeps its existing ROS 2 TCP interface (control + odometry/scanners), and

• the arm is controlled via FRI (UDP) using lbr_fri_ros2_stack?

Questions:

• Can FRI (UDP) run in parallel with the base TCP communication within the same Sunrise application?

• Is this setup feasible?

Thanks!

[mhubii]

Hi @protoCore160, sorry I have no experience.

Generally speaking, the FRI on Sunrise runs blocking. So to run another communication, one would have to run it asynchronously, which seems possible in Java.

But then again, I've never gotten to use a base.

[protoCore160]

Thanks @mhubii, that’s already helpful.

We’ll look into it. If anyone has tried this on a KMR iiwa with Sunrise, any extra hints would be very welcome.

[LAKY911]

Hi @protoCore160 — I have access to the KMR system and I’m trying to get the lbr-stack working. Do you have any update? Have you already tried running this setup with KMR + FRI?

Regarding the FRI, both of our KMRs have only a single Ethernet port—unlike the standard LBR iiwa controller, which provides both the X66 and KONI ethernet ports. Did you happen to verify whether FRI can be run through the KMR’s only Ethernet port, or if there’s any workaround for exposing the KONI-equivalent interface on the KMR?

[protoCore160]

@LAKY911 I’ve used the FRI ROS 2 package with the KMR through the front KLI port, and it worked very well at 5ms. If you ever need higher speeds, the KONI interface is also available internally, although it doesn’t provide direct external access. Since the LBR controller is located inside the cabinet, this robot is essentially a combination of two products that were not originally designed as a single integrated system.

[LAKY911]

@protoCore160 Great, how did you combine both the lbr_fri_ros2_stack with the KMR? Are you willing to share the code which you've uploaded to the controller?

Thank you!

[protoCore160]

@LAKY911 The NTNU module for the mobile base has some issues — it was originally built for Sunrise 1.16, while we're using 1.17. We were having trouble getting the laser scan and odometry to work, but we managed to implement a new sensor reader that fixes this, probably we still have to do some tests here.

In isolation, we tested the arm without the NTNU modules and as I said above it was working very well.

The next step would be to remove all the LBR-related code from the NTNU stack and integrate a new FRI LBRServer.java (code from this package), running in a separate thread within the same application that controls the mobile base.

Right now, we’re waiting for the robot to return so we can continue development, so the work is not finished yet.

If we manage to get everything working, we’ll probably try to share it in a repository. Since the documentation and guidance for the KMR is quite limited, this LBR stack has been the only thing well documented.

[MarekFeik]

Hi @protoCore160, I’m working on a very similar setup and facing the same challenges with the NTNU stack on Sunrise 1.17.0.5

I was wondering if you’ve made any progress with removing the LBR-related code and integrating the FRI LBRServer.java as a separate thread? If you’ve managed to set up a repository or have any lessons learned from the integration, it would be incredibly helpful to hear about it. Thanks for any updates!