Merge branch 'master' of github.com:UBC-Thunderbots/Software

Author: GrayHoang

.github/CODEOWNERS

@@ -1,2 +1,2 @@
 # These owners will be the default owners for everything in the repo.
-*       @itsarune @williamckha @sauravbanna
+*       @williamckha @sauravbanna @Andrewyx

.github/actions/environment-setup/action.yml

@@ -0,0 +1,17 @@
+name: Environment Setup
+runs:
+  using: "composite"
+  steps:
+    # Remove unused packages in the CI runner to free up disk space
+    # https://github.com/actions/runner-images/issues/2840
+    - name: Free disk space
+      shell: bash
+      run: |
+        sudo rm -rf /usr/share/dotnet
+        sudo rm -rf /usr/local/lib/android
+        sudo rm -rf /opt/ghc
+
+    - name: Run setup_software.sh
+      shell: bash
+      run: |
+        "${GITHUB_WORKSPACE}"/environment_setup/setup_software.sh

.github/workflows/main.yml

@@ -14,72 +14,60 @@ jobs:
   multiplatform-build:
     strategy:
       matrix:
-        platform: [ ubuntu-24.04 ]
+        platform: [ ubuntu-24.04-arm ]
 
     name: Ubuntu Alternate Builds
     runs-on: ${{ matrix.platform }}
     steps:
-      # checks-out the repository under $GITHUB_WORKSPACE
       - uses: actions/checkout@v4
-
-      - name: Environment Setup
-        run: |
-          "${GITHUB_WORKSPACE}"/environment_setup/setup_software.sh
+      - uses: ./.github/actions/environment-setup
 
       - name: Software Build Test
         run: |
           cd src
-          bazel build --show_timestamps --copt=-O3  \
+          bazel build --show_timestamps --copt=-O3 --verbose_failures \
             -- //... -//software:unix_full_system   \
             -//software/simulated_tests/...         \
             -//software/ai/hl/...                   \
             -//software/field_tests/...             \
             -//software/embedded/...                \
-            -//cc_toolchain/...
+            -//toolchains/cc/...
 
       - name: Jetson Nano Build Test
         run: |
           cd src
-          bazel build //software/embedded:thunderloop_main --copt=-O3 --//software/embedded:host_platform=NANO --platforms=//cc_toolchain:robot
+          bazel build //software/embedded:thunderloop_main --copt=-O3 --//software/embedded:host_platform=NANO --platforms=//toolchains/cc:robot
 
       - name: Raspberry Pi Build Test
         run: |
           cd src
-          bazel build //software/embedded:thunderloop_main --copt=-O3 --//software/embedded:host_platform=PI --platforms=//cc_toolchain:robot
+          bazel build //software/embedded:thunderloop_main --copt=-O3 --//software/embedded:host_platform=PI --platforms=//toolchains/cc:robot
 
 
   software-tests:
     name: Software Tests
-    runs-on: ubuntu-22.04
+    runs-on: ubuntu-24.04
     steps:
-      # checks-out the repository under $GITHUB_WORKSPACE
       - uses: actions/checkout@v4
-
-      - name: Environment Setup
-        run: |
-          "${GITHUB_WORKSPACE}"/environment_setup/setup_software.sh
+      - uses: ./.github/actions/environment-setup
 
       - name: Software Test
         run: |
           cd src
-          bazel test --copt=-O3 --show_timestamps       \
+          bazel test --copt=-O3 --show_timestamps --verbose_failures \
             -- //... -//software:unix_full_system \
             -//software/simulated_tests/...  \
             -//software/ai/hl/...            \
             -//software/field_tests/...      \
             -//software/ai/navigator/...     \
-            -//cc_toolchain/...
+            -//toolchains/cc/...
 
   robot-tests:
     name: Robot Software Tests
-    runs-on: ubuntu-22.04
+    runs-on: ubuntu-24.04
     steps:
-      # checks-out the repository under $GITHUB_WORKSPACE
       - uses: actions/checkout@v4
-
-      - name: Environment Setup
-        run: |
-          "${GITHUB_WORKSPACE}"/environment_setup/setup_software.sh
+      - uses: ./.github/actions/environment-setup
 
       - name: Install and start redis server
         run: |
@@ -97,25 +85,21 @@ jobs:
       - name: Jetson Nano Build
         run: |
          cd src
-         bazel build //software/embedded:thunderloop_main --copt=-O3 --//software/embedded:host_platform=NANO --platforms=//cc_toolchain:robot
+         bazel build //software/embedded:thunderloop_main --copt=-O3 --//software/embedded:host_platform=NANO --platforms=//toolchains/cc:robot
 
 
       - name: Raspberry Pi Build
         run: |
          cd src
-         bazel build //software/embedded:thunderloop_main --copt=-O3 --//software/embedded:host_platform=PI --platforms=//cc_toolchain:robot
+         bazel build //software/embedded:thunderloop_main --copt=-O3 --//software/embedded:host_platform=PI --platforms=//toolchains/cc:robot
 
 
   simulated-gameplay-tests:
     name: Simulated Gameplay Tests
-    runs-on: ubuntu-22.04
+    runs-on: ubuntu-24.04
     steps:
-      # checks-out the repository under $GITHUB_WORKSPACE
       - uses: actions/checkout@v4
-        
-      - name: Environment Setup
-        run: |
-          "${GITHUB_WORKSPACE}"/environment_setup/setup_software.sh
+      - uses: ./.github/actions/environment-setup
 
       - name: Simulated Test Run
         run: |
@@ -146,14 +130,10 @@ jobs:
 
   autorefd-game:
     name: AutoRef'd Game (3 Minutes)
-    runs-on: ubuntu-22.04
+    runs-on: ubuntu-24.04
     steps:
-      # checks-out the repository under $GITHUB_WORKSPACE
       - uses: actions/checkout@v4
-
-      - name: Environment Setup
-        run: |
-          "${GITHUB_WORKSPACE}"/environment_setup/setup_software.sh
+      - uses: ./.github/actions/environment-setup
 
       - name: AI vs AI (3 minutes)
         run: |

.github/workflows/pre-commit.yml

@@ -14,15 +14,11 @@ concurrency:
 jobs:
   formatting-check:
     name: Formatting and FSM diagram generation with pre-commit-ci-lite
-    runs-on: ubuntu-22.04
+    runs-on: ubuntu-24.04
     if: github.event.pull_request.draft == false
     steps:
-      # checks-out the repository under $GITHUB_WORKSPACE
       - uses: actions/checkout@v4
-
-      - name: Environment Setup
-        run: |
-          "${GITHUB_WORKSPACE}"/environment_setup/setup_software.sh
+      - uses: ./.github/actions/environment-setup
 
       - name: Install pip
         run: curl -sS https://bootstrap.pypa.io/get-pip.py | python

docs/code-style-guide.md

@@ -44,7 +44,7 @@ If you want to know more about our coding style you can take a look at our [clan
 * All variable names are `lowercase_with_underscores`
   ```cpp
   // Incorrect
-  float calculatedDistnace;
+  float calculatedDistance;
 
   // Correct
   float calculated_distance;
@@ -179,7 +179,7 @@ If you think some ASCII art will help explain something better, go for it! [asci
 
 ### Includes
 
-* Use `#include` sparingly and only include the necessary sources to build the file. Do not include headers whos class or implementation is not used.
+* Use `#include` sparingly and only include the necessary sources to build the file. Do not include headers whose class or implementation is not used.
 * Often `.cpp` files include its corresponding header `.h` file, it means the `.cpp` file include everything included in the header. Do not have duplicate `#include`'s in both `.h` and `.cpp` files.
 * `#include`s are generally preferred written on the `.cpp` side; use minimum `#include` in the header file. Use _forward declarations_ in headers if necessary.
 * Specify full path of the include file on the file system, relative to the top-level project directory or _WORKSPACE_ file. Do not use relative paths.
@@ -273,22 +273,6 @@ private functions for a class/file that should not be exposed to users. impl can
   // Correct
   using PointsArray = std::vector<std::pair<int, int>>;
   ```
-* Avoid initializing multiple variables on the same line.
-  ```cpp
-  // Incorrect
-  int x, y, z = 0;
-
-  // Correct
-  int x;
-  int y;
-  int z = 0;
-
-  // However, the author may have intended the following
-  // or a code reader may have assumed the following
-  int x = 0;
-  int y = 0;
-  int z = 0;
-  ```  
 * Avoid ternary operators. Clarity is more important than line count.
   ```cpp
   // Incorrect

docs/coroutine_test_examples.cpp

@@ -505,7 +505,7 @@ int main(int argc, char** argv)
     //
     // The move constructor / assgnment is allowed.
     //
-    // We can verify this with the code below, or by lookinAg at pull_coroutine.hpp
+    // We can verify this with the code below, or by looking at pull_coroutine.hpp
     // https://www.boost.org/doc/libs/1_74_0/libs/coroutine2/doc/html/coroutine2/coroutine/asymmetric/pull_coro.html
 
     auto data = std::make_shared<int>(99);

docs/getting-started.md

@@ -357,15 +357,17 @@ Tracy also samples call stacks. If the profiled binary is run with root permissi
 
 ## Building for the robot
 
-To build for the robot computer, build the target with the `--platforms=//cc_toolchain:robot` flag and the toolchain will automatically build using the ARM toolchain. For example, `bazel build --platforms=//cc_toolchain:robot //software/geom/...`.
+To build for the robot computer, build the target with the `--platforms=//toolchains/cc:robot` flag and the toolchain will automatically build using the ARM toolchain. For example, `bazel build --platforms=//toolchains/cc:robot //software/geom/...`.
 
 ## Deploying Robot Software to the robot
 
 We use Ansible to automatically update software running on the robot. [More info here.](useful-robot-commands.md#flashing-the-robots-compute-module) 
 
 To update binaries on a working robot, you can run:
 
-`bazel run //software/embedded/ansible:run_ansible --platforms=//cc_toolchain:robot --//software/embedded:host_platform=<platform> -- --playbook deploy_robot_software.yml --hosts <robot_ip> --ssh_pass <robot_password>`
+```bash
+bazel run //software/embedded/ansible:run_ansible --platforms=//toolchains/cc:robot --//software/embedded:host_platform=<platform> -- --playbook deploy_robot_software.yml --hosts <robot_ip> --ssh_pass <robot_password>
+```
 
 Where `<platform>` is the robot platform you are deploying to (`PI` or `NANO`), and `<robot_ip>` is the IP address of the robot you are deploying to. The `robot_password` is the password used to login to the `robot` user on the robot.
 
@@ -388,7 +390,7 @@ It is possible to run Thunderloop without having a fully-working robot. Using th
 
 2. If you have a robot PC that doesn't have proper communication with the power or motor board, you can still run Thunderloop in a limited capacity to test software features (eg. networking).
     1. First, build the Thunderloop binary:
-        - `bazel build //software/embedded:thunderloop_main --//software/embedded:host_platform=LIMITED --platforms=//cc_toolchain:robot`
+        - `bazel build //software/embedded:thunderloop_main --//software/embedded:host_platform=LIMITED --platforms=//toolchains/cc:robot`
     2. Find the `<robot_ip>` of the robot you want to run Thunderloop on. This guide may help you find the IP address of the robot: [Useful Robot Commands](useful-robot-commands.md#Wifi-Disclaimer).
     3. Copy the binary to the robot:
         - `scp bazel-bin/software/embedded/thunderloop_main robot@<robot_ip>:/home/robot/thunderloop_main`

docs/images/high_level_architecture.svg

@@ -26,7 +26,7 @@
 
 For a more detailed look at how Ansible works, [see the RFC](https://docs.google.com/document/d/1hN3Us2Vjr8z6ihqUVp_3L7rrjKc-EZ-l2hZJc31gNOc/edit)
 
-Example command: `bazel run //software/embedded/ansible:run_ansible --platforms=//cc_toolchain:robot --//software/embedded:host_platform=<platform> -- --playbook deploy_robot_software.yml --hosts <robot_ip> --ssh_pass <robot_password>`
+Example command: `bazel run //software/embedded/ansible:run_ansible --platforms=//toolchains/cc:robot --//software/embedded:host_platform=<platform> -- --playbook deploy_robot_software.yml --hosts <robot_ip> --ssh_pass <robot_password>`
 * <platform>: `PI` or `NANO` depending on the computer on the robot
 * <robot_ip>: IP address of the robot
 * <robot_password>: Password of the robot

docs/robot-software-architecture.md

@@ -78,7 +78,9 @@
 
 # Architecture Overview
 
-At a high-level, our system is split into several independent processes that [communicate with each other](#inter-process-communication). Our architecture is designed in this manner to promote decoupling of different features, making our system easier to expand, maintain, and test.
+![High-Level Architecture Diagram](images/high_level_architecture.svg)
+
+At a high-level, our system is split into several independent processes that [communicate with each other](#inter-process-communication). Our architecture is designed in this manner to promote decoupling of different features, making our software easier to expand, maintain, and test.
 
 - [**Fullsystem**](#fullsystem) is the program that processes data and makes decisions for a [team](#team) of [robots](#robot). It manages [**Sensor Fusion**](#sensor-fusion), which is responsible for processing and filtering raw data, and the [**AI**](#ai) that makes gameplay decisions.
 
@@ -519,7 +521,7 @@ Once it is time to start the pass, the condition for the loop will become false
 Once we have entered the second stage, we know we don't have to look at the first stage again. Because the coroutine "remembers" where the execution is each time the function is called, we will resume inside the second stage and therefore never execute the first stage again! This makes it much easier to write and read this strategy code, because we can clearly see the 2 stages of the strategy, and we know they will be executed in order.
 
 ### Coroutine Best Practices
-Coroutines are a complex feature, and the boost coroutines we use don't always behave in was we expect. We have done extensive testing on how coroutines are safe (or not safe) to us, and derived some best practices from these examples. See [coroutine_test_exmaples.cpp](coroutine_test_examples.cpp) for the full code and more detailed explanantions.
+Coroutines are a complex feature, and the boost coroutines we use don't always behave in was we expect. We have done extensive testing on how coroutines are safe (or not safe) to us, and derived some best practices from these examples. See [coroutine_test_examples.cpp](coroutine_test_examples.cpp) for the full code and more detailed explanantions.
 
 To summarize, the best practices are as follows:
 1. Avoid moving coroutines. If the absolutely must be moved, make sure they are not moved between the stack and heap.
@@ -550,7 +552,7 @@ Trajectories are generated by sampling intermediate *sub-destinations* around th
 
 # Thunderscope
 
-**Thunderscope** chiefly refers to the [GUI application](#thunderscope-gui) we use to visualize and interact with our robots and software. Some non-UI related functionality (namely, Robot Communication) is implemented as part of Thunderscope since it acts as a central point in our architecture, making it convenient for coordinating activities between different modules.
+**Thunderscope** refers to the [GUI application](#thunderscope-gui) we use to visualize and interact with our robots and software. Some non-UI related functionality (namely, Robot Communication) is implemented as part of Thunderscope since it acts as a central point in our architecture, making it convenient for coordinating activities between different modules.
 
 [`thunderscope_main.py`](/src/software/thunderscope/thunderscope_main.py) serves as the main entry point ("launcher") for our entire system. You can run the script to start up the [Thunderscope GUI](#thunderscope-gui) and a number of other optional processes, such as a [Fullsystem](#fullsystem) for each [AI](#ai) team, the [Simulator](#simulator), and [SSL Gamecontroller](#ssl-gamecontroller).
 
@@ -617,7 +619,7 @@ Our simulator is what we use for physics simulation to do testing when we don't
 * [SSL-Vision](#ssl-vision) by publishing new vision data
 * the robots by accepting new [Primitives](#primitives)
 
-Using the current state of the simulated world, the simulator simulates the new [Primitives](#primitives) over some time step and publishes new SSL vision data based on the updated simulated world. Since the simulator interfaces with the our software over the network, it is essentially indistinguishible from robots receiving [Primitives](#primitives) and an [SSL-Vision](#ssl-vision) client publishing data over the network.
+Using the current state of the simulated world, the simulator simulates the new [Primitives](#primitives) over some time step and publishes new SSL vision data based on the updated simulated world. Since the simulator interfaces with the our software over the network, it is essentially indistinguishable from robots receiving [Primitives](#primitives) and an [SSL-Vision](#ssl-vision) client publishing data over the network.
 
 The simulation can also be configured with "realism" parameters that control the amount of noise added to vision detections, simulate missed vision detections and packet loss, and add artificial vision/processing delay, all with some degree of randomness. 
 
@@ -650,7 +652,7 @@ A `Validation Function` comes in two types:
 2. Non-terminating: Some condition that must be met for the entire duration of the test, i.e. "for all time". (*Eg. The ball never leaves the field or all friendly robots follows SSL rules*).
 
 Benefits of `Validation Functions`:
-1. They are reuseable. We can write a function that validates the ball never leaves the field, and use it for multiple tests.
+1. They are reusable. We can write a function that validates the ball never leaves the field, and use it for multiple tests.
 2. They can represent assertions for more complex behaviour. For example, we can build up simpler `Validation Functions` until we have a single `Validation` function for a specific [Tactic](#tactics).
 3. They let us validate independent sequences of behaviour. For example, we create a different `ValidationFunction` for each [Robot](#robot) in the test. This makes it easy to validate each [Robot](#robot) is doing the right thing, regardless if they are dependent or independent actions.