MDv6 Ansible Flashing

.github/workflows/main.yml

@@ -39,6 +39,22 @@ jobs:
           cd src
           bazel build //software/embedded:thunderloop_main --copt=-O3 --platforms=//toolchains/cc:robot
 
+      - name: Motor Firmware build Test
+        run: |
+          cd src
+          bazel build @mdv6_firmware//:mdv6_firmware_main --platforms=//toolchains/cc:motor_board
+
+  motor-firmware:
+    name: Motor Firmware
+    runs-on: ubuntu-24.04
+    steps:
+      - uses: actions/checkout@v4
+      - uses: ./.github/actions/environment-setup
+
+      - name: Build Motor Firmware
+        run: |
+          cd src
+          bazel build @mdv6_firmware//:mdv6_firmware_main --platforms=//toolchains/cc:motor_board
 
   software-tests:
     name: Software Tests
@@ -90,7 +106,7 @@ jobs:
             //software/simulated_tests/...    \
             //software/ai/hl/...              \
             //software/ai/navigator/...       
-            
+
       - name: Upload simulated test proto logs
         # Ensure that simulated test logs get uploaded
         if: always()

docs/setup-pi.md

@@ -10,9 +10,11 @@ The Raspberry Pi 5 is compatible with many different (primarily Linux-based) ope
 
 ### Install OS Using Raspberry Pi Imager
 
-To install the Raspberry Pi OS onto a microSD card, we use the Raspberry Pi Imager program. Install it [here](https://www.raspberrypi.com/software/). 
+To install the Raspberry Pi OS onto a microSD card, we use the Raspberry Pi Imager program. Install it [here](https://www.raspberrypi.com/software/).
 
-*Note: if using the "Download for Linux" option, you will have to right click on the installed `.AppImage` file and select `Properties` → `Permissions` → `Allow Executing File as Program` (this may appear as a checkbox)
+*Note 1: If on Linux, download the app image through `Download for Linux (x86_64)`. Using `sudo apt install rpi-imager` installs an older version of the program, which does not properly apply OS customization required in later steps. 
+
+*Note 2: if using the "Download for Linux" option, you will have to right click on the installed `.AppImage` file and select `Properties` → `Permissions` → `Allow Executing File as Program` (this may appear as a checkbox)
 
 When you open the imager, you should see something like this:
 

docs/software-architecture-and-design.md

@@ -5,16 +5,6 @@
 <!--TOC-->
 
 - [Table of Contents](#table-of-contents)
-- [Architecture Overview](#architecture-overview)
-  - [League-Maintained Software](#league-maintained-software)
-    - [SSL Vision](#ssl-vision)
-    - [SSL Gamecontroller](#ssl-gamecontroller)
-- [Protobuf](#protobuf)
-  - [Important Protobuf Messages](#important-protobuf-messages)
-    - [Primitives](#primitives)
-    - [Robot Status](#robot-status)
-- [Conventions](#conventions)
-  - [Coordinates](#coordinates)
   - [Angles](#angles)
   - [Convention Diagram](#convention-diagram)
 - [Fullsystem](#fullsystem)
@@ -71,74 +61,6 @@
 
 <!--TOC-->
 
-# Architecture Overview
-
-![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.
-
-- [**Thunderscope**](#thunderscope) is an application that provides a GUI for visualizing and interacting with our software.
-
-- The [**Simulator**](#simulator) provides a physics simulation of the world (robots, ball, and field), enabling testing of our gameplay when we don't have access to a real field. This process is optional and used only for development and testing purposes; in a real match, our system will receive data from [SSL-Vision](#ssl-vision).
-
-- [**Thunderloop**](/docs/robot-software-architecture.md#thunderloop) is the software that runs onboard our robots. It is responsible for coordinating communication between our [AI](#ai) computer and the motor and power boards in our robots. It is part our robot software architecture, which is documented [here](/docs/robot-software-architecture.md).
-
-## League-Maintained Software
-
-Our software is designed to interact with the following software developed and maintained by the RoboCup Small Size League:
-
-### SSL Vision
-* This is the shared vision system used by the Small Size League. It is what connects to the cameras above the field, does the vision processing, and transmits the positional data of everything on the field to our [AI](#ai) computers.
-* The GitHub repository can be found [here](https://github.com/RoboCup-SSL/ssl-vision)
-
-### SSL Gamecontroller
-* Sometimes referred to as the "Referee", this is another shared piece of Small Size League software that is used to send gamecontroller and referee commands to the teams. A human and/or [computer auto-referee](#https://ssl.robocup.org/league-software/#auto-referees) controls this application during the games to send the appropriate commands to the robots. For example, some of these commands are what stage the gameplay is in, such as `HALT`, `STOP`, `READY`, or `PLAY`.
-* The GitHub repository can be found [here](https://github.com/RoboCup-SSL/ssl-game-controller)
-
-# Protobuf
-[Protobufs or protocol buffers](https://protobuf.dev/) are used to pass messages between components in our system.
-After building using Bazel, the `.proto` files are generated into `.pb.h` and `.pb.cc` files, which are found in `bazel-out/k8-fastbuild/bin/proto`.
-To include these files in our code, we simply include `proto/<protobuf_filename>.pb.h`.
-
-## Important Protobuf Messages
-These are [protobuf](https://developers.google.com/protocol-buffers/docs/cpptutorial) messages that we define and that are important for understanding how the [AI](#ai) works.
-
-### Primitives
-
-**Primitives** represent the low-level actions that a robot can execute. They are sent to the robots and can be "blindly" executed without knowledge of the [World](#world) and/or the high-level gameplay [strategy](#strategy). Primitives are understood directly by our robot software, which will translate the primitive into motor and power board inputs to make the robot move, dribble, kick, and/or chip as instructed.
-
-Each Primitive is a C++ class that generates an associated `TbotsProto::Primitive` protobuf message that can be sent to the robots.
-
-Primitives act as the abstraction between our [AI](#ai) and our robot software. It splits the responsibility such that the [AI](#ai) is responsible for sending a Primitive to a robot telling it what it wants it to do, and the robot is responsible for making sure it does what it's told.
-
-### Robot Status
-The `TbotsProto::RobotStatus` protobuf message contains information about the status of a single robot. Examples of the information they include are:
-* Robot battery voltage
-* Whether or not the robot senses the ball in the breakbeam
-* The capacitor charge on the robot
-* The temperature of the dribbler motor
-
-Information about the robot status is communicated and stored as `RobotStatus` protobuf messages. [Thunderscope](#thunderscope) displays warnings from incoming `RobotStatus` messages so we can take appropriate action. For example, during a game we may get a "low battery warning" for a certain robot, so we know to substitute it and replace the battery before it dies on the field.
-
-
-# Conventions
-
-Below documents various conventions we use and follow in our software.
-
-## Coordinates
-We use a slightly custom coordinate convention to make it easier to write our code in a consistent and understandable way. This is particularly important for any code handling gameplay logic and positions on the field.
-
-The coordinate system is a simple 2D x-y plane. The x-dimension runs between the friendly and enemy goals, along the longer dimension of the field. The y-dimension runs perpendicular to the x-dimension, along the short dimension of the field.
-
-Because we have to be able to play on either side of a field during a game, this means the "friendly half of the field" will not always be in the positive or negative x part of the coordinate plane. This inconsistency is a problem when we want to specify points like "the friendly net", or "the enemy corner". We can't simple say the friendly net is `(-4.5, 0)` all the time, because this would not be the case if we were defending the other side of the field where the friendly net would be `(4.5, 0)`.
-
-In order to overcome this, our convention is that:
-* The **friendly half** of the field is **always negative x**, and the **enemy half** of the field is **always positive x**
-* `y` is positive to the "left" of someone looking at the enemy goal from the friendly goal
-* The center of the field (inside the center-circle) is the origin / `(0, 0)`
-
 This is easiest to understand in the [diagram](#convention-diagram) below.
 
 Based on what side we are defending, [Sensor Fusion](#sensor-fusion) will transform all the coordinates of incoming data so that it will match our convention. This means that from the perspective of the rest of the system, the friendly half of the field is always negative x and the enemy half is always positive x. Now when we want to tell a robot to move to the friendly goal, we can simply tell it so move to `(-4.5, 0)` and we know this will _always_ be the friendly side. All of our code is written with the assumption in mind.

environment_setup/setup_software.sh

@@ -201,4 +201,8 @@ print_status_msg "Set up ansible-lint"
 /opt/tbotspython/bin/ansible-galaxy collection install ansible.posix
 print_status_msg "Finished setting up ansible-lint"
 
+print_status_msg "Setting up STM32 cross-compiler"
+install_stm32_cross_compiler $g_arch
+print_status_msg "Done setting up STM32 cross-compiler"
+
 print_status_msg "Done Software Setup, please reboot for changes to take place"

environment_setup/util.sh

@@ -121,6 +121,19 @@ install_python_dev_cross_compile_headers() {
     rm -rf /tmp/tbots_download_cache/python-3.12.0.tar.xz
 }
 
+install_stm32_cross_compiler() {
+    arch="aarch64"
+    if is_x86 $1; then
+        arch="x86_64"
+    fi
+    download_link=https://developer.arm.com/-/media/Files/downloads/gnu/14.3.rel1/binrel/arm-gnu-toolchain-14.3.rel1-${arch}-arm-none-eabi.tar.xz
+
+    wget -N $download_link -O /tmp/tbots_download_cache/arm-gnu-toolchain.tar.xz
+    tar -xf /tmp/tbots_download_cache/arm-gnu-toolchain.tar.xz -C /tmp/tbots_download_cache/
+    sudo mv /tmp/tbots_download_cache/arm-gnu-toolchain-14.3.rel1-${arch}-arm-none-eabi /opt/tbotspython/arm-none-eabi-gcc
+    rm /tmp/tbots_download_cache/arm-gnu-toolchain.tar.xz
+}
+
 install_python_toolchain_headers() {
   sudo mkdir -p /opt/tbotspython/py_headers/include/
   sudo ln -sfn "$(python3.12-config --includes | awk '{for(i=1;i<=NF;++i) if ($i ~ /^-I/) print substr($i, 3)}' | head -n1)" /opt/tbotspython/py_headers/include/

src/MODULE.bazel

@@ -193,6 +193,17 @@ http_archive(
     url = "https://github.com/saebyn/munkres-cpp/archive/61086fcf5b3a8ad4bda578cdc2d1dca57b548786.tar.gz",
 )
 
+# For flashing the motor driver board
+http_archive(
+    name = "bazel_embedded",
+    sha256 = "91a78efbb0f94479fe9ca2912aced712be9e7028325bada9a73e7d325427b404",
+    strip_prefix = "bazel-embedded-cf5b240d510313b3383e0cdb550eb9f32be7244e",
+    url = "https://github.com/bazelembedded/bazel-embedded/archive/cf5b240d510313b3383e0cdb550eb9f32be7244e.zip",
+)
+
+openocd = use_extension("//starlark/firmware:open_ocd.bzl", "openocd_extension")
+use_repo(openocd, "com_openocd")
+
 http_archive(
     name = "LTC4151",
     build_file = "@//extlibs:LTC4151.BUILD",
@@ -201,6 +212,24 @@ http_archive(
     url = "https://github.com/kerrydwong/LTC4151/archive/729952f10bcdcf359877b6f728565c17a8f17423.tar.gz",
 )
 
+# TODO: Perhaps set this to pull latest
+#http_archive(
+#    name = "mdv6_firmware",
+#    build_file = "@//extlibs:mdv6_firmware.bzl",
+#    sha256 = "8054aca4ae3543e39d3587c58aa5904917d9b268922564f6ca3acf4b59bd8fe8",
+#    strip_prefix = "MDv6_Firmware-81627d25b5f147c0b5b3f8ceb2c22c883625a3d1",
+#    url = "https://github.com/UBC-Thunderbots/MDv6_Firmware/archive/81627d25b5f147c0b5b3f8ceb2c22c883625a3d1.tar.gz",
+#)
+
+git_repository = use_repo_rule("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
+
+git_repository(
+    name = "mdv6_firmware",
+    branch = "master",
+    build_file = "@//extlibs:mdv6_firmware.bzl",
+    remote = "https://github.com/UBC-Thunderbots/MDv6_Firmware.git",
+)
+
 http_archive(
     name = "trinamic",
     build_file = "@//extlibs:trinamic.BUILD",
@@ -224,6 +253,7 @@ register_toolchains(
     "//toolchains/cc:cc_toolchain_for_k8_aarch64_linux",
     "//toolchains/cc:cc_toolchain_for_k8",
     "//toolchains/cc:cc_toolchain_for_aarch64",
+    "//toolchains/cc:cc_toolchain_for_stm32",
 )
 
 ##############################################
@@ -256,6 +286,12 @@ new_local_repository(
     path = "/opt/tbotspython/aarch64-tbots-linux-gnu/",
 )
 
+new_local_repository(
+    name = "motor_board_gcc",
+    build_file = "@//extlibs:motor_board_gcc.BUILD",
+    path = "/opt/tbotspython/arm-none-eabi-gcc/",
+)
+
 new_local_repository(
     name = "py_cc_toolchain_host",
     build_file = "@//extlibs:py_cc_toolchain.BUILD",

src/extlibs/mdv6_firmware.bzl

@@ -0,0 +1,89 @@
+load("@bazel_embedded//tools/openocd:defs.bzl", "openocd_flash")
+
+cc_binary(
+    name = "mdv6_firmware_main",
+    # Linker file informs the toolchain how much RAM and flash you have as well as its locations on the chip
+    additional_linker_inputs = [
+        "STM32CubeIDE/STM32F031C6TX_FLASH.ld",
+    ],
+    linkopts = ["-T $(location STM32CubeIDE/STM32F031C6TX_FLASH.ld)"],
+    target_compatible_with = [
+        "@platforms//cpu:armv6-m",
+        "@platforms//os:none",
+    ],
+    deps = [
+        ":mdv6_firmware",
+    ],
+)
+
+openocd_flash(
+    name = "mdv6_firmware_flash",
+    device_configs = [
+        # Part of the STM32F0 family
+        # https://www.st.com/resource/en/reference_manual/rm0091-stm32f0x1stm32f0x2stm32f0x8-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
+        "target/stm32f0x.cfg",
+    ],
+    # WARNING! `flash_offset` attribute is broken in the Bazel rule. The .elf file (mdv6_firmware_main.stripped)
+    # contains the memory mappings already, so this attribute is necessary.
+    flash_offset = "",
+    # .stripped strips debug symbols to reduce the size of the binary.
+    # see: https://bazel.build/reference/be/c-cpp#cc_binary
+    image = ":mdv6_firmware_main.stripped",
+    interface_configs = [
+        "interface/stlink.cfg",  # The ST-Link V2 programmer is used to flash the firmware.
+    ],
+)
+
+cc_library(
+    name = "mdv6_firmware",
+    srcs = glob([
+        "Core/Src/**/*.c",
+        "Src/**/*.c",
+        "STM32CubeIDE/Application/Startup/*.s",
+        "STM32CubeIDE/Application/User/*.c",
+        "*.c",
+        "Drivers/STM32F0xx_HAL_Driver/Src/*.c",
+    ], exclude = [
+        "Drivers/STM32F0xx_HAL_Driver/Src/*_template.c",
+    ]) + [
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/bus_voltage_sensor.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/circle_limitation.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/digital_output.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/feed_forward_ctrl.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/ntc_temperature_sensor.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/open_loop.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/pid_regulator.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/pqd_motor_power_measurement.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/r_divider_bus_voltage_sensor.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/ramp_ext_mngr.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/revup_ctrl.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/speed_pos_fdbk.c",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Src/virtual_speed_sensor.c",
+    ],
+    hdrs = glob([
+        "Core/Inc/**/*.h",
+        "*.h",
+        "Inc/**/*.h",
+        "Drivers/STM32F0xx_HAL_Driver/Inc/**/*.h",
+        "Drivers/CMSIS/Device/ST/STM32F0xx/Include/**/*.h",
+        "Drivers/CMSIS/Include/**/*.h",
+        "MCSDK_v6.4.1-Full/**/*.h",
+    ]),
+    includes = [
+        "Core/Inc",
+        "Drivers/STM32F0xx_HAL_Driver/Inc",
+        "Drivers/CMSIS/Device/ST/STM32F0xx/Include",
+        "Drivers/CMSIS/Include",
+        "MCSDK_v6.4.1-Full/MotorControl/MCSDK/MCLib/Any/Inc",
+        "Inc",
+    ],
+    defines = [
+        # Our MCU is the STM32F0251: https://www.st.com/resource/en/datasheet/stspin32f0251.pdf
+        "STM32F031x6",
+        # Use the HAL and Low-Layer APIs.
+        "USE_HAL_DRIVER",
+        "USE_FULL_LL_DRIVER",
+        "ARM_MATH_CM0",
+    ],
+    alwayslink = True,
+)

src/extlibs/motor_board_gcc.BUILD

@@ -0,0 +1,9 @@
+package(default_visibility = ["//visibility:public"])
+
+filegroup(
+    name = "includes",
+    srcs = glob([
+        "arm-none-eabi/include",
+        "lib/gcc/arm-none-eabi/14.3.1/include",
+    ]),
+)

src/software/embedded/BUILD

@@ -73,6 +73,11 @@ sh_binary(
     srcs = ["setup_robot_software_deps.sh"],
 )
 
+sh_binary(
+    name = "setup_openocd_deps",
+    srcs = ["setup_openocd_deps.sh"],
+)
+
 filegroup(
     name = "hash_thunderloop_binary",
     srcs = ["hash_thunderloop_binary.sh"],

src/software/embedded/ansible/BUILD

@@ -19,6 +19,7 @@ py_binary(
         ":playbooks",
         ":tasks",
         "//software/embedded:hash_thunderloop_binary.sh",
+        "//software/embedded:setup_openocd_deps",
         "//software/embedded:setup_robot_software_deps",
         "//software/embedded:thunderloop_main",
         "//software/embedded/linux_configs/pi:pi_files",