Fix links to removed ROS_INTERFACES.md file

Author: urfeex

ur_robot_driver/README.md

@@ -4,8 +4,6 @@ This package contains the actual driver for UR robots. It is part of the *univer
 repository and requires other packages from that repository. Also, see the [main repository's
 README](../README.md) for information on how to install and startup this driver.
 
-## ROS-API
-The ROS API is documented in a [standalone document](doc/ROS_INTERFACE.rst).
 
 ## Technical details
 The following image shows a very coarse overview of the driver's architecture.
@@ -41,7 +39,7 @@ The robot won't accept script code from a remote source unless the robot is put
 *remote_control-mode*. However, if put into *remote_control-mode*, the program containing the
 **External Control** program node can't be started from the panel.
 For this purpose, please use the **dashboard** services to load, start and stop the main program
-running on the robot. See the [ROS-API documentation](doc/ROS_INTERFACE.rst) for details on the
+running on the robot. See the [Dashboard client documentation](doc/dashboard_client.rst) for details on the
 dashboard services.
 
 For using the **tool communication interface** on e-Series robots, a `socat` script is prepared to
@@ -55,42 +53,13 @@ recommend using the controllers from the `ur_controllers` package. See it's
 available using the controllers from `ur_controllers`**
 
 ## A note about modes
-The term **mode** is used in different meanings inside this driver.
-
-### Remote control mode
-On the e-series the robot itself can operate in different command modes: It can be either in **local control
-mode** where the teach pendant is the single point of command or in **remote control mode**, where
-motions from the TP, starting & loading programs from the TP activating the freedrive mode are
-blocked. Note that the **remote control mode** has to be explicitly enabled in the robot's settings
-under **Settings** -> **System** -> **Remote Control**. See the robot's manual for details.
-
-The **remote control mode** is needed for many aspects of this driver such as
- * headless mode (see below)
- * sending script code to the robot
- * many dashboard functionalities such as
-   * restarting the robot after protective / EM-Stop
-   * powering on the robot and do brake release
-   * loading and starting programs
- * the `set_mode` action, as it uses the dashboard calls mentioned above
-
-### Headless mode
-Inside this driver, there's the **headless** mode, which can be either enabled or not. When the
-[headless mode](./doc/ROS_INTERFACE.rst#headless_mode-default-false) is activated, required script
-code for external control will be sent to the robot directly when the driver starts. As soon as
-other script code is sent to the robot either by sending it directly through this driver or by
-pressing any motion-related button on the teach pendant, the script will be overwritten by this
-action and has to be restarted by using the
-[resend_robot_program](./doc/ROS_INTERFACE.rst#resend_robot_program-std_srvstrigger) service. If this
-is necessary, you will see the output `Connection to robot dropped, waiting for new connection.`
-from the driver. Note that pressing "play" on the TP won't start the external control again, but
-whatever program is currently loaded on the controller. This mode doesn't require the "External
-Control" URCap being installed on the robot as the program is sent to the robot directly. However,
-we recommend to use the non-headless mode and leverage the `set_mode` action to start program
-execution without the teach pendant. The **headless** mode might be removed in future releases.
-
-**Note for the e-Series:** In order to leverage the **headless** mode on the e-Series the robot must
-be in **remote_control_mode** as explained above.
+The term **mode** is used in different meanings inside this driver. See [Operation
+Modes](doc/operation_modes.rst) for details.
 
 ## controller_stopper
-A small helper node that stops and restarts ROS controllers based on a boolean status topic. When the status goes to `false`, all running controllers except a set of predefined *consistent_controllers* gets stopped. If status returns to `true` the stopped controllers are restarted.
-This is done by Subscribing to a robot's running state topic. Ideally this topic is latched and only publishes on changes. However, this node only reacts on state changes, so a state published each cycle would also be fine.
+A small helper node that stops and restarts ROS controllers based on a boolean status topic. When
+the status goes to `false`, all running controllers except a set of predefined
+*consistent_controllers* gets stopped. If status returns to `true` the stopped controllers are
+restarted. This is done by Subscribing to a robot's running state topic. Ideally this topic is
+latched and only publishes on changes. However, this node only reacts on state changes, so a state
+published each cycle would also be fine.