UR programm just continues if URcap was active but connection dropped

[ipa-lth]

Summary

I am currently working on a VM<->VM setup. With one VM running ursim and another the ROS driver.

My connection quality is quite bad, so I was able to recognize that, if the URcap is included in a larger UR program and the connection between the URcap and ur_driver drops, the URprogram steps to the next command and just continues.

I find this very unsettling, because the external control was not finished properly and the robot might be in a state where it cannot continue with the UR program.

However, my setup is somewhat special and in the mids of development... Could someone please verify this issue on a more "vanilla" setup?

Introduction to the issue

Versions

• ROS Driver version: latest
• Tested with Robot Software Version(s): ursim 3.13
• URCaps Software version(s): latest

Impact

The robot might crash against something, because the target pose of the next UR-motion cannot be reached from the (random) pose where the external_control left it.

Steps to Reproduce

• start a ursim and create a robot program with a ptp ->external_ctrl -> lin ->...
• start the robot program on the ur and connect with the ur_driver
• the UR program should stay in the "external_ctrl" step (Do not call the "hand_back_control" ros_service, yet.)
• Kill the ur_driver as brutally as possible or pull the ethernet wire (to lose connection)

Expected Behavior

The UR program should stop or ask for user intervention

Actual Behavior

The UR program continues (and possibly loops to the external_ctrl step again)

[fmauch]

I think, I never had that in mind, yes. Thanks for bringing that up.

Currently, this is the communication scheme: The program node will exit once no data is sent from the remote anymore. This could be an intentional disconnect attempt or a loss of connection.

To do proper error handling, we would have to make sure that we always send a MODE_STOPPED signal each time we intentionally end the connection.

If we don't receive a package from the remote we assume a connection loss.

One problem I see is how to distinguish between an intentional disconnection (as in ctrl-c the driver) vs. a non-intentional one (e.g. a crash of the driver or an exit of a driver due to a required node in the same launch file crashing...)