pre-commit

ros-industrial · Apr 23, 2024 · c4e9d1b · c4e9d1b
1 parent bc8a263
commit c4e9d1b
Show file tree

Hide file tree

Showing 4 changed files with 17 additions and 19 deletions.
diff --git a/canopen/sphinx/user-guide/configuration.rst b/canopen/sphinx/user-guide/configuration.rst
@@ -27,7 +27,7 @@ Consequently, the structure of the configuration package should look as follows:
           ├── CMakeLists.txt
           └── package.xml
 
-See section :doc:`how-to-create-a-configuration` for more details.  
+See section :doc:`how-to-create-a-configuration` for more details.
 
 Bus Configuration File
 -----------------------

diff --git a/canopen/sphinx/user-guide/operation.rst b/canopen/sphinx/user-guide/operation.rst
@@ -47,13 +47,11 @@ To start with ROS2 CANOpen Stack, you need to have the following prerequisites:
 
 To effectively implement and utilize the ROS2 CANopen stack, certain prerequisites must be met. Below is a comprehensive list of these requirements:
 
-1. **EDS or DCF Files**: You'll need the Electronic Data Sheet (EDS) or Device Configuration File (DCF) for each CANopen device. These files contain 
-crucial device-specific parameters and configuration details necessary for communication and operational functionality.
+1. **EDS or DCF Files**: You'll need the Electronic Data Sheet (EDS) or Device Configuration File (DCF) for each CANopen device. These files contain
+    crucial device-specific parameters and configuration details necessary for communication and operational functionality.
 
-2. **bus.yml File Configuration**: Prepare the `bus.yml` file, which outlines the bus topology and device-specific settings. This configuration file 
-should specify details such as which devices are connected, the relevant EDS/DCF files, parameter overrides, and driver assignments for each device.
+2. **bus.yml File Configuration**: Prepare the ``bus.yml`` file, which outlines the bus topology and device-specific settings. This configuration file should specify details such as which devices are connected, the relevant EDS/DCF files, parameter overrides, and driver assignments for each device.
 
 3. **Network Configuration**: Set up and configure your network to match the requirements of your CANopen devices and the ROS2 CANopen stack. See :doc:`../quickstart/setup-network`
 
 These are the basic requirements, and continue with the following sections to learn more about the operation modes and how to set up the ROS2 CANopen stack.
-
diff --git a/canopen/sphinx/user-guide/operation/managed-service-interface.rst b/canopen/sphinx/user-guide/operation/managed-service-interface.rst
@@ -3,28 +3,28 @@ Managed Service Interface
 
 Device Container with Managed Nodes
 -----------------------------------
-The device container operates as a ROS2 component manager with load and unload services disabled. It utilizes the Bus Configuration File (``bus.yml``) to 
+The device container operates as a ROS2 component manager with load and unload services disabled. It utilizes the Bus Configuration File (``bus.yml``) to
 load devices. This container also offers a list service, which can be utilized with ros2cli to verify the loaded components.
 
 .. figure:: ../../images/device-manager.png
     :alt: Device Manager Concept
 
     Overview of the device manager concept.
 
-Upon startup, the device container uses the bus description file to identify and load the appropriate drivers for each device, 
+Upon startup, the device container uses the bus description file to identify and load the appropriate drivers for each device,
 including the CANopen master node. Initially, the nodes are in an unconfigured state.
 
-The default launch files from the ``canopen_core`` package automatically initiate the lifecycle manager node, which orchestrates 
-the sequencing and state transitions of all nodes within the container. Activating the lifecycle manager progresses all nodes from an 
+The default launch files from the ``canopen_core`` package automatically initiate the lifecycle manager node, which orchestrates
+the sequencing and state transitions of all nodes within the container. Activating the lifecycle manager progresses all nodes from an
 unconfigured to an active state in a predetermined sequence.
 
-.. note:: 
+.. note::
 
     For custom implementations, it is crucial to configure and activate the master node before setting up any driver nodes to ensure proper system functionality.
 
 Bus Configuration
 -----------------
-The bus configuration specific to this interface must incorporate driver classes designated as lifecycle drivers. The master driver within 
+The bus configuration specific to this interface must incorporate driver classes designated as lifecycle drivers. The master driver within
 this setup dictates whether the ``bus.yml`` is considered a managed or an unmanaged service interface.
 
 .. csv-table:: Available Driver Components
@@ -46,5 +46,5 @@ The device manager's operation is guided by several crucial configuration parame
    master_bin, string, (Optional) Path to the concise DCF (.bin) file for master configuration, typically generated by dcfgen as master.bin. (default: "")
    can_interface_name, string, (Mandatory) Name of the CAN interface to be used. (default: "vcan0")
 
-This section outlines the configuration and management of nodes within the ROS2 CANopen architecture, emphasizing the importance of lifecycle management 
+This section outlines the configuration and management of nodes within the ROS2 CANopen architecture, emphasizing the importance of lifecycle management
 for robust device interaction and control.
diff --git a/canopen/sphinx/user-guide/operation/ros2-control-interface.rst b/canopen/sphinx/user-guide/operation/ros2-control-interface.rst
@@ -4,14 +4,14 @@ This package provides multiple hardware interfaces for testing. Mainly the follo
 
 - canopen_ros2_control/CanopenSystem: A system interface for ProxyDrivers
 - canopen_ros2_control/Cia402System: A system interface for Cia402Drivers
-- canopen_ros2_control/RobotSystem: A system interface for Cia402Drivers in a robot configuration. 
+- canopen_ros2_control/RobotSystem: A system interface for Cia402Drivers in a robot configuration.
 
 
 Robot System Interface
 ----------------------
-The Robot System Interface utilizes information from the robot's URDF (Unified Robot Description Format) to configure and manage Cia402Drivers 
-via the ros2_control hardware interface. The system configuration is determined by the `bus.yml` file, and each joint's associated CANopen device 
-is specified using the `node_id`.
+The Robot System Interface utilizes information from the robot's URDF (Unified Robot Description Format) to configure
+and manage Cia402Drivers via the ros2_control hardware interface. The system configuration is determined by the ``bus.yml``
+file, and each joint's associated CANopen device is specified using the ``node_id``.
 
 **Configuration Example**:
 
@@ -48,7 +48,7 @@ The package provides several controllers optimized for different setups within t
 
 Robot Controller Configuration
 ------------------------------
-The Robot Controller simplifies the operation of robotic joints, automatically managing their states through the ros2_controller lifecycle. 
+The Robot Controller simplifies the operation of robotic joints, automatically managing their states through the ros2_controller lifecycle.
 Once activated, the controller ensures that all drives are operational without requiring further user intervention.
 
 **Configuration Parameters**:
@@ -61,4 +61,4 @@ Once activated, the controller ensures that all drives are operational without r
                 - joint1
                 - joint2
             operation_mode: 1  # Operational mode of the controller
-            command_poll_freq: 5  # Frequency (Hz) at which the controller polls for command feedback
+            command_poll_freq: 5  # Frequency (Hz) at which the controller polls for command feedback