"Failed to read state from robot. Shutting down!": Maximum kinetic energy exceeded

[cschindlbeck]

Description

I just noticed that i get Maximum kinetic energy, Command motor torque, Command gear torque errors on all axes when i use MoveIt for trajectory planning on kinetic.
Does the path planner generate motions that are too fast?
How can i debug this problem?

Setup

• ROS Kinetic
• Ubuntu 16.04
• Build from binary
• kuka_rsi_hw_interface
• Path Planner: RRTConnectkConfigDefault

Potentially related problems

Payload not considered

Path Planning

• rsi_hw_iface: "1073: Command gear torque An" error on any use rsi_hw_iface: "1073: Command gear torque An" error on any use #89
• Command gear torque A3/A2 error when using kuka_rsi_hw_interface Command gear torque A3/A2 error when using kuka_rsi_hw_interface #126
• Moveit! trajectory velocity has weird behavior on kinetic Moveit! trajectory velocity has weird behavior on kinetic moveit/moveit#416
• Improve time parameterization Improve time parameterization moveit/moveit#160
• Path time parameterization yields non-smooth time evolution Path time parameterization yields non-smooth time evolution moveit/moveit_core#167

Paket Loss

• RSI: set holdon to 1 to prevent late packets from crashing rsi connection RSI: set holdon to 1 to prevent late packets from crashing rsi connection #119

[gavanderhoorn]

Without more information this is going to be difficult to diagnose.

Have you always run Kinetic with this setup? Has anything changed on the robot side (EEF changed without updating payload settings)? Any MoveIt updates that you performed? Have you tried turning the controller on and off (you'd be surprised)?

Any hardware changes? Using wireless instead of wired network by mistake? etc

These kind of errors point to missing/dropped packets, problems with trajectories (violations of limits) or something else.

If you can, plot some trajectories and see what is going on.

[BrettHemes]

I assuming this is with kuka_rsi_hw_interface?

[cschindlbeck]

Sorry, i will try to be more verbose (updated initial post).

I assuming this is with kuka_rsi_hw_interface?

Yes.

I have connected Gazebo to efficiently debug my problem (see PR 92bd9ac). The trajectories are really smooth and i even slowed them down to be sure that i do not run into some velocity limits.

(EEF changed without updating payload settings)

Yeah i actually attached a small aluminum plate. Since it is lightweight (it has an off-axis center of mass though) i thought this cannot be the problem. Giving some thought to your comment this is the only thing that makes sense.

How can i change the payload settings?
Edit: I think i found it.
Start-Up -> Calibrate -> Supplementary load data
(if that is the case it wouldnt hurt to add this to the trouble shooting page)

[gavanderhoorn]

Note that I was just guessing. The payload settings could be a red herring.

re: updating the Troubleshooting guide might make sense, if it turns out to be the payload.

[cschindlbeck]

This issue was removed by:

• Accounting for the payload in the KUKA controller
• Activation of HOLDON on the KUKA C4, see RSI: set holdon to 1 to prevent late packets from crashing rsi connection #119

Thanks for the tip @gavanderhoorn

Jerky and "weird" trajectory behavior still persists but the discussion should be continued in the issues referenced in the initial post

[RhysMcK]

@cschindlbeck how accurately did you have to set the payload in the KUKA controller? Did you use the KUKA provided software- Kuka.LoadDataDetermination, or did you manually add the mass, CoM and inertia's. Thanks!

[cschindlbeck]

I have a custom gripper made of aluminum and an aluminum plate so i have inferred the inertial data from Solidworks (keep in mind to export your data wrt to the correct coordinate system). The only thing not accounted for is a servo motor so it's not totally spot on but i would say 95% accuracy.

I entered the data manually with the teach pendant (Calibration -> Tool -> load supplementary data).

I forgot to mention that i have furthermore slowed down the trajectories with

set_max_velocity_scaling_factor(0.02)
set_max_acceleration_scaling_factor(0.01)

I haven't sped up the trajectories to "normal" speed yet. Maybe you can try with really slow trajectory execution and work you way from there.

[RhysMcK]

Thanks @cschindlbeck for getting in touch. If your using a similar environment setup to myself, i fear you might once again encounter this error when you speed things back up to "normal" speed. Please see my latest comment on this discuss #126 (comment) . Cheers!