RSI Load Check

[emielke12]

Software:
Running ROS Melodic Ubuntu 18.04.5 and indigo-devel branch of this repo.

Hardware: Kuka Agilus KR6 with KRC4 controller. Tool load has been entered, along with center of mass and moments of inertia, and I double checked these for accuracy.

Issue: Every so often, when running a long (180s), slow (appx. 1 mm/s) command, the pendant spits out an error Overload calculated when checking robot load, which causes the brakes to engage on the controller, but this information is not fed back to the RSI ROS node. This causes errors with my program (using moveit for path planning) and the next motion attempt continues. The overload doesn't appear for other speeds, and only appears if the robot speed is low for an extended amount of time.

Possible solutions:

• I am able to use the pendant controller settings to change from stop to warning, and my program runs fine, but I am worried that this could cause issues if the robot should put the brakes on for a different overload calculated scenario.
• If the RSI node would show an error or throw an exception, I could use this to stop the rest of the program from running, but currently, no error shows up when the brakes are engaged due to the overload calculation. Is this correct behavior? Should the RSI node at least indicate brakes have been engaged?

Side note: does anyone know why the overload would trip only at these low speeds? I found a link here that suggests perhaps at slow speeds, the noise to signal ratio is skewed in favor of noise, which makes the kuka controller think the load is too high. That makes sense, but this error only shows up after over 100s of 1mm/s motion. Is the kuka controller doing some kind of error accumulation? Or is it just chance that I've noticed it only happening after 100s?

[gavanderhoorn]

This reads like a duplicate/related to #89, #126 and #147.

RSI can be sensitive to jerks, which are typically what causes the kinds of problems you describe.

Running trajectories through something like pantor/ruckig may help. I've had good results with other robots with sensitive controllers.

[emielke12]

RSI can be sensitive to jerks, which are typically what causes the kinds of problems you describe.

Good to know, I'll go refresh myself on our time parameterization to see what we're doing w.r.t. jerk.

Running trajectories through something like pantor/ruckig may help. I've had good results with other robots with sensitive controllers.

I'll take a look. Thanks!

In regards to the ROS node, perhaps it should throw an error if this occurs? The robot engages the brakes, and the pendant script faults out, but moveit doesn't register this as the RSI node doesn't alert anything (the driver doesn't die or anything, from the ROS side).

[gavanderhoorn]

In regards to the ROS node, perhaps it should throw an error if this occurs?

there isn't really an easy way to detect this.

It might be possible to configure RSI to send back current active errors (or through some other mechanism), but at least right now that's not implemented.

[gavanderhoorn]

I'm going to close this due to inactivity.

We also already have a couple of open issues tracking the same problem.

I suggest we continue the discussion there.