Fix RTD theme and perform some cleanup (#82)

* Cleanup conf.py

* Update RTD theme

* Reformat lists

* Fix trailing whitespace

(cherry picked from commit 311a61a)

# Conflicts:
#	doc/getting_started/getting_started.rst
#	doc/project_ideas.rst

Author: christophfroehlich

_themes/sphinx_rtd_theme/static/css/theme.css

@@ -14,8 +14,6 @@
 #
 import itertools
 import os
-import shutil
-import subprocess
 import sys
 import time
 
@@ -26,7 +24,7 @@
 # -- General configuration -------------------------------------------------
 # General information about the project.
 project = "control.ros.org"
-author = "ros2_control Maintainers"
+author = "ros2_control Development Team"
 copyright = "{}, {}".format(time.strftime("%Y"), author)
 
 # Adjust those to change ros distribution
@@ -63,7 +61,7 @@
 #
 # This is also used if you do content translation via gettext catalogs.
 # Usually you set "language" from the command line for these cases.
-language = None
+language = "en"
 
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
@@ -89,8 +87,6 @@
     "sphinx.ext.extlinks",
     "sphinx.ext.ifconfig",
     "sphinx_copybutton",
-    "sphinx.ext.autodoc",
-    "sphinx.ext.doctest",
     "sphinx.ext.viewcode",
 ]
 
@@ -119,7 +115,7 @@
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ["_static"]
+# html_static_path = ["_static"]
 
 # Custom sidebar templates, must be a dictionary that maps document names
 # to template names.

conf.py

@@ -73,19 +73,23 @@ We use the following naming conventions for branches.
 
 **Development branch**:
 
-  - Name: ``master``
-  - CI rule for merge:
-    - must: ``semi-binary`` (working against development branch of ros2_control)
-    - good: ``binary``      (working against the same stable branch of other ros2_control repositories)
-  - ``source`` build each day check against master branches of ROS 2
+* Name: ``master``
+* CI rule for merge:
+
+  * must: ``semi-binary`` (working against development branch of ros2_control)
+  * good: ``binary``      (working against the same stable branch of other ros2_control repositories)
+
+* ``source`` build each day check against master branches of ROS 2
 
 **Stable branches**:
 
-  - Name: ``<ros_distro>`` (e.g., foxy, galactic)
-  - CI rule for merge:
-    - must: ``semi-binary`` (working against the same stable branch of other ros2_control repositories)
-    - must: ``binary``    (working against released versions of ros2_control) - except for adding new non-braking features
-  - ``source`` build each day against distribution branches
+* Name: ``<ros_distro>`` (e.g., foxy, galactic)
+* CI rule for merge:
+
+  * must: ``semi-binary`` (working against the same stable branch of other ros2_control repositories)
+  * must: ``binary``    (working against released versions of ros2_control) - except for adding new non-braking features
+
+* ``source`` build each day against distribution branches
 
 
 CI configuration
@@ -94,10 +98,10 @@ Three build stages are checking the current and future compatibility of the fram
 
 1. ``binary`` - against released packages (main and testing) in ROS distributions. This Shows that direct local build is possible.
 
-1. ``semi-binary`` - against released core ROS packages (main and testing), but the immediate dependencies are pulled from the source.
+2. ``semi-binary`` - against released core ROS packages (main and testing), but the immediate dependencies are pulled from the source.
    This shows that local build with dependencies is possible, and if it fails there, we can expect that after the next package sync, we will not be able to build.
 
-1. ``source`` - also core ROS packages are build from source. It shows potential issues in the mid future.
+3. ``source`` - also core ROS packages are build from source. It shows potential issues in the mid future.
 
 
 Documentation Usage

doc/contributing/contributing.rst

@@ -1,14 +1,25 @@
 .. _getting_started:
 
+#################
 Getting Started
-===============
+#################
 
+<<<<<<< HEAD
 The ros2_control framework is released for ROS 2 Foxy.
 To use it, you have to install ``ros-foxy-ros2-control`` and ``ros-foxy-ros2-controllers`` packages.
 Other dependencies are installed automatically.
+=======
+Installation
+============
+>>>>>>> 311a61a (Fix RTD theme and perform some cleanup (#82))
+
+Binary packages
+------------------
+The ros2_control framework is released for ROS 2 rolling.
+To use it, you have to install ``ros-rolling-ros2-control`` and ``ros-rolling-ros2-controllers`` packages.
 
-Compiling
----------
+Building from Source
+---------------------------
 
 If you want to install the framework from source use following commands in your workspace main folder:
 

doc/getting_started/getting_started.rst

@@ -1,6 +1,6 @@
 .. _project_ideas:
 
-Project Ideas for GSoC 2022
+Project Ideas for GSoC 2024
 =============================
 
 Tutorials and Demos for ros2_control
@@ -10,28 +10,36 @@ This project is about extending our tutorials and examples on how to use the ros
 Also, existing demos should be integrated with our documentation at `control.ros.org <https://control.ros.org>`_.
 In general, the following tasks are envisioned:
 
+<<<<<<< HEAD
 - Examples on simulators' integration (Gazebo and Ignition) and their use; 
 - Showcase multi-robot and multi-controller manager use-case with examples and by using simulators
 - Showcase: How to do Error Management with ros2_control (graceful error handling and degradation)
 - Implementing different example robot-hardware architectures for industrial and service robotics
 - Implementing use-cases from `roadmap <https://github.com/ros-controls/roadmap>`_ repository
+=======
+* Examples on simulators' integration (Gazebo and Ignition) and their use;
+* Showcase multi-robot and multi-controller manager use-case with examples and by using simulators
+* Showcase: How to do Error Management with ros2_control (graceful error handling and degradation)
+* Implementing different example robot-hardware architectures for industrial and service robotics
+* Implementing use-cases from `roadmap <https://github.com/ros-controls/roadmap>`_ repository
+>>>>>>> 311a61a (Fix RTD theme and perform some cleanup (#82))
 
 The all code will be placed into our `demo repository <https://github.com/ros-controls/ros2_control_demos/>`_.
 
 Related design drafts:
 
-- `Robot-Hardware Architectures <https://github.com/ros-controls/roadmap/blob/master/design_drafts/components_architecture_and_urdf_examples.md>`_
-- `GPIO Interfaces <https://github.com/ros-controls/roadmap/blob/master/design_drafts/non_joint_command_interfaces.md>`_
-- `Showcase mode-switching and conflict check <https://github.com/ros-controls/roadmap/blob/master/design_drafts/mode_switching_and_conflict_check.md>`_
-- `Movement-/Safety-critical Interfaces <https://github.com/ros-controls/roadmap/pull/51>`_
+* `Robot-Hardware Architectures <https://github.com/ros-controls/roadmap/blob/master/design_drafts/components_architecture_and_urdf_examples.md>`_
+* `GPIO Interfaces <https://github.com/ros-controls/roadmap/blob/master/design_drafts/non_joint_command_interfaces.md>`_
+* `Showcase mode-switching and conflict check <https://github.com/ros-controls/roadmap/blob/master/design_drafts/mode_switching_and_conflict_check.md>`_
+* `Movement-/Safety-critical Interfaces <https://github.com/ros-controls/roadmap/pull/51>`_
 
 ----
 
 | Skills required/preferred:
 
-- Good C++ skills
-- Basic understanding of ROS and/or ROS 2
-- Familiarity with the Gazebo simulator
+* Good C++ skills
+* Basic understanding of ROS and/or ROS 2
+* Familiarity with the Gazebo simulator
 
 | Possible mentors: Denis Štogl
 | Expected size of project: 350 hours
@@ -51,18 +59,18 @@ This functionality should replace some high-level components currently used, e.g
 
 The main functionalities for the components and goals of the project are:
 
-- Defining a scenario in form of a multi-robot and multi-tool configuration and its behavior that serves as a benchmark.
-- Extending controller_manager with status publisher, providing all needed data to a mission-control component.
-- Adding status topics to all standard controllers.
-- Defining format of a YAML file where users can configure controller presets.
-- Implementing the mission-control module/script that sets the controller_manager, i.e., the ros2_control framework, in a specific configuration/state.
+* Defining a scenario in form of a multi-robot and multi-tool configuration and its behavior that serves as a benchmark.
+* Extending controller_manager with status publisher, providing all needed data to a mission-control component.
+* Adding status topics to all standard controllers.
+* Defining format of a YAML file where users can configure controller presets.
+* Implementing the mission-control module/script that sets the controller_manager, i.e., the ros2_control framework, in a specific configuration/state.
 
 ----
 
 | Skills required/preferred:
 
-- Good C++ skills
-- Basic understanding of ROS and/or ROS 2
+* Good C++ skills
+* Basic understanding of ROS and/or ROS 2
 
 | Possible mentors: Bence Magyar, Denis Štogl
 | Expected size of project: 350 hours
@@ -75,23 +83,23 @@ Add support for hardware semantic components
 
 The ros2_control framework relies on simple command and state interfaces in the form of double values to exchange data between hardware components and controllers. It is desired however to provide good C++ data structures both on the hardware component and the controller side which improves code readability and maintainability. 
 
-Earlier in the project, the concept of semantic components were introduced which essentially provides a grouping for these values and a semantic-specific API to use them. For instance, an IMU sensor will typically report 9 values, 3 values for each axis of the acelerometer, gyroscope and compass sensor parts respectively. Such values can be grouped and served through an API as a ROS IMU message or as a C++ struct for both input and output of these values while the ros2_control framework maintains it's low-profile communication interfaces internally.
+Earlier in the project, the concept of semantic components were introduced which essentially provides a grouping for these values and a semantic-specific API to use them. For instance, an IMU sensor will typically report 9 values, 3 values for each axis of the accelerometer, gyroscope and compass sensor parts respectively. Such values can be grouped and served through an API as a ROS IMU message or as a C++ struct for both input and output of these values while the ros2_control framework maintains it's low-profile communication interfaces internally.
 
 The goal of this project is to add semantic components that are relevant for hardware components.
 Additionally, this project includes extending the existing simulation tools with a set of common semantic components to support different sensors and actuators.
 
 Related design document and code implementations:
 
-- [Few idea about Semantic Components for hardware](https://github.com/ros-controls/roadmap/pull/45)
-- [Semantic Components for Controllers](https://github.com/ros-controls/ros2_control/tree/master/controller_interface/include/semantic_components)
+* `Few idea about Semantic Components for hardware <https://github.com/ros-controls/roadmap/pull/45>`__
+* `Semantic Components for Controllers <https://github.com/ros-controls/ros2_control/tree/master/controller_interface/include/semantic_components>`__
 
 ----
 
 | Skills required/preferred:
 
-- Good C++ skills
-- Basic understanding of ROS and/or ROS 2
-- Basic understanding of the Gazebo simulator
+* Good C++ skills
+* Basic understanding of ROS and/or ROS 2
+* Basic understanding of the Gazebo simulator
 
 | Possible mentors: Bence Magyar, Denis Štogl
 | Expected size of project: 175 hours
@@ -109,21 +117,21 @@ This work will consist of reviewing the two versions of the two controllers and
 
 Related existing issues are:
 
-- https://github.com/ros-controls/ros2_controllers/issues/303
-- https://github.com/ros-controls/ros2_controllers/issues/304
+* https://github.com/ros-controls/ros2_controllers/issues/303
+* https://github.com/ros-controls/ros2_controllers/issues/304
 
 Stretch goals:
 
-- https://github.com/ros-controls/realtime_tools/issues/81
-- https://github.com/ros-controls/ros2_controllers/issues/302
+* https://github.com/ros-controls/realtime_tools/issues/81
+* https://github.com/ros-controls/ros2_controllers/issues/302
 
 ----
 
 | Skills required/preferred:
 
-- Good C++ skills
-- Basic understanding of ROS and/or ROS 2
-- Basic understanding of unit testing with gmock
+* Good C++ skills
+* Basic understanding of ROS and/or ROS 2
+* Basic understanding of unit testing with gmock
 
 | Possible mentors: Bence Magyar
 | Expected size of project: 350 hours