From 211d91e62395d854dcbb32f5cede93eba2291673 Mon Sep 17 00:00:00 2001 From: Sebastian Castro Date: Thu, 11 Jan 2024 05:09:23 -0800 Subject: [PATCH 1/2] Place sentences in separate lines in READMEs (#113). Having long sentences in READMEs makes them harder to change, and also makes processing the diffs harder (among other disadvantages). This commit implements the one-sentence-per-line principle, by placing different sentences in separate lines in the README. --- moveit2/README.md | 6 ++++-- space_robots/README.md | 7 +++++-- spaceros/README.md | 8 +++++--- 3 files changed, 14 insertions(+), 7 deletions(-) diff --git a/moveit2/README.md b/moveit2/README.md index 3e366be..665d620 100644 --- a/moveit2/README.md +++ b/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# diff --git a/space_robots/README.md b/space_robots/README.md index ccf7ce6..2928caa 100644 --- a/space_robots/README.md +++ b/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 diff --git a/spaceros/README.md b/spaceros/README.md index 55066c5..52bfb85 100644 --- a/spaceros/README.md +++ b/spaceros/README.md @@ -19,7 +19,7 @@ The build process defaults to cloning the `ros2.repos` file from [spaceros](http 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 +47,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$ @@ -221,7 +222,8 @@ 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 From 7764129684f7509769bb6068a9db50280fb16c2f Mon Sep 17 00:00:00 2001 From: Ivan Perez Date: Thu, 11 Jan 2024 05:13:11 -0800 Subject: [PATCH 2/2] Place sentences in separate lines in READMEs (#113). Having long sentences in READMEs makes them harder to change, and also makes processing the diffs harder (among other disadvantages). This commit implements the one-sentence-per-line principle, by placing different sentences in separate lines in the README. --- renode_rcc/README.md | 3 ++- spaceros/README.md | 16 +++++++++++----- zynq_rtems/README.md | 9 ++++++--- 3 files changed, 19 insertions(+), 9 deletions(-) diff --git a/renode_rcc/README.md b/renode_rcc/README.md index 27c2c18..6137aaf 100644 --- a/renode_rcc/README.md +++ b/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 diff --git a/spaceros/README.md b/spaceros/README.md index 52bfb85..ad84631 100644 --- a/spaceros/README.md +++ b/spaceros/README.md @@ -15,7 +15,9 @@ 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" @@ -107,7 +109,8 @@ 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 @@ -115,7 +118,8 @@ spaceros-user@d10d85c68f0e:~/spaceros$ colcon test --event-handlers console_dire ## Viewing Test Output - The output from the tests are stored in XUnit XML files, named *\*.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 *\*.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: @@ -181,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" @@ -223,7 +228,8 @@ spaceros-user@d10d85c68f0e:~/spaceros$ colcon test --build-base build_ikos --ins ``` 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: +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 diff --git a/zynq_rtems/README.md b/zynq_rtems/README.md index de8f878..89ed0d9 100644 --- a/zynq_rtems/README.md +++ b/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...