EKI instead of RSI

[durovsky]

In addition to Robot Sensor Interface, there is also Ethernet KUKA Interface available. Is there any particular reason why RSI is preferred? From product description EKI seems to be more suitable for the purposes of ROS-I driver.

[gavanderhoorn]

RSI allows for 250 Hz real-time joint position control by the hw interface component. Apart from FRI (which is meant for different use-cases / controllers), I don't think you'll find a more performant external motion interface for KUKA KR* controllers.

EKI seems to be more suitable for the purposes of ROS-I driver.

can you elaborate a bit on why you feel this is the case?

[gavanderhoorn]

Btw: EKI might be a nice way to implement some other interfaces to KUKA controllers from ROS nodes, but I'm specifically thinking of the motion interface here, as you asked why RSI is used in the hw interface.

[gavanderhoorn]

I remember @simonschmeisser mentioning EKI some time ago as well.

[durovsky]

One more question to clarify before we continue: From my previous experience with ROS-I driver it was always stream trajectory first and then execute (ABB, Motoman for example) . I thought that the role of ROS-I driver is to allow performing plan&execute approach. Why real-time control in case of KUKA?

[tingelst]

The initial use case for the RSI hw interface was a force control application. That is the reason for RSI over EKI.

Unfortunately, we (NTNU) have not any EKI licenses on our robots, so we are not in a position to develop or test such an interface at this time. However, we are in contact with KUKA regarding upgrading our controllers with EKI.

[gavanderhoorn]

From my previous experience with ROS-I driver it was always stream trajectory first and then execute (ABB, Motoman for example)

abb_driver implements a download approach, motoman_driver is a streaming driver. The former uploads (download from the controller's pov) the entire trajectory, then executes. The latter streams a trajectory pointwise (with a small buffer on the controller side).

I thought that the role of ROS-I driver is to allow performing plan&execute approach.

Yes? Both downloading and streaming would seem to support that.

Why real-time control in case of KUKA?

Because it covers both the use-cases that more 'traditional' ros-i drivers support, as well as more high-fidelity (high-bw) and real-time use-cases (such as visual servoing). We use ros_control (and specifically joint_trajectory_controller) to in the end expose a ROS-I compatible JointTrajectory action interface, which hides all the differences (while enjoying all the advantages of a higher-bw interface).

Btw: there is no requirement for ROS-I drivers to use the common infrastructure and messaging system provided by the industrial_robot_client packages: simple_message is by no means a panacea, and especially for vendors that already provide good external motion interfaces (ABB, KUKA, Mitsubishi, etc) those are preferred, as they typically allow for much better trajectory execution and motion control.

[gavanderhoorn]

@tingelst wrote:

The initial use case for the RSI hw interface was a force control application. That is the reason for RSI over EKI.

and I'm glad the hw interface uses RSI.

However, we are in contact with KUKA regarding upgrading our controllers with EKI.

At least for external motion control purposes I don't think EKI would be considered an upgrade, right?

[simonschmeisser]

@gavanderhoorn Yes you're right, we used a EKI based interface (EthernetXML) with a customn protocoll for our demo during Automatica 2016 (at the IPR booth). It definitely has some up-sides as well

• it's cheaper (factor 2)
• your PC does not need to give any real-time guarantees (I still didn't get to testing the 'low latency' variants ...)
• it's easier to debug
• you can do some manual controller side checking (we had some issues with collision checking so it was nice to have this as a fallback)
• unrelated to control: you can send arbitrary data and execute subprograms on the controller

on the down-side:

• while execution of dense trajectories can reach full speed (using spline mode), transmitting/interpreting or similar introduced some noticeable delay. We didn't have access to the hardware to further debug this and kuka was unwilling to give/lend us a copy of their simulator for a reasonable price.

generally speaking I like the dead-simple nature of trajectory uploading based control.

@durovsky are you at photoneo using ros-I itself or are you just looking for some general info?

[durovsky]

@gavanderhoorn thanks for clarification about downloading and streaming, I wasn't sure about the streaming part. Learned something new again.
@simonschmeisser we are not using ros-I. It is not entirely suitable for our purposes. Recently we have also developed our own "downloading" interface for KUKA using EKI. And our experience was similar as you have written, much simpler than RSI based version, does not require ros_control and enables trajectory execution as well. So just I wanted to know why is RSI preferred in case of ROS-I. But if real-time control is required in addition to the trajectory downloading than okay, keep RSI interface.

[gavanderhoorn]

@durovsky wrote:

So just I wanted to know why is RSI preferred in case of ROS-I. But if real-time control is required in addition to the trajectory downloading than okay, keep RSI interface.

I feel I didn't completely make this clear: RSI does not support down- or uploading or trajectories: it allows us to close the (feedback) loop on a low-level joint space or Cartesian position controller over a high-bandwidth, low-latency interface. That is not something that most other simple_message based drivers do (although it is possible).

For all intents and purposes, high-bw, low-latency seem like a good thing to me.

By layering ros_control on top of that, and then a joint_trajectory_controller plugin, we get a 'traditional' JointTrajectory action interface, that supports the same semantics as the nodes in industrial_robot_client (ie: goals, status tracking, preemption, etc).

So at the ROS API level, the hw interface is compatible with industrial_robot_client. At a lower level however, it provides a much more performant interface to a KUKA controller, that enables us to cover use-cases that otherwise would not be possible (ie: performance of EKI will never approach that of RSI). For applications where things like force control are required (like @tingelst mentioned) only RSI will provide enough bandwidth and remove enough latency to make that possible.

And our experience was similar as you have written, much simpler than RSI based version, does not require ros_control and enables trajectory execution as well.

I'm curious what you found "much simpler". In my experience setting up the RSI component is a matter of following the readme, starting the small controller side program and the hw interface. At that point it becomes "just another" ROS enabled robot.

[gavanderhoorn]

@durovsky, @simonschmeisser: I can definitely see the value of an EKI based driver though, if only because it is a cheaper option compared to RSI.

Would either of you be interested in working on that?

@durovsky: do you think photoneo would be interested in opening up your work?

[ivareri]

I made a driver using a C++ library inspired by JOpenShowVar. It uses KUKAVARPROXY on the controller side. I'll clean up the code, and you can see if it replaces the need for EKI as a cheap driver option.

[gavanderhoorn]

@ivareri: interesting. That could be another approach, yes.

[simonschmeisser]

@ivareri sounds cool, is it going to be actually "open" as in "there is code available and has a suiteable licence" or is just another wrapper for some obscure kukavarproxy.exe file?

[ivareri]

@simonschmeisser It uses kukavarproxy.exe on the controller. According to aauc-mechlab/JOpenShowVar/issues/4 the source code for kukavarproxy.exe cannot be released yet.

[gavanderhoorn]

@durovsky, @simonschmeisser: I'd actually be interested in adding a driver node that could use EKI like discussed in this thread.

Would either of you be in a position to contribute something like that?

@simonschmeisser: you mentioned that you internally have already used something?

[simonschmeisser]

@gavanderhoorn we have one implemented that follows the idea of the default ros industrial driver but uses a xml protocol instead of the simplemessage one (I did not manage to get scanf/text parsing to run at that time as the order of arguments is switched compared to default c ...). I can send it to you privately and we can than discuss about what needs to be changed before publishing/integrating it

[BrettHemes]

See #110 for a ros_control / streaming approach using Kuka.EthernetKRL (EKI). Testing, feedback, comments are welcome :)

[gavanderhoorn]

Now that #110 is merged, I'm going to close this.

Thanks for starting the discussion @durovsky.

If anyone feels the need, please feel free to still comment on this.