Dashboard client does not survive minor errors

[felixvd]

The dashboard client disconnects when it encounters an error / does not receive an answer. I think that it should not disconnect, but reset the socket connection instead.

For me, 95% of the time, the error occurs because I left the teaching pendant in Local mode. However, instead of changing to Remote Control and continuing, the whole launch file needs to be restarted, only for the dashboard client. This seems unnecessary.

If there is no particular reason for this behavior I am happy to file a PR.

[fmauch]

This could definitely be improved, I would have to take a deeper look into the code to give a proper answer.

However, you don't have to restart the whole driver, there are the services dashboard/quit and dashboard/connect to disconnect and connect to the dashboard server.

When trying to make a call that requires remote control enabled, the driver will tell you that in the output and that you should reconnect the dashboard server. If you could provide a specific (reproductible) use case where you think, the behavior should be changed, we can try to find a viable solution for that :-)

[felixvd]

Is there a reason not to quit and reconnect immediately after the error?

I have a simple blind script that launches the URCap on my robots to make sure they are ready to use. Here is how it becomes an awkward workflow:

1. Put the robot in Local mode
2. Call ur_hardware_interface/dashboard/play with "ROS_external_control.urp" :)
3. Recovery steps:
   • Put the robot in Remote Control mode
   • Restart the driver OR, as you said:
   • Call ur_hardware_interface/dashboard/quit
   • Call ur_hardware_interface/dashboard/connect
   • Restart from step 2

If the dashboard client reconnected automatically, this would be a lot smoother. Although I admit that there is a workaround (checking if the program is running already) that I didn't see before.

[fmauch]

The reason we're doing it that way is basically twofold:

• As the socket connection isn't closed from the robot after the rejected call, you can still use calls that are possible in local mode
• We would have to monitor for those mode changes and there is no information source for that that wouldn't have to be queried frequently. If you have an idea how to get around this, this is welcome.

[felixvd]

Sorry for the late response. I implemented the quit/connect fallbacks in Python and C++, but it is not a very smooth experience. loadProgram can time out for no reason, and it is not clear which of the two services needs to be called when a call to a dashboard service has failed (connect? quit and connect?). These scripts have been serving me well, so I uploaded them in case someone else would like to restart/reconnect the dashboard client comfortably.

I still don't really understand why dashboard/connect should not be called whenever the socket failed to connect. Is there an upside to the dashboard client/socket staying disconnected? It just seems like a defunct state to me that shouldn't require a manual reset. Feel free to close this if you prefer.

[felixvd]

Related (dashboard usability): #262