Dashboard Client seg faults when switching from remote mode to local mode

[hugols16]

On the e-series, the Teach Pendant must be in remote mode to control the arm. Detecting whether it's in remote mode or not can be done via the dashboard client. The problem resides when using this to monitor whether it's in remote mode, and expecting the end user to switch to local modes at times (for jogging, freedrive, etc.). When the end user switches to local mode on the Teach Pendant, the dashboard server closes the connection, which is not handled properly by the Dashboard Client, and it ultimately segfaults. This can be tested very simply:

1. Start your program in remote mode
2. Periodically check if the Teach Pendant is in remote mode
3. Manually switch to local mode
4. It segfaults

[fmauch]

On the e-series, the Teach Pendant must be in remote mode to control the arm.

This is not really true.

However, we know that changing between local and remote mode does cause problems with the dashboard client, but I was not aware that this actually causes segfaults. I can currently not reproduce this, as the disconnect does not happen with URSim, but I'll give that a bug label nevertheless and try to reproduce with a real robot later.

[fmauch]

I could not reproduce a segfault. When I start the driver while being in remote_control mode, then switch to local mode and try to send something to the dashboard server, I get

[dashboard_client-2] [ERROR] [1663768349.973294092] [UR_Client_Library]: Attempt to write on a non-connected socket
[dashboard_client-2] [ERROR] [1663768349.973329027] [Dashboard_Client]: Service Call failed: 'Failed to send request to dashboard server. Are you connected to the Dashboard Server?'

Then calling

ros2 service call /dashboard_client/connect std_srvs/srv/Trigger

brings me back to a working dashboard client.

I'm not saying that the issue does not exist, but I can't currently reproduce it. Could you tell us a bit more about your setup? Which ROS version, source build or binary packages, Polyscope version....

[urmarp]

This issue has been addressed in PR #118

[fmauch]

@urmarp so you managed to reproduce the issue? Could you tell us a bit more about that, please?

[urmarp]

Yes, I could reproduce the error on a real robot with SW 5.12 by following the steps @hugols16 mentioned. The problem was that the receive timeout was not set in the dashboard client.

[fmauch]

I've always looked at that through a ROS (1) service. That first of all limits the rate with which you can call that with the service call overhead and also catches the exceptions inside the service architecture. And on top of that we initialize the timeout to 1 second, there.

My fault for not checking with the standalone library.

[fmauch]

@hugols16 what was the environment you tested this in? ROS, ROS2, ISAAC, standalone? As mentioned in https://github.com/UniversalRobots/Universal_Robots_Client_Library/pull/118#pullrequestreview-1120279954 it was a decision to throw an exception here that would have to be caught on the application level to decide what to do with that.

[fmauch]

Closing, since the timeout was fixed in #118.