Troubleshooting

This page lists some of the possible errors and issues encountered when using the kuka_rsi_hw_interface package. The below subsections provide possible solutions.

If you encounter an error not listed on this page or the provided remedy does not seem to work, please contact the developers by posting a message in the ROS-Industrial category on ROS Discourse.

Hardware Interface

rsi_hw_iface node shuts down on agressive motions

Some aggressive motions will cause the hardware interface to fail and shutdown (e.g., with the RQT Joint Traj Controller, it is possible to move the sliders fast enough to cause said issue).

Cause: Aggressive motions that violate dynamic limits internal to the robots’s physical robot controller (e.g., KR C4) will cause the ros_rsi.src program to fault out on the controller and subsequent shutdown of the kuka_rsi_hw_interface.

Remedy: Check your commanded trajectories for feasibility. Trajectories should be sufficiently smooth and satisfy the dynamic limits of the physical robot. If you are sending JointTrajectories with only position information, try providing velocities (and accelerations) to ensure smooth interpolation. In general, anything generated from MoveIt! with correctly specified joint limits shouldn’t cause this issue.

What exactly does the RSI 'timeout' parameter do?

From the krl readme:

Notice the RSIObject of type ETHERNET. Within this object is a parameter called Timeout. This parameter is set to 100 by default. The RSI interface operates at 250 Hz (4ms cycle). The kuka_rsi_hardware_interface does not have a period configured and is completely driven by the controller's output. Every controller RSI output has a IPOC timestamp which increments for every cycle. The kuka_rsi_hardware_interface will answer as quickly as possible. The answer includes the last IPOC received. If the connected PC with ROS did not manage to answer within the RSI cycle of 4 ms, the IPOC timestamp of RSI has incremented. The IPOC included in the answer is not matched and the controller will increment a counter. When this counter hits the Timeout parameter (100), the RSI connection will shut down. If this parameter is lowered, the demand for real-time computation will increase.

Everything seems right but my (new/additional) PC won't connect to the hardware interface

Some users have had problems connecting when switching PC's and using the same IP address. This is most likely to ARP caching within the robot's physical controller (i.e., KR C4) and can be fixed with a cold start of the controller. To summarize, the RSI interface will only work with the first connected PC for a given IP until the next cold start of the controller.

Cause: Switching hardware while using the same IP address to connect to kuka_rsi_hardware_interface.

Remedy: Change the IP address (IP_NUMBER tag in ros_rsi_ethernet.xml) for any new hardware OR force a cold start of the controller (recommended) as follows (via the robot pendant): Main Menu > Shutdown > Settings that are only valid next time the system is switched off: Force cold start followed by a power cycle on the controller.