added doc

lbr_bringup/doc/lbr_bringup.rst

@@ -1,38 +1,169 @@
 lbr_bringup
 ===========
-The ``lbr_bringup`` works for the simulation and the real robot. Run:
+The ``lbr_bringup`` package hosts some launch files, which can be included via standard procedures:
+
+.. code:: python
+
+    from launch import LaunchDescription
+    from launch.actions import IncludeLaunchDescription
+    from launch.launch_description_sources import PythonLaunchDescriptionSource
+
+    def generate_launch_description() -> LaunchDescription:
+        ld = LaunchDescription()
+        ld.add_action(
+            IncludeLaunchDescription(
+                PythonLaunchDescriptionSource(
+                    PathJoinSubstitution(
+                        [
+                            FindPackageShare("lbr_bringup"),
+                            "launch",
+                            "mock.launch.py",
+                        ]
+                    )
+                ),
+            )
+        )
+        return ld
+
+The launch files can also be run via the command line, as further described below.
+
+.. contents:: Table of Contents
+   :depth: 2
+   :local:
+   :backlinks: none
+
+Launch Files
+------------
+Launch a Mock Setup
+~~~~~~~~~~
+Useful for running a physics-free simulation of the system. This launch file will (see `mock.launch.py <https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/humble/lbr_bringup/launch/mock.launch.py>`_:octicon:`link-external`):
+
+#. Run the ``robot_state_publisher``
+#. Run the ``ros2_control_node`` with mock components as loaded from ``robot_description``
+#. Load ``ros2_controllers``
 
 .. code:: bash
 
-    ros2 launch lbr_bringup bringup.launch.py \
-        model:=iiwa7 # [iiwa7, iiwa14, med7, med14] \
-        sim:=true # [true, false] \
-        rviz:=true # [true, false] \
-        moveit:=true # [true, false]
+    ros2 launch lbr_bringup mock.launch.py \
+        model:=iiwa7 # [iiwa7, iiwa14, med7, med14]
 
 .. note::
-    For a list of available parameters, call ``ros2 launch lbr_bringup bringup.launch.py -s``.
+    List all arguments for the launch file via ``ros2 launch lbr_bringup mock.launch.py -s``.
 
-When using the real robot, select ``sim:=false`` and
+Launch the Gazebo Simulation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Useful for running a physics simulation the the system. This launch file will will (see `gazebo.launch.py <https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/humble/lbr_bringup/launch/gazebo.launch.py>`_:octicon:`link-external`):
 
-.. dropdown:: Launch the ``LBRServer`` application on the ``KUKA smartPAD``
+#. Start the ``robot_state_publisher``
+#. Start the ``Gazebo`` simulation
+#. Spawn the selected robot model (includes the ``ros2_control_node`` within the ``Gazebo`` plugin)
+#. Load ``ros2_controllers``
 
-    .. thumbnail:: ../../lbr_demos/doc/img/applications_lbr_server.png
+.. code:: bash
 
-Select
+    ros2 launch lbr_bringup gazebo.launch.py \
+        model:=iiwa7 # [iiwa7, iiwa14, med7, med14]
 
-- ``FRI send period``: ``10 ms``
-- ``IP address``: ``your configuration``
-- ``FRI control mode``: ``POSITION_CONTROL`` or ``JOINT_IMPEDANCE_CONTROL`` (will put the robot into a compliant mode)
-- ``FRI client command mode``: ``POSITION``
+.. note::
+    List all arguments for the launch file via ``ros2 launch lbr_bringup gazebo.launch.py -s``.
 
-Users may also refer to :ref:`Software Architecture` for a better understanding of the underlying ``lbr_fri_ros2`` package.
+Launch Hardware
+~~~~~~~~~~~~~~~
+.. warning::
+    Do always execute in ``T1`` mode first.
 
 .. note::
-    For the real robot, make sure you have followed :doc:`Hardware Setup <../../lbr_fri_ros2_stack/doc/hardware_setup>` first.
+    Make sure you have followed :doc:`Hardware Setup <../../lbr_fri_ros2_stack/doc/hardware_setup>` first.
 
-.. warning::
-    On the real robot, do always execute in ``T1`` mode first.
+#. Client side configurations:
+
+    .. dropdown:: Launch the ``LBRServer`` application on the ``KUKA smartPAD``
+
+        .. thumbnail:: ../../lbr_demos/doc/img/applications_lbr_server.png
+
+    Select
+
+    - ``FRI send period``: ``10 ms``
+    - ``IP address``: ``your configuration``
+    - ``FRI control mode``: ``POSITION_CONTROL`` or ``JOINT_IMPEDANCE_CONTROL``
+    - ``FRI client command mode``: ``POSITION``
+
+#. Launch file:
+
+    This launch file will (see `hardware.launch.py <https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/humble/lbr_bringup/launch/hardware.launch.py>`_:octicon:`link-external`):
+
+    #. Run the ``robot_state_publisher``
+    #. Run the ``ros2_control_node`` with the ``lbr_fri_ros2::SystemInterface`` plugin from :doc:`lbr_ros2_control <../../lbr_ros2_control/doc/lbr_ros2_control>` as loaded from ``robot_description`` (which will attempt to establish a connection to the real robot).
+    #. Load ``ros2_controllers``
+
+    .. code:: bash
+
+        ros2 launch lbr_bringup hardware.launch.py \
+            model:=iiwa7 # [iiwa7, iiwa14, med7, med14]
+
+    .. note::
+        List all arguments for the launch file via ``ros2 launch lbr_bringup hardware.launch.py -s``.
+
+Launch RViz
+~~~~~~~~~~~
+This launch file will spin up ``RViz`` for visualization. It will (see `rviz.launch.py <https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/humble/lbr_bringup/launch/rviz.launch.py>`_:octicon:`link-external`):
+
+#. Read ``RViz`` configurations.
+#. Run ``RViz``.
+
+.. code:: bash
+
+    ros2 launch lbr_bringup rviz.launch.py \
+            rviz_config_pkg:=lbr_bringup \
+            rviz_config:=config/mock.rviz # [gazebo.rviz, hardware.rviz, mock.rviz]
+
+.. note::
+    List all arguments for the launch file via ``ros2 launch lbr_bringup rviz.launch.py -s``.
+
+.. note::
+    Requires the user to run :ref:`Launch a Mock Setup`, :ref:`Launch the Gazebo Simulation` or :ref:`Launch Hardware` first.
+
+Launch MoveIt
+~~~~~~~~~~~~~
+Please note that MoveIt configurations are specific and you as a user will need to create your own for your system (potentially containing multiple robots or an end-effector).
+
+.. code:: bash
+
+    ros2 launch lbr_bringup move_group.launch.py \
+        model:=iiwa7 \
+        mode:=mock \
+        rviz:=true
+
+.. note::
+    Requires the user to run :ref:`Launch a Mock Setup`, :ref:`Launch the Gazebo Simulation` or :ref:`Launch Hardware` first.
+
+.. note::
+    Runs ``RViz`` with specific MoveIt configurations.
+
+Mixins
+------
+The ``lbr_bringup`` package makes heavy use of mixins. Mixins are simply state-free classes with static methods. They are a convenient way of writing launch files.
+
+The below shows an example of the `rviz.launch.py <https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/humble/lbr_bringup/launch/rviz.launch.py>`_:octicon:`link-external` file:
+
+.. code:: python
+
+    from launch import LaunchDescription
+    from lbr_bringup.rviz import RVizMixin
+
+
+    def generate_launch_description() -> LaunchDescription:
+        ld = LaunchDescription()
+
+        # launch arguments
+        ld.add_action(RVizMixin.arg_rviz_config())
+        ld.add_action(RVizMixin.arg_rviz_config_pkg())
+
+        # rviz
+        ld.add_action(RVizMixin.node_rviz())
+        return ld
+
+Which is quite compact and easy to read.
 
 General Information on the FRI
 ------------------------------

lbr_ros2_control/doc/lbr_ros2_control.rst

@@ -34,18 +34,18 @@ The ``controller_manager::ControllerManager`` has a node, the `controller_manage
 
 Hardware Plugin
 ---------------
-lbr_fri_ros2::SystemInterface
+lbr_ros2_control::SystemInterface
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The ``lbr_fri_ros2::SystemInterface`` plugin implements a ``hardware_interface::SystemInterface`` and utilizes the :ref:`lbr_fri_ros2` package for communication with the robot. Overview :ref:`below <lbr_ros2_control detailed software architecture figure>` (click to expand):
+The ``lbr_ros2_control::SystemInterface`` plugin implements a ``hardware_interface::SystemInterface`` and utilizes the :ref:`lbr_fri_ros2` package for communication with the robot. Overview :ref:`below <lbr_ros2_control detailed software architecture figure>` (click to expand):
 
 .. _lbr_ros2_control detailed software architecture figure:
 .. thumbnail:: img/lbr_ros2_control_detailed_v2.0.0.svg
     :alt: lbr_ros2_control_detailed
 
 - The ``controller_manager::ControllerManager`` loads the correct plugin from the ``<ros2_control>`` tag in the ``robot_description``: `lbr_system_interface.xacro <https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/humble/lbr_ros2_control/config/lbr_system_interface.xacro>`_:octicon:`link-external`
-- FRI relevant parameters are forwarded to the ``lbr_fri_ros2::SystemInterface`` plugin from `lbr_system_paramters.yaml <https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/humble/lbr_ros2_control/config/lbr_system_parameters.yaml>`_:octicon:`link-external`
+- FRI relevant parameters are forwarded to the ``lbr_ros2_control::SystemInterface`` plugin from `lbr_system_paramters.yaml <https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/humble/lbr_ros2_control/config/lbr_system_parameters.yaml>`_:octicon:`link-external`
 
-The ``lbr_fri_ros2::SystemInterface`` is spun with the ``controller_manager`` node at a rate set by the ``update_rate`` parameter. The communication to the robot is run **asynchronously** at a rate set by the robot's sample time.
+The ``lbr_ros2_control::SystemInterface`` is spun with the ``controller_manager`` node at a rate set by the ``update_rate`` parameter. The communication to the robot is run **asynchronously** at a rate set by the robot's sample time.
 
 **Why asynchronously**? KUKA designed the FRI that way, by adhering to this design choice, we can support multiple FRI versions, see :ref:`fri`!