UniversalRobots
Service for connection state
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.
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).
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.
@gavanderhoorn How do other drivers handle this usually? I think, many drivers would just exit, right?
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.
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)