From c4e9d1b24d5c71bd89cac985d7bb94a12df18013 Mon Sep 17 00:00:00 2001 From: ipa-vsp Date: Tue, 23 Apr 2024 13:02:28 +0200 Subject: [PATCH] pre-commit --- canopen/sphinx/user-guide/configuration.rst | 2 +- canopen/sphinx/user-guide/operation.rst | 8 +++----- .../operation/managed-service-interface.rst | 14 +++++++------- .../operation/ros2-control-interface.rst | 12 ++++++------ 4 files changed, 17 insertions(+), 19 deletions(-) diff --git a/canopen/sphinx/user-guide/configuration.rst b/canopen/sphinx/user-guide/configuration.rst index 58858da9..9adbaf36 100644 --- 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 index 62f72b31..602c5af9 100644 --- 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 index 7424dc5b..133a8fdd 100644 --- a/canopen/sphinx/user-guide/operation/managed-service-interface.rst +++ b/canopen/sphinx/user-guide/operation/managed-service-interface.rst @@ -3,7 +3,7 @@ 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 @@ -11,20 +11,20 @@ load devices. This container also offers a list service, which can be utilized w 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 index 68ea97cc..d6583e50 100644 --- 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 \ No newline at end of file + command_poll_freq: 5 # Frequency (Hz) at which the controller polls for command feedback