Update RSI configuration readme

[bj0rkedal]

Updated the steps in order to get RSI up and connected to the kuka_rsi_hw_interface.

@gavanderhoorn and @tingelst : Please give some feedback on possible changes and improvements.

[gavanderhoorn]

Thanks @bj0rkedal for taking the time to work on this.

@yaozr: would it be an idea for you to take a look at the updated documentation and see whether it helps you set up your controller?

You can find the latest version here.

[gavanderhoorn]

The RSI interface operates at 250 Hz and expects new data every 4ms.

might be good to mention here that the hw_iface doesn't have a period configured, and is completely driven by the controller's output.

[bj0rkedal]

Thanks for feedback @gavanderhoorn. I will do some changes tomorrow.

[bj0rkedal]

@gavanderhoorn: I have now added some details based on your feedback. I agree on your last comment concerning the editing of configuration files. The updated approach works for the repository in the current state. I guess that the template you mentioned will need to be created at a later time?

[cschindlbeck]

Hey bj0rkedal,

thanks alot for the effort. I went through the README and have some minor remarks:

• Maybe specify where to plug the Ethernet Cable on KUKA KR C4 (there are multiple ethernet slots)
• you could add that the robot_description line should be added after the two rosparam load commands in the launch file
• In 1.4 you state that there is some application on the desktop, however, mine doesnt show anything so it might be software-specific
• It should be noted if the test_params.yaml refers to the KUKA-side IP or ROS-side
• You could add in 4 after "roslaunch kuka_rsi_hw_interface test_hardware_interface.launch sim:=false" that an info/error is thrown if the IP-configuration was done incorrectly:

[ INFO] [1467968557.426540933]: Setting up RSI server on: (169.254.yy.xx, 49152)
ERROR on binding socket

• I had a problem initially, but you have to execute the src file as Expert/Admin, which it unfortunately changes after some time

I managed to move the robot via ROS exactly once for a short period of time. I suspect some timeout problem, when i ping the KUKA controller from my ROS pc i get

64 bytes from 169.254.xx.yy: icmp_seq=1 ttl=255 time=0.074 ms
64 bytes from 169.254.xx.yy: icmp_seq=1 ttl=64 time=0.213 ms (DUP!)
64 bytes from 169.254.xx.yy: icmp_seq=2 ttl=255 time=0.098 ms
64 bytes from 169.254.xx.yy: icmp_seq=2 ttl=64 time=0.115 ms (DUP!)
64 bytes from 169.254.xx.yy: icmp_seq=3 ttl=255 time=0.099 ms
64 bytes from 169.254.xx.yy: icmp_seq=3 ttl=64 time=0.118 ms (DUP!)
64 bytes from 169.254.xx.yy: icmp_seq=4 ttl=255 time=0.111 ms
64 bytes from 169.254.xx.yy: icmp_seq=4 ttl=64 time=0.117 ms (DUP!)

which might cause a problem.

Maybe something like a FAQ would be reasonable to include as well in addition to the README instructions

[bj0rkedal]

@cschindlbeck: Thanks for your remarks.

The duplicate answers when pinging the KUKA controller happens here as well when pinging the RSI interface IP. I don't know if this is something bad. It might just be a result of the usage of virtual networks on the controller. Pinging the controller IP of the Windows interface should return normal answers though.

As I mentioned, if you have problems with the RSI connection shutting down, this may be related to the hw_iface not being able to answer before the next RSI state is received. It might be worth a try to increase the priority level of hw_iface.

[cschindlbeck]

Does the Windows IP (172.31.xx.yy) have to be in the same namespace as the RSI ip?
i cannot ping the Windows IP of the KUKA controller from my ROS pc

[gavanderhoorn]

Thanks for the review of the changes @cschindlbeck. Much appreciated.

As to your other issue(s): we should be careful not to turn this PR into a generic RSI troubleshooting issue. It's really a PR to update the documentation.

Could I perhaps ask you to create a new issue or open a ROS Answers question about this? I'm sure @bj0rkedal would be willing to take a look at it.

[tingelst]

@cschindlbeck No, as far as I remember the 172.31.xx.yy network is only used internally in the controller and should not be modified.

Here is the documentation from KUKA regarding ethernet setup for RSI:

[cschindlbeck]

Sorry for cluttering this PR with other stuff @gavanderhoorn , will take better care in the future.
The instructions in README now work for me, however, i have another 2 suggestions for point 4):

• In 4.4 i have to confirm additionally (to the play button) that sensor movement is active in the top bar where the warnings/errors are shown, otherwise there is no "Got connection from the robot"
• The default values from the KRL files allow only for a slow movement such that the robot shouldnt be moved too fast (otherwise the robot stops suddenly)

[bj0rkedal]

@cschindlbeck Good that it's working.

About your first suggestion:
I guess that happens only when running T1 mode? If so, that does happen. When RSI and hw_iface is successfully configured and tested without any problems, it is of course possible to run in AUTO mode. An additional confirmation should not be necessary in this case. You must ALWAYS be able to reach the EMERGENCY STOP when moving the robot in AUTO mode.

About your second suggestion:
The default KRL files do limit movement in each axis to +-90 degrees, but they do not limit the speed as far as I know. Might be a safety torque limit shutting it down, or again, lack of real-time execution of the hw_iface.

I will review the problems described and do some changes to the README.

[tingelst]

Both of these issues are due to running in T1-mode.

[BrettHemes]

So it seems that two networks interfaces are required to run this. Could someone please elaborate on what each one does? I am trying to figure out how I want to put this in/on our subnets and would like to make an educated decision.

In general, I think the readme would benefit from a similar overview in the intro.

[gavanderhoorn]

@BrettHemes wrote:

So it seems that two networks interfaces are required to run this.

can you clarify to which "two network interfaces" you are referring?

Do you expect to need two on the controller, or on your desktop?

[BrettHemes]

can you clarify to which "two network interfaces" you are referring?

Via the readme, there is a Windows Interface and an RSI Interface which I assume need to be on different subnets.

As I understand it currently, I need a desktop (ROS-side) NIC configured on the same subnet as the KRC Windows Interface. I also seem to need a second desktop (ROS-side) NIC configured on the same subnet as the RSI Interface.

Currently I have multiple local subnets with sensors, io, robots, etc. on each where each subnet encapsulates a typical workcell. If I do the same for a Kuka setup will I have two subnets for that setup (i.e., sensors, io, etc. on one AND rsi on another)?

[gavanderhoorn]

@BrettHemes wrote:

As I understand it currently, I need a desktop (ROS-side) NIC configured on the same subnet as the KRC Windows Interface. I also seem to need a second desktop (ROS-side) NIC configured on the same subnet as the RSI Interface.

No, you don't. I'll leave it to @bj0rkedal and / or @tingelst to clarify this a bit more.

From a performance / reliability perspective though, it would perhaps be a good thing not to mix RSI UDP traffic with other traffic on your network. A direct connection ROS<->Controller for this would avoid any potential issues with throughput and associated robot motion performance.

[tingelst]

@BrettHemeshttps://github.com/BrettHemes wrote:

As I understand it currently, I need a desktop (ROS-side) NIC configured on the same subnet as the KRC Windows Interface. I also seem to need a second desktop (ROS-side) NIC configured on the same subnet as the RSI Interface.

No, you don't. I'll leave it to @bj0rkedalhttps://github.com/bj0rkedal and / or @tingelsthttps://github.com/tingelst to clarify this a bit more.

You only need to have a connection on the RSI subnet. However, you cannot ping the RSI interface on the KRC to check for connection, only the Windows interface can be pinged. That is the reason for having both subnets.

[BrettHemes]

Got this working. Good writeup 👍

As apparent from the above comments, the only confusing area to me was the (seemingly unnecessary) pinging of the Windows interface. I think the statement to the effect of "IF you can ping the Windows interface THEN setup the RSI interface" was what threw me off. Although, after actually executing the readme instructions (as opposed to reviewing them before starting) things became more clear.

Some aside questions:

1. What exactly do the MaxE# values do?
2. Is the timeout equal to the number of allowed missed packets? So at Timeout=100, 100*4ms have elapsed since the last answered RSI packet?

And a final note:
I was able to trigger hw_iface shutdowns while in AUTO using the RQT Joint Traj Controller by somewhat aggressively dragging a slider. Could be a priority issue or a robot torque limit as mentioned above (running non-real-time) but I just wanted to note that you can reproduce cschindlbeck's issue (although not as easily) outside of T1.

[tingelst]

What exactly do the MaxE# values do?

The MaxE values monitor the overall correction of external axes, e.g., if you have the robot mounted on a rail. I am uncertain if the AXISCORRMON object is really needed and should be removed. What do you think @gavanderhoorn ?

Is the timeout equal to the number of allowed missed packets? So at Timeout=100, 100*4ms have elapsed since the last answered RSI packet?

Yes, that is correct.

[gavanderhoorn]

Btw:

The RSI interface operates at 250 Hz (4ms cycle).

Is that actually correct? It is my understanding that this is the case only if you have the "fast RSI" option enabled. Typical periods are 8 and 12 ms, no?

[BrettHemes]

From what I can tell, 250 Hz is actually the default.

From the 3.2 manual:

The signal processing is calculated at the sensor cycle rate. Depending on the mode, the
sensor cycle rate is 12 ms (IPO mode) or 4 ms (IPO_FAST mode).

and

The signal processing is carried out by default in IPO_FAST mode. In this
case, the reference coordinate system for the sensor correction must be con-
figured in the RSI object POSCORR. If the signal processing is activated in
IPO mode, the reference coordinate system must be defined with RSI_ON().

[gavanderhoorn]

Seems I misremembered.

Thanks @BrettHemes for the doc reference.

@bj0rkedal: perhaps you could add that reference to the readme? Would explain where the 4 ms 'magic nr' comes from.

[gavanderhoorn]

@bj0rkedal: are you happy with the current version of the updated README? I think we've had 2 external reviews now (thanks @cschindlbeck and @BrettHemes), and I've had some people here at my university check it as well.

If you're ok with it, I'd then like to proceed and merge this PR.

Thanks for all your work already! 🍰

[tingelst]

@gavanderhoorn I think this PR is ready to be merged.

[bj0rkedal]

@gavanderhoorn: I read through the README now and I agree with @tingelst, the current version is ready to be merged.

I'm happy that I could contribute!

[gavanderhoorn]

Great, thanks @bj0rkedal and @tingelst.

I've captured some of the comments we didn't address (entirely) in issues #70, #71 and #72. We can address those later.

[gavanderhoorn]

Takk ;)

[tingelst]

Ingen årsak!