Merge remote-tracking branch 'origin/dev-readme-splitlines'. Close #113.

moveit2/README.md

@@ -1,6 +1,7 @@
 # MoveIt2 Docker Image
 
-The MoveIt2 Docker image uses the Space ROS docker image (*openrobotics/spaceros:latest*) as its base image. The MoveIt2 Dockerfile installs all of the prerequisite system dependencies to build MoveIt2 (and Moveit2 tutorials) and then pulls and builds the latest MoveIt2 and Moveit2 tutorials source code.
+The MoveIt2 Docker image uses the Space ROS docker image (*openrobotics/spaceros:latest*) as its base image.
+The MoveIt2 Dockerfile installs all of the prerequisite system dependencies to build MoveIt2 (and Moveit2 tutorials) and then pulls and builds the latest MoveIt2 and Moveit2 tutorials source code.
 
 ## Building the MoveIt2 Image
 
@@ -37,7 +38,8 @@ There is a run.sh script provided for convenience that will run the spaceros ima
 ./run.sh
 ```
 
-Upon startup, the container automatically runs the entrypoint.sh script, which sources the MoveIt2 and Space ROS environment files. You'll now be running inside the container and should see a prompt similar to this:
+Upon startup, the container automatically runs the entrypoint.sh script, which sources the MoveIt2 and Space ROS environment files.
+You'll now be running inside the container and should see a prompt similar to this:
 
 ```
 spaceros-user@8e73b41a4e16:~/moveit2#

renode_rcc/README.md

@@ -1,5 +1,6 @@
 # renode-RCC
-Building [RTEMS Cross Compilation System (RCC)](https://www.gaisler.com/index.php/products/operating-systems/rtems), has a different directory structure compare to building RTEMS from source (might not be true). This will run RTEMS on leon3 in a renode simulation.
+Building [RTEMS Cross Compilation System (RCC)](https://www.gaisler.com/index.php/products/operating-systems/rtems), has a different directory structure compare to building RTEMS from source (might not be true).
+This will run RTEMS on leon3 in a renode simulation.
 
 ## Usage
 To run the simulator in docker container

space_robots/README.md

@@ -1,12 +1,15 @@
 # Space ROS Space Robots Demo Docker Image
 
-The Space ROS Space Robots Demo docker image uses the moveit2 docker image (*openrobotics/moveit2:latest*) as its base image. Build instructions for that image can be found at [docker/moveit2/README.md](https://github.com/space-ros/docker/blob/main/moveit2/README.md). The Dockerfile installs all of the prerequisite system dependencies along with the demos source code, then builds the Space ROS Space Robots Demo.
+The Space ROS Space Robots Demo docker image uses the moveit2 docker image (*openrobotics/moveit2:latest*) as its base image.
+Build instructions for that image can be found in [this README](../moveit2/README.md).
+The Dockerfile installs all of the prerequisite system dependencies along with the demos source code, then builds the Space ROS Space Robots Demo.
 
 This is for Curiosity Mars rover and Canadarm demos.
 
 ## Building the Demo Docker
 
-The demo image builds on top of the `spaceros` and `moveit2` images. To build the docker image, first build both required images, then the `space_robots` demo image:
+The demo image builds on top of the `spaceros` and `moveit2` images.
+To build the docker image, first build both required images, then the `space_robots` demo image:
 
 ```bash
 cd docker/spaceros

spaceros/README.md

@@ -15,11 +15,13 @@ To build the image, run:
 
 The build process will take about 20 or 30 minutes, depending on the host computer.
 
-The build process defaults to cloning the `ros2.repos` file from [spaceros](https://github.com/space-ros/space-ros) repository. It looks for a branch with the same name as the current local branch; if it doesn't find one, it falls back to cloning from the main branch. For testing purposes, you can customize both the spaceros repository URL and the branch name by modifying arguments defined in the [Earthfile](./Earthfile).
+The build process defaults to cloning the `ros2.repos` file from [spaceros](https://github.com/space-ros/space-ros) repository.
+It looks for a branch with the same name as the current local branch; if it doesn't find one, it falls back to cloning from the main branch.
+For testing purposes, you can customize both the spaceros repository URL and the branch name by modifying arguments defined in the [Earthfile](./Earthfile).
 Example:
 ```bash
 earthly +image --SPACEROS_REPO_URL="https://github.com/my-org/my-spaceros-fork.git" --SPACEROS_GIT_REF="my-branch-name"
-``` 
+```
 
 ## Running the Space ROS Docker Image in a Container
 
@@ -47,7 +49,8 @@ There is a run.sh script provided for convenience that will run the spaceros ima
 ./run.sh
 ```
 
-Upon startup, the container automatically runs the entrypoint.sh script, which sources the Space ROS environment file (setup.bash). You'll now be running inside the container and should see a prompt similar to this:
+Upon startup, the container automatically runs the entrypoint.sh script, which sources the Space ROS environment file (setup.bash).
+You'll now be running inside the container and should see a prompt similar to this:
 
 ```
 spaceros-user@d10d85c68f0e:~/spaceros$
@@ -106,15 +109,17 @@ spaceros-user@d10d85c68f0e:~/spaceros$ colcon test --ctest-args -LE "(ikos|xfail
 
 The tests include running the static analysis tools clang_tidy and cppcheck (which has the MISRA 2012 add-on enabled).
 
-You can use colcon's `--packages-select` option to run a subset of packages. For example, to run tests only for the rcpputils package and display the output directly to the console (as well as saving it to a log file), you can run:
+You can use colcon's `--packages-select` option to run a subset of packages.
+For example, to run tests only for the rcpputils package and display the output directly to the console (as well as saving it to a log file), you can run:
 
 ```
 spaceros-user@d10d85c68f0e:~/spaceros$ colcon test --event-handlers console_direct+ --packages-select rcpputils
 ```
 
 ## Viewing Test Output
 
- The output from the tests are stored in XUnit XML files, named *\<tool-name\>*.xunit.xml. After running the unit tests, you can scan the build directory for the various *\*.xunit.xml* files.
+ The output from the tests are stored in XUnit XML files, named *\<tool-name\>*.xunit.xml.
+After running the unit tests, you can scan the build directory for the various *\*.xunit.xml* files.
 
  For example, a clang_tidy.xunit.xml file looks like this:
 
@@ -180,7 +185,8 @@ CONTAINER ID   IMAGE                   COMMAND                  CREATED
 d10d85c68f0e   openrobotics/spaceros   "/entrypoint.sh …"   28 minutes ago   Up 28 minutes             inspiring_moser
 ```
 
-The container ID in this case, is *d10d85c68f0e*. So, run the following command in the host terminal:
+The container ID in this case, is *d10d85c68f0e*.
+So, run the following command in the host terminal:
 
 ```bash
 docker exec -it d10d85c68f0e /bin/bash --init-file "install/setup.bash"
@@ -221,7 +227,9 @@ To generate a JUnit XML file for a specific package only, you can add the *--pac
 spaceros-user@d10d85c68f0e:~/spaceros$ colcon test --build-base build_ikos --install-base install_ikos --packages-select rcpputils
 ```
 
-The `colcon test` command runs various tests, including IKOS report generation, which reads the IKOS database generated in the previous analysis step and generates a JUnit XML report file. After running `colcon test`, you can view the JUnit XML files. For example, to view the JUnit XML file for IKOS scan of the rcpputils binaries you can use the following command:
+The `colcon test` command runs various tests, including IKOS report generation, which reads the IKOS database generated in the previous analysis step and generates a JUnit XML report file.
+After running `colcon test`, you can view the JUnit XML files.
+For example, to view the JUnit XML file for IKOS scan of the rcpputils binaries you can use the following command:
 
 ```
 spaceros-user@d10d85c68f0e:~/spaceros$ more build_ikos/rcpputils/test_results/rcpputils/ikos.xunit.xml

zynq_rtems/README.md

@@ -4,7 +4,8 @@
 
 The goal is to create an hard real-time embedded application that runs on a Xilinx Zynq SoC FPGA which will communicate with Space-ROS.
 
-This demonstration will be on [QEMU](https://www.qemu.org), the open-source CPU and system emulator. This is for several reasons:
+This demonstration will be on [QEMU](https://www.qemu.org), the open-source CPU and system emulator.
+This is for several reasons:
  * Development cycles in QEMU are much faster and less painful than hardware.
  * Given the state of the semiconductor industry at time of writing (late 2022), it is nearly impossible to obtain Zynq development boards.
  * QEMU-based work requires no upfront hardware costs or purchasing delays
@@ -58,7 +59,8 @@ cd /path/to/zynq_rtems
 cd hello_zenoh
 ./run_zenoh_router
 ```
-This will print a bunch of startup information and then continue running silently, waiting for inbound Zenoh traffic. Leave this terminal running.
+This will print a bunch of startup information and then continue running silently, waiting for inbound Zenoh traffic.
+Leave this terminal running.
 
 In the second terminal, we'll run the Zenoh subscriber example:
 
@@ -78,7 +80,8 @@ cd hello_zenoh
 ```
 
 The terminal should print a bunch of information about the various emulated Zynq network interfaces and their routing information.
-After that, it should contact the `zenohd` instance running in the other terminal. It should print something like this:
+After that, it should contact the `zenohd` instance running in the other terminal.
+It should print something like this:
 
 ```
 Opening zenoh session...