Check links using lychee instead of a custom script

.github/workflows/check_links.yml

@@ -11,9 +11,30 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-      - name: Check URLs
-        run: |
-          .github/helpers/check_urls.sh \
-            -d ".git build CMakeModules debian" \
-            -f "package.xml ursim_docker.rst architecture_coarse.svg" \
-            -p "vnc\.html opensource\.org\/licenses\/BSD-3-Clause"
+      - name: Restore lychee cache
+        id: restore-cache
+        uses: actions/cache/restore@v4
+        with:
+          path: .lycheecache
+          key: cache-lychee-${{ github.run_id }}-${{ github.run_attempt }}
+          restore-keys: cache-lychee-
+      - name: Link Checker
+        id: lychee
+        uses: lycheeverse/lychee-action@v2
+        with:
+          fail: true
+          args: >
+            --verbose
+            --no-progress
+            --cache
+            --cache-exclude-status 429
+            --max-cache-age 2d
+            --exclude '^http://192\.168\.56\.101'
+            --max-concurrency 1
+            './**/*.md' './**/*.html' './**/*.rst' './**/*.cpp' './**/*.h' './**/*.py'
+      - name: Save lychee cache
+        uses: actions/cache/save@v4
+        if: always()
+        with:
+          path: .lycheecache
+          key: ${{ steps.restore-cache.outputs.cache-primary-key }}

.gitignore

@@ -12,3 +12,4 @@ docs_output
 docs_build
 cross_reference
 ur_robot_driver/doc/generated
+.lycheecache

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.