Service for connection state

[enabled-tfi]

Summary

If the driver is started and connection to the robot is lost afterwards, the driver will continue to publish data on the /joint_state topic. Since there is no service/topic indicating the connection state, there is no way of knowing whether the data on /joint_states is old data. Either a service giving the connection state, or no new data on /joint_states when connection is lost, would solve the problem. However, both implementations would be nice.

Steps to Reproduce

Start e.g. ur5e_bringup.launch and remove the connection between the host and the robot (e.g. by unplugging the network cable) and observe that data is still published to /joint_states

Expected Behavior

Old data should not be published with new timestamps on /joint_states

Actual Behavior

Old data published on /joint_states

Workaround Suggestion

Either implement a service for connection state or avoid publishing old data.

[gavanderhoorn]

Could you clarify why you'd want a service specifically?

Seeing as connection state could be considered to be part of the state, I would expect a topic to make more sense.

Otherwise clients / interested entities would have to keep polling the service constantly, which is not very nice.

avoid publishing old data.

Personally I would suggest we do this (ie: don't publish if there is no data).

[enabled-tfi]

I agree that a topic would make more sense.

avoid publishing old data.

Personally I would suggest we do this (ie: don't publish if there is no data).

I would prefer both a topic and avoiding to publish data. If the state should be communicated to an end-user, it would be nice to just forward a given state.

[fmauch]

@gavanderhoorn How do other drivers handle this usually? I think, many drivers would just exit, right?

[gavanderhoorn]

Many drivers would indeed shut down.

But we could manage this a bit more graceful here though.

The first thing to fix I would say would be:

[If] connection to the robot is lost afterwards, the driver will continue to publish data on the /joint_state topic.

[fmauch]

I think, #104 should stop the driver from publishing joint data.

Adding a separate state topic seems like a good idea at first glance, however we should think of a good name. Currently, we have:

• robot_mode: Robot mode as reported from the robot (I wouldn't touch that as it is a reserved term in UR language)
• robot_program_running: Only tells whether the program interpreting the commands is running

We could add driver_state (enum) or driver_connected (bool)